A report from the Standish Group confirms that only a distinct minority of software projects is completed on time and on budget. In their report, the success rate was only 16.2%, while challenged projects (operational, but late and over budget) accounted for 52.7%. Canceled projects accounted for 31.1%.
The report indicates that the most significant contributors to projects’ failure relate to requirements. In many cases, requirements are not correctly determined and defined at the outset, or are not well managed as the project unfolds .
The solution is probably clear to many of us. As a matter of fact, The Standish Group's CHAOS report did establish that managing requirements well was the factor most related to successful projects. Then If projects fail due to ineffective requirements management process, and having a better and effective approach ensures success, so why don’t organizations enforce a better and effective requirements management process? The solution is so simple, why didn’t anybody figure that one out. The truth is they have. Next page !!
Requirements management is not a new concept. All the software engineering processes have focused on requirements management activities, one way or the other. The traditional waterfall model dedicated an entire phase to requirements management.
Vision that identifies the high-level user view of the system to be built. In this vision document, initial requirements are expressed as key features the system must possess in order to solve the most critical problems. In addition, all stakeholders are identified at this point.
Requirements have many sources. They may come from anyone with an interest in the outcome of the project. Customers, partners, end users, and domain experts are some sources of requirements. Management, project team members, business policies, and regulatory agencies can be others. It is important to know how to determine who the sources should be, how to get access to those sources, and how to elicit information from them. The individuals who serve as primary sources for this information are referred to as &quot;stakeholders&quot; in the project.
The primary outputs are collections of stakeholder requests, which enable refinement of the Vision document.
The Problem Analysis workflow and the Understanding Stakeholder Needs workflow create early iterations of key system definitions including the vision document, a first outline to the use-case model, and the requirements attributes. The Defining the System workflow completes the description of the system-level requirements with the addition of new actors, use cases, and supplementary specifications.
Add Use case Specifications
The main purpose of this technique is prioritize the requirements and determine which requirements to implement first.
The main purpose of this technique is to provide a more in-depth understanding of the system’s features by further refining the requirements and adding detailed descriptions of the use cases in the Case Specification document.
Use case model consists of diagrams and specifications.
The main objective of this technique is not to stop requirements from changing, it is instead meant to control and track the changes. In fact, in the Rational Unified Process change in requirements is not only accepted, it is actually expected. The process recognizes that requirements are dynamic and change in requirements is, in some cases, good. A change in requirements may indicate that the team has spent time and efforts to understand the stakeholder needs and define the system that meets those needs.
Dedication in the process, and tools that automate these difficult tasks.