1. ® IBM Software Group © 2007 IBM Corporation The Importance of a robust Requirements Engineering Process Richard Crisp – Director, RM and QM Product Delivery

2. IBM Software Group | Rational software 2 Efficiency Business Value Control & Flexibility Individual productivity through automation Global team effectiveness & collaboration lowering costs Organizational governance & asset utilization driving greater predictability Software investment management aligned with business & operational priorities BUSINESS FOCUS AND IMPACT The “Business Process” of Systems and Software Delivery… A focus on delivering business differentiation leveraging Systems and software as a strategic business asset TeamIndividualBusinessOrganization S C O P E Optimizing Systems and software “supply chains”

3. IBM Software Group | Rational software 3 There is a Significant Impact to the Business As a Result or a Poor Requirements Engineering Process Requirements Rework  Errors, late detected in the Maintenance phase can cost up to 200 times more than detected early in Requirement Analysis phase 1  More than 40% of development budget can be consumed by poor requirements 2 Project Impacts  41% of projects fail to deliver the expected business value and ROI 3  49% of projects overrun original estimates 3  28% of projects on time and on budget 4 Requirements Delays  Being late to market by 6 months or more will cost organizations 33% of the 5-year ROI 5 “Our research indicates 80-plus percent of development failures result directly from poor requirements gathering, management, and analysis.” IDC, November 2007 Requirements issues drive excessive rework, delays, poor quality, and project failures 20 200 Relative Cost to Repair Acceptance Test Unit TestCodingDesignAnalysis 0 Maintenance 1-2 10 5 50 Time not spent in requirements is time spent in rework (at cost x200) Stage in which Requirements Error Is Discovered Sources: 1) Leffingwell & Widrig, “Managing Software Requirements,” Addison Wesley, 1999 2) IAG Consulting, 2008 3) Dynamic Market Limited, 2007 4) Standish Group, 2001 5) Don Reinertsen, McKinsey, 1983

4. IBM Software Group | Rational software 4 Requirements Engineering Poses Significant Challenges Across the Product Lifecycle and Across Engineering Domains  Poor quality of requirements definition  Requirements are often expressed poorly  Misunderstandings and misinterpretations occur frequently  Requirements Definition and Analysis is typically inefficient  Requirements are ubiquitous and labor-intensive  Requirements gathering is complex and involves numerous stakeholders  Requirements Engineering requires significant commitment  Many activities are manual (e.g. coverage and dependency analysis)  Establishing and maintaining traceability can be time consuming and error-prone  Change management in the context of requirements engineering can be difficult  Requirements are often validated late in the process, with linkage to quality assurance at the very end Project, Configuration, Change, Metrics and Documentation Tools Requirements Engineering Tools Analysis & Design Tools Modeling Tools Simulation Tools Development Tools Testing Tools

5. IBM Software Group | Rational software 5 Process and Collaboration Challenges To Deliver Higher Quality Systems & Software, Defined By Accurate Requirements and Project Information CTO/Programme Director Project Manager QA Manager Project EngineerDeveloper Audit is a nightmare as the project teams and suppliers do things differently We do ok on our small projects, but on our really large ones my teams as well as the suppliers struggle to get all the pieces to fit together… Requirements change but why doesn’t anyone tell me? We struggle with complex projects delivering on time, to cost and quality and what the customer asked for The customer often gives us bad requirements –it’s a nightmare tracing how they are implemented by internal and external suppliers Many of my colleagues are working are working on their own specifications, so I am never sure where the latest requirement are or what status they are at” “I need a process that ensures traceability between my requirements and changes. I need to know the status of those changes” Requirements Manager “Everyone need to be following the same process and creating the same metrics and reports” “I need to implement a process that supports collaboration with customers, project team and suppliers” “I need to implement a process that enforces traceability between all my project information and supply chain “I need access to a live central repository and to know that I am looking at the latest approved requirements” It’s impossible to roll up multiple-project information to know we are on track or not “I need to implement a generic process across the organisation that all projects & progammes follow

