8 | The Quest for Good Requirements
300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com
Documentation Formats
Requirements are commonly written as simple narrative statements. User requirements are best
expressed as more elaborate documents. A common format for documenting user requirements is
use cases. In addition, constructing visual models simplifies communication of complex requirements.
A visual model, such as a UML diagram, can more precisely describe requirements than a written
paragraph. It is also easier to discover mistakes in a diagram than a lengthy narrative. A requirements
specification typically includes a combination of narratives, use cases, and visual models.
Requirements Identification
All requirements must be labeled so that it is easy to refer to them through a unique handle rather than
its description. The following conventions are often used:
• User/stakeholder requirements are expressed as use cases and use the prefix UC; e.g., UC1.
• Functional requirements use the prefixes R or FR; e.g., R92, FR876.
• Business requirements use the prefix O (for objective); e.g., O2.
• Business rules use the prefix BR; e.g., BR12.
• Non-functional (or quality of service) requirements also use the prefix R, although some prefer to
use NFR; e.g., R14 or NFR23.
Requirements Traceability
Requirements must be traceable. That means for any requirement, one must be able to ascertain
its source and its realization; i.e., a reason why the requirement exists and a guarantee that the
requirement has actually been implemented. Generally, analysts construct a matrix that traces each
requirement to implementation, test cases, and sources. The source of a requirement is generally some
stakeholder but might also be a regulation or mandate.
Requirements Approval
Many organizations have a formal process of "signoff" or approval where the customer or project
sponsor formally agrees to the requirements that have been captured. While it is somewhat formal,
signoff must be viewed as a project milestone rather than a formal contract. Requirements very likely
will still change after signoff. After all, the business does not remain static; things change constantly
in the business world. Project teams must adopt a requirements change procedure that stakeholders
can fall back on when a requirement does indeed change. Naturally, the project manager must explain
to the stakeholders that a change to the requirements (either by adding, modifying, or removing a
requirement from the specification) likely will have an impact on the project's schedule, budget, and
delivery milestones.
