Requirements Management

Requirements Management

Prior to the advent of modern requirements management tools, project organizations would often receive the requirements documents from the customer and manually enter the requirements into a database to track them. This lets you sort, search, and uniquely identify each requirement. However, this approach has several problems:

  • The text in the database can become out of synchronization with the text in the written requirements document. This is especially true for requirements documents that are not completely finished. As the documents are updated and changed, the entries in the database must be manually edited to reflect changes, additions, and deletions to the document. This is tedious, time-consuming, and error-prone.

  • Requirements documents and the corresponding database information are not easily shared over an intranet or the Internet.

  • Sometimes, a requirement cannot be easily interpreted without the context of the information surrounding it. Therefore, when viewing certain requirements in the database, the user must manually find where the requirement is located in the written documents.

  • The history of how requirements have changed over time, as well as auditing information regarding the change, must be kept manually.

  • It is difficult to easily trace information concerning the requirements, such as defects and change requests, directly to the requirement.

  • Relationships between differing levels of requirements cannot be easily tracked. It is difficult to quickly determine the effect that changing a high-level requirement will have on lower-level requirements traced to it.

These issues illustrate how using a simple database to track requirements creates as many problems as it solves. Project success is completely dependent on collecting and organizing a large amount of information. This information comes from people in a variety of roles, with each role potentially having different interests and goals. Your success depends on how well you collect, process, and organize this information. The next section lists the features needed in a good requirements management tool.

Important Features to Look for in a Requirements Management Tool

Requirements encompass the heart and soul of any software project. The requirements drive all activities on a project. In some cases, requirements change frequently. It is, therefore, important that the requirements management tool is helpful in managing and tracking these changes.

Core Capabilities

The following features are considered essential for proper requirements management:

  • The tool must be able to create and manage requirement documentation. Most customers will want to be able to receive and circulate printed copies of the various requirements documents created.

  • The tool must be able to distinguish individual requirements within the requirements document. A single document could contain hundreds of requirements. The tool needs to be able to recognize and track each requirement independently.

  • In addition to tracking the text of the requirement, a requirements management tool should be able to track other information about the requirement. This information is not contained within the text of the requirement. Examples include the date the requirement was created, its priority, its scheduled release date, and its status. The user should be able to define unique attributes for the requirement.

  • The tool should have a searching and sorting capability. This capability should search the requirements text and all the information associated with the requirements. It should be possible to sort and filter the list of requirements according to the information tracked along with the requirement. This makes it possible to show only requirements assigned to a certain release, to sort requirements by a rated level of importance, and so on.

  • Requirements can sometimes be decomposed into closely related but separate requirements. For example, a requirement could have this form: "The system shall provide the ability to send data in the form of text messages, audio data, and audiovisual data." Although the requirement is contained in a single sentence, it has multiple parts. This is known as a parent/child relationship. The parent requirement is the portion that reads, "The system shall provide the ability to send data in the form of." The child requirements are "text messages, audio data, and audiovisual data." By tracking these portions of the requirement separately, you can manage them more effectively. For example, suppose the ability to implement the sending of text messages was needed in an earlier release of the product. If this requirement were tracked as a single requirement, it would be difficult to indicate that a portion of the requirement must be implemented earlier than other portions. Tracking them separately allows this, but the nature of the parent/child relationship still documents the fact that the requirements are closely related.

  • There are different levels of requirements. Each level may be contained in its own document. Figure 6-1 shows an example of the different levels of requirements that may exist on a project.

    Figure 6-1. Different levels of requirements on a project

    Furthermore, the requirements within a given level drive the requirements in the next level below. Thus, a change to a requirement could potentially affect the requirements in the level below. To make managing and controlling this process easier, the requirements tool needs the following capabilities:

    • Individual requirements defined at one level need to be traceable to one or more requirements defined in the level above. The tool must document these traceability relationships and baseline the relationships along with the requirements themselves.

    • The tool should allow the user to perform impact analysis by illustrating the effect of a change to a specific requirement. In other words, if one requirement is changed, the tool should report the entire list of requirements traced directly and indirectly to it. This helps you understand how extensively the change will affect other requirements.

  • The tool should be able to create a baseline of all the requirements documents, traceability relationships, and information associated with the requirements. It should be possible to examine the artifacts in the state they were in at the time of the baseline. This makes it possible to baseline the requirements along with developed code releases and other related artifacts.

Tracking Changes to the Requirements

Requirements changes can come from many sources at any time. It is imperative that the project team be able to distinguish the exact set of requirements it is obligated to fulfill from the plethora of changes being considered. Some requirements management tools may be able to track changes as a built-in capability. Other vendors take a different approach and accomplish this effect through integration with other tools. Either way, the following list identifies the capabilities needed to manage these changes:

  • If a change affects an existing requirement, the tool should indicate to the viewer of the requirement that change requests have been submitted against the requirement.

  • If a change request is a submission of an entirely new (unapproved) requirement, it should be clearly separated from the list of official requirements. In other words, users who are concerned only with the set of requirements they are obligated to fulfill should not have to sift through unofficial, unapproved requirements. Why not place enhancement requests directly in the requirements repository? There are several reasons why this should be avoided:

    • Enhancement requests usually originate from the customer and end users. On most projects, a specified process should be followed to determine whether a request should be translated directly into a requirement the team is contractually bound to deliver. Once the end of this process is reached, a decision is made whether to accept the request as a requirement, defer it, or reject it. Therefore, it is not appropriate to enter a new request as an official requirement until this process is followed through to completion.

    • End users may not be able to express a new requirement in such a way as to contain all the attributes of a properly written requirement. In other words, all requirements should be clear, concise, testable, and verifiable. The initial request needs to be reviewed, and possibly modified, before it can become an official requirement.

    • End users requesting new functionality are often unaware of contractual issues, budget constraints, and so on that may prevent a new request from being implemented immediately.

    • End users and customers may not know whether a suggested new feature was previously requested or whether it might be out of scope of the system under development.

  • Regardless of whether a change request is to change an existing requirement or to request a new one, the tool should create a complete audit trail of all changes to a requirement. This includes the identity of the person making the change, as well as the identity of the person requesting the change.

  • E-mail notification can be a useful capability. For example, a capability that automatically generates and sends an e-mail if certain requirements are changed can alert the right people, who can react to the change.

Other Important Capabilities

The following features may not be needed, depending on the exact scenario for your project. Consider each of these features and determine whether they may be useful:

  • The tool should have a Web-based interface that could be deployed over the Internet if needed. This is particularly useful in an outsourcing scenario in which the customer (or potentially other contractors) can access the requirements if needed and if appropriate.

  • In some situations, there may not be network connectivity (even over the Internet) to the requirements management repository. In this scenario, the customer may communicate new or changed requirements by modifying the original requirements document and issuing a new version of the document. The requirements management tool should have a comparison tool that can compare an existing requirements document with a newer version of the document and integrate the changes.

  • Security is a very important consideration, especially if many people are allowed access to the requirements repository. The tool should allow creation of groups of users with different security levels. For example, a project might want to provide read-only access to users outside the immediate project team, while requirements analysts directly on the team would have read/write privileges.