The Language Of Requirements Documents - When To Use Shall, Will & Should.

A well-written business requirements document (BRD) forms the basis of successful projects and can be used to verify that all stakeholders are on the same page regarding what the solution looks like. Three words that are often misunderstood and therefore misused in requirement documents are shall, should and will. 

But first…

Why Do We Need A Business Requirements Document (BRD)? 

Fundamentally, a BRD details the problems a product or service is trying to solve. It logically lists a product’s requirements in relation to the customers’ needs. It directs the project and keeps everyone involved on the same page, right through its lifecycle. The BRD:

●      is simple and defines business needs in a clear and concise way.

●      is agreed on by the relevant stakeholders.

●      describes what to achieve rather than how to achieve it.

●      has a logical structure.

More specifically, our choice of language can ensure clarity and meaning throughout the BRD.

Shall

In spoken English, we use both shall and will (almost) interchangeably to talk about the future. “I shall go to bed early” has more or less the same meaning as, “I will go to bed early”. In a BRD however, there’s a distinction that needs to be respected for the sake of clarity.

In a BRD, shall - and its negative, shall not - are used to describe a requirement. A requirement described with “shall” tends to have a high priority, same as when you use the term, “must”. If it helps, think of Gandalf’s intensity when he says, “You shall not pass!” in Lord of The Rings. He means business and that's what the word brings to your BRD. 

Let’s look at some examples: ‘The website shall have a homepage that lists the purpose of the organization.’  This is verifiable (easy to check) and has to be satisfied for the project to go ahead. If the website doesn't have a homepage that lists the purpose of the organisation, associated test cases will fail.

Will

Although in everyday English, shall and will are largely interchangeable, in a BRD, you really need to take into consideration which one to use and what message it conveys.

Will is used as a declaration of purpose or when describing features or specifications.

Here’s an example: ‘The system will include features to help employees track their time,’ The system might be in existence now and its purpose (yet to be fulfilled) is to track employees’ time.

Should

Should, and should not, are used to communicate a goal, which is an objective for the design team, or whoever is responsible for the development of the product/service. 

Think of it as a feature you really want in your product; one that makes it more attractive to the customer and the design team needs to know about but is not a mandatory requirement (the project can still go ahead if it’s not fulfilled).

Your product’s goals often translate well over to marketing and can be expressed as its features. For example, ‘The hiking boot should be waterproof even in heavy rain’. 

Another way to look at should in the BRD context is to give the development team something to aim for. Take this example: “The system shall have a response time of less than or equal to 0.5 seconds”. You want a faster system, but it might not be possible, so instead, you could set the goal: ‘The system should have a response time of 0.25 seconds.’ By giving the development team a goal, it gives them something to aim for beyond the required speed. Even if they only hit 0.40 seconds, it’s still an improved performance.

How BRD Writers Can Avoid Common Language-Related Errors 

Clarity is key when writing a BRD. If you keep to these 3 guidelines at the minimum, you can avoid common language errors and you and your stakeholders will be on the same page.

1. Avoid using indirect terms like may and might, as they are less definitive/descriptive of the actual requirement when compared with shall, will and should.

2. State what you mean by shall, will and should clearly at the start of the document. To avoid ambiguity and excessive follow-up questions, state what they mean within the context of your BRD before you start documenting your requirements.

3. Ditch the jargon. BRDs can be complicated and detailed, so stick to straightforward language. Keep in mind also, it’s not just your development team who will use this document; business users also need to validate the content of the document. Remove any references to technical jargon but if technical terms are unavoidable, remember to include a reference list with definitions.

I hope this article has cleared up any questions you might have had about the language to use in your BRD. If you keep these tips in mind, you would be one step closer to a complete and accurate BRD, your final product and happy stakeholders.