The Requirements Problem

Key Points

The goal of software development is to develop quality softwareon time and on budgetthat meets customers' real needs. 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.

The Goal of Software Development goal: to develop quality softwareon time and on budgetthat meets customers' real needs The Root Causes of Project Success and Failure The 1994 Standish Group study noted the three most commonly cited factors that caused projects to be "challenged":

1. Lack of user input: 13 percent of all projects 2. Incomplete requirements and specifications: 12 percent of all projects 3. Changing requirements and specifications: 12 percent of all projects Although the majority of projects do seem to experience schedule/budget overruns. the Standish Group found that 9 percent of the projects in large companies were delivered on time and on budget; 16 percent of the projects in small companies enjoyed a similar success the primary "success factors" for those projects? According to the Standish study, the three most important factors were 1. User involvement: 16 percent of all successful projects 2. Executive management support: 14 percent of all successful projects 3. Clear statement of requirements: 12 percent of all successful projects Other surveys: the European Software Process Improvement Training Initiative (ESPITI) [1995] conducted a survey to identify the relative importance of various types of software problems in industry

Figure 1-1. Largest software development problems by category. (Data derived from ESPITI [1995].)

The two largest problems, appearing in about half the responses, were

The two largest problems, appearing in about half the responses, were 1. Requirements specifications 2. Managing customer requirements It seems clear that requirements deserve their place as a leading root cause of software problems. The Frequency of Requirements Errors the Standish and the ESPITI studies provide qualitative data indicating that respondents feel that requirements problems appear to transcend other issues in terms of the risks and problems they pose to application development. Capers Jones that provides data regarding the likely number of "potential" defects in a development project and the typical "efficiency" with which a development organization removes those defects through various combinations of testing, inspections, and other strategies

Requirements errors top the delivered defects and contribute approximately one-third of the total delivered defects to the defect pile. The High Cost of Requirements Errors: If requirements errors can be fixed quickly, easily, and economically, we still may not have a huge problem

the figure illustrates cost savings results from finding errors in the requirements stage versus finding errors in the maintenance stage of the software lifecycle If a unit cost of one is assigned to the effort required to detect and repair an error during the coding stage, then the cost to detect and repair an error during the requirements stage is between five to ten times less. Furthermore, the cost to detect and repair an error during the maintenance stage is twenty times more. we detect and fix at this stage are requirements errors

1. By the time the requirements-oriented error is discovered, the development group will have invested time and effort in building a design from those erroneous requirements. As a result, the design will probably have to be thrown away or reworked. 2. The true nature of the error may be disguised; everyone assumes that they're looking for design errors during the testing or inspection activities that take place during this phase, and considerable time and effort may be wasted until someone says, "Wait a minute! This isn't a design mistake after all; we've got the wrong requirements." The reason is that in order to repair the defect, we are likely to experience costs in some or all of the following areas:

Respecification. Redesign. Recoding. Retesting. Change orders (telling users and operators to replace a defective version of the system with the corrected version). Corrective action (undoing whatever damage may have been done by erroneous operation of the improperly specified system, which could involve sending refund checks to angry customers, rerunning computer jobs, and so on). Scrap (including code, design, and test cases that were carried out with the best of intentions but then had to be thrown away when it became clear they were based on incorrect requirements). Recall of defective versions of shrink-wrapped software and associated manuals from users. (Since software is now embedded in products ranging from digital wristwatches to microwave ovens to automobiles, the recall could include both tangible products and the software embedded within them.) Warranty costs. Product liability (if the customer sues for damages caused by the defective software). Service costs for a company representative to visit a customer's field location to reinstall the new software. Documentation. Conclusion:

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 percent to 40 percent of the total project budget.

Introduction to Requirements Management

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.

What Is a Software Requirement?

1. A software capability needed by the user to solve a problem to achieve an objective 2. 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
authors Dorfman and Thayer What Is Requirements Management?

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. Application of Requirements Management Techniques Types of Software Applications Information systems and other applications developed for use within a company Software developed and sold as commercial products Software that runs on computers embedded in other devices, machines, or complex systems Stakeholder Needs: It is also our responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution. As we elicit those needs, we'll stack them in a little pile called stakeholder needs Requirements and the Software Lifecycle:

Key Points

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.

The Waterfall Model

A logical, stepwise process model that progressed from a requirement phase to a design phase to a coding phase and so on the "waterfall model" of software development. The waterfall model improved on the strictly stepwise model Recognizing the need for feedback loops between stages, thereby acknowledging that design affects requirements, that coding the system will cause the design to be revisited, and so on

Developing a prototype system in parallel with requirements analysis and design activities

In the waterfall model (Figure 3-1), software activities proceed logically through a sequence of steps. Each step bases its work on the activities of the previous step. Design logically follows requirements, coding follows design, and so on. The waterfall model was widely followed in the 1970s and '80s and served successfully as a process model for a variety of medium- to large-scale projects.

The waterfall model has been successful in reinforcing the role of requirements, which form a first step in software development and serve as the basis for design and coding activities In this case, over time, the team may become completely disengaged from the real world on which the project was originally based. Disaster invariably results the waterfall model has fallen out of favor. One unfortunate result has been the tendency for teams to leap right into code, with an inadequate understanding of the requirements

The Spiral Model: "spiral model" of software development serves as a role model for those who believe that success follows a more risk-driven and incremental development path In the spiral model, development is initially driven by a series of risk-driven prototypes; then a structured waterfalllike process is used to produce the final system.

In the spiral model, development is initially driven by a series of risk-driven prototypes; then a structured waterfalllike process is used to produce the final system. the process of creating instant legacy code, progress being measured by our newfound ability to create unmaintainable and incomprehensible code two to three times as fast as with earlier methods. the spiral model starts with requirements planning and concept validation, followed by one or more prototypes to assist in early confirmation of our understanding of the requirements for the system. advantage of this process is the availability of multiple feedback opportunities with the users and customers