6. IBM Software Group | Rational software 6 Today’s Typical Siloed Systems Engineering Process Customer Requirements Acceptance Testing Specifications Design Integration Testing System Testing Implementation Situation Ad hoc process for requirements definition and management Poor hand-offs between supply chain/steps No practical way to trace changes in requirements Implications Requirements often missed – fail to meet stakeholder and business needs, missed schedules and cost targets Lack of traceability – can’t demonstrate compliance/V & V Lack of impact analysis – can’t react to changing contractual requirements X X Situation Poor visibility to clear requirements so tests are performed against the design, not the requirements All requirements appear to have same priority Implications Testing against what was designed, not what the customer asked for – rework after acceptance testing fails, induces schedule slip, more cost Business impact not used to drive testing – increased business risk since high priority requirements may be pushed to end of process and dropped So how do I fix this mess? And stop being late and over budget? X X X X X X X X X X

7. IBM Software Group | Rational software 7 You Need to Define a Requirements Engineering Process that Complements and Supports your SE Process Customer Requirements Acceptance Testing Specifications Design Integration Testing System Testing Implementation Benefits Process enforcement ensures collaboration and continuity between project team and supply chain Traceability across the project and through supply chain Manage customer/supplier requirements effectively Reduce the cost of requirements related defects Remember to… Support the process with a Requirements Management & traceability tool that can scale for complexity Understand the relationship between the SE & RE Processes Configure the tool using a generic information and data model for re-use across projects and used by ALL staff Train staff on the RE process and tool Customer Supplier Customer Supplier Customer Supplier

8. IBM Software Group | Rational software 8  Traceability - manage compliance (at every level) to requirements and test  Improve ability and efficiency in managing change and impact assessment  Reduce defects and cost of recall/in- service modifications  Quality improvements – higher user satisfaction  Ability to cope with higher complexity  Reduce the need for re-training when staff move projects  Common repository – use the latest versions and know where they are  Use of common attributes provide for common reporting and metrics  Supply chain  better visibility of solution and compliance to customer requirements  easier validation of deliverable(s) IBM Requirements Engineering Solution Capture Trade-off Analysis Validation Change Management Traceability Impact Analysis Reporting & Metrics Monitoring Business AnalysisSystems/Product Analysis & Implementation Test & MaintenanceAnalysisIdeasImplementation Requirements DefinitionRequirements Management IBM Requirements Engineering Solution Objectives For Programs, Projects, Products, Systems and Systems-of-Systems

9. IBM Software Group | Rational software 9 10 Principles of Good Requirements Engineering 1.Know where RM fits 2.Distinguish between problem and solution 3.Avoid premature detail 4.Use concise, clear, consistent language in statements 5.Focus on documents as well as statements 6.Understand the role of modelling 7.Employ quantification for testing 8.Create, review and use traceability 9.Use a tool-supported process 10.Use attributes to support your process Time precludes me from addressing each of these, so here is a selection….

10. IBM Software Group | Rational software 10 Principle 1 - Know Where Requirements Fit Customer Requirements Acceptance Testing Specifications Design Integration Testing System Testing Implementation Customer Supplier Customer Supplier Customer Supplier  Develop a detailed RE process that supports your Systems Engineering and Project/Programme management processes  Include your Systems, Software and Mechanical design domains in the RE process

11. IBM Software Group | Rational software 11 Principle 2: Distinguish between Problem and Solution Problem definition Specific solution Abstract solution Stakeholder Requirements System Requirements Design Risk of defining the wrong problem Risk of not meeting the requirements Should be possible to change the design without changing system requirements Risk of unnecessarily constraining the solution

12. IBM Software Group | Rational software 12 1.Know where RM fits 2.Distinguish between problem and solution 3.Avoid premature detail 4.Use concise, clear, consistent language in statements 5.Focus on documents as well as statements 6.Understand the role of modelling 7.Employ quantification for testing 8.Create, review and use traceability 9.Use a tool-supported process 10.Use attributes to support your process Time precludes me from addressing each of these, so here is a selection…. Principle 3 & 4:

