Effective Requirements Management – an overview

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

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. 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 guidancein the selection of the mostappropriate solution • Therefore, requirements provide the map and compass

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. Requirements Management: Project Success Source: “Chaos Chronicles, III, 2003”. www.standishgroup.com

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. Quality and Requirements • Quality: conformance to requirements • Requirements management:delivering quality throughout the life-cycle

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. Component : handle Component : bowl Interface : to hand Interface : to mouth Interface : to table Simple System: a Cup

10. : gravity Environment Enclosing system

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. Changing design may not mean changing requirements Risk of defining the wrong problem Abstract solution Risk of unnecessarily constraining the solution Specific solution Risk of not meeting the requirements Problem and Solution Stakeholder Requirements Problem definition System Requirements Design

13. Differentiating Problem and Solution Problem Solution • Stakeholder requirements • A description of the problemand 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 ….”

14. Disaster! 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

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

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

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. Traceability allows analysis • impact • impact coverage • derivation • derivation coverage • completeness • relevance

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

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

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

22. Traceability view User Reqts Technical Reqts Design Test Cases End-to-end visual validation in a single view

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. Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer Models Bridge Layers of Requirements Statement of need e.g Goal / Usage modeling Stakeholder requirements Functional modeling e.g. Functional modeling System requirements Functional modeling Functional modeling e.g. Performance modeling Architectural design

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. 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. Requirements Driven Testing Integrated Defect Management Requirements Driven Development Optimizing Business Value of Development Acceptancetesting User Requirements Specification Functional Specification System testing Design Integration testing System Build

28. QUESTIONS?