1. Managing complexity in large development programmes Presenter: Dr Steve Rivkin, Acando UK University of Manchester 11 October 2012

2. Topics to be Covered Common problems Requirements management
Requirements-driven Design
Project Support processes
Benefits of Process Integration
Managing Commercial and Legal Requirements
Operation, Maintenance and System Disposal
Benefits of Requirements-driven Design
Example of graphical navigation
Conformance to International Standards
Safety Case Life Cycle
Multiple Life Cycles
Profiling Requirements to Industry Sectors
Nuclear Safety Case Example
Pharmaceutical drug Development Example
Multiple Contractors
Information Requirements for Key Decision Makers
Decision Process Integration and Information Flow
Challenges
Slide No.

3. Common Problems Stakeholder & Programme/System Requirements inadequate
Contractor(s) have previous experience and ‘know’ what is needed
Even if more detailed requirements produced, not linked to Stakeholders’ Requirements
Designs not linked formally to Stakeholders’ Requirements or System Requirements
One key area where preparation is often weak is where the Stakeholders’ Requirements, and any resulting Programme and Project Requirements, have not been defined adequately. Even on very large programmes, the Stakeholders’ Requirements may consist of a small set of ill-formed requirements that state, at a very high level, what is required from the development programme. These requirements are often loosely specified, and sometimes constitute little more than a ‘wish list’.
The fact that the set of Stakeholders’ Requirements is not rigorous, or comprehensive, is not necessarily viewed as a problem. The contractors’ familiarity with the nature of the work required by the programme allows them to proceed with the design because, based on previous experience of similar programmes of work, they ‘know’ what is required. Usually, a more detailed set of System Requirements may be produced by the Project Team in order to expand on the set of Stakeholder Requirements, and provide a better source of guidance prior to the production of the design. However, the System Requirements are usually not linked formally to the Stakeholders’ Requirements, and the designs produced by the contractors are not linked to the Stakeholders’ Requirements, or to the System Requirements.
Slide No.

4. Common Problems Legal advice => only award contracts
against well specified sets of requirements
Still no linkage between Stakeholders’ Requirements and System requirements
No auditable traceability from Stakeholders’
Requirements to System Requirements & Design
Can’t prove design meets Stakeholders’ & System Requirements
When Client’s specialists study completed
designs, some aspects may fail to meet System and/or Stakeholder Reqs
A risk-averse culture exists currently, and when the legal team for the Project Team becomes involved during the procurement stage, they invariably advise that the individual contracts for the Implementation phase must only be awarded against well specified sets of requirements, rather than against any preliminary designs (such as a Reference Design to gain Approval in Principle) that may have been produced by the Project Team. The reason for this is that, if the contract was based on the Reference Design, and this design caused subsequent problems, the contractors could claim that they were not liable, because the contract obliged them to base their design on the Reference Design, which proved to be flawed. Awarding the contracts against appropriate subsets of the System Requirements places the risk on the contractors, because they have to meet the requirements specified in the contract, and where a Reference Design is provided, it is provided for information only, and the contractor carries the risk if they use any part of the Reference Design.
Despite these precautions, there are still problems with the above approach:
There is no linkage between the Stakeholders’ Requirements and the System Requirements, so that it cannot be shown that System Requirements truly represent what is required by the Stakeholders, and therefore, there is no clear, detailed specification from which to produce the design
There is no auditable traceability from the Stakeholders’ Requirements down through the System Requirements, to the design, so there is no way of showing that the design exactly fulfils what is required by the Stakeholder Requirements, and the more detailed System Requirements
When the completed designs are eventually studied by technical specialists on the client-side, aspects of the designs may be deemed to have failed to meet the System Requirements, and/or the Stakeholders’ Requirements.
Unfortunately for the contractors, by the time the design problems have been identified, some, or all, of the teams who produced the designs will have been assigned to other work. In addition, because the designs did not completely meet the contractual requirements, much, or all, of the cost of the additional work may be charged to the contractors. The Contract may even contain penalty clauses which could result in the contractor not being paid at all
Slide No.

5. Three Questions Three Fundamental Questions must be
Addressed for any Development:
What do you want?
What => Requirement
How will you do it?
How => Design
Can you prove you have done what you said you would do
Proof => Verification
In any development project, three fundamental questions must be answered:
What do you want?
How will you do it?
Can you prove you have done what you said you would do?
When the question ‘What do you want?’ is posed, what is really being asked is ‘What are the requirements for the system that is to be developed?’
How will you do it? refers to how the requirements are to be addressed by the Design.
Can you prove you have done what you said you would do? This really means can you provide evidence to verify the developed system and, ultimately, validate the final built system?
Slide No.

6. Strategy The strategy must: address the three questions
Provide a means of specifying and capturing the Requirements
Allow for the specification of the Design(s), whilst accommodating various design approaches
Provide verification mechanisms so that it can be shown you have done what you said you would do
Any strategy which is proposed must address the three questions. There must be a means of eliciting and specifying the requirements. There must also be a means of specifying the Design, which will accommodate various existing design approaches.
Finally, all requirements that are specified during the development of the system must be justified by textual verification arguments which give the reasons why each requirement is necessary, and why the design approaches taken for the design elements associated with each requirement have been chosen.
Slide No.

7. What Type of Requirements Approach
Definition
Requirement management is the process of capturing, assessing and justifying stakeholders’ wants and needs
Success
A clear and agreed expression of requirements and their acceptance criteria is essential for the success of any project, programme or portfolio.
Four Step Process
gather requirements from stakeholders;
analyse the requirements to look for overlaps, gaps and conflicts;
justify the requirements to distinguish wants from needs;
Establish baseline before commencing solutions development process.
Sector practice
Steps undertaken differently, depending on sector practice & individual development methodologies used. E.g.:
approach for software development using Agile different from that using a waterfall approach;
managing requirements for business transformation will be different from construction.
It is accepted good practice in many industries to develop the Requirements, top-down for each stage of the life cycle, and let them drive the development. A typical development time to develop the Requirements
is 20% of the overall project development time.
A clear and agreed expression of requirements and their acceptance criteria is essential for the success of any project, programme or portfolio. Requirements may be expressed as physical deliverables or business benefits, as aspirations or solutions, and as functional or technical needs. [Ref: APM BoK version 6, section Requirements Management]
A simple process for requirements management has four steps:
gather requirements from stakeholders;
analyse the requirements to look for overlaps, gaps and conflicts;
justify the requirements to distinguish wants from needs;
baseline the needs before commencing the solutions development process.
These steps will be undertaken in different ways, depending on sector practice and the individual development methodologies used. For example, the approach for software development using Agile methods would be different from that using a waterfall approach; managing requirements for business transformation will be different from construction.
Slide No.

8. Requirements Management - management aspects
Requirements Management is necessary to avoid problems described
Needs:
Senior Management buy-in
Backed up with budget
A Requirements Manager
Requirements Management Plan
Strategy (which addresses the 3 questions)
Allocation of Resources (Team Requirements Representative)
Generic approach across the geography)
Requirements management activities detailed in the project schedule
Elicitation
Analysis
Reviews
A Requirements Manager is needed to produce a Requirements Management Plan which defines the strategy for Requirements Management, and which addresses the three questions. It must also describe how resources will be allocated, and where an extended geography is involved and/or where multiple discipline teams are working on the project, it should describe a generic approach to formulating requirements and creating designs, which should be used as much as possible
The Requirements Manager must then implement the Requirements Management strategy detailed in the Requirements Management Plan. The personality of the Requirements Manager is very important. They must be able to manage and mentor multi-discipline teams, and also have a strong enough personality to ensure that the appropriate amount of detail is produced, and to the right quality. This is the only way to ensure that the system can be verified completely. Changing an existing culture is difficult, and it is essential to have the endorsement and support of senior management if this change is to be achieved. This support must not only be the stated agreement to the planned strategy, but must also be present in the form of a budget which will cover the costs associated with implementing the strategy.
Requirements Management should not been viewed as something that is set apart from the rest of the development activities. The activities that implement the strategy (elicitation, analysis, reviews) proposed in the Requirements Management Plan need to be integrated into the overall programme of work, with time planned in for all of the related activities.
Slide No.