13. IBM Software Group | Rational software 13 Need to balance two aspects:  Essential to provide a structure in which to place the requirements to enable:  Engineers need to visualise the system being specified in context with additional information such as constraints, background information, etc.  Create a hierarchical structure to cope with the complexity of 100s and 1000s of requirements  Standard templates should be created for documents at each level of the V  Providing a good structure enables the following:  Understanding context  Assessing completeness  Identifying repetition/conflict  Navigating/searching requirements Principle 5: Focus on documents as well as statements

14. IBM Software Group | Rational software 14 Structuring Documents - Goals Organizing requirements into the right structure can help:  Understand large amounts of information  Navigate sets of requirements relating to particular topics  Detect omissions and duplications  Minimize the number of requirements  Eliminate conflicts between requirements  Evaluate requirements sets  Reuse requirements across projects Time precludes me from addressing each issue today…… Principle 5: Focus on documents as well as statements

15. IBM Software Group | Rational software 15 Seven Criteria for Requirements Documents Each requirements set should be: 1.Complete / Sufficient: all requirements are present 2.Consistent: no two requirements are in conflict 3.Non-redundant: each requirement is expressed once 4.Modular: requirements statements that belong together are close to one another 5.Structured: there is a clear structure to the requirements document 6.Satisfied: the appropriate degree of design traceability has been achieved 7.Evaluated: the appropriate degree of test traceability has been achieved Define an outline structure at the outset, and improve it as you go Principle 5: Focus on documents as well as statements

16. IBM Software Group | Rational software 16 Principle 6: Understand the role of modeling Requirements layer Modeling layer  The requirements are the “bread and butter” of development  What is a sandwich without the bread?  Requirements alone are a little dry  Modeling is what makes the whole rather more interesting  The filling holds the bread together  It is the bread and the filling together that make a sandwich

17. IBM Software Group | Rational software 17 Functional modeling Functional modeling Functional modeling Models Bridge Layers of Requirements Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer e.g Goal / Usage modeling e.g. Functional modeling Stakeholder Requirements Design Specification System Requirements Statement of need e.g. Architecture modeling Principle 6: Understand the role of modeling

18. IBM Software Group | Rational software 18 Principle 7: Quantify requirements for testing  Of every requirement statement, ask:  “How will you know if the need has been met?”  Improves the way the requirement is expressed  Is it quantified?  What are the success criteria?  Add requirements to make system testable  Plan the tests now, not later:  What kind of tests will be used?  When will the tests be performed?  Preparing the tests may take months or years:  Collect requirements for test facilities  Trace tests to requirements  Include tests in impact analysis

19. IBM Software Group | Rational software 19 Principle 8: Create, review and use traceability  DEFINITION OF TRACEABILITY  Documenting how high-level goals are transformed into low-level goals  Understanding how needs are satisfied  Understand how requirements are qualified (tests, inspections, trials, etc.)

20. IBM Software Group | Rational software 20 Customer Requirements Acceptance Testing Specifications Design Integration Testing System Testing Implementation Verifying the System satisfies Evaluating the Design Principle 8: Create, review and use traceability Validating the Product

21. IBM Software Group | Rational software 21 Principle 8: Create, review and use traceability Coverage Analysis – Top Down Customer Requirements Acceptance Testing Specifications Design Integration Testing System Testing Implementation Verifying the System satisfies Evaluating the Design Validating the Product % Complete … ?

22. IBM Software Group | Rational software 22 Principle 8: Create, review and use traceability Customer Requirements Acceptance Testing Specifications Design Integration Testing System Testing Implementation Verifying the System satisfies Evaluating the Design Validating the Product Coverage Analysis – Bottom Up Gold plating … ? ?? Gold plating … ?

23. IBM Software Group | Rational software 23 Customer Requirements Acceptance Testing Specifications Design Integration Testing System Testing Implementation Verifying the System satisfies Evaluating the Design Principle 8: Create, review and use traceability Validating the Product Impact Analysis - Managing Change using Traceability  Identity a proposed change  Assess impact  Decide whether to go ahead  Define the change  Decide whether to go ahead  Apply the change

24. IBM Software Group | Rational software 24 Principle 9: Use a tool-supported process Elements of process:  User roles and responsibilities  Types of information to manage  Layers of information to manage  Documents and reports to generate  Types of statement  Life-cycle of statement types (status information)  Relationships between statement types (traceability)  Process goals  Activities and tasks  Process conformance (CMMI, ISO 9000, etc.)  Key process measures

25. IBM Software Group | Rational software 25 Customer Requirements Acceptance Testing System Requirements Design Requirements Integration Testing System Testing Sub- system/component Requirements Verifying the System satisfies Evaluating the Design Validating the Product Principle 9: Use a tool-supported process - Information to be managed Change Requests Risks, Issues, Assumptions Bibliography Standards

26. IBM Software Group | Rational software 26 ENGINEERING PROCESS FLOW DIAGRAM

27. IBM Software Group | Rational software 27 Information & Data Model Customer Requirement Specification Platform Architecture S Standards Derived Requirements Bibliography V A System Requirement Specification RS Software Requirement Specification RS Software Component Specification RS Application Requirement Specification RS IC Requirement Specification RS IC Component Specification RS Software Architecture A Product Architecture A IC Architecture A DVP Requirement Delta DVPx FRS Software Component Test Spec TS Software Integration Spec TS Software Test Spec TS IC Component Test Spec TS IC Test Spec TS System Test Spec TS System Integration Spec TS IC Integration Spec TS System Folder Marketing Folder Software Folder IC Folder Application Folder Project y Project x S S S S S S S S S S S S V VV V V V V Cw S Sb S Df Assumption s Risks Issues A A R R R I I I Key: A = Architecture Module RS = Requirement Module TS = Test Module A = Assumption Links Cw = Complies with Links Df = Derived from Links I = Issue Links R = Risk Links S = Satisfies Links Sb = Satisfied by Links V = Verifies Links

28. IBM Software Group | Rational software 28 There is a better way “50 percent of the reasons given for project success were related directly to well-managed requirements.” - Standish Group, “Chaos Chronicles III”

29. IBM Software Group | Rational software 29 Requirements Engineering Process & Tool Enforcement ROI – quantifiable savings  Advanced Weapon Control System – incremental development lifecycle ImprovementsBeforeAfter Requirements Volatility - @ Preliminary Design Review @ Final Design Review 72% 33% 48% 17% Requirements Changes Implemented - Changes accepted Changes rejected 98% 2% 16% 84% Testing Time - Integration System User Acceptance 9 weeks 13 weeks 22 weeks 4 weeks 6 weeks 10 weeks Defects found after production Software Requirements Specification Production Time 728 10 days 165 2 days Impact analysis could not be done, so most changes were accepted Impact analysis took up to 2 days, now only a matter of minutes

30. IBM Software Group | Rational software 30 Requirements Engineering Process & Tool Enforcement ROI – quantifiable savings  Alcatel Lucent Development Lifecycle – massive interval reduction  Development releases consisting of typically 8000 requirements used to take 6 months  Phase 1 - Application of robust process and tool enforcement reduced this period to 12 Weeks over a period of 1 year  Phase 2 - Continuous process improvement for a further 12 months reduced this period to 6 weeks  Over time, defect removal and effectiveness was 55% at phase 1, 88% at phase 2 and still improving  Defects undetected end up with the customer – the figures represent huge improvements in cost of re-work, quality and customer satisfaction

