Cont Eng Methodology

StephanieWalsh–[email protected]

Purpose of CONTINUOUS ENGINEERING REQUIREMENTS METHODOLOGY The objective of this methodology is to lay out the high-level concepts and procedures geared at the most effective usage of Rational Requirements Composer [RRC] for the benefit of any project following a regulatory brief. The methodology will centre on the establishment and management of requirements traceability in the most effective fashion whilst rooting the activity in best practices for business analysis [as laid out by the International Institute of Business Analysis and the British Computer Society] and for Rational software usage [as laid out by IBM]. The methodology is supported by detailed, step-by-step RRC guidance notes which exist as a standalone artefact created and maintained in the tool itself. The V-Model AND CONTINUOUS ENGINEERING For many years, sequential product development across the end-to-end project lifecycle was the go-to method for delivery. Underpinned by the V-model for software development, it centred on two main phases [definition and validation], with several sequential sub-phases that generally started from a business case and analysis plus planning, and proceeded to requirements definition, detailed design, build, test and deployment. [insert image of V-Model here] Each sub-phase in validation traced back to its sub-phase within definition, thus providing a loop of verification that was methodical and sequential. While the overarching premise of this model is still entirely valid, as are the phases of product development, a surge in increased complexity, a desire for greater quality, and a need to deliver products fast has introduced a revision to the model known as continuous engineering. With it, complexity is managed better, reusability of artefacts is expedited, and efficiencies are greatly improved. [insert image of V-Model revised here] The success of the V-model revised, however, is only possible when a requirements management tool is used in conjunction with good analysis practices and standards. For a long time, business analysis was conducted with tools that were not designed for it. Requirements documented in Word or Excel or Visio provide none of the transparency, flexibility, and traceability that are of paramount importance to vast change programmes. The new complexity we currently deal with is part of continuous engineering itself as it puts a twist on the way in which the accepted activities of definition and verification are undertaken. That new spin is now the central iteration that happens in constant loops within the V-model itself. As regulations and compliance become more extensive [while deadlines become more aggressive and are squeezed by greater dependencies], the necessity for a flexible, yet strong, requirements management tool is acutely felt. To this end, the client purchased RRC, but its adoption and roll-out needs to be supported and controlled, as with great flexibility and far-reaching capabilities come resistance, frustration, and confusion. Insofar as one of the crucial activities, traceability, is concerned, a move from hierarchical to interdependent traces can only be spearheaded by a change in culture supported by careful usage of the tool, both of which, in turn, support an understanding of the activity and of why we undertake it.


Traceability: ACTIVITY VS. DELIVERABLE Traceability reveals the record of the process of creating and adapting a business solution by establishing and maintaining relationships between each of the project elements in order to understand the solution. It is an essential activity to any project regardless of domain because: Ø It ensures that the solution is built right; Ø It ensures that we built the right solution; Ø It ensures the coherence of the solution; Ø It supports the management of change and risk; Ø It allows for a precise assessment of change; Ø It proves our contractual obligations have been met; Ø It proves that we meet regulatory compliance as requested. Traceability is rooted in verification of requirements throughout all phases: validated requirements demonstrate that value has been delivered to all stakeholders while being aligned to the business goals and objectives. If a requirement cannot be validated [and before that, traced], it means that it does not benefit the organization or does not fall within the scope of the solution, or indeed both. A non-validated requirement is, in a sense, an impossibility, or oxymoron. If a requirement exists, then so must its validation. Challenges always arise for two reasons: Ø Lack of understanding of what traceability is; and Ø Lack of understanding of the importance of traceability. Very often confusion arises because the term is used both in relation to the activity and as a shortcut to reference a specific deliverable. While the activity to trace is all-encompassing and, as demonstrated by the V-model, carries on beyond the analysis phase all the way to deployment, the output is one, the Requirements Verification Traceability Matrix [known as RVTM]. Analysis best practices recommend both an analysis RVTM and an end-to-end


