1. 1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software Requirements Management, A use case approach”, by Leffingwell and Widrig

2. 2 The requirements Problem

3. 3 Key points  The goal of software development is to develop quality software—on time and on budget—that meets customers' real needs. Project Features Project Cost Project Time

4. 4 Key Points  Project success depends on effective requirements management.  Requirements errors are the most common type of systems development error and the most costly to fix.  A few key skills can significantly reduce requirements errors and thus improve software quality.

5. 5 Some numbers …  A study by the Standish Group [1994] reported (USA):the Standish Group [1994] More than $250 billion each year on IT application development  175,000 projects. Avg. cost of a development project:  for a large company: $2,322,000;  for a medium company: $1,331,000,  and for a small company: $434,000 31% of projects canceled before they ever get completed! 52.7% of projects will cost 189% of their original estimates! American companies and government agencies will spend $81 billion for canceled software projects. These same organizations will pay an additional $59 billion for software projects that will be completed but will exceed their original time estimates.

6. 6 Root causes of success and failure  Standish Group study noted the three most commonly cited factors that caused projects to be "challenged“ (late/did not meet expectations): Lack of user input: 13 % of all projects Incomplete requirements and specifications: 12 % of all projects Changing requirements and specifications: 12 % of all projects Unrealistic schedule or time frame: 4 % Inadequate staffing and resources: 6 % Inadequate technology skills: 7 %

7. 7 Root causes of success and failure  9 % of the projects in large companies were delivered on time and on budget (16 % of the projects in small companies)  Primary "success factors" for those projects? User involvement: 16 % of all successful projects Executive management support: 14 % of all successful projects Clear statement of requirements: 12 % of all successful projects

8. 8 Root causes of success and failure  Survey done by European Software Process Improvement Training Initiative (ESPITI) - 3,800 responses –European Software Process Improvement Training Initiative (ESPITI)

9. 9 Root causes of success and failure  The two largest problems, appearing in about half the responses, were: Requirements specifications Managing customer requirements

10. 10 Frequency of requirements errors

11. 11 The cost of requirements errors

12. 12 Summary  Two main things: Requirements errors are likely to be the most common class of error. Requirements errors are likely to be the most expensive errors to fix.  Requirements errors are likely to consume 25 % to 40 %: Requirements errors will contribute the majority— often 70 % or more—of the rework costs. Rework typically consumes 30 % to 50 % of a typical project budget [Boehm and Papaccio 1988]Boehm and Papaccio 1988

13. 13 Overview on Requirements Management

14. 14 Key Points  A requirement is a capability that is imposed on the system.  Requirements management is a process of systematically eliciting, organizing, and documenting requirements for a complex system.  Our challenge is to understand users' problems in their culture and their language and to build systems that meet their needs.  A feature is a service that the system provides to fulfill one or more stakeholder needs.  A use case describes a sequence of actions, performed by a system, that yields a result of value to a user.

15. 15 What Is a Software Requirement?  Dorfman and Thayer [1990]: Dorfman and Thayer [1990] A software capability needed by the user to solve a problem to achieve an objective A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation

16. 16 What Is Requirements Management?  Requirements define capabilities that the systems must deliver, and conformance (or lack of conformance) to a set of requirements often determines the success (or failure) of projects. It makes sense, therefore, to find out what the requirements are, write them down, organize them, and track them in the event that they change.  Requirements management is: a systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

17. 17 Needs, Features, Requirements  Stakeholder Needs  Features of the System: services provided by the system that fulfill one or more stakeholder needs.  Software Requirements: Once we have established the feature set and have gained agreement with the customer, we can move on to define the more specific requirements we will need to impose on the solution.

18. 18 Problem & Solution Domains  Problem domain: user needs we discovered  Solution domain: a definition of a system that will be represented by the features of the system and the software requirements that will drive its design and implementation.

19. 19 Problem & Solution Domains

20. 20 Requirements & the Software Lifecycle

21. 21  The team's development process defines who is doing what, when, and how.  In the waterfall model, software activities proceeded through a sequence of steps, and requirements were "fixed" early.  In the spiral model, the first steps were taken to a more risk-driven and incremental approach to development.  The iterative approach, a hybrid of the waterfall and spiral models, decouples the lifecycle phases from the software activities that take place in each phase.  The iterative model is a more robust model and provides for successive refinement of the requirements over time. Key Points

22. 22 Traditional Software Process Models  The Waterfall Model

23. 23 Traditional Software Process Models  The Spiral Model

24. 24 The Iterative Approach  Lifecycle phases  Iterations

25. 25 The Iterative Approach  Disciplines

26. 26 Requirements in the Iterative Model  The iterative approach provides two major advantages: Better adaptability to requirements change (revisited at every iteration  new requirements can be considered at each iteration) Better scope management (If the first iteration is missed by 30 %  indicator that the project may be badly scoped, and adjustments can be made)

27. 27 The Software Team

28. 28 Key Points  Effective requirements management can be accomplished only by an effective software team.  Requirements management touches every team member, in different ways.  Effective requirements management requires mastering six team skills.

29. 29 Team Skills for Effective Requirements Management  Team Skill 1 - Analyzing the Problem: techniques the team can use to gain a proper understanding of the problem that a new software system is intended to solve. Team Skill 1  Team Skill 2 - Understanding User and Stakeholder Needs: techniques the team can use to elicit requirements from the system users and stakeholders. Team Skill 2  Team Skill 3 - Defining the System: initial process by which the team converts an understanding of the problem and the users' needs to the initial definition of a system that will address those needs. Team Skill 3

30. 30 Team Skills for Effective Requirements Management  Team Skill 4 - Managing Scope: arm the team with the ability to do a better job of managing the scope of the project. Team Skill 4  Team Skill 5 - Refining the System Definition: help the team organize/refine the requirements information. Team Skill 5  Team Skill 6 - Building the Right System: discuss some more technical aspects of testing and change management, and show how traceability can be used to help ensure a quality outcome. Team Skill 6

31. 31 The Project team  Team Members Have Different Skills  The Organization of Software Teams

32. 32 Skill 1 Analyzing the problem …