The quality of your requirements can make or break your project. Good requirements give you control over your project development and prevent rework. Less rework means your project has a much better chance at on time and on budget delivery. All that adds up to project success and high customer satisfaction.
What makes a requirement a good requirement? Good requirements generally meet four basic criteria:
- Good requirements meet a specific need
- Good requirements are verifiable
- Good requirements are attainable
- Good requirements are clear
Meeting a specific need
A requirement is a basically a statement of something someone needs. The something is a product or solution that performs a service or function. The someone may be a company, a user, a customer, support, testers, or another product.
For example, a company needs a manufacturing machine that stamps out widgets, or they need a certain plastic to feed a manufacturing machine that they already have. A bank must process debit card transactions. Alternatively, a requirement is a statement of a characteristic of something someone needs. Proceeding with these examples then, a machine must stamp out 60 widgets an hour. The raw material must be formed in sheets, or it must be red in color. A bank must process at least 1,200 debit card transactions in one hour.
Generally, you must distinguish between needs and wants. Even if it is verifiable, attainable and well-stated, a requirement that is not necessary is not a good requirement. The definition of need will depend on the context or circumstances. For instance, if you are spending taxpayers’ or shareholders’ money, need will be narrowly defined. For commercial products, a consumer want is a need for your product when it tips the consumer’s buy decision in your product’s favor.
Be verifiable
A requirement must state something that can be verified by inspection, analysis, test, or demonstration. As you review a requirement, think about how you will prove that the product meets it. Determine the specific criteria for product acceptance, which will ensure verifiable requirements.
Be attainable
The requirement must be attainable. It must be within the budget and schedule and be technically feasible. Don’t write requirements for things that cannot be built or that are not reasonably within the project budget. If you do, it’s a waste of time and effort.
Many feasibility questions will not necessarily be clear-cut. You may not have the expertise to judge whether a requirement is technically feasible. If that is the case, make sure you include members of the development team in the review process to foresee technical problems. Your team may need to conduct research to determine a requirement’s feasibility before it is added to the product baseline. If this research still leaves you uncertain about the feasibility of what you want, consider stating the need as a goal rather than as a requirement. If you can’t back off to a less demanding but obviously feasible requirement, you will have to identify the requirement as a risk and monitor it with other risks and issues throughout the project.
Be clear
A good requirement cannot be misunderstood. It expresses a single thought. It is concise and simple. The more straightforward and plainly worded, the better. Use short, simple sentences with consistent terminology for requirements. If possible, decide on specific names for your solution or product and deliverables and refer to them by name alone in your requirements. Use consistent language. As you define subsystems, name them also and refer to them only by those names. Use acronyms if you have to in order to keep them short. The less complex and more consistent everything is from requirement to requirement, the better. Too many words and too many references breed inconsistency and confusion.
State your requirements positively whenever possible. It is easier to develop and test a product that does something specific than one that does not do something specific. It is extremely difficult, if not impossible, to test that something does not happen. This type of testing is expensive, time consuming and can break a project’s budget.