9. Requirements Hierarchy
The majority of requirements can be evolved top-down, from a progressive, logical refinement from the higher levels into the lower, more detailed levels of requirements
Additional requirements may need to be added at various stages to take account of: legislation, standards, EEC Directives, etc. These cannot be derived from a logical consideration of the system.
Also, some additional ‘Bottom Up’ requirements may be required due to existing ‘de facto’ standards. These are typically due to existing components that are supplied by manufacturers, which do not necessarily comply with any formal standards.
It is important to consider KPIs, and the requirements for mechanisms to obtain KPI data during system operation, early in the development lifecycle.. It is too late if KPIs are only considered when the system is about to go into operation. Any subsystems required for gathering KPI information must be developed as part of the system design.
Slide No.

10. Requirements-driven Design
Requirements-driven Design can cater for all types of requirements in the hierarchy.
The main benefits of a Requirements-driven approach is that:
There is a traceable path throughout the lifecycle, so that the ‘reasoning behind the evolution of the various levels of detail can be preserved, and the path can also be audited.
At each level of Requirements, the Set of Requirements produced provides a clear specification of what is needed at that stage, and it scopes what will be needed in the subsequent stage.
The visibility of that a clear, well-produced Set of Requirements provides allows any errors of logic/thinking to be identified early, rather than discovered later. This means that the errors can be fixed early in the lifecycle, when the costs of any changes is small.
The slide shows the logical arrangement of requirements modules, verification modules and design documents in the Requirements-driven Design approach.
A single requirement is linked to several more detailed requirements at the next level down in the development lifecycle via a Satisfaction Argument (SA). [Note: This is known as Rich Traceability’, and is the name given by Jeremy Dick [4, 5] (then of Telelogic, now of Integrate Systems Engineering Ltd) to the traceability afforded by the use of satisfaction arguments in the West Coast Main Line .
The SA contains text which describes how lower level requirements derived from higher level requirement, and justifies why each lower level requirement is necessary, such that all the (several) lower level requirements replace the single higher level requirement. There is a greater level of detail at the lower level, but the scope of the group of requirements is the same as the single, higher level requirement.
In Requirements-driven Design, the above approach has been extended to incorporate the use of Compliance Arguments (CA) and Design Verification Arguments (DVA ). A Compliance Argument (CA) links Domain Knowledge, Standards, or Legislation to requirement based on linked information. The text of the CA explains why the requirement(s) is necessary to comply with the referenced source compliance information.
Design Verification Argument (DVA) links a design element to its requirement. The text of the DVA explains how the design element implements the Requirement, and an additional field shows where to find the design evidence. This could be in a design document and/or drawing in a document management system (such as Documentum, or Domdoc).
Slide No.

11. Requirements Driven Design
Suitable for large development projects with known direction and desired outcomes
Addresses the three questions:
Capture and evolve requirements hierarchy
only start design when a clear set of requirements agreed at corresponding level What => Requirement
Complete auditable traceability down through Requirements hierarchy and to designs How => Design
Verification evidence provided Proof => Verification
justifies all derived requirements
show how requirements are implemented by design
In the Requirements-driven Design approach, the Requirements and Design activities are performed in two cycles in a stage of the lifecycle where a design level is required. When a designer is developing a design, then for each element of the design it is usual to think ‘what shall I design?’ Instead of creating the design element at this stage, the 1st of the two cycles commences.
For each new requirement the 1st cycle, the Requirements Cycle, commences:
the higher level requirement relating to this area, from the previous stage of the development, is used to scope the design considerations
the what is converted into formal wording for a requirement which is entered into the requirements module for that stage, and a status attribute in the requirements module is set to Not Completed
if required, an assumption would be raised
a Design Verification Object is created and linked to the new requirement, and the reference to the design element is entered into the Document Reference attribute of the Design Verification Argument
the new requirement is linked via the Satisfaction Argument to the higher level requirement, and a component of the Satisfaction Argument, relating to the new requirement, is completed
The 2nd cycle, the Design Cycle, commences:
For each requirement
The linked design element is completed, specifying how the design will implement what is stated in the requirement
The Verification Argument is created and entered into the linked Design Verification Argument
Slide No.

12. Requirements-driven Design Structures
The next slide is shown here to remind you of the key aspects relating to Requirements-driven Design:
Refinement & top-down, structured decomposition of requirements into sets of more detailed requirements
Levels of Design corresponding to the various levels of the sets of Requirements
Slide No.

13. Requirements-driven Design Structures
Satisfaction Argument Structure
The Satisfaction Argument (SA) Construct
A possible construct for the SA is shown. Two levels of requirements are shown in their respective modules: the Scheme Requirements Module; and the High Level Advanced Design Requirements Module. Interposed between these two modules is the Satisfaction Argument Module. For each individual SA there is a Satisfaction Argument ID, which is a numeric, unique identifier generated by DOORS®*, and which is preceded by a user-defined character sequence. In the diagram, three requirements in the High Level Design Requirements Module are linked back to a single SA in the Satisfaction Argument Module, and this SA is, in turn, linked back to a single requirement in the Scheme Requirements Module. The Satisfaction Argument Module has a single attribute, ‘Satisfaction Argument’ defined, and this is used to contain the text for the individual SAs.
*DOORS (Dynamic Object Oriented Requirements System), is a specialist requirements database (IBM Rational® DOORS®®, IBM Corporation Software Group, Route 100 Somers, NY U.S.A.)
Slide No.

14. Example of a Satisfaction Argument
Requirements Modules in DOORS
The slide shows a SA which explains how the lower level requirements address the higher level requirement, showing, in this case, how measures will be taken to guard against land contamination during construction.
Example of a Satisfaction Argument
in the DOORS Database
Slide No.

15. Requirements Modules in DOORS
DOORS allows designers to build the exact data structures they require, so that Requirements can be managed in an efficient way. Several views from DOORS are shown here. Some of the features displayed are:
Requirements Modules
An example of a drop-down (or ‘combo’) box, offering options for selection to indicate the type of validation needed for specific Requirements
An extract from a Verification View that is used to verify how a particular portion of design addresses what is wanted by a specific Requirement
Slide No.

16. Requirements-driven Design Strategy
Overall Requirements Strategy
Create Requirements Management Plan
Defines the overall strategy
Requirements-driven Design Processes
Implemented in 2 iterations per stage for each level of Requirements/Design
Requirements Definition
Requirements Elicitation & Capture
Requirements Analysis
Requirements Review
Requirements Verification
Requirements baselining => Delivers a set of Requirements
Design Specification
Create designs
Design and DVA Reviews => delivering Design elements linked to corresponding Requirements
Overall Requirements Strategy
As stated earlier, it is essential to create a Requirements Management Plan at the beginning of the project, which defines the overall strategy to be used for Requirements Management, and which explains how that strategy will be used to help meet the objectives of the project.
With the Requirements-driven approach, the strategy is usually implemented in two iterations for each stage of the project where design are developed. Each stage requires a Set of Requirements to be defined (i.e. Requirements Definition - 1st Iteration), followed by the production of a design which meets those Requirements (i.e. Design Specification - 2nd Iteration). The various steps in the Requirements Definition are:
Requirements Elicitation & Capture
Requirements Analysis
Requirements Review
Requirements Verification
Requirements baselining
Slide No.

17. Requirements Capture & Elicitation (Style & Formulation)
What makes a ‘robust’ requirement?
Each requirement must:
Stand alone
Specify clearly and unambiguously what is wanted
Must be verifiable
Must be necessary
Must be achievable
Must be traceable
Must be at the right level
Must be well-formed
Each requirement must be written in a formal style
e.g. The combined level of risk due to all the hazards under the direct control of the Infrastructure Controller shall not exceed 0.01 equivalent fatalities per year.
What makes a robust, well-stated Requirement?
The Requirement must stand on its own – i.e. is must be self-contained?
The Requirement must be worded at the appropriate level of detail for a Requirement for that stage of the project?
It must be testable – i.e. it must be possible to show that the requirement has been met?
The Requirement must be traceable – i.e. it must be able to be traced back via links to a higher level of Requirement, or via a Compliance Argument to supporting documentation/legislation/domain knowledge?
The Requirement must be well-formed – i.e. is the wording must be appropriate for a Requirement, and it must be unambiguous,
Slide No.

18. Requirements Review Design Teams Review their own Set of Requirements:
Examine structure of Team’s Requirement Set
Check Requirements against criteria for a ‘Good Requirement’
Unambiguous, verifiable, necessary, achievable, traceable, at the right level, well-formed
Check that each Requirement is Testable
What is the Test Method?
Test, Analysis, Demonstration, Inspection, To be specified at a later stage of Design
Are there any Assumptions?
What are they predicated upon?
Risk (Risk raised? Risk ID specified?)
Issue (Issue raised? Issue ID specified?)
Awaiting information (RFI raised? RFI Ref specified?)
Once a Specialist Team believes that it has created a complete Set of Requirements for a specific Stage of the Lifecycle, the Team must conduct its own, internal Review of the Requirements.
A number of criteria must be set for the successful completion of a Review, and the Set of Requirements must be reviewed against these criteria.
Examples of Criteria for a Successful Review are:-
Is each Requirement a ‘Good Requirement’? Is it: Unambiguous; Verifiable; Necessary; Achieveable; Traceable, ‘At the right level’; ‘Well-formed’; etc.?
Is it Testable – what is the Test Method: Test against a Test Script; Analysis of Results produced; Demonstration; Inspection; etc., ?
If an Assumption needs to be made about a Requirement, it means that the knowledge about that Requirement is incomplete.
Therefore the Review needs to ask: Have any Assumptions been made in respect of a Requirement? If so, what are they predicated upon:
Risk – has the Risk been raised in the Risk Register? Has the Risk ID number been specified?
Issue – has the Issue been raised in the Issue Register? Has the Issue ID been specified?
Is there outstanding information needed related to the Requirement? Has an RFI (Request For Information been raised? Has an RFI Ref No. been specified?
Once the item upon which the Assumption has been predicated has been resolved, the Assumption itself can been resolved, and the Requirement can then be specified in its final form.
Slide No.

19. Design and Verification Argument Review
Disciplinary, Inter-Disciplinary, and Stakeholder Requirements and Satisfaction Argument
Perform Reviews:
Disciplinary => Requirements + Satisfaction Arguments
Inter-Disciplinary => Requirements
Promoter Review
Stakeholder => Requirements
Review the Design Verification Arguments (DVAs) + the Design
Discipline Reviews
Inter-Disciplinary Reviews
Stakeholder Review of Requirements
Create a System Baseline Set of Requirements
Update the DVAs and/or Requirements and the Design according to comments
The final part of the Specialist Team’s review of the Set of Requirements is to ensure that every Requirement at that stage of the Lifecycle can be justified. To do this, reviews are conducted to check that the Satisfaction Arguments that are used to link groups of Requirements at that Stage to individual, higher level Requirements, have completed explained, and justified, why each Requirement at that Stage is necessary.
Once the Specialist Team has completed a satisfactory Review of a Set of Requirements, Inter-Disciplinary Reviews (IDRs) must be carried out. The Interdisciplinary reviews will involve specialists from other teams, who will attend reviews of other specialist areas to check on possible impacts of their Requirements on the Requirements from their own specialist area. To assist the review processes, Requirements Specification documents will be generated from the Requirements Modules in DOORS, using export facilities in DOORS to generate Microsoft Word documents. Comments made by the review teams will be captured in a Comment attribute in the row in DOORS corresponding to the Requirement.
Once the Project specialist teams have reviewed specific Sets of Requirements, the Requirements will be passed to the major Stakeholder to obtain their review comments, and to make any further changes that may be necessary. The Requirements can then be Baselined (i.e. ’Frozen’), and the Design can be begun against these Requirements.
As the various specialist teams complete sections of the Design, they will undertake further reviews, performing gap analyses of the Design against the Requirements to check that the Design is completely aligned with the Requirements for that Stage of the Design. Next, a further series of reviews will be performed to check that Interdisciplinary, Interface, and Generic Requirements have been completely addressed by the Designs.
For every Requirement two fundamental questions will be asked:
How does the Design satisfy the Requirement?
Where is the evidence to prove that the Design satisfies the Requirement?
Prior to conducting these verification reviews, the specialists will answer these questions for each Requirement. The requirement states ‘what’ is required; the design specification states ‘how’ the requirement is to be met within the system to be built. The Design Verification Argument will contain text that explains how the referenced element(s) of the Design satisfies the Requirement.
The Verification Evidence component of the DVA will contain a reference(s) to a document(s) or drawing(s) that are part of the design documentation, and the reference will indicate the section(s) or clause(s) that implement the requirement in the design. This will answer the second question. Only when it has been checked that satisfactory responses to both questions have been given, for all Requirements, will the review be certified as having been passed successfully.
Slide No.

20. System Engineering Structures and processes
Requirements Management
- System engineering and management
System Engineering Structures and processes
Important for Requirements Manager to work with other
process managers to:
Understand how other processes interact with Requirements Management process
Liaison with managers of key areas (Risk, Change Control)
Integration of processes
Determine data required to manage other processes
Establish specific data to be managed in DOORS
Structures
Schema
Organisation of Requirements
Attributes of Requirements
A secondary level of traceability is created by integrating the Requirements Management process with other project processes. The Requirements Manager needs to work with the managers of other key processes to understand and document the relationship of the other processes with the requirements database.
Prior to building the links and modules in the database, it is essential to define the Schema for the structures. The Schema specifies the modules, the attributes in the modules, and the links and link directions connecting modules and data.
Slide No.

21. Key Project Support Processes
Requirements Management
Assumptions Management
Change Control
Risk Management
Issue Management
Legal Process
Environmental Management process
We have spoken about the Requirements-driven structures, and the sources of inputs for Requirements. The slide shows a list of typical, key project processes.
Slide No.

22. Supporting Project Processes - Risk Management
Here the slide shows a Process Model for a Risk Management process.
Slide No.

23. Benefits of Processes Integration - Risk Management
Purpose of Risk Register:
- capture and maintain information on identified threats and opportunities
Each risk is allocated a unique identifier (Risk ID) as well as details such as:
Who raised the risk
The category of risk
The description of the risk (cause, risk event, effect)
Probability, impact and expected value
Proximity
Risk owner
This slide shows some of the attributes which need to be stored in a Risk Register
Slide No.

24. Changing Requirements
A Requirement may need to be changed if:
An Assumption proves to have been incorrect
Design details indicate that the Requirement:
cannot be implemented as original thought
Alternative design needs a modification to the Requirement
Change Control process used to:
Manage changes to Design and/or Requirements
If Requirement part of set that has not yet been baselined, then manage change locally within Project Team
If Requirement part of Baselined set, then refer ‘Change Request’ to Project Review Board for decision about change
Here we see the various situations that may lead to the need for Requirements to be changed.
Sometimes, when a requirement is specified initially, there may be some aspects of the requirement which may not be known completely. For example, there may be an outstanding Request For Information (RFI) which needs to be resolved before some specific details of the requirement can be quantified, or the results of functional, or performance modelling, may need to be obtained, resulting in qualification of the requirement. In other cases, a risk, or issue, may be identified in relation to a requirement. When requirements are specified in these circumstances, an assumption needs to be made that the requirement has been documented in its current form, but may be subject to change when the outcome of the related, outstanding information is known. An Assumptions Management process for requirements must be established, such that an assumption can be created when a requirement is specified, which states the nature of the dependency on the related information. The Assumptions Management process monitors the processes related to the assumptions (i.e. Risk management, Issue Management, RFI), such that when the outcome of an assumption is resolved (e.g. a risk has been resolved/mitigated, an issue has been resolved, or the information for an RFI has been received), the requirement can be stated in its final form.
 Another way that requirements can be changed is to manage them locally wiyhin the project Team. If a requirement has not been baselined (n.b. bselining means freezing the set of requirements so that they are not subjected to further change), then if it needs to be amended, or deleted, this can be managed within the project Team. If a baselined requirement needs to be changed, a Change Request needs to be raised and considered by the Project Review Board, who will decide what action can be taken.
Slide No.

25. Supporting Project Processes - Change Control
This slide shows a Process Model for a Change Control process.
Slide No.

26. Project Support Environment
Here we see a graphical depiction of the Requirements-driven structure, and modules, supported by the project support processes. In the diagram, we see some of the Review processes being invoked for reviewing:
Requirements and their corresponding Satisfaction Arguments
Designs and their corresponding Design Verification Arguments.
Slide No.

27. Benefits of Processes Integration - Risk Management
A matrix can be constructed where the cells
of the matrix reflect ranges of Risk Score
Probability
Very High
VHΛVL
VHΛL
VHΛM
VHΛH
VHΛVH
High
HΛVL
HΛL
HΛM
HΛH
HΛVH
Medium
MΛVL
MΛL
MΛM
MΛH
MΛVH
Low
LΛVL
LΛL
LΛM
LΛH
LΛVH
Very Low
VLΛVL
VLΛL
VLΛM
VLΛH
VLΛVH
Impact
The highest Risk Score in the above example would be:
Probability(Very High) x Impact(very High)
Similarly, the lowest Risk Score would be:
Probability(Very Low) x Impact(very Low)
This slide shows a typical risk matrix, using a Red, Amber, Green (RAG) Risk Score designation.
Individual risks can be given a Red/Amber/Green (RAG) status, corresponding to their Risk Score. In the above example scores of HΛH, or VHΛH, are shown in Red. Moderate and lower Risk Scores are indicated by the yellow and green areas in the matrix
Slide No.

28. Benefits of Processes Integration - Risk Management
Enter new risk into the Risk Register
Requirements Manager check if any of the existing requirements (in DOORS) are impacted by the risk.
If so, update ‘Risk ID’ attributes of the requirement(s)
Link to the new risk’s Risk ID in the Risk Register
A risk can also be identified when a new requirement is created. Initially, some aspects of a new requirement may not be known completely:
An Assumption is raised which is linked to a new (or existing) Risk
The Risk ID attribute in DOORS is linked to the new (or existing) Risk in the Risk Register
When a new risk is entered into the Risk Register the Requirements Manager will check whether any of the existing requirements (in DOORS) are impacted by the risk. If so, the ‘Risk ID’ attributes of the requirement(s) are updated and linked to the new risk’s Risk ID in the Risk Register.
A risk can also be identified when a new requirement is created. Sometimes, when a requirement is specified initially, there may be some aspects of the requirement which may not be known completely. An Assumption is raised which is linked to a new (or existing) Risk. The Risk ID attribute in DOORS is linked to the new (or existing) Risk in the Risk Register.
Slide No.

29. Benefits of Processes Integration - Risk Management
Large projects, typically involving construction, often produce an Initial Reference Design to gain Approval in Principal. These designs are used to investigate potential areas of high risk in order to eliminate, or mitigate, these risks.
IT is normally difficult to precisely scope/extent of the areas of design – there is no detailed linkage between the Risks, the Requirements, and the corresponding Design elements.
Using a Requirements-driven Design approach the requirements associated with individual risks can be identified. Also, because each element of the design is linked directly to its corresponding requirement, the scope of the initial design can be determined precisely so that only those aspects of the design specifically associated with the Red risks need to be documented.
As a consequence of this the cost of producing the initial design can be kept to a minimum. Clearly, this approach can be extended to investigate design elements associated with specific risks with high risk scores at any stage of the lifecycle when designs are being produced.
Slide No.

30. Managing Commercial and Legal Requirements
The slide shows examples of a number of different types of sets of requirements:
System
Technical
Legal
Environmental
Safety
Requirements-driven approach can
support both technical & non-technical requirements
In the example, legal requirements are generated at a high level from the Business Requirements and Agreement Processes of Standard ISO/IEC (an international Systems Standard)
Any Legal Requirements will be Contractually binding, but there is often little, or no, communication between technical & legal teams
Without some linked design activity, nothing will happen with legal agreements. Normally, try to use a generic approach to design. However, a legal document usually means that there is some specific, exception condition applying. Therefore, the lower level requirements linked to the legal document (at the high level) must be merged into the appropriate section of the Requirements at the design levels so that the appropriate exception to the (generic) design can be incorporated.
Slide No.

31. Whole Life Cycle Considerations
Testing
RHS of V-Model shows Unit Testing through to System testing
When the Left Hand Side (LHS) requirements are created, the method of testing must be specified
This information can be used to formulate the test requirements, which are used to define what is needed in the test scripts
Peer-to-peer testing is performed, using the Right hand Side (RHS) test scripts to test that the LHS requirements have been met
A Test Verification Argument (TVA) is created linking each RHS test result to its LHS requirement
The TVA shows how the test, and test result (verified against predicted results) verify that LHS requirement has been met
Operation, Maintenance & Support
The Operational, Maintenance and Support Requirements should be specified during the creation of the LHS requirements hierarchy
When the system goes operational, the Maintenance & Support Requirements are typically used to address:
The performance of the Maintenance Contractors (response time, etc.)
The Condition Monitoring of System Assets
The Maintenance Regime
KPI Monitoring and Reporting
The KPI monitoring procedures obtain metrics on the performance of the operational system
Periodic reports are produced from the KPI data
Reports compare actuals against KPI targets
System Disposal
Disposal requirements should be established during the creation of the LHS requirements
Should encompass factors such as: design lifetime, build materials, location
The Operational, Maintenance, Support & Disposal requirements should be subject to periodic Review (perhaps annually) against current legislation. Where neceesary, the Requirements, and corresponding, related activities, should be Updated as necessary.
Slide No.

32. Benefits of Reqs-driven Design
Benefits of the Requirements Driven Approach:
The Design evolves thoroughly from the Stakeholder Requirements
The Design Brief will be clear, and the Design will require no iteration
Large teams of Engineers will not be tied into the Design Phase for extended periods
There is full, auditable traceability through the requirements hierarchy and to every element of each level of design
Early Acquirer/Stakeholder visibility of the requirements enables changes to be made at that time, rather than later, after months of design reviews, when design changes would require much re-work with corresponding high cost
Project-wide visibility, and use of natural language, promotes better understanding for engineers across all disciplines
Verification evidence at each stage contributes incrementally to the Safety Case
The benefits of a Requirements-driven Design approach may be summarised as follows:
The design evolves thoroughly from the Stakeholder Requirements down through successive levels of derived requirements
The Design Brief will be clear, so that the design will require no iteration
Large teams of engineers will not be tied into the Design Stage for extended periods, as there should be no iteration
There will be a full, auditable traceability through the requirements hierarchy and to every element of each level of design
Early client and stakeholder visibility of the requirements enables changes to be made at that time, rather than later, after months of design reviews, when design changes would require much re-work with corresponding high cost
Project-wide visibility, and use of natural language, promotes better understanding for both the Project Team and the stakeholders
The Verification evidence at each stage contributes incrementally to the Safety Case
Slide No.

33. Example: Guide to Railway Investment Projects (GRIP)
One of key elements for success is
good communication
consider using graphical applications
(e.g. MindManager) to document processes and process interactions
include contextual help (including DOORS help)
Link through to DOORS and carry out operations directly in DOORS
Example of processes integration:
Guide to Railway Investment Projects (GRIP)
Approach is based upon best practice within Network Rail and other industries that undertake major infrastructure projects
Also best practice recommended by major professional bodies including:
the Office of Government Commerce (OGC)
the Association of Project Management
Covers the investment lifecycle from inception through to the post-implementation realisation of benefits
Dynamic Map Examples
The following sequence is followed in the demonstration of graphical navigation shown in the video of the presentation
Click on the ‘Dynamic Map Examples’ hyperlink
If file is a .pdf, then click on the prompt to run the .pdf file (‘>’ symbol in bottom left corner)
If file is Flash, then will run automatically
Initially shows a project organisation structure
Then goes into the top level of the engineering processes, via the project phases, into the Requirements Management process
Shows Help info on the map – DOORS Explorer, hyperlink to an audio-visual presentation, and them the Login icon to DOORS to login to a live session (if the engineer has understood all the Help info)
Then shows the Issue Management process
Next, the Risk Management process
Then goes into the Design procedures for GRIP (Network Rail’s Dev’t Lifecycle processes – Guide to Railway Investment Projects). Goes into GRIP Stage 3 (Enhancements), then Single Option Dev’t to the Design Specification. Goes down to an individual design team’s designs.
Slide No.

34. Some examples of large projects using DOORS
Heathrow Terminal 5
Cross London Rail Link (Crossrail)
Some examples of where aspects of this approach has been used successfully on large, complex programmes of work are:
Heathrow Terminal 5
The East London Line railway
And the £17 Billion Crossrail project
East London Line
Slide No.

35. Conformance to International Standards
ISO/IEC Life Cycle Processes
ISO/IEC 15288:2008 establishes a common framework for describing the life cycle of systems created by humans. It defines a set of processes and associated terminology. These processes can be applied at any level in the hierarchy of a system's structure. Selected sets of these processes can be applied throughout the life cycle for managing and performing the stages of a system's life cycle. This is accomplished through the involvement of all interested parties, with the ultimate goal of achieving customer satisfaction. This standard also provides processes that support the definition, control and improvement of the life cycle processes used within an organisation or a project. Organisations and projects can use these life cycle processes when acquiring and supplying systems.
This diagram shows the four main groupings of processes that are described by 15288:
Agreement Processes – used to help construct the Contractual/Business Agreements between the Customer and the Supplier.
The Organisational Project-Enabling Processes which are used to specify
The Life Cycle Model to be used
Management of the total Project Infrastructure
The Project Portfolio - the Business-related aspects of the Project
Project Resourcing and staff management
Quality Management
the Quality System to be used
How it is to be managed
The Quality Plan requirements, etc.
The Project Processes – (described on the slide)
The Technical Processes – (described on the slide)
Slide No.

36. Additional ISO/IEC 12207 Life Cycle Processes
ISO/IEC is a companion standard to ISO/IEC and it provides Life Cycle processes, activities and tasks for software. This can be for part of a larger System, or for standalone software products and services. By using ISO/IEC 12207, a common framework for software Life Cycle processes can be established.
The areas covered by ISO/IEC 12207: Acquisition, supply, development, operation, and maintenance of software.
These functions are supported in the form of quality assurance, configuration management, joint reviews, audits, verification, validation, problem resolution, and documentation.
Some of the benefits of ISO/IEC are the:
Management and improvement of the organisation’s processes and personnel.
Establishment of software management and engineering environments based upon the life cycle processes as adapted and tailored to serve business needs.
improved understanding between customers and vendors/suppliers, and among the stakeholders involved in the life cycle of a software product.
Additional software processes that are invoked by during the Implementation Phase corresponding to Clause of
Slide No.

37. Application of ISO/IEC 15288 & 12207 throughout the Lifecycle
The next slide shows the addition of the Software Implementation processes of 12207, where these are incorporated during the Implementation phase of The other Software processes of have not been shown, but some, or all of these remaining processes may be needed.
Slide No.

38. ISO/IEC 15288 Systems Life Cycle
ISO/IEC 15288:2008 Life Cycle
Agreement Processes
Organisational & Project Enabling Processes
Project Processes
Technical Processes
Stakeholder Requirements Definition
Requirements Analysis
Architectural Design
Implementation
Integration
Verification
Transition
Validation
There are many different types of model used for the system life cycle, but one of the simplest is also one of the most commonly used for large system development. This is the V Model.
The V Model was developed in the United Kingdom by the Department of Trade and Industry (DTI) STARTS Project, and the name of the model comes from the English letter “V” which illustrates the shape of the model. The sequence of activities varies for different projects, but is generally: feasibility study; analysis; design; construction; unit testing; integration testing; system testing; user acceptance.
For each of the individual life cycles key activities are shown at various points along the V model. In all cases, elapsed time starts from the top left of the “V” and increases as the left hand side of the V is traversed, and moves up the right hand side of the V.
For one of the individual models we have the activities, as time elapses, as shown below.
ISO/IEC 15288:2008 V Model:
Agreement Processes; Organisational & Project Enabling Processes; Project Process; … ; Transition; Validation.
Slide No.

39. Safety Case Life Cycle Safety Case Life Cycle Slide No.
Establish Stakeholder Safety Requirements
AND (if there are pre-existing Designs)
Generic Design Assessment (GDA)
[from Suppliers]
High Level Optioneering
Single Option (for the overall approach)
Produce Preliminary Safety Report (PSR)
Generate System Safety Final Requirements
Proposed System Integrity Level (SIL)
Pre-Construction Safety Report (PCSR)
Pre-Operational Safety Report (POSR) – i.e the Safety Case
PCmSR1 (Inactive Pre-Commissioning Safety Report)
PCmSR2 (Active Pre-Commissioning Safety Report)
Safety Case Life Cycle: Establish Safety Case Requirements; High Level Optioneering; Single Option; … PCmSR1 (Inactive Pre-commissioning Safety Report); PCmSR2 (Active Pre-commissioning Safety Report).
Slide No.

40. Traditional V-model Life Cycle
Traditional Life Cycle
Unit Test
System Test
System Acceptance
De-commission
Business Case
Business Objectives
System Procurement
Invitation to Tender
Requirements Definition
High Level Design
Detailed Design
Implementation
Integration
Operate & Maintain
Design Outputs contribute to Safety Case
Traditional Life Cycle: Business Case; Business Objectives; System Procurement; Requirements Definition; System Test; System Acceptance; Operate & Maintain; De-commission
Slide No.

41. Multiple V-Model Life Cycles
Traditional Life Cycle
Safety Case Life Cycle
In addition to the three example life cycles already given, there may be additional lifecycles that are contracted out to subcontractors once the system’s subsystem requirements have been defined.
ISO/IEC 15288:2008 Life Cycle
Slide No.

42. Multiple V-Model Life Cycles
Business Case
Business Objectives
System Procurement
Invitation to Tender
Requirements Definition
High Level Design
Detailed Design
Implementation
Unit Test
Integration
System Test
System Acceptance
Operate & Maintain
De-commission
Traditional Life Cycle
Safety Case Life Cycle
Requirements Elicitation
Prepare Manuals
Test on Target Trainee Group
Training
Distribute Manuals
Establish Stakeholder Safety Requirements
AND (if there are pre-existing Designs)
Generic Design Assessment (GDA)
[from Suppliers]
Agreement Processes
Training Package Development
Organisational & Project Enabling Processes
High Level Optioneering
Pre-Operational Safety Report (POSR) – i.e the Safety Case
Project Processes
Single Option (for the overall approach)
Validation
Technical Processes
PCmSR2 (Active Pre-Commissioning Safety Report)
Stakeholder Requirements Definition
Produce Preliminary Safety Report (PSR)
If there are multiple life cycles operating, how can these be organised so that the project may be managed without the complexity of multiple, concurrent life cycles? The answer is to map the key deliverables/activities/gateways from each life cycle onto one life cycle for the whole of the project. Since the general, engineering life cycle is most frequently used, this is the most widely understood V Model. In the example shown, the key activities from the ISO/IEC 15288:2008 Life Cycle, and the Safety Case Life Cycle, will be mapped onto the Traditional Engineering Life Cycle, and the gateways for the Traditional Life Cycle will contain deliverables for the other lifecycles..
There may be additional ‘mini life cycles’ that occur during the project life cycle. In Fig. 4, an example is shown where a Training Package starts during the ‘Requirements Definition’ stage of the Traditional Life Cycle, and is delivered during the ‘Implementation’ stage. The Training Package, itself, may be developed using a V Model, or some other life cycle which is appropriate to that development.
PCmSR1 (Inactive Pre-Commissioning Safety Report)
ISO/IEC 15288:2008 Life Cycle
Proposed System Integrity Level (SIL)
Transition
Requirements Analysis
Generate System Safety Final Requirements
Verification
Architectural Design
Pre-Construction Safety Report (PCSR)
Design Outputs contribute to Safety Case
NOTE: Review Gateways and Safety Hold Points would be established by considering all the contributing Life Cycles
Integration
Implementation
Slide No.

43. Mechanics of Conformance
Map major deliverables and Gateways onto traditional V-model
Use CAs to merge in the requirements of a standard into the requirements sets at appropriate stages of the development life cycle
Each CA links to clause in standard that has caused the need for a requirement
CA argument states why requirement is necessary, and how it addresses the clause in the standard
Conformance is achieved in the Requirements-driven Design approach by the use of CAs to merge in the requirements of a standard at the appropriate stages of the development lifecycle. Requirements are created at the various stages of the development lifecycle, specifying what is required by the standard at each specific stage. Each CA references the clause in the standard that has necessitated the creation of the corresponding requirement at that stage in the lifecycle. The argument in the CA states why the requirement is necessary, and how it addresses the clause in the standard
Slide No.

44. Regulated Industries – Safety Case Considerations
Major Stages of a Nuclear Plant Associated Safety Cases
Life Cycle
Early Design Preliminary Safety Case
Pre- Construction and Installation Pre- Commencement (Construction) Safety Case
(including modifications)
Pre- Commissioning Pre- Inactive Commissioning Safety Case
Pre- Active Commissioning Safety Case
Pre- Operation Pre-Operational Safety Case
Operation Plant or Station Safety Case or Site Wide
Safety Case if relevant
Updated as necessary
Periodically reviewed
Post Operation Post- Operational Safety Case
Pre- Decommissioning Safety Strategy Overview (applies to complex decommissioning projects only)
Decommissioning Decommissioning Strategy
Safety Case(s) for Decommissioning
Operations
Post- Decommissioning Post-Decommissioning
Clearance Safety Case
The slide shows the various stages of the life cycle for a nuclear plant, with the corresponding safety cases for each stage of the life cycle.
Slide No.

45. Regulated Industries – Safety Case Considerations
Pre- Inactive Commissioning Safety Case
To demonstrate that the plant as-built meets relevant safety criteria and is capable of safe operation
To enable the production of a programme of safety commissioning activities that will:-
demonstrate as far as practicable the safe functioning of all systems and equipment
prove as far as practicable all safety claims
confirm as far as practicable all safety assumptions confirm as far as practicable the effectiveness of all safety related procedures
To list aspects of safety that cannot be demonstrated inactively
Some of the high level regulatory requirements stated in the Safety Case Purpose guide for the Pre-inactive Commissioning Safety case, required to be specified during the Pre-Commissioning Stage, are shown in the slide. Various verbs are used, such as: demonstrate, prove, confirm.
Slide No.

46. Regulated Industries – Safety Case Considerations
Key Points
Requirements-driven Design provides a generic
methodology that supports full vertical traceability through the requirements hierarchy, and links every design requirement to its corresponding design element, with verification evidence for all the linked information
The Safety Cases need to access the verification evidence in specific, prescribed ways at each stage of the Safety Case Lifecycle and are, therefore, not generic
but
The verbs in the Safety Case Purpose statements are generic in the nature of what they require
Therefore
We can use generic sub-schemas corresponding
to each type of verb alongside the generic
structures of Requirements-driven Design
Requirements-driven Design provides a generic methodology that provides full top-down traceability through the requirements hierarchy an through from every design requirement to its corresponding element of design.
In regulated industries the safety requirements need to be linked to their verification evidence according to strict, prescribed evidential obligations which vary at different stage of the life cycle. Therefore, over the whole life cycle, the regulatory requirements are not generic. However, at specific stages of the life cycle, the verbs in the Safety Case Purpose statements are generic in respect of the nature of the type of verification information they require. This means that, at each stage of the life cycle, we can use generic sub-schemas corresponding to each type of verb in the Safety Case Purpose statements alongside the generic structures for the rest of the system requirements at that stage.
Slide No.

47. Regulated Industries – Safety Case Considerations
Req ID
Statement
Obj Type
Req Type
PSC.1
Statement of Intent
Header
PSC.2
Textual Statement
Text || || ||
Control and Management
Header
PSC.n
PSC.n+1
Control and Management
Requirement
Demonstrate
PSC.n+2
Control and Management
Requirement
Demonstrate
Option Selection
Header
PSC.m
PSC.n
Discussion and selection of options
Text
This slide shows part of the layout of a requirements module in DOORS. The module contains various types of ‘objects’, where an object can be of type ‘Text, ‘Header’, or ‘Requirement’. A Header is used to provide structure to the requirements when they are printed as a text document, and the Statement part of the Header object contains the text for a heading in the document. The Text object is used to provide text for a printed document, and the sentence, or paragraph, of the text is entered into the Statement part of the Text object. The Requirement type of Object contains the details for a requirement. The actual wording of the requirement would be entered into the Statement field of the Requirement Object. In the example, there is an attribute called Req Type which contains ‘Demonstrate’, and this indicates that the requirement specified in the Statement field of the Requirement Object contains one of the Regulatory Requirements calling for verification evidence demonstrating specific aspects of compliance to the regulations.
Preliminary Safety Case Module
Slide No.

48. Regulated Industries – Safety Case Considerations
Generic Sub-schemas SA
URL
Design Reports
DVA
Early Design
Stage
Early Design
Requirements
Prelim Safety
Case Requirements
Document Management System
‘Demonstrate’ Module
Validation Methods Module
Test Management Module
Specific Test Methods
Test Script
Test Results SA
Pre- Construction and Installation Stage
Pre- Construction and Installation Requirements
Safety Analysis Module
‘Prove’ Module
URL
URL
Specific Analytical Techniques
Here the slide shows part of the hierarchy of the System Requirements, where the Early Design Requirements are linked, via Satisfaction Arguments, to the Pre-Construction Requirements. The set of Preliminary Safety Case Requirements are shown alongside the Early Design Requirements, and in the example, contains requirements of type Demonstrate and Prove. Generic sub-schemas are shown for these two types of Safety Case Requirements.
In the Demonstrate sub-schema, a Demonstrate requirement is shown linked to a specific validation method in the Validation Methods module. The validation method, in turn, is linked to an appropriate suite of tests specified in the Test Management module. Each specific test method is selected from, and linked to, the suite of tests in the Test Management module. When the tests are conducted, using the Test Scripts corresponding to the test methods, the test scripts and test results are stored in the project’s document management system, and both the test script and test method are linked via URLs to the test method. The test scripts and corresponding test results form part of the validation evidence, in this case, for the Preliminary Safety Case.
The generic Prove sub-schema is constructed in a similar way to that of the Demonstrate module. Here the Prove requirements are linked to the Proof Methods module, and the specific proof methods are linked to the appropriate safety analysis method in the Safety Analysis module. The specific analysis techniques, linked to the Safety Analysis method, are invoked from the Specific Analysis techniques module. The results of the analysis are stored in the document management system, and contribute to the Preliminary Safety Case.
By defining generic sub-schemas similar to those proposed in the above examples, large, complex safety cases can be given easily-navigable structures which aid understanding, and also allow for easier inspection if subsequent problems arise.
Proof Methods
Module
Analysis
URL
Generic Schema for ‘Demonstrate’ Requirement
verification evidence
Document Management System
Generic Schema for ‘Prove’ Requirement
Document Management System
Results of Analysis
verification evidence
‘Demonstrate’ Schema diagram
Slide No.

49. Regulated Industries – Safety Case Considerations
Site Wide Safety Case
Site Wide Safety Case
Geographical Region 1
Pre- Commencement Safety Case
Pre- Commencement Safety Case
Pre- Inactive Commissioning Safety Case
Geographical Region n
Pre- Active Commissioning Safety Case
Plant ‘n’ or Station Safety Case
The slide shows the situation where, for example, a nuclear power plant covers a significant geographical area. The safety case for geographical area ‘1’ is shown on the left hand side, and the overarching safety case for that area is contained in Plant 1 Safety Case. The safety cases for the other geographical areas are contained in Plant n safety Case, where n denotes the number of the geographical area. The individual plant Safety Cases are collected together to form the Site Wide Safety case.
Pre-Operational Safety Case
Plant ‘1’ or Station Safety Case
Slide No.

50. Example: Pharma Development Life Cycle
Life Cycle Management for the Life Science and Medical Devices Industries
Compliance with the Quality System Inspections Technique used by US Food and Drugs Administration (FDA) field inspectors.
Inspector usually:
examines the compliance of a single project.
needs confirmation that design inputs were established.
needs to verify that the design elements that are essential to the proper functioning of the device have been identified.
needs to determine if risk analysis was performed.
needs to ensure that changes to requirements were controlled
Life Sciences is another industry sector where regulatory requirements have to be met prior to a licence being granted to sell a drug. The Medicines and Healthcare products Regulatory Agency (MHRA) is the UK government agency which is responsible for ensuring that medicines and medical devices work and are acceptably safe. However, many large pharmaceutical companies also comply with the US Food and Drugs Administration (FDA) regulations, because their market is global, and the US is a significant part of that market.
In accordance with the regulations of the US Food and Drugs Administration, FDA field inspectors check compliance with the Quality System Inspections Technique, usually:
Examine the compliance of a single project.
Need confirmation that design inputs were established.
Need to verify that the design elements that are essential to the proper functioning of the device have been identified.
Need to determine if risk analysis was performed.
Need to ensure that changes to requirements were controlled
In respect of drug development, a series of studies and clinical trials is necessary, which may take, typically, 11 to 15 years before the drug has been completely tested, approved, and can go to market.
Slide No.

51. FDA's Drug Review Process
Pre-clinical (Animal) Testing
Investigational New Drug
(IND) Application
Show FDA results of preclinical testing and what is propose d for human testing
Phase 1 Studies
(typically 20 to 80 people)
Phase 2 Studies
(typically a few dozen
to about 300 people)
Phase 3 Studies
Pre-NDA period (FDA and
drug sponsors meet)
(typically several hundred
to about 3000 people)
Submission of an NDA
This slide shows a typical drug development life cycle for compliance to the FDA’s requirements. The studies require a series of clinical trials, initially involving tens of people, and ultimately involving several thousand people. The proposed generic structures for managing the regulatory requirements, and the results of studies and clinical testing, are shown alongside the various phases of the drug development life cycle.
Ask the FDA to consider a drug for marketing approval
FDA decision whether
to Review (60 day period )
FDA files NDA
FDA review team evaluates the sponsor's research on drug's safety and effectiveness
Slide No.

52. Managing Multiple Development Contracts
Detailed Requirements Elicitation
Subcontractor 1
Subcontractor n
System Requirements
Subsystem 1 Requirements
Subsystem n Requirements
Traditional Life Cycle
Apportionment of
Requirements to Subcontractors
The slide shows how, once the subsystem requirements have been specified, subcontracts can be awarded to subcontractors for the development of the subsystems. When the subsystems have been developed, they are integrated together during the implementation stage of the main (traditional) life cycle.
Implementation
Main Project V-model Life Cycle
Slide No.

53. Managing Multiple Development Contracts
Access control & remote working capabilities of DOORS can support management of multiple contracts
Sets of requirements can be allocated to, or produced by, various contractors
Sets can be linked to Project Teams’ requirements via SAs
Contractors only given Read Access to Project Teams’ requirements
Subsystems developed & implemented, then tested by Contractors against contracted set of requirements, and test results reviewed by Client
Completed subsystems can be integrated into overall system during the subsystem and system integration phases of life cycle
The subsystem requirements for a specific subsystem can be made available to the subcontractor as ‘read-only’ requirements, which can be accessed via a web-based link. The subcontractor can develop their own requirements and designs, and link them back through their highest level of requirements, via satisfaction arguments, back to the read-only subsystem requirements. The developed, implemented, and tested subsystems are delivered back to the client, together with the test results, for integration into the system.
Slide No.

54. Managing Multiple Development Contracts
DOORS – (Key User)
Structure, Control, Illicit, Develop/Edit, Link, Analyze, Discuss, Collaborate
DWA – (Review/Edit)
Analyse, Review, Discuss, Edit, Link
RPE – Deliver, Report
DWA
Requirements Manager/Seniors BA’s
Requirements Engineers/Business Analyst
Rest of the Business Stakeholders
The whole Engineering Team
DOORS
Stakeholder Review/Quality Assurance
RPE
5. Any Business Stakeholder can produce approved high quality document specifications for wider distribution across the business
1. Establish requirements process and document templates for use in all projects within a centralized database
2. Input project vision & stakeholder requirements and establish critical attribute values
3. Develop:-
functional & non-functional requirements
/system requirements
high level designs
4. Requirement reviews are carried out to to ensure requirements are correct, complete and of good quality
Slide No. 54

55. Managing Multiple Development Contracts
Inter-Contractor Requirements Reviews
Subcontractor x
Subcontractor y
Subcontractor z v
Discipline Team Reviews
Inter-Disciplinary Team Reviews
Stakeholder Reviews
Discipline Team Reviews
Inter-Disciplinary Team Reviews
Stakeholder Reviews
Discipline Team Reviews
Inter-Disciplinary Team Reviews
Stakeholder Reviews
Inter-Contractor Reviews
Inter-Contractor Requirements Reviews
This is an area which is most often neglected. Each Contractor’s plans and schedules should be aligned with those of other Contractors, and the milestones and inter-dependencies checked to ensure alignment. Agreements should be made on Interface Management during the contractual stage.
During the initial stage following contract award, inter-contractor reviews should be conducted, and the milestones and inter-dependencies should re-checked and adjusted according to any issues raised by the reviews, and the interfaces re-visited for any impact following the reviews.
There should be another set of inter-contractor reviews following each subcontractor’s refinement of the set of read-only subsystem requirements. It is here that any inter-subsystem effects between different sets of subsystem requirements can be picked up early, and resolved, prior to the completion of the subsystem development life cycle.
Slide No.

56. Information Requirements for Key Decision-making
Delivering the Desired Benefits
Create the Business Plan
Establish the Desired Benefits
Set the Objectives for delivering the Desired Benefits
Establish the Stakeholder Requirements
Consult with Key Stakeholders and produce the Stakeholder Requirements
Formulate the Benefits-related Business Requirements derived from the Objectives and merge them into the Stakeholders Requirements
Use a Requirements-driven Design approach to produce the desired outcomes and benefits
The desired benefits and the objectives of the organisation, should be stated in the Business Plan. The Stakeholders’ Requirements need to be derived by consultation with the Stakeholders, and consideration of source information, and these requirements need to be linked to the objectives. A Requirements-driven Design approach can be used to ensure that the desired outputs and benefits are achieved.
Slide No.

57. Information Requirements for Key Decision-making
Providing information for key decision making
Use of Requirements-driven design alone is not sufficient
Internal and external events impact projects and programmes
Need to provide information to key decision-makers which will support the decision-making process
Requires integration of project and programme processes (e.g. Risk Management, Change Control)
Appropriate attendance of key people at reviews
Timely delivery of essential information to key people
Requirements-driven Design is not sufficient to achieve success. There are many internal and external events that can impact projects and programmes. As these events occur, it is important to provide accurate, timely information to key decision makers, so that the decisions can be made in the light of all the available information.
Towards this end, it is important to integrate the key project processes, such as risk Management and Change Control.
Slide No.

58. Organisational Structures
Programme Board
Senior Responsible Owner
Programme Manager
Business Change Manager
Project Manager
Senior User
Project Board
Project Delivery Team
Project n
Project n + 1
Organisation
Sponsoring Group
Senior Mangers responsible for: - Investment decision
Direction of the Business
Alignment of Programme to strategic direction of organisation
Project x
Project x + 1
Single Organisation
Project Executives
The slide shows a typical organisational structure, where several projects report up to a programme Board, which in turn reports via a Senior Responsible Owner, to a Steering Group.
Slide No.

59. Roles and Responsibilities
Sponsoring Group
Responsible for:
Investment Decision
Definition of Business Direction
On-going alignment of programme to strategic direction of organisation
Senior Responsible Owner (SRO)
Securing investment for the programme
Overall direction and leadership for programme
Owns the Business Case
Accountable for programme Governance
Managing the interface with the Key Stakeholders
Personal accountability for outcome of the programme
Slide No.

60. Process Integration and Information Flow
Sponsoring Group
Programme Board
Project Board
Programme Manager
Senior Responsible Owner
Project Risk Management
Project Manager
Project
Programme
Programme Risk Management
Project Risk Register
Programme Risk Register
Project Change Control
Request Change to Requirements
Requires change to Requirements AND not manageable at Project level
Programme Change Control
Request Change to Strategic Requirements
Manage Programme Risks (including strategic), plus individual Project and cross-project Risks
Escalated Key Risks impacting on Strategy and/or Benefits
Strategic change to Requirements
Change to Requirements
Strategic, and Programme and Project, Go/NoGo decisions
Change to Programme Requirements
Change to Project Requirements
The flow of information up the organisational is shown by solid red lines, whilst the information transmitted down the organisation is shown by dotted red lines.
Key risks are reported upwards from the project level Risk Register to the programme level Risk Register, and considered at meetings of the programme Change Control Board. If key baselined requirements need to be changed, the Senior Responsible Owner reports these for consideration by the Sponsoring Group, and permission granted/refused (with alternative actions) is transmitted back down the hierarchy. Where external business events, or high impact other events, require change to strategy, with associated changes to requirements, these requirements changes are transmitted back down the hierarchy.
Slide No.
Manage project-specific Risks

61. For large complex programmes need to be CMMI Lev 3
Challenges
For large complex programmes need to be CMMI Lev 3
Maturity Levels in Capability Maturity Model Integration (CMMI) for Development
The Capability Maturity Model Integration (CMMI) was developed by Carnegie Melon University together with a group of industry experts. It can be used to guide process improvement across a project, or an entire organisation. Processes are assessed at five levels, according to their maturity levels, as: Initial; Managed; Defined; Quantitatively Managed; Optimising.
There are currently three areas of interest addressed by CMMI:
Product and Service Development – CMMI for Development (CMMI-DEV)
Service establishment, management – CMMI for Services (CMMI-SVC)
Product and service acquisition – CMMI for Acquisition (CMMI – ACQ)
For a large, complex development project/programme, the process should be mature to at least level 3 of CMMI-DEV.
Slide No.

62. Challenges
Maturity levels in Capability Maturity Model Integration (CMMI) for Development, core process areas for Maturity Level 3 - Defined
Abbreviation
Name
Core Process
DAR
Decision Analysis and Resolution 
IPM
Integrated Project Management
OPD
Organisational Process Definition
OPF
Organisational Process Focus OT
Organisational Training PI
Product Integration RD
Requirements Development
RSKM
Risk Management TS
Technical Solution
VAL
Validation
VER
Verification
The slide shows the core process areas (ticked) for Maturity Level 3 in CMMI-DEV.
Slide No.

63. Challenges At CMMI Level 3 need following Core Processes:
Configuration Management (Level 2)
Measurement and Analysis (Level 2)
Project Monitoring and Control (Level 2)
Project Planning (Level 2)
Process and Product Quality Assurance (Level 2)
Requirements Management (Level 2)
Decision Analysis and Resolution (Level 3)
Integrated Project Management (Level 3)
Organisational Process Definition (Level 3)
Organisational Process Focus (Level 3)
Organisational Training (Level 3)
Risk Management (Level 3)
This slide shows the core processes, including those at Level 2, that are needed by a project/programme at Maturity Level 3.
Slide No.

64. Challenges
Need multiple, integrated tools & applications to manage complexities of large programmes and projects
Integration of all applications/tools require N x (N-1) integrations at specific versions
Each time an application/tool changes, may require (N-1) integrations with other application/tools
For large developments, a number of integrated tools and applications are required to manage the complexity.
The integration of all the tools, each at specific versions, requires N x (N-1) integrations, where N is the number of tools. Each time a new version of a tool is released, N-1 integrations are required to integrate with the other tools.
Slide No.

65. Consider an open source common data layer (e.g. IBM Jazz, or similar)
Challenges
Consider an open source common data layer (e.g. IBM Jazz, or similar)
Inter-process data transfers using open source data layer
If the tools are interfaced with a common, open data layer, then the integration between tools is performed at the data layer. It is then only necessary to perform one integration per tool to the data layer. If a new version of a tool is released, it is only necessary to perform a single integration to the data layer for that tool.
Only necessary for 1 integration with the Data Layer for each application
Slide No.

66. Summary (i) Summary To manage the complexity
A Requirements-driven approach has been described, which provides
A structured, top-down decomposition of the complexity into manageable sizes
Full traceability from the lowest elements of the Design/Implementation, back to the Requirements, and through to compliance documents (standards, etc.)
Verification mechanisms are an integral part of the mechanisms used in the approach
The Requirements-driven approach is supported by an integrated set of Project processes, which are also tightly coupled to bespoke modules and attributes in the DOORS Database
Conclusion
Three key aspects were identified in relation to large projects:
The need to manage Complexity
The need for traceability, and
The need to provide Verification
A Requirements-driven approach has been proposed, which provides
A structured, top-down decomposition of the complexity into manageable sizes
Full traceability from the lowest elements of the Design/Implementation, back to the Requirements, through to the Stakeholder Requirements and Compliance Documentation
Verification mechanisms are an integral part of the mechanisms used in the approach
The Requirements-driven approach is supported by an integrated set of Project processes, which are also tightly coupled to bespoke modules and attributes in the DOORS Database
The Requirements-driven Design approach, using DOORS, which has been described assists with the management of the design and implementation of complex Projects, and allows comprehensive traceability and verification to be achieved
Slide No.

67. ‘the right thing is built in the right way’
Summary (ii)
Three simple principles operate at the
heart of this approach:
Specify what you require of the system
Show how you will implement it
Provide the evidence to prove that you have produced the system that was required
These principles address the initial three questions, are valid for any development, and can be used across all business sectors
The Requirements-driven approach is one that attempts to ensure that
‘the right thing is built in the right way’
The approach described operates according to three simple principles:
Specify what you require of the system
Show how you will implement it
Provide the evidence to prove that you have produced the system that was required
These principles address the initial three questions, are valid for any development, and can be used across all business sectors
The Requirements-driven approach is one that attempts to ensure that
‘the right thing is built in the right way’
Slide No.

68. Summary (iii)
Requirements-driven Design alone is not sufficient to ensure the desired outcomes and delver the required benefits
Also need:
A robust governance structure
Core processes appropriate for organisations operating at a level > CMMI Level 3
Integration of Key Processes
Sound delivery mechanisms to ensure that the necessary information reaches the Key Decision Makers in a timely fashion to support strategic decision making
An adequate set of tools and applications to support the management of the complexity of large programmes and projects
Requirements-driven Design alone is not sufficient to ensure the desired outcomes and delver the required benefits
Also need:
A robust governance structure
Core processes appropriate for organisations operating at a level > CMMI Level 3
Integration of Key Processes
Sound delivery mechanisms to ensure that the necessary information reaches the Key Decision Makers in a timely fashion to support strategic decision making
An adequate set of tools and applications to support the management of the complexity of large programmes and projects
Slide No.

69. Summary (iii)
The Requirements-driven approach is one that attempts to ensure that ‘the right thing is built in the right way’ ‘Managing Complexity in Large Development Programmes’, series of three articles published in Project Manager Today (March – May 2010) ‘Linking Key Risks to Requirements to Reduce Design Effort’, article published in Project Manager Today (December 2011) APM BoK, section Requirements management Rivkin, S, (2010) Managing Complexity in Large Development Programmes, BCS Requirements Engineering Specialist Group Requirements Quarterly: RQ54: RQ55: RQ56:
Slide No.