by Wayne Woodruff (wayne@bmwmat.bucks.pa.us)
Copyright © 1997 Rational Software Corporation
All Rights Reserved
Many good reasons exist for implementing a formal requirements management process-finding defects earlier in the development process, keeping product definitions up to date, and communicating change to the development team, among others.
In many smaller companies, requirements management is a difficult challenge. Smaller groups mean fewer resources, and many organizations focus their efforts on design, development and testing not on managing requirements. Some small organizations may perceive requirements management as an activity only for large organizations that have complex products and large staffs to support the effort.
This article describes a practical approach to requirements management for small organizations, including the following issues:
To accomplish the above tasks, a small organization needs an efficient, affordable, and easy-to-use tool for managing requirements. I have found Rational Software Corporation's RequisitePro to be such a tool.
The standard requirements elicitation process begins with the marketing organization interviewing current and potential customers. From this elicitation process, a product definition is formed. From the product definition, engineering develops one or more engineering-oriented requirements documents such as the Software Requirements Specification (SRS), Hardware Requirements Specification (HRS), and so on. From these specifications, detailed design documentation is generated. Test plans and procedures are developed as well as user documentation. A change to the product definition has a significant ripple-down effect on other project documents (see Figure 1). The effort required to manage this suite of documents rises quickly as the number of documents increases.
Smaller organizations can benefit from paring the documentation tree to a more manageable level. One significant reduction involves combining the product requirements, the Software Requirements Specification and the Hardware Requirements Specification into a single document (see Figure 2). This hybrid document contains different levels of requirements: the higher-level sections are marketing-centric while the detailed levels are more engineering focused.
For example, Section 1.2 may define a particular function for marketing purposes while Sections 1.2.1, 1.2.2, etc., define the function at the engineering requirements level. Utilizing this technique, only one document needs to be maintained versus three or more, reducing duplicate information and improving productivity. This combined requirements specification should describe the product's features and their relative importance, but should not contain design information.
Figure 1 - Example of Standard Requirements Document
Hierarchy
Figure 2 - Example of Hybrid Document Hierarchy
A requirements document defines the what and why of a product. To make use of individual requirements, they must be identified. For instance, the following statement is a requirement:
This requirement has attributes or characteristics. For instance: Is this requirement approved for development? Are there outstanding technical or financial issues? How important is this requirement? Is it needed in the first release or the fifth release? How much effort is involved? Is the requirement difficult to implement?
The following table shows a few examples of requirements and their attributes:
| SRS1 The modem port shall be initialized on system power up or system reset. | Approved | Low | Release 3 |
| SRS2 After initialization has completed, the modem port must be active and available to transmit the diagnostic data at 14.4k baud. | Postponed | High | Not Assigned |
| SRS3 Protocol shall be no parity, 8 data bits, 1 stop bit. | Approved | Medium | Release 1 |
As you can see from this example, identifying requirements and attributes for a complex product would be extremely time consuming without a specialized tool.
With RequisitePro and its integration with Microsoft Word™, requirement identification is as simple as highlighting the area of the text and clicking "Create Requirement." A database entry is automatically created, including the requirement text and a set of attributes with default values. The original document is not changed and can be saved in Word format. This database can be queried on any combination of attributes, and a report can be easily generated.
The attributes of requirements must be user defined to match organizational preferences. Some organizations may want to start with just a few attributes and add more as the organization matures. Attributes can be text, integer numbers or values selected from a pick list. Attributes are also customizable for each type of document.
RequisitePro helps teams effectively identify and manage requirements when they must be maintained between multiple documents (i.e., product definitions, the SRS, the HRS, test plans, etc.).
Another activity related to requirements management is change control. When the product definition changes, who needs to be notified? What other documents need to change? How significant are the changes? Historically, this process was managed using a manual traceability matrix. The traceability matrix lists requirements from a specification along one axis and the requirements from a related specification on another axis. When one requirement is related to another, a check mark is placed at the intersection. The following table shows an example of the relationships between the Software Requirements Specification (SRS) and the Software Test Plan (TST).
| TST 1 | TST 2 | |
| SRS 1 | x | |
| SRS 2 | x | |
| SRS 3 | x |
In this case, Software Test Plan Requirement 1 (TST 1) is traced from Software Requirements Specification Requirement 1 (SRS 1) while TST 2 is traced from SRS 2 and SRS 3. Even for a small project, it is quite easy to have 100 or more requirements in the Software Requirements Specification alone. The above traceability matrix becomes impossible to manage when a change occurs. The matrix must be manually scanned to identify which requirements are impacted. The person responsible for that requirement must then be notified and asked for their assessment. This process continues for each affected requirement.
Small organizations can't afford this unproductive process, nor can they afford the costs associated with resulting errors. Using RequisitePro, this becomes much simpler and more intuitive. The tool maintains all of the requirements in a database. When one or more requirements change, it will automatically identify affected requirements in other documents (see Figure 3) using suspect links (requirements with a slash through them). RequisitePro immediately identifies the potential changes to all documents for easy impact analysis.
Figure 3 - RequisitePro Traceability Matrix
In the above example, the Software Requirements Specification has changed, specifically, requirements SRS1 and SRS2. Subsequently, test requirements TST1, TST4, TST5, and TST6 are now suspect and need to be reviewed to understand how the changes to the SRS will impact the test plan.
RequisitePro also provides the ability to query for
requirements in one document that are not linked to requirements
in another document (i.e., a specific software requirement with
no corresponding requirement in the test plan). This prevents
features from escaping untested. In Figure 4 below, SRS3, SRS4,
etc. have no corresponding requirement in the test plan. Why?
Were they overlooked? Using this part of the tool, RequisitePro
prevents untested requirements from falling through the cracks.
Figure 4 - RequisitePro Traceability Tree
Requirements management presents many challenges. Lack of dedicated personnel and robust tools often reduce the effort expended on this important function. A well-rounded tool like RequisitePro can supplement this process and make it more practical for smaller organizations.