How to write good requirements? | Learn how to structure a requirement effectively.

Different requirements statement’s formats are like umbrellas. They all have the same purpose of covering you from the rain but they don’t all do it equally well.

If you have been a Business Analyst for a while you will know that the way that a business, stakeholder or solution requirement is written has changed many times during the last decade or more. There are many different ways to write a good requirements statement and many of those methods are valid and works well. But which of these formats or methods is the ‘right’ way?

The blog article will start by outlining what are important considerations when you formulate a requirements statement and will then provide you with some examples of what could be considered as good requirement statement formats to use in the correct context. So hang in there and first take a moment to understand what aspects of a requirements statement are important and why these are important.

Important considerations for how to write good requirements.

#1 Use a single concept and it must be cohesive

Regardless of the level of requirement, whether it is a business, stakeholder or solution requirement statement it is essential to only cover one single concept per requirement statement. The reader should be able to interpret the requirement statement as a single statement that has a meaning without being dependent on other requirements for it to make sense. This is important because it enables the various readers (testers, developers or business stakeholders) to test, design or simply discuss one requirement concept at a time. This way it is also possible to clearly track the life cycle of each individual requirement.

#2 Measurable and specific

The requirement statement should be measurable in some way. This means that you should be able to clearly tell when this requirement has been met. If the requirement statement is for example concerned with a certain system functionality that must be available, you will know the requirement has been met by testing that the functionality exists and works. One reason why it is important to make sure that your requirement statements are measurable and specific is to ensure there are no ambiguity about what is required as part of a solution.

#3 Active and consistent sentence structure

Use a consistent sentence structure for all your requirements statements. Once you choose what the format will be, make sure that it is also structured in the active voice. Therefore, start with the “subject” of the sentence, then the active “verb” and then the “object” of the sentence. It is good practice to make your sentences as concise and clear as possible by using a consistent structure for all the requirements. This helps with comprehension and readability of requirements which in turn promotes a success during the implementation phases.

Example formats for requirement statements.

So let’s now look at two different example formats of requirements formats that are currently being used by Business Analysts around the world. These two formats are not necessarily the ultimate or the only two formats out there but they have all the attributes of great requirement statements when used in the correct context and for the correct purpose.

Example Format 1

As [role], I [want / must] be able to [perform / do something], so that [reason why I want/must have this].

• As a bank teller I must be able to search for a customer record so that I can serve my customers.

• As a senior manager I want to be able to run a monthly management sales report so that I can project the sales forecast every month.

Although this example format is most commonly used in listing high level Agile user stories, more companies are adopting this format for their high level business and stakeholder requirements statements as well. This example format has a few strong benefits. It not only adheres to the basic considerations of a good requirements statement but it also tells the reader who needs the specific capability and it provides a reason why it is required. A disadvantage of this format is that the same requirement may apply to many different types of roles in the organisation and the reason may sometimes be repetitive for a set of requirements.

Example Format 2

Ability to [do something] using the system.

• Ability to search for a customer record using the following search criteria (list search criteria).

• Ability to run a monthly management sales report which include the following information: (list attribute detail).

This example format has the benefit of being in a simple and clear statement format. It is however not always considered the most appropriate format because it doesn’t add enough value or detail when specifying requirements at a lower level of detail. It is tempting to an inexperienced Business Analyst to over simplify and then loose the meaning of the requirement. Another  consideration before using this format is to realize that it can sometimes result in requirements statements which don’t necessarily make sense to a reader that doesn’t have a background in a particular project. It also doesn’t indicate who will use the requirement that is being asked for or why it is required. Although we could argue that this example format is not as effective as the first example format, this is a common format which is still being used with reasonably good results.

In conclusion

By now it may be clear that there is not only one format to write a requirements statement in but a few different formats. We only covered two of the most common example formats here of how to write requirements. Many variations on requirements structures are derived from these two formats and may just have a slight variant in the way they are structured. It is also important that a Business Analyst considers the overall purpose for writing requirements  in the first place (example considerations would be: who is your audience, what type of requirements are you writing and how will your requirements be used) because this has an impact of which format you will choose to use.  It is more important that the Business Analyst covers the key considerations we listed here for each requirement statement they write than necessarily following a particular format.

Please share your opinion about how best to structure a requirements statement below.