Presentation on theme: "Managing complexity in large development programmes Presenter: Dr Steve Rivkin, Acando UK University of Manchester 11 October 2012."— Presentation transcript:
1Managing complexity in large development programmes Presenter: Dr Steve Rivkin, Acando UK University of Manchester 11 October 2012
2Topics to be Covered Common problems Requirements management Requirements-driven DesignProject Support processesBenefits of Process IntegrationManaging Commercial and Legal RequirementsOperation, Maintenance and System DisposalBenefits of Requirements-driven DesignExample of graphical navigationConformance to International StandardsSafety Case Life CycleMultiple Life CyclesProfiling Requirements to Industry SectorsNuclear Safety Case ExamplePharmaceutical drug Development ExampleMultiple ContractorsInformation Requirements for Key Decision MakersDecision Process Integration and Information FlowChallengesSlide No.
3Common Problems Stakeholder & Programme/System Requirements inadequate Contractor(s) have previous experience and ‘know’ what is neededEven if more detailed requirements produced, not linked to Stakeholders’ RequirementsDesigns not linked formally to Stakeholders’ Requirements or System RequirementsOne 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.
4Common Problems Legal advice => only award contracts against well specified sets of requirementsStill no linkage between Stakeholders’ Requirements and System requirementsNo auditable traceability from Stakeholders’Requirements to System Requirements & DesignCan’t prove design meets Stakeholders’ & System RequirementsWhen Client’s specialists study completeddesigns, some aspects may fail to meet System and/or Stakeholder ReqsA 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 designThere 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 RequirementsWhen 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 allSlide No.
5Three Questions Three Fundamental Questions must be Addressed for any Development:What do you want?What => RequirementHow will you do it?How => DesignCan you prove you have done what you said you would doProof => VerificationIn 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.
6Strategy The strategy must: address the three questions Provide a means of specifying and capturing the RequirementsAllow for the specification of the Design(s), whilst accommodating various design approachesProvide verification mechanisms so that it can be shown you have done what you said you would doAny 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.
7What Type of Requirements Approach DefinitionRequirement management is the process of capturing, assessing and justifying stakeholders’ wants and needsSuccessA clear and agreed expression of requirements and their acceptance criteria is essential for the success of any project, programme or portfolio.Four Step Processgather 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 practiceSteps 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 Requirementsis 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.
8Requirements Management - management aspects Requirements Management is necessary to avoid problems describedNeeds:Senior Management buy-inBacked up with budgetA Requirements ManagerRequirements Management PlanStrategy (which addresses the 3 questions)Allocation of Resources (Team Requirements Representative)Generic approach across the geography)Requirements management activities detailed in the project scheduleElicitationAnalysisReviewsA 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 possibleThe 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.
9Requirements 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 requirementsAdditional 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.
10Requirements-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.
11Requirements Driven Design Suitable for large development projects with known direction and desired outcomesAddresses the three questions:Capture and evolve requirements hierarchyonly start design when a clear set of requirements agreed at corresponding level What => RequirementComplete auditable traceability down through Requirements hierarchy and to designs How => DesignVerification evidence provided Proof => Verificationjustifies all derived requirementsshow how requirements are implemented by designIn 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 considerationsthe 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 Completedif required, an assumption would be raiseda 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 Argumentthe 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 completedThe 2nd cycle, the Design Cycle, commences:For each requirementThe linked design element is completed, specifying how the design will implement what is stated in the requirementThe Verification Argument is created and entered into the linked Design Verification ArgumentSlide No.
12Requirements-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 requirementsLevels of Design corresponding to the various levels of the sets of RequirementsSlide No.
13Requirements-driven Design Structures Satisfaction Argument StructureThe Satisfaction Argument (SA) ConstructA 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.
14Example of a Satisfaction Argument Requirements Modules in DOORSThe 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 Argumentin the DOORS DatabaseSlide No.
15Requirements 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 ModulesAn example of a drop-down (or ‘combo’) box, offering options for selection to indicate the type of validation needed for specific RequirementsAn extract from a Verification View that is used to verify how a particular portion of design addresses what is wanted by a specific RequirementSlide No.
16Requirements-driven Design Strategy Overall Requirements StrategyCreate Requirements Management PlanDefines the overall strategyRequirements-driven Design ProcessesImplemented in 2 iterations per stage for each level of Requirements/DesignRequirements DefinitionRequirements Elicitation & CaptureRequirements AnalysisRequirements ReviewRequirements VerificationRequirements baselining => Delivers a set of RequirementsDesign SpecificationCreate designsDesign and DVA Reviews => delivering Design elements linked to corresponding RequirementsOverall Requirements StrategyAs 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 & CaptureRequirements AnalysisRequirements ReviewRequirements VerificationRequirements baseliningSlide No.
17Requirements Capture & Elicitation (Style & Formulation) What makes a ‘robust’ requirement?Each requirement must:Stand aloneSpecify clearly and unambiguously what is wantedMust be verifiableMust be necessaryMust be achievableMust be traceableMust be at the right levelMust be well-formedEach requirement must be written in a formal stylee.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.
18Requirements Review Design Teams Review their own Set of Requirements: Examine structure of Team’s Requirement SetCheck Requirements against criteria for a ‘Good Requirement’Unambiguous, verifiable, necessary, achievable, traceable, at the right level, well-formedCheck that each Requirement is TestableWhat is the Test Method?Test, Analysis, Demonstration, Inspection, To be specified at a later stage of DesignAre 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.
19Design and Verification Argument Review Disciplinary, Inter-Disciplinary, and Stakeholder Requirements and Satisfaction ArgumentPerform Reviews:Disciplinary => Requirements + Satisfaction ArgumentsInter-Disciplinary => RequirementsPromoter ReviewStakeholder => RequirementsReview the Design Verification Arguments (DVAs) + the DesignDiscipline ReviewsInter-Disciplinary ReviewsStakeholder Review of RequirementsCreate a System Baseline Set of RequirementsUpdate the DVAs and/or Requirements and the Design according to commentsThe 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.
20System Engineering Structures and processes Requirements Management- System engineering and managementSystem Engineering Structures and processesImportant for Requirements Manager to work with otherprocess managers to:Understand how other processes interact with Requirements Management processLiaison with managers of key areas (Risk, Change Control)Integration of processesDetermine data required to manage other processesEstablish specific data to be managed in DOORSStructuresSchemaOrganisation of RequirementsAttributes of RequirementsA 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.
21Key Project Support Processes Requirements ManagementAssumptions ManagementChange ControlRisk ManagementIssue ManagementLegal ProcessEnvironmental Management processWe 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.
22Supporting Project Processes - Risk Management Here the slide shows a Process Model for a Risk Management process.Slide No.
23Benefits of Processes Integration - Risk Management Purpose of Risk Register:- capture and maintain information on identified threats and opportunitiesEach risk is allocated a unique identifier (Risk ID) as well as details such as:Who raised the riskThe category of riskThe description of the risk (cause, risk event, effect)Probability, impact and expected valueProximityRisk ownerThis slide shows some of the attributes which need to be stored in a Risk RegisterSlide No.
24Changing Requirements A Requirement may need to be changed if:An Assumption proves to have been incorrectDesign details indicate that the Requirement:cannot be implemented as original thoughtAlternative design needs a modification to the RequirementChange Control process used to:Manage changes to Design and/or RequirementsIf Requirement part of set that has not yet been baselined, then manage change locally within Project TeamIf Requirement part of Baselined set, then refer ‘Change Request’ to Project Review Board for decision about changeHere 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.
25Supporting Project Processes - Change Control This slide shows a Process Model for a Change Control process.Slide No.
26Project 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 ArgumentsDesigns and their corresponding Design Verification Arguments.Slide No.
27Benefits of Processes Integration - Risk Management A matrix can be constructed where the cellsof the matrix reflect ranges of Risk ScoreProbabilityVery HighVHΛVLVHΛLVHΛMVHΛHVHΛVHHighHΛVLHΛLHΛMHΛHHΛVHMediumMΛVLMΛLMΛMMΛHMΛVHLowLΛVLLΛLLΛMLΛHLΛVHVery LowVLΛVLVLΛLVLΛMVLΛHVLΛVHImpactThe 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 matrixSlide No.
28Benefits of Processes Integration - Risk Management Enter new risk into the Risk RegisterRequirements 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 RegisterA 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) RiskThe Risk ID attribute in DOORS is linked to the new (or existing) Risk in the Risk RegisterWhen 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.
29Benefits 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.
30Managing Commercial and Legal Requirements The slide shows examples of a number of different types of sets of requirements:SystemTechnicalLegalEnvironmentalSafetyRequirements-driven approach cansupport both technical & non-technical requirementsIn 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 teamsWithout 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.
31Whole Life Cycle Considerations TestingRHS of V-Model shows Unit Testing through to System testingWhen the Left Hand Side (LHS) requirements are created, the method of testing must be specifiedThis information can be used to formulate the test requirements, which are used to define what is needed in the test scriptsPeer-to-peer testing is performed, using the Right hand Side (RHS) test scripts to test that the LHS requirements have been metA Test Verification Argument (TVA) is created linking each RHS test result to its LHS requirementThe TVA shows how the test, and test result (verified against predicted results) verify that LHS requirement has been metOperation, Maintenance & SupportThe Operational, Maintenance and Support Requirements should be specified during the creation of the LHS requirements hierarchyWhen 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 AssetsThe Maintenance RegimeKPI Monitoring and ReportingThe KPI monitoring procedures obtain metrics on the performance of the operational systemPeriodic reports are produced from the KPI dataReports compare actuals against KPI targetsSystem DisposalDisposal requirements should be established during the creation of the LHS requirementsShould encompass factors such as: design lifetime, build materials, locationThe 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.
32Benefits of Reqs-driven Design Benefits of the Requirements Driven Approach:The Design evolves thoroughly from the Stakeholder RequirementsThe Design Brief will be clear, and the Design will require no iterationLarge teams of Engineers will not be tied into the Design Phase for extended periodsThere is full, auditable traceability through the requirements hierarchy and to every element of each level of designEarly 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 costProject-wide visibility, and use of natural language, promotes better understanding for engineers across all disciplinesVerification evidence at each stage contributes incrementally to the Safety CaseThe 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 requirementsThe Design Brief will be clear, so that the design will require no iterationLarge teams of engineers will not be tied into the Design Stage for extended periods, as there should be no iterationThere will be a full, auditable traceability through the requirements hierarchy and to every element of each level of designEarly 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 costProject-wide visibility, and use of natural language, promotes better understanding for both the Project Team and the stakeholdersThe Verification evidence at each stage contributes incrementally to the Safety CaseSlide No.
33Example: Guide to Railway Investment Projects (GRIP) One of key elements for success isgood communicationconsider using graphical applications(e.g. MindManager) to document processes and process interactionsinclude contextual help (including DOORS help)Link through to DOORS and carry out operations directly in DOORSExample 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 projectsAlso best practice recommended by major professional bodies including:the Office of Government Commerce (OGC)the Association of Project ManagementCovers the investment lifecycle from inception through to the post-implementation realisation of benefitsDynamic Map ExamplesThe following sequence is followed in the demonstration of graphical navigation shown in the video of the presentationClick on the ‘Dynamic Map Examples’ hyperlinkIf 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 automaticallyInitially shows a project organisation structureThen goes into the top level of the engineering processes, via the project phases, into the Requirements Management processShows 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 processNext, the Risk Management processThen 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.
34Some examples of large projects using DOORS Heathrow Terminal 5Cross 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 5The East London Line railwayAnd the £17 Billion Crossrail projectEast London LineSlide No.
35Conformance to International Standards ISO/IEC Life Cycle ProcessesISO/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 specifyThe Life Cycle Model to be usedManagement of the total Project InfrastructureThe Project Portfolio - the Business-related aspects of the ProjectProject Resourcing and staff managementQuality Managementthe Quality System to be usedHow it is to be managedThe Quality Plan requirements, etc.The Project Processes – (described on the slide)The Technical Processes – (described on the slide)Slide No.
36Additional 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 ofSlide No.
37Application 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.
38ISO/IEC 15288 Systems Life Cycle ISO/IEC 15288:2008 Life CycleAgreement ProcessesOrganisational & Project Enabling ProcessesProject ProcessesTechnical ProcessesStakeholder Requirements DefinitionRequirements AnalysisArchitectural DesignImplementationIntegrationVerificationTransitionValidationThere 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.
39Safety Case Life Cycle Safety Case Life Cycle Slide No. Establish Stakeholder Safety RequirementsAND (if there are pre-existing Designs)Generic Design Assessment (GDA)[from Suppliers]High Level OptioneeringSingle Option (for the overall approach)Produce Preliminary Safety Report (PSR)Generate System Safety Final RequirementsProposed System Integrity Level (SIL)Pre-Construction Safety Report (PCSR)Pre-Operational Safety Report (POSR) – i.e the Safety CasePCmSR1 (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.
40Traditional V-model Life Cycle Traditional Life CycleUnit TestSystem TestSystem AcceptanceDe-commissionBusiness CaseBusiness ObjectivesSystem ProcurementInvitation to TenderRequirements DefinitionHigh Level DesignDetailed DesignImplementationIntegrationOperate & MaintainDesign Outputs contribute to Safety CaseTraditional Life Cycle: Business Case; Business Objectives; System Procurement; Requirements Definition; System Test; System Acceptance; Operate & Maintain; De-commissionSlide No.
41Multiple V-Model Life Cycles Traditional Life CycleSafety Case Life CycleIn 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 CycleSlide No.
42Multiple V-Model Life Cycles Business CaseBusiness ObjectivesSystem ProcurementInvitation to TenderRequirements DefinitionHigh Level DesignDetailed DesignImplementationUnit TestIntegrationSystem TestSystem AcceptanceOperate & MaintainDe-commissionTraditional Life CycleSafety Case Life CycleRequirements ElicitationPrepare ManualsTest on Target Trainee GroupTrainingDistribute ManualsEstablish Stakeholder Safety RequirementsAND (if there are pre-existing Designs)Generic Design Assessment (GDA)[from Suppliers]Agreement ProcessesTraining Package DevelopmentOrganisational & Project Enabling ProcessesHigh Level OptioneeringPre-Operational Safety Report (POSR) – i.e the Safety CaseProject ProcessesSingle Option (for the overall approach)ValidationTechnical ProcessesPCmSR2 (Active Pre-Commissioning Safety Report)Stakeholder Requirements DefinitionProduce 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 CycleProposed System Integrity Level (SIL)TransitionRequirements AnalysisGenerate System Safety Final RequirementsVerificationArchitectural DesignPre-Construction Safety Report (PCSR)Design Outputs contribute to Safety CaseNOTE: Review Gateways and Safety Hold Points would be established by considering all the contributing Life CyclesIntegrationImplementationSlide No.
43Mechanics of Conformance Map major deliverables and Gateways onto traditional V-modelUse CAs to merge in the requirements of a standard into the requirements sets at appropriate stages of the development life cycleEach CA links to clause in standard that has caused the need for a requirementCA argument states why requirement is necessary, and how it addresses the clause in the standardConformance 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 standardSlide No.
44Regulated Industries – Safety Case Considerations Major Stages of a Nuclear Plant Associated Safety CasesLife CycleEarly Design Preliminary Safety CasePre- Construction and Installation Pre- Commencement (Construction) Safety Case(including modifications)Pre- Commissioning Pre- Inactive Commissioning Safety CasePre- Active Commissioning Safety CasePre- Operation Pre-Operational Safety CaseOperation Plant or Station Safety Case or Site WideSafety Case if relevantUpdated as necessaryPeriodically reviewedPost Operation Post- Operational Safety CasePre- Decommissioning Safety Strategy Overview (applies to complex decommissioning projects only)Decommissioning Decommissioning StrategySafety Case(s) for DecommissioningOperationsPost- Decommissioning Post-DecommissioningClearance Safety CaseThe 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.
45Regulated Industries – Safety Case Considerations Pre- Inactive Commissioning Safety CaseTo demonstrate that the plant as-built meets relevant safety criteria and is capable of safe operationTo enable the production of a programme of safety commissioning activities that will:-demonstrate as far as practicable the safe functioning of all systems and equipmentprove as far as practicable all safety claimsconfirm as far as practicable all safety assumptions confirm as far as practicable the effectiveness of all safety related proceduresTo list aspects of safety that cannot be demonstrated inactivelySome 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.
46Regulated Industries – Safety Case Considerations Key PointsRequirements-driven Design provides a genericmethodology 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 informationThe Safety Cases need to access the verification evidence in specific, prescribed ways at each stage of the Safety Case Lifecycle and are, therefore, not genericbutThe verbs in the Safety Case Purpose statements are generic in the nature of what they requireThereforeWe can use generic sub-schemas correspondingto each type of verb alongside the genericstructures of Requirements-driven DesignRequirements-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.
47Regulated Industries – Safety Case Considerations Req IDStatementObj TypeReq TypePSC.1Statement of IntentHeaderPSC.2Textual StatementText||||||Control and ManagementHeaderPSC.nPSC.n+1Control and ManagementRequirementDemonstratePSC.n+2Control and ManagementRequirementDemonstrateOption SelectionHeaderPSC.mPSC.nDiscussion and selection of optionsTextThis 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 ModuleSlide No.
48Regulated Industries – Safety Case Considerations Generic Sub-schemasSAURLDesign ReportsDVAEarly DesignStageEarly DesignRequirementsPrelim SafetyCase RequirementsDocument Management System‘Demonstrate’ ModuleValidation Methods ModuleTest Management ModuleSpecific Test MethodsTest ScriptTest ResultsSAPre- Construction and Installation StagePre- Construction and Installation RequirementsSafety Analysis Module‘Prove’ ModuleURLURLSpecific Analytical TechniquesHere 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 MethodsModuleAnalysisURLGeneric Schema for ‘Demonstrate’ Requirementverification evidenceDocument Management SystemGeneric Schema for ‘Prove’ RequirementDocument Management SystemResults of Analysisverification evidence‘Demonstrate’ Schema diagramSlide No.
49Regulated Industries – Safety Case Considerations Site Wide Safety CaseSite Wide Safety CaseGeographical Region 1Pre- Commencement Safety CasePre- Commencement Safety CasePre- Inactive Commissioning Safety CaseGeographical Region nPre- Active Commissioning Safety CasePlant ‘n’ or Station Safety CaseThe 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 CasePlant ‘1’ or Station Safety CaseSlide No.
50Example: Pharma Development Life Cycle Life Cycle Management for the Life Science and Medical Devices IndustriesCompliance 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 controlledLife 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 controlledIn 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.
51FDA's Drug Review Process Pre-clinical (Animal) TestingInvestigational New Drug(IND) ApplicationShow FDA results of preclinical testing and what is propose d for human testingPhase 1 Studies(typically 20 to 80 people)Phase 2 Studies(typically a few dozento about 300 people)Phase 3 StudiesPre-NDA period (FDA anddrug sponsors meet)(typically several hundredto about 3000 people)Submission of an NDAThis 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 approvalFDA decision whetherto Review (60 day period )FDA files NDAFDA review team evaluates the sponsor's research on drug's safety and effectivenessSlide No.
52Managing Multiple Development Contracts Detailed Requirements ElicitationSubcontractor 1Subcontractor nSystem RequirementsSubsystem 1 RequirementsSubsystem n RequirementsTraditional Life CycleApportionment ofRequirements to SubcontractorsThe 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.ImplementationMain Project V-model Life CycleSlide No.
53Managing Multiple Development Contracts Access control & remote working capabilities of DOORS can support management of multiple contractsSets of requirements can be allocated to, or produced by, various contractorsSets can be linked to Project Teams’ requirements via SAsContractors only given Read Access to Project Teams’ requirementsSubsystems developed & implemented, then tested by Contractors against contracted set of requirements, and test results reviewed by ClientCompleted subsystems can be integrated into overall system during the subsystem and system integration phases of life cycleThe 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.
54Managing Multiple Development Contracts DOORS – (Key User)Structure, Control, Illicit, Develop/Edit, Link, Analyze, Discuss, CollaborateDWA – (Review/Edit)Analyse, Review, Discuss, Edit, LinkRPE – Deliver, ReportDWARequirements Manager/Seniors BA’sRequirements Engineers/Business AnalystRest of the Business StakeholdersThe whole Engineering TeamDOORSStakeholder Review/Quality AssuranceRPE5. Any Business Stakeholder can produce approved high quality document specifications for wider distribution across the business1. Establish requirements process and document templates for use in all projects within a centralized database2. Input project vision & stakeholder requirements and establish critical attribute values3. Develop:-functional & non-functional requirements/system requirementshigh level designs4. Requirement reviews are carried out to to ensure requirements are correct, complete and of good qualitySlide No.54
55Managing Multiple Development Contracts Inter-Contractor Requirements ReviewsSubcontractor xSubcontractor ySubcontractor zvDiscipline Team ReviewsInter-Disciplinary Team ReviewsStakeholder ReviewsDiscipline Team ReviewsInter-Disciplinary Team ReviewsStakeholder ReviewsDiscipline Team ReviewsInter-Disciplinary Team ReviewsStakeholder ReviewsInter-Contractor ReviewsInter-Contractor Requirements ReviewsThis 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.
56Information Requirements for Key Decision-making Delivering the Desired BenefitsCreate the Business PlanEstablish the Desired BenefitsSet the Objectives for delivering the Desired BenefitsEstablish the Stakeholder RequirementsConsult with Key Stakeholders and produce the Stakeholder RequirementsFormulate the Benefits-related Business Requirements derived from the Objectives and merge them into the Stakeholders RequirementsUse a Requirements-driven Design approach to produce the desired outcomes and benefitsThe 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.
57Information Requirements for Key Decision-making Providing information for key decision makingUse of Requirements-driven design alone is not sufficientInternal and external events impact projects and programmesNeed to provide information to key decision-makers which will support the decision-making processRequires integration of project and programme processes (e.g. Risk Management, Change Control)Appropriate attendance of key people at reviewsTimely delivery of essential information to key peopleRequirements-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.
58Organisational Structures Programme BoardSenior Responsible OwnerProgramme ManagerBusiness Change ManagerProject ManagerSenior UserProject BoardProject Delivery TeamProject nProject n + 1OrganisationSponsoring GroupSenior Mangers responsible for: - Investment decisionDirection of the BusinessAlignment of Programme to strategic direction of organisationProject xProject x + 1Single OrganisationProject ExecutivesThe 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.
59Roles and Responsibilities Sponsoring GroupResponsible for:Investment DecisionDefinition of Business DirectionOn-going alignment of programme to strategic direction of organisationSenior Responsible Owner (SRO)Securing investment for the programmeOverall direction and leadership for programmeOwns the Business CaseAccountable for programme GovernanceManaging the interface with the Key StakeholdersPersonal accountability for outcome of the programmeSlide No.
60Process Integration and Information Flow Sponsoring GroupProgramme BoardProject BoardProgramme ManagerSenior Responsible OwnerProject Risk ManagementProject ManagerProjectProgrammeProgramme Risk ManagementProject Risk RegisterProgramme Risk RegisterProject Change ControlRequest Change to RequirementsRequires change to Requirements AND not manageable at Project levelProgramme Change ControlRequest Change to Strategic RequirementsManage Programme Risks (including strategic), plus individual Project and cross-project RisksEscalated Key Risks impacting on Strategy and/or BenefitsStrategic change to RequirementsChange to RequirementsStrategic, and Programme and Project, Go/NoGo decisionsChange to Programme RequirementsChange to Project RequirementsThe 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
61For large complex programmes need to be CMMI Lev 3 ChallengesFor large complex programmes need to be CMMI Lev 3Maturity Levels in Capability Maturity Model Integration (CMMI) for DevelopmentThe 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.
62ChallengesMaturity levels in Capability Maturity Model Integration (CMMI) for Development, core process areas for Maturity Level 3 - DefinedAbbreviationNameCore ProcessDARDecision Analysis and ResolutionIPMIntegrated Project ManagementOPDOrganisational Process DefinitionOPFOrganisational Process FocusOTOrganisational TrainingPIProduct IntegrationRDRequirements DevelopmentRSKMRisk ManagementTSTechnical SolutionVALValidationVERVerificationThe slide shows the core process areas (ticked) for Maturity Level 3 in CMMI-DEV.Slide No.
63Challenges 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.
64ChallengesNeed multiple, integrated tools & applications to manage complexities of large programmes and projectsIntegration of all applications/tools require N x (N-1) integrations at specific versionsEach time an application/tool changes, may require (N-1) integrations with other application/toolsFor 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.
65Consider an open source common data layer (e.g. IBM Jazz, or similar) ChallengesConsider an open source common data layer (e.g. IBM Jazz, or similar)Inter-process data transfers using open source data layerIf 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 applicationSlide No.
66Summary (i) Summary To manage the complexity A Requirements-driven approach has been described, which providesA structured, top-down decomposition of the complexity into manageable sizesFull 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 approachThe 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 DatabaseConclusionThree key aspects were identified in relation to large projects:The need to manage ComplexityThe need for traceability, andThe need to provide VerificationA Requirements-driven approach has been proposed, which providesA structured, top-down decomposition of the complexity into manageable sizesFull traceability from the lowest elements of the Design/Implementation, back to the Requirements, through to the Stakeholder Requirements and Compliance DocumentationVerification mechanisms are an integral part of the mechanisms used in the approachThe 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 DatabaseThe 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 achievedSlide No.
67‘the right thing is built in the right way’ Summary (ii)Three simple principles operate at theheart of this approach:Specify what you require of the systemShow how you will implement itProvide the evidence to prove that you have produced the system that was requiredThese principles address the initial three questions, are valid for any development, and can be used across all business sectorsThe 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 systemShow how you will implement itProvide the evidence to prove that you have produced the system that was requiredThese principles address the initial three questions, are valid for any development, and can be used across all business sectorsThe Requirements-driven approach is one that attempts to ensure that‘the right thing is built in the right way’Slide No.
68Summary (iii)Requirements-driven Design alone is not sufficient to ensure the desired outcomes and delver the required benefitsAlso need:A robust governance structureCore processes appropriate for organisations operating at a level > CMMI Level 3Integration of Key ProcessesSound delivery mechanisms to ensure that the necessary information reaches the Key Decision Makers in a timely fashion to support strategic decision makingAn adequate set of tools and applications to support the management of the complexity of large programmes and projectsRequirements-driven Design alone is not sufficient to ensure the desired outcomes and delver the required benefitsAlso need:A robust governance structureCore processes appropriate for organisations operating at a level > CMMI Level 3Integration of Key ProcessesSound delivery mechanisms to ensure that the necessary information reaches the Key Decision Makers in a timely fashion to support strategic decision makingAn adequate set of tools and applications to support the management of the complexity of large programmes and projectsSlide No.
69Summary (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.