RVTM whose responsibility within a project or programme is shared by all leads. The former is a sub-section of the latter. It is also best practice to make the lead business analyst responsible for end-to-end traceability because it is from analysis that all requirements originate and that, unless some fall out of scope mid-way, their life should be verified and validated to deployment. This is not a particularly taxiing task provided a project [and, indeed, organization] understands traceability and follows strong requirements management practices. RRC specifically supports this effort by encouraging discipline from composition of requirements to tracing [to and from] them. Retrospective traceability creates an enormous, impractical and time-consuming overhead while defeating the purpose of verification: verification [followed by validation] is an ongoing process that takes place throughout the delivery lifecycle. It must happen continuously because stakeholder, solution and transition requirements must align to the business requirements and therefore be proven to satisfy the design. Any deviation must be rectified as soon as possible because misalignment is time-consuming and incredibly costly to fix. An ongoing verification process exposes misalignments as they occur and prevents the carry-over to subsequent phases. Here, it is of paramount importance that traceability as an activity is deeply understood and that the RVTM becomes part of ‘business as usual’ and not a retrospective exercise of little value [but huge overhead]. RRC uptake will support both efforts. HIERARCHICAL AND INTERDEPENDENT TRACEABILITY If no requirements management tool exists within an organization, the RVTM is provided as an Excel sheet. However, Excel is nothing other than a glorified table and can only capture hierarchical traceability, that is, the parent/child [or high-level / low-level] relationships that many requirements are made to adhere to. [insert sample RVTM in Excel] In many cases, however, requirements cannot [and should not] be organized merely in a tiered fashion. The different planning approaches which exist, for example, in Agile, favour requirements that are flexibly related to others. Similarly, any large IT project will include requirement types that are more complex and vast than mere functional or non-functional needs. For example, the relationships that govern interface specifications, validation rules, business rules, data mapping, user stories, and epics are only partly hierarchical but entirely interdependent. A regulatory project is likely to map from regulation to high-level requirements, but also to group project documents, implementation evidence and user acceptance tests that overlap both business and IT functions. RRC provides a multitude of ways to capture these complex, interdependent relationships, in ways which satisfy the needs of different consumers of this information, from analysts and managers, to architects, testers and coders. [insert sample RVTM view in RRC] [insert sample RVTM walker layout in RRC] [insert sample RVTM radial layout in RRC] With the introduction of RRC, the client will transition from manual, retrospective traceability, to an ongoing, live activity which will provide the RVTM in RRC in a variety of views as desired. As RRC is a collaborative, web-based tool, the RVTM will always be available in real time and will be accessible as a Shared View. Additionally, complementary


views will be created so to facilitate the exposure of gaps in traceability across the piece. RRC USAGE within the Fabulous Programme The roll-out of RRC will be spearheaded by the Fabulous Programme. To start with, the programme will begin to transition to RRC through a controlled plan of adoption that will start in-flight. In step one, regulation to requirement, the relevant regulations will be imported into RRC, the relevant requirements will also transition to RRC, and the traceability between the two will be established with the close support of the central traceability team. In time, the team will help the programme establish a process that will ensure the verification and validation of the requirements beyond step one, across to additional documents, implementation and, finally, user acceptance testing. While the central team will lead and support the adoption of the tool, the strong recommendation to the programmes will be to transition analysis from untraceable documentation maintained in Word and Excel, to working in RRC itself as it was conceived: it is a requirements composer and as such supports all requirements management activities, from the creation of artefacts [both for business and IT projects], to the tracing, verifying and validating of them, from auditing and reviewing, to supporting all project methodologies thanks to flexible configuration. Specifically, RRC will directly support the core activities and principles that ensure the traceability effort is appropriately conducted and becomes part of the organisation: Ø Plan and document [process and requirements] Ø Adopt consistency [central traceability team to guide and direct as per RRC guidance notes] Ø Usage of unique identifiers [configured in RRC] Ø Ownership [programmes supported by the central traceability team] Ø Centralisation [requirements in RRC for all to collaborate on] Ø Education of users [relevant RRC labs conducted with all new users to instruct, direct and advise] Ø Iteration and repetition [optimize the process and utilize it consistently] Ø Communication of changes [directly achieved by using RRC, via invitations to review and/or extraction of data from RRC] Lastly, throughout the adoption effort it will be necessary to use consistent and accurate terminology when introducing RRC to the users. While traceability is one high-profile capability, RRC is not merely ‘a traceability tool’ but a requirements management tool which supports the creation and maintenance of traceability. To refer to it as ‘a traceability


tool’ will suggest to the uninitiated that all work conducted in it merely transfers an exercise in retrospective tracing from Excel to RRC. In reality, the introduction of the first step in the usage methodology is expected to highlight the efficiency gains that users will experience when they will be confident enough to transpose their analysis activities from Word and Excel to RRC. Accurate terminology will be of paramount importance throughout all support sessions with the analysts so that they immediately become disciplined users of the tool and understand it appropriately. For example, in RRC terms, import, upload, insert, copy, duplicate, reuse, create must not be used interchangeably as they do not yield the same results, neither are they appropriate for all documents to transition to RRC. Similarly, not all links in RRC are traceability links as some are merely hyperlinks [internal or external]. [……..]

Cont Eng Methodology

Documents

Transcript of Cont Eng Methodology