The following diagram illustrates the requirements management workflow advocated by the Rational Unified Process. As the diagram shows, the process is iterative and dynamic, and change management takes place throughout the process. Phases of the process are associated with specific documents in which team members capture the project requirements. These phases and documents will be referred to often throughout this tutorial.
(Courtesy of Rational Unified Process, 2001)
Determining the real problem is an important first step toward designing a successful project. We define the word problem as the gap between our perception of what customers say they want and what they actually want. Determining the real problem may be trickier than it appears; what people state as a problem may not be the actual problem. To address this, you solicit the customer's definition of the problem and then continue to probe until you get to the problem behind the problem. When the root causes of the problem have been identified, you can focus on the ones that contribute most to the problem.
Effective solutions to complex problems require input from a diverse group of stakeholders (people who are materially affected by the implementation of a solution to the problem). People who use the system (staff and customers) are good sources of information on its shortcomings; others whose opinions must be solicited include those who must approve the new system and those who will maintain it. These individuals will also be able to provide important information regarding the requirements that must be provided by a solution.
Example: A mail-order catalog company that manufactures and sells miscellaneous home items discovered that it had not made any profit for two quarters. Company executives and key staff members tried to determine the causes for this lack of profit; they focused on the cost of all the things that go wrong and produce waste, scrap, and other excess costs. This cost included rework, scrap, customer dissatisfaction, and employee turnover. When they tried to quantify the cost of nonquality, they concluded that production waste, or scrap, was the largest contributor.
The next step was to find the root cause, or the problem behind the problem in scrap. What factors contribute to the problem? Company staff were able to identify many contributors: customer returns, damaged shipments, inaccurate sales orders, and manufacturing defects. Then they tried to determine the contribution of each of these factors to the overall problem. Their records helped them determine that the single greatest contributor to the problem of scrap was produced by customer returns related to inaccurate sales orders; additional relevant information was obtained from sales order entry clerks, sales order supervisors, and billing clerks, to name just a few. Company managers concluded that by addressing this problem, they would substantially reduce waste; they defined a successful outcome as one that would increase accuracy of sales orders at point of entry and improve reporting of sales data to management.
When you define the system, you translate and organize your understanding of stakeholder needs into a description of the system to be built. Documents that define the product to be built and describe the system's external behavior are called requirement specifications. They include Use-Case Documents, which are designed to identify the functional behavior of the system, and Supplementary Requirements Specification Documents, which define features of the system in specific terms.
(Adapted from Managing Software Requirements: A Unified Approach, by Dean Leffingwell and Don Widrig. Boston: Addison-Wesley, 2000, pp. 35–39 and 159–160.)