Requirements: do it correct right from the start

Lately we had a quote from a client who was seeking for a help in writing software requirements. He was looking for someone to translate a unstructured input into a set of solid, high quality requirements. That was a wise step because requirements is where the quality of a product starts.

More and more people come up with ideas of a software product but the numbers of people who can transform an idea into a full spectrum of professional requirements remain too low. I will try to explain some of the ideas behind writing good requirements, so one could do this on a high level without a help.

Let's start with definition. Software requirements are a set of statements that define software behavior. Under behavior I mean the functionality available for the user or the characteristics of the software that directly affect its business success.

Aside from the qualities of requirements a big role is played by the process. The way you work with requirements defines their effectiveness in the development cycle. During the lifecycle requirements go through several stages:

- Creation or gathering
- Review
- Modification or update

As you see this is not enough to just create requirements. You have to have means to update it later, when changes come up. No matter how good at gathering requirements you are or how good you know what you want to have in the product, you will face change requests. They can come up out of review, development, testing, beta program and field usage. So, you must have a process how to deal about changes, so as to have the lowest possible cost of the update, making sure everyone interested is notified.

All above impose the following demands on the requirements:

- Correctness
- Completeness
- Consistency
- Non-ambiguity
- Testability
- Traceability
- Maintainability or changeability
- Sense of priority

Correctness means that your requirements shall speak the truth. This is not enough to simply state the truth once. You need to make sure that requirements are being updated timely.

Completeness implies the all the required information is provided. You need to remember who the customers of the document are. They span from developers through testers and deployment engineers toward technical writers and support engineers. In some cases, the customer also is a consumer. So, interests of all those people shall be taken into account.

Non-ambiguity means that there is only one understanding of what requirements say. Two different people reading requirements must have the same idea of what they speak of. There three possible failure scenario for this quality:

- Boundary shift ("up to 100" instead of "100 or less")
- Synonyms use (use the same term consistently throughout the document)
- Negative sentences (use positive sentences instead)


Testability is as simple as its name. You should be able to check if a requirement is met. And you should be able do this in a reasonable time and with reasonable resources. Testers are best people to judge upon it.

Traceability is a key to connecting different entities in your process into logical chains. Change in requirements may need according changes in design or test documents. To track those changes and update all connected entities correspondingly, we need to give a requirement an identifier. This is usually an unique number, that defines one and only one atomic statement.

Maintainability is how easily you can update it. The structure of the document defines how much efforts you may need to make a change. Duplicate information doubles the efforts, so use references instead.

Sense of priority gives the possibility to easily say which requirement is a must and which is nice to have. This is especially important when it comes to selecting tests for regression testing or shaking up the functional scope with hope to find 1-2 man months you are lacking in the development plan.

If you manage to write requirements that meet the above qualities then you are most likely to succeed. I would also recommend keeping it short. As one wise man said "conciseness is talent's sister".

Additionally I would recommend finding articles related to wording to be used in requirements definition. Following simple rules may help making requirement easier to read. All the more, the language is ambiguous per se. You may find in there which construction of language to avoid making it less ambiguous.

Good luck!