Clear Requirements

The requirements you capture must be stated in business terms, must be clearly stated, must be concise, and must be feasible. To ensure that requirements are clearly stated, you should have them proof read by someone external to the project (or at least someone not familiar with the requirements you’ve captured). Any questions raised by your proof reader should trigger a re-write of that requirement. Clean the language up until your proof reader understands the requirement.

Requirements should address a business need. Requirements that can’t be translated into a benefit for the business should be questioned for validity. By benefiting the business I don’t necessarily mean generating new revenue (although this is never a bad thing), but benefits derived from software application are typically derived through cost savings, eliminating manual effort, or supporting new products. The requirement should address one of these areas.

Requirements should be stated in terms that are verifiable. A requirement that states the need for a "fast” transaction provides little guidance to the business analyst who will translate the requirement into a technical feature, or the programmer who will code it. Make sure that all the requirements that are captured are testable: "the user should be able to recover their session after an error” isn’t good, "the user should be returned to the order input screen upon an error” is good (and testable). When a requirement speaks to how well the system performs, such the speed at which a transaction is performed, or the systems ability to process multiple transactions, the requirement should come with specific benchmarks. For example: "the transaction must complete in under 2 seconds”. Even better: "the transaction must complete in under 2 seconds during during peak load periods”.

Your business analysts will be responsible for translating the requirements into a technical specification so they should be consulted when requirements are being captured. The BAs are your best measure of the feasibility of a requirement. If the requirement is not compatible with the software and hardware systems chosen to implement the solution, the BAs should be able to detect this and avoid wasting effort developing software that won’t satisfy the requirement. There are 2 critical approvals in the process of gathering requirements:

1. The vetting of business requirements by the Business Analysts
2. The vetting of the requirements specs (written by the BAs), by the authors of the requirements.

Providing this level of oversight over the requirements gathering process will enhance your chances of capturing and delivering the right requirements.

One of the most important facets of requirements management is the identification and tracking of the requirements through the design and build phases. Requirements should be captured as discrete entities. They may be stated in a sentence, or a paragraph, but must be uniquely identified by a numbering system that assigns that unique identifier to the requirement. This unique identifier will be used throughout the development process to ensure that each requirement has been designed, developed, and tested.

Following the tips in this page won’t guarantee you a successful project, but should help you to identify the business needs of your stakeholders as efficiently as possible and ensure that they are accurately captured and translated into a software solution.