Why do Project Fail? Unclear or continually changing product definitions Product does not meet customer or market requirements 37% 42% Unrealistic schedule expectations Projects not adequately staffed Unclear or continually changing priorities Unrealistic financial expectations 27% 26% 24% 24% 0% 10% 20% 30% 40% 50% Source: AberdeenGroup, August 2006 1
Why is requirements management so critical? Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure - bigger than bad technology, missed deadlines or change management fiascoes - CIO Magazine, November 2005 2
IBM Software Group How to Manage Requirement 2006 IBM Corporation
Risk IBM Software Group Rational software Requirements Are Everywhere Requirements 4 Objective Feature Need Regulation Rule Goal Aim Function Criterion
V-Shape Requirement Development Statement of need Operational use Stakeholder Requirements validating the product Acceptance test confront ITIL, ISO9001 satisfies Company Standard System Requirements satisfies Subsystem Requirements satisfies Component Requirements verifying the system evaluating the subsystems evaluating components Component test Subsystem test System test IT Outsourcing Design Outsourcing Implementation Outsourcing 5
Requirement Database Unlimited hierarchy of Projects/Folders supports scalability Folders Projects DOORS Documents Deleted Folder Organize Your Projects 6
Document Views Everything you need in one window! Spell check Context Requirements OLE Improves productivity, reduces errors, increases quality 7
IBM Software Group How to Manage Requirement Relationship? 2006 IBM Corporation
Traceability is the key to Requirement Managmenet 1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves. 2. 820.30(c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s). 2.7. The design input requirements shall be reviewed by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). 2.9. The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 2.10. Questions. 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of design input. 2.10.2. From what sources are design inputs sought? 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) 2.10.3.1. intended use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.5. For the specific design covered, how were the design input requirements reviewed for adequacy? Design 1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design 1.1. Identify and development impacted elements due to a change in another element 1. Capture design and related information activities and define responsibility for implementation. Traceability Reports: consistency 1. Capture with design driving and related design information elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, Impact or result Reports: other design elements affected 1.2. Reference external information sources 1.2. Reference external information sources 1.3. Reference external documentation in, input to the design and development process. Links to impacted design elements 1.3. Reference external documentation 1.1.1. Create backward traces to design elements within and across any organizational 2. Store design and related information The plans shall be reviewed as design and development evolves. procedure 2. Store design and related information 2.1. Identify and tag design information The plans shall as unique be updated design as design elements and development evolves. 2.1. Identify and tag design information as unique design elements The plans shall be approved as design and development evolves. Traceability Reports: Procedure Attribute 2.2. Organize design elements 2.2. Organize design elements 2.2.1. Organize by Design Control Guidance Element 1.1.2. Create backward traces to design 2.2.1. elements Organize within by Design and Control across Guidance any project Element milestone 2.2.2. Organize by inter-relationships 2. 820.30(c) Design Input Traceability Reports: Milestone 2.2.2. Organize Attribute by inter-relationships 2.3. Ensure all design elements are 2.1. available Each manufacturer shall establish procedures to ensure that the design requirements 1.1.3. relating Create to backward a traces to design 2.3. Ensure elements all design within elements and are across available Design Control 2.3.1. Store design elements by Design device Control are appropriate Guidance and Element address the intended use of the device, including the needs of the user Guidance Elements 2.3.1. Store design elements by Design Control Guidance Element 2.3.2. Store design elements and their and historical patient. values 2.3.2. Store design elements and their historical values 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating Traceability to a Reports: Linked design elements 3. Manage all user needs device are appropriate and address the intended use of the device, including the 1.1.4. needs of Create the user forward impacts 3. to design Manage elements all user needs within and across any organizational 3.1. Identify the source of the user need and patient. procedure 3.1. Identify the source of the user need 3.2. Identify all user types (groups) 2.3. The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure 3.2. Identify Attribute all user types (groups) 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 1.1.5. Create forward impacts to design elements within and across any project milestone 3.4. Profile the expected patients 3.4. Profile the expected patients 3.5. State the intended use of the 2.6. product The (family) design input requirements shall be documented by a designated individual(s). Impact Reports: Milestone 3.5. State Attribute the intended use of the product (family) 3.6. Capture the acceptance criteria 2.7. for The each design user need input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design 3.6. Capture elements the acceptance within and criteria across for each Design user need Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 4. Manage design input requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage design input requirements shall be documented. Impact Reports: Linked design elements 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 2.10. Questions. 1.2. Associate changed design elements with related elements 4.2. Identify the associated user need 4.2. Identify the associated user need 4.3. Capture requirement description and 2.10.1. attributes Summarize the manufacturer's written procedure(s) for identification and control Link of Change Design Object 4.3. with Capture affected requirement design element(s) description and attributes 4.4. Capture acceptance criteria design input. Traceability Links and Reports 4.4. from Capture affected acceptance design criteria element(s) 4.5. Assign responsibility for each requirement 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that Impact apply and Links and Reports from affected design element(s) 4.6. Manage incomplete requirements 4.6. Manage incomplete requirements 4.7. Manage ambiguous requirements list additional aspects.) 1.2.1. Associate design element changes 4.7. Manage with ambiguous decisions, requirements rationale, and approval authority 4.8. Manage conflicting requirements 2.10.3.1. intended use information 4.8. Manage conflicting requirements 4.9. Approve all requirements 2.10.3.2. user/patient/clinical Change Decision Objects 4.9. with Approve following all requirements Attributes: 2.10.3.3. performance characteristics 2.10.3.4. safety Disposition Attribute 5. Manage acceptance 5. Manage acceptance 5.1. Ensure the acceptance of every user need 2.10.3.5. limits and tolerances Decision Attribute 5.1. Ensure the acceptance of every user need 5.2. Ensure the acceptance of every design 2.10.3.6. input requirement risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.3. Document the results of every user need 2.10.3.7. acceptance toxicity test and biocompatibility Owner Attribute 5.3. Document the results of every user need acceptance test 5.4. Document the results of every design 2.10.3.8. input requirements electromagnetic test compatibility (EMC) 5.4. Document the results of every design input requirements test 5.5. Make acceptance results available 2.10.3.9. compatibility with accessories/auxiliary devices Management Approval Attribute 5.5. Make acceptance results available 2.10.3.10. compatibility with the environment of intended use 1.2.2. Provide associations within and across any organizational procedure 6. Manage change 2.10.3.11. human factors Change Design Object 6. Traceability Manage change Link on Procedure Attribute 6.1. Maintain history of design element changes 2.10.3.12. physical/chemical characteristics Change Design Object Impacts 6.1. Maintain Link history on Procedure of design Attribute element changes 6.1.1. Make complete change history available 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.2. Maintain history within and across 2.10.3.14. any organizational reliability 1.2.3. Provide associations within and across any project milestone procedure 6.1.2. Maintain history within and across any organizational procedure 6.1.3. Maintain history within and across 2.10.3.15. any project statutory milestone and regulatory requirements Change Design Object Traceability 6.1.3. Maintain Link history on Milestone within and Attribute across any project milestone 6.1.4. Maintain history within and across 2.10.3.16. any Design voluntary Control standards Guidance Elements Change Design Object Impacts 6.1.4. Link Maintain on Milestone history within Attribute and across any Design Control Guidance Elements 6.2. Capture frequency and nature of element 2.10.3.17. changes manufacturing processes 1.2.4. Provide associations within 6.2. and Capture across frequency Design and Control nature Guidance of element changes Elements 6.2.1. Provide rationale for change 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.2. Describe decisions made 2.10.3.19. MDRs/complaints/failures and other historical data Change Design Object Traceability Link to traced design elements 6.2.2. Describe decisions made 6.2.3. Identify approval authority for the 2.10.3.20. change design history files (DHFs) Change Design Object Impacts 6.2.3. Link Identify to linked approval design authority elements for the change 6.2.4. Capture date, time, and signature 2.10.4. of approving For the specific authority design covered, how were the design input requirements 1.3. Mange identified? the change process 6.2.4. Capture date, time, and signature of approving authority 6.3. Identify impacted elements due to 2.10.5. a change For in the another specific element design covered, how were the design input requirements reviewed for Design Change Module 6.3. Identify impacted elements due to a change in another element 6.3.1. Create backward traces to design elements adequacy? within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone Object History Object History Reports Versions Baselines User Reqts Technical Reqts Test Cases 1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements 1.1.1. Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute 1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute 1.1.3. Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements 1.1.4. Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute 1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 1.1.6. Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) 1.2.1. Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute 1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute 1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines Initial user requirements should be decomposed to detailed requirements, then to design, tests, etc. Decomposition creates traceability relationships Relationships define your traceability model Your traceability model is the basis for your process Enforce your traceability model; improve your process 9
Traceability; drag-and-drop linking i 10 Drag-and-drop to link within a document...... or from document to document 10
Traceability view User Reqts Technical Reqts Design Test Cases 1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves. 2. 820.30(c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s). 2.7. The design input requirements shall be reviewed by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). 2.9. The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 2.10. Questions. 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of design input. 2.10.2. From what sources are design inputs sought? 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) 2.10.3.1. intended use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.5. For the specific design covered, how were the design input requirements reviewed for adequacy? 1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design 1.1. Identify and development impacted elements due to a change in another element 1. Capture design and related information activities and define responsibility for implementation. Traceability Reports: consistency 1. Capture with design driving and related design information elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, Impact or result Reports: other design elements affected 1.2. Reference external information sources 1.2. Reference external information sources 1.3. Reference external documentation in, input to the design and development process. Links to impacted design elements 1.3. Reference external documentation 1.1.1. Create backward traces to design elements within and across any organizational 2. Store design and related information The plans shall be reviewed as design and development evolves. procedure 2. Store design and related information 2.1. Identify and tag design information The plans shall as unique be updated design as design elements and development evolves. 2.1. Identify and tag design information as unique design elements The plans shall be approved as design and development evolves. Traceability Reports: Procedure Attribute 2.2. Organize design elements 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2.2.2. Organize by inter-relationships 2. 820.30(c) Design Input Traceability Reports: Milestone 2.2.2. Organize Attribute by inter-relationships 2.3. Ensure all design elements are 2.1. available Each manufacturer shall establish procedures to ensure that the design requirements 1.1.3. relating Create to backward a traces to design 2.3. Ensure elements all design within elements and are across available Design Control 2.3.1. Store design elements by Design device Control are appropriate Guidance and Element address the intended use of the device, including the needs of the user Guidance Elements 2.3.1. Store design elements by Design Control Guidance Element 2.3.2. Store design elements and their and historical patient. values 2.3.2. Store design elements and their historical values 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating Traceability to a Reports: Linked design elements 3. Manage all user needs device are appropriate and address the intended use of the device, including the 1.1.4. needs of Create the user forward impacts 3. to design Manage elements all user needs within and across any organizational 3.1. Identify the source of the user need and patient. procedure 3.1. Identify the source of the user need 3.2. Identify all user types (groups) 2.3. The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure 3.2. Identify Attribute all user types (groups) 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 1.1.5. Create forward impacts to design elements within and across any project milestone 3.4. Profile the expected patients 3.4. Profile the expected patients 3.5. State the intended use of the 2.6. product The (family) design input requirements shall be documented by a designated individual(s). Impact Reports: Milestone 3.5. State Attribute the intended use of the product (family) 3.6. Capture the acceptance criteria 2.7. for The each design user need input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design 3.6. Capture elements the acceptance within and criteria across for each Design user need Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 4. Manage design input requirements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage design input requirements shall be documented. Impact Reports: Linked design elements 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 2.10. Questions. 1.2. Associate changed design elements with related elements 4.2. Identify the associated user need 4.2. Identify the associated user need 4.3. Capture requirement description 2.10.1. and attributes Summarize the manufacturer's written procedure(s) for identification and control Link ofchange Design Object 4.3. with Capture affected requirement design element(s) description and attributes 4.4. Capture acceptance criteria design input. Traceability Links and Reports 4.4. from Capture affected acceptance design criteria element(s) 4.5. Assign responsibility for each requirement 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that Impact apply and Links and Reports from affected design element(s) 4.6. Manage incomplete requirements 4.6. Manage incomplete requirements list additional aspects.) 1.2.1. Associate design element changes with decisions, rationale, and approval authority 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements 4.8. Manage conflicting requirements 2.10.3.1. intended use information 4.8. Manage conflicting requirements 4.9. Approve all requirements 2.10.3.2. user/patient/clinical Change Decision Objects 4.9. with Approve following all requirements Attributes: 2.10.3.3. performance characteristics 2.10.3.4. safety Disposition Attribute 5. Manage acceptance 5. Manage acceptance 5.1. Ensure the acceptance of every user need 2.10.3.5. limits and tolerances Decision Attribute 5.1. Ensure the acceptance of every user need 5.2. Ensure the acceptance of every design 2.10.3.6. input requirement risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.3. Document the results of every user need 2.10.3.7. acceptance toxicity test and biocompatibility Owner Attribute 5.3. Document the results of every user need acceptance test 5.4. Document the results of every design 2.10.3.8. input requirements electromagnetic test compatibility (EMC) 5.4. Document the results of every design input requirements test 5.5. Make acceptance results available 2.10.3.9. compatibility with accessories/auxiliary devices Management Approval Attribute 5.5. Make acceptance results available 2.10.3.10. compatibility with the environment of intended use 1.2.2. Provide associations within and across any organizational procedure 6. Manage change 2.10.3.11. human factors Change Design Object 6. Traceability Manage change Link on Procedure Attribute 6.1. Maintain history of design element changes 2.10.3.12. physical/chemical characteristics Change Design Object Impacts 6.1. Maintain Link history on Procedure of design Attribute element changes 6.1.1. Make complete change history available 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.2. Maintain history within and across 2.10.3.14. any organizational reliability 1.2.3. Provide associations within and across any project milestone procedure 6.1.2. Maintain history within and across any organizational procedure 6.1.3. Maintain history within and across 2.10.3.15. any project statutory milestone and regulatory requirements Change Design Object Traceability Link on Milestone Attribute 6.1.3. Maintain history within and across any project milestone 6.1.4. Maintain history within and across 2.10.3.16. any Design voluntary Control standards Guidance Elements Change Design Object Impacts 6.1.4. Link Maintain on Milestone history within Attribute and across any Design Control Guidance Elements 6.2. Capture frequency and nature of element 2.10.3.17. changes manufacturing processes 1.2.4. Provide associations within 6.2. and Capture across frequency Design and Control nature Guidance of element changes Elements 6.2.1. Provide rationale for change 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.2. Describe decisions made 2.10.3.19. MDRs/complaints/failures and other historical data Change Design Object Traceability Link to traced design elements 6.2.2. Describe decisions made 6.2.3. Identify approval authority for the 2.10.3.20. change design history files (DHFs) Change Design Object Impacts 6.2.3. Link Identify to linked approval design authority elements for the change 6.2.4. Capture date, time, and signature 2.10.4. of approving For the specific authority design covered, how were the design input requirements 1.3. Mange identified? the change process 6.2.4. Capture date, time, and signature of approving authority 6.3. Identify impacted elements due to 2.10.5. a change For in the another specific element design covered, how were the design input requirements reviewed for Design Change Module 6.3. Identify impacted elements due to a change in another element 6.3.1. Create backward traces to design elements adequacy? within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone Object History Object History Reports Versions Baselines 1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements 1.1.1. Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute 1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute 1.1.3. Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements 1.1.4. Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute 1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 1.1.6. Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) 1.2.1. Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute 1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute 1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines End-to-end visual validation in a single view 11
Traceability Verification or Completeness Increases customer confidence Detect missing links Creation and deletion of links is recorded in history Traceability through an Orphan report shows missing links 12
Impact / Derivation Analysis Stakeholder Requirements Impact Analysis Acceptance test Plan System Requirements Impact Analysis Subsystem Requirements Component Requirements Derivation Analysis Derivation Analysis System test plan Integration test plan Component test plan 13
Requirement Coverage Analysis Stakeholder Requirements All requirements are allocated to sub requirements? Acceptance test Plan System Requirements System test plan Subsystem Requirements All requirements are tested without an exception? Integration test plan Component Requirements Component test plan 14
IBM Software Group How to Manage Requirement Change? 2006 IBM Corporation
Suspect Links Suspect links are visible directly in the document - as indicators or as a full description Clear on a right click Never miss a change again 16
The Requirement lifecycle Nonintegrated project data is imported, structured, linked and traced, i to produce reports of managed information 17
Problems (or Risk) of Outsourcing Risks are not fully shifted to outsourcing as Stakeholders bear the risk of project failure. Requirements are not fully covered by testing Lack of defect management process Lack of validation and verification Lack of Project Transparency 18
The unsuccessful failure rate for software projects is still alarmingly high Software project results Project success rates average less than 55% Cancelled projects cost $81 Billion worldwide each year Of the 50% of projects which are successfully delivered, 28% of these projects are not yielding the expected planned value Software project waste $55 Billion $38 Billion in lost dollar value $17 Billion in cost over runs Although cancellation rates are down and fewer projects are troubled, improving software development governance provides increased value to projects, producing about 30% more projects that deliver expected value. Source: Standish Chaos Report, Allinean ROI of Software Development 19
IBM Software Group How to Plan? 2006 IBM Corporation
Quality management plan First step to succeed Create snapshot to record of your progress. Structured plan to fulfill Software Sub-contact Management, e.g. Business Objectives, Requirements, Acceptance Criteria, Schedule, Attachments, & etc 21
IBM Software Group How to Manage Test Coverage? 2006 IBM Corporation
Test Coverage Find requirements that have or have no test case 23
Test Coverage on updated (suspect) requirement 24
Test Coverage on updated (suspect) requirement 25
IBM Software Group How to Manage Defect? 2006 IBM Corporation
Defect Management Transparent and centralised overview of development requests and status List of defects with status 27
Defect Management Dashboard Provide information about the project status Notifications, and defects will be displayed in dashboard profile: know which projects are involved Customisable charts for project analysis Know what is happening in this project 28
Defect Management Vendor to fix defects Find Potential Duplicates Vendor fixes defect and update status Important communication is kept in discussion section 29
Defect Management Audit Trail 30
Defect Management Traceability understand which requirement has defect 31
IBM Software Group How to Verify Quality? 2006 IBM Corporation
Validation on Quality Management Plan Reviewal and Approval 33
Verification on Quality Test Execution overview Result Details Vendor provides step-by-step screenshots evidence as attachments. 34
IBM Software Group How to Manage Project Transparency? 2006 IBM Corporation
Project Transparency - On demand reporting Snapshot views of project status from multiple perspectives Customizable reporting enables sharing and communication of vital project information 36
Project Transparency - Finding overdue items Over due item 37
Project Transparency Finding all outstanding defects Have vendor fixed all the defects? 38
Project Transparency Acceptance Criteria 39
IBM Software Group How to Manage Multiple Projects? 2006 IBM Corporation
Multi-Project Support Representation of software projects Different Project Area for different vendor 41
Summary Business Benefits: Requirement Coverage Make Sure that Project is focusing on defined Requirement inside the lifecycle, not at the end. Defect Management All parties have visibility on defects and all activities, Sub-Contractor will be notified when new defects raised. Can be traced to requirements. Validation and Verification Review + Approval + Collaboration. Evidence to meet Acceptance Criteria. Project Transparency Real-time Dashboard + Report. Business Stakeholders and subcontractors can be anywhere in the world and work around the clock. Quality Assurance Business Sub- Contractors 42
Centralized Quality Management Solution IBM Collaborative Application Lifecycle Management Telelogic DOORS Collaborative Requirement Repository Requirement Traceability Impact Analysis Test Requirement Bi-directional auto-synchronization IBM Collaborative Application Lifecycle Management Rational Quality Manager Quality Dashboard Quality Management Test Result Create Plan Build Tests Execute Tests Report Results Manage Defects 43
Flexible Deployment Customer Outsourcing IBM Collaborative Application Lifecycle Management Telelogic DOORS Collaborative Requirement Repository Requirement Traceability Impact Analysis IBM Collaborative Application Lifecycle Management Rational Quality Manager Quality Dashboard Quality Management Create Plan Build Tests Manage Test Lab Execute Tests Report Results 44
Benefits Reduce outsourcing projects still have high failure rate [DOORS] Requirement Repository to maintain the Source of Trust [DOORS] Requirement Integrity through Traceability Mitigate Potential risks of using Sub-contractors [RQM] Real Time Quality Dashboard to increase Transparency [RQM] Test Coverage visibility [RQM] Defect Management Improve your winning chance when outsourcing projects Real Time Monitoring & Tracking during lifecycle Full Lifecycle Traceability ensure No Missing Issue Highly Quality project delivery 45
46