31. IBM Software Group | Rational software 31 Why IBM for Requirements Engineering? “DOORS enables us to plan, execute, and track the progress of the practices that we're improving for our members … DOORS helps us provide a good example of best practices in systems engineering.“ Pat Hale, President-elect, International Council on Systems Engineering (INCOSE) Business WireBusiness Wire, May 15, 2007 “DOORS (Telelogic) provides the best coverage of our list of requirements. It stands out in our four assessment dimensions. DOORS demonstrates strengths in capturing, linking and analyzing the requirements during their whole lifecycle.” Yphise Agile Requirements-Driven Development, Yphise, March 2008

32. IBM Software Group | Rational software 32 © Copyright IBM Corporation 2007. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. Further information: “Requirements Engineering” by Hull, Jackson and Dick, Edition 2, Springer 2005 “10 Principles of Requirements Management” by Professor Ken Jackson

33. IBM Software Group | Rational software 33 Next Steps  Enterprise Model  How does Requirements Engineering interface into your development and project engineering processes

34. IBM Software Group | Rational software 34 OPERATIONAL FRAMEWORK Lifecycle Management Engineering Lifecycle Stages Project Engineering Management Processes Engineering Planning Engineering Shut-Down Engineering Development Processes LM 05/01 LM 05/02 Includes the Requirements Process Enterprise Model

35. IBM Software Group | Rational software 35 Next Steps  Enterprise Model  How does Requirements Engineering interface into your development and project engineering processes?  Implementation  How can you best implement Requirements Engineering?

36. IBM Software Group | Rational software 36 Implementation  Leadership - Sponsor’s vision and empowerment  Process Group - Mature RM process definition  Tool Selection - made by Systems Engineering Managers  Focus Group - Lead Implementation Team (LIT)  Common approach to “Process - Tools - Guidance”  Penetration to all project employees  IT infrastructure  Mandate to contract for licences, support and maintenance to achieve broadly based deployment

37. IBM Software Group | Rational software 37 Key Objectives of the LIT  Remove duplication - one-Company approach  Procurement of tool and support services  Tailoring the tool to exploit the process  Automate RM metrics  Manage rollout and deployment  Monitor and control effectiveness  Establish knowledge base  Establish and execute training  Support implementation  Measure RM performance  Use feedback to improve process and deployment

38. IBM Software Group | Rational software 38 Next Steps  Enterprise Model  How does Requirements Engineering interface into your development and project engineering processes?  Implementation  How can you best implement Requirements Engineering?  What are the areas that most concern you?  Understanding the problem before solutioneering

39. IBM Software Group | Rational software 39 What all of the stakeholders need What the customer needs What the customer thinks he needs What the customer tells us he needs Given thisYou must determine this A Fundamental Problem

40. IBM Software Group | Rational software 40 Next Steps  Enterprise Model  How does Requirements Engineering interface into your development and project engineering processes?  Implementation  How can you best implement Requirements Engineering?  What are the areas that most concerns you?  Understanding the problem before solutioneering  RE Process  Can we re-use the Selex process?

41. IBM Software Group | Rational software 41 ENGINEERING PROCESS FLOW DIAGRAM

42. IBM Software Group | Rational software 42 Next Steps  Enterprise Model  How does Requirements Engineering interface into your development and project engineering processes?  Implementation  How can you best implement Requirements Engineering?  What are the areas that most concerns you?  Understanding the problem before solutioneering  RE Process  Can we re-use the Selex process?  Systems of Systems  Can we manage systems of systems?

43. IBM Software Group | Rational software 43 A formation of systems that can offer alternative capabilities to a Customer / Operator according to their configuration A level of an Asset that is high value, semi-autonomous that may contribute to a System of Systems. A specific major System that performs a complementary role within an Asset. Alternative – A collection of interrelated entities such that both the collection and the interrelations together perform an objective. A level of a System that delivers particular functionality within an end to end system. Equivalent to a System, but contained within a larger system. A purchased / manufactured part. Alternative – Any self contained part, combination of parts, sub-assemblies or units, which perform a distinctive function necessary to the operation of the system. System of Systems IntegratedSystem System Sub-System Component Product Hierarchy