1. Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific

2. © Telelogic AB 2 Agenda What is Requirements Management? Why Requirements Management? Key concepts –Quality and Requirements –Systems –Problem and Solution domain –Information traceability –Requirements and Modeling –Requirements Driven Development

3. © Telelogic AB 3 Requirements are Vital Requirements are a clear statement of objectives. Requirements state the initial problem and the need that is to be satisfied Requirements define the characteristics of the set of acceptable solutions Requirements also provide guidance in the selection of the most appropriate solution Therefore, requirements provide the map and compass

4. © Telelogic AB 4 Requirements Management NOT just a front-end activity Forms the back-bone of the WHOLE lifecycle –Cradle-to-grave, not just development activity Helps you focus on the most important objectives –Not all requirements are equal in cost, risk, benefit Saves money through EARLY defect identification –“Quality is free” (Philip Crosby) The more complex the system, the greater the need for requirements to be well managed (RMB-43)

5. © Telelogic AB 5 Requirements Management: Project Success Source: “Chaos Chronicles, III, 2003”. www.standishgroup.com

6. © Telelogic AB 6 The Benefits of Requirements Management Satisfaction: real stakeholder needs met Integration: the pieces work together Testability: know what to test the product against Communication: developers have consistent ideas of what the product is for Visibility: managers can take a global view Change control: the impact of change can be assessed Quality: we know what quality means for the stakeholder Optimization: we build only what is wanted

7. © Telelogic AB 7 Quality and Requirements Quality: conformance to requirements Requirements management: delivering quality throughout the life-cycle

8. © Telelogic AB 8 What is a system? A collection of components (people or machine) – which co-operate in an organized way – to achieve some desired result. A system is more than the sum of its parts –it has emergent properties A system is always part of an enclosing system –systems of systems

9. © Telelogic AB 9 Simple System: a Cup Component: handleComponent: bowl Interface: to hand Interface: to table Interface: to mouth

10. © Telelogic AB 10 Enclosing system Environment : gravity

11. © Telelogic AB 11 Emergent Properties Properties not located in any particular component of a system, e.g. –Ability to float, or to fly Properties that depend on the way components interact, e.g. –Journey time from London to Glasgow –Reliability What about: –Weight? Question: what are the emergent properties of the cup?

12. © Telelogic AB 12 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 Changing design may not mean changing requirements Risk of unnecessarily constraining the solution

13. © Telelogic AB 13 Stakeholder requirements A description of the problem and its context Results that stakeholders want from the system Do not define the solution, other than for environment Quality of results Owned by stakeholders or their representatives (e.g. marketing) System requirements An abstract representation of the solution What the system does Do not define the design How well it does it Owned by systems engineers “The user shall be able to....”“The system shall do ….” Differentiating Problem and Solution ProblemSolution

14. © Telelogic AB 14 Results of mixing Problem and Solution Don’t understand the problem Can’t decide on functions Developers dominate Can’t do acceptance User and system constraints muddled Unclear ownership Disaster!

15. © Telelogic AB 15 Acceptance test validating the product Stakeholder Requirements The V-Model Statement of need Operational use satisfies Component Requirements Component test qualifying components Subsystem Requirements Subsystem test qualifying the subsystems satisfies System Requirements System test verifying the system satisfies

16. © Telelogic AB 16 Requirements at every level System Requirements Subsystem Requirements Component Requirements System test Subsystem test Component test Acceptance test validating the product verifying the system qualifying the subsystems qualifying components Stakeholder Requirements satisfies Statement of need Operational use

17. © Telelogic AB 17 Definition of Traceability INFORMATION TRACEABILITY: Understanding how information at a high-level is transformed into low-level. Understanding how needs are satisfied and qualified Principle underpinning: Programme management Accountability Audit trails Risk management Safety management

18. © Telelogic AB 18 Traceability allows analysis impact impact coverage derivation derivation coverage completeness relevance

19. © Telelogic AB 19 Acceptance test Stakeholder Requirements Impact Analysis Statement of need Operational use satisfies Component Requirements Component test Subsystem Requirements Subsystem test satisfies System Requirements System test satisfies validates What if … ?

20. © Telelogic AB 20 Acceptance test Stakeholder Requirements Coverage Analysis Statement of need Operational use satisfies Component Requirements Component test Subsystem Requirements Subsystem test satisfies System Requirements System test satisfies validates Complete … ?

21. © Telelogic AB 21 Life of a requirement statement Y Impacted? Drafted Proposed Approved –By customer –By supplier –By validation and test team Traced Reviewed –Accepted –Rejected Baselined

22. © Telelogic AB 22 Traceability view End-to-end visual validation in a single view User ReqtsTechnical ReqtsTest CasesDesign

23. © Telelogic AB 23 Systems Modeling Introduces formality into the definition of systems Specification and design visualized in diagrams Uses diagrams, not just pictures Definition of precise vocabulary across the system Means of reasoning about a problem and its potential solutions Multiple (interacting) aspects of a system are modeled Progressive refinement towards more detailed design Validation of some aspects of design through animation Encourages communication between different organizations through the use of common standard notations (UML2.0)

24. © Telelogic AB 24 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 Architectural design System requirements Statement of need Functional modeling e.g. Performance modeling

25. © Telelogic AB 25 Models and Requirements Models and Requirements complement each other Diagrams help clarify understanding of requirements Modeling can help identify gaps and misunderstandings A formalized but flexible graphical notation enables expressive, ‘people friendly’ diagrams DOORS/Analyst: integrated modeling with requirement management

26. © Telelogic AB 26 Requirements Driven Development Requirements must be captured and communicated to development. Design and functional requirements must be managed and linked to user requirements. Development activities must be driven from design and functional requirements. Relationship between requirements and development artefacts must be established and automatically updated.

27. © Telelogic AB 27 Requirements Driven Development Integrated Defect Management Requirements Driven Testing Optimizing Business Value of Development User Requirements Specification Functional Specification Design System Build Integration testing System testing Acceptance testing

28. © Telelogic AB 28 QUESTIONS?