The Quest for Good Requirements | 7
300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com
Successful analysts know how to select the right documentation techniques and do not limit
themselves to just one documentation approach, such as wireframes, use cases, or narrative
requirements. They blend the different approaches to specify all requirements clearly, unambiguously,
and concisely.
While writing documentation is generally not a value-added activity from the user's perspective, it
is a necessary mechanism to mitigate certain project risks. The amount of necessary documentation
is dependent on the specific risks that are present, particularly when projects are implemented by
outsourcing partners, distributed teams, or when access to stakeholders is limited or sporadic.
Requirements Validation
Requirements must be validated prior to implementation to ensure that they are correctly understood
and still valid, lest the team wastes precious resources implementing functionality that is not needed.
Validation is achieved through several means, including:
• Formal and informal inspection: In this approach, the project team meets and walks through the
requirements package, including any visual and executable models.
• Stakeholder reviews: Present the requirements, models, and prototypes to the stakeholders
for review and validation. At the conclusion of the review, the stakeholders "sign off" on the
requirements to indicate their approval.
• Acceptance criteria definition: For each user requirement (generally expressed as a use case),
define post-conditions so that tests can be constructed that verify that the requirements have
been met.
Writing Effective Requirements
Documenting requirements is an essential part of the requirements process. Over the years, many
approaches to documenting requirements have been developed. Among the more prominent
recommendations is IEEE Standard 830, which contains the recommended practices for writing
software requirements specifications (SRS).
Requirements that are useful exhibit several important characteristics:
• Complete: The requirement must contain all the information necessary to allow the project team
to fulfill the requirement.
• Accurate: The requirement must be correct; validation is generally done through reviews with
stakeholders; an accurate requirement cannot be in conflict with another requirement.
• Testable: The requirement can be verified through a test.
• Feasible: The requirement can be implemented; there is no technical or other impediment that
make the requirement undoable.
• Necessary: The requirement must describe a feature that the stakeholders actually need; it must
relate to a business objective.
• Unambiguous: The requirement must be described in a simple and concise manner that
guarantees that there are no differing interpretations of what the requirement means.
• Prioritized: The requirement's degree of necessity relative to other requirements has been
established through stakeholder consultation.
