Business Writing
Business Requirements: Should you use Shall v Will?
Oct
Should you use Shall or Will when writing business requirements? Or something else? For example, some business analyst friends prefer to use Must.
Others insist that Shall is the international standard, so we should stick with it.
Download this Business Requirements template
Learn more about this template
Business Analysts use this to captures WHAT is required so that Software Developers then take these requirements and determine HOW these needs are to be met. This template pack includes a 24-page Business Requirements Specification, Use Case, Requirements Traceability Matrix and Data Model templates in Microsoft Word, Excel and Visio.
Business Requirements: Should you use Shall v Will?
The counter-argument says that’s not good enough. Times have changed. We need to put the reader first. No one uses Shall anymore.
And then there’s the argument that Shall is grammatically incorrect.
Others suggest to use both, but to be very clear about their meaning.
However, if the reader skips the glossary of terms they may not be aware of the differences. Likewise, if they are searching the requirements online, they may open a page deep in the documentation set and overlook the glossary.
And, of course, we need to consider how to translate the requirements.
So, why is this important?
As you can see, there’s quite a lot involved. There’s compelling arguments to use (and avoid) Will, Shall, and Must when writing requirements.
However, as business analysts, we can’t afford to sit on the fence. We need to understand when and why we should use Shall, Must or Will.
Creating Writing Guidelines for Business Requirements
Recently, a new client asked us to look at their document repository.
It’s was mix of technical documents, policies, SOPs, and a lot of requirements.
Requirements in SOPs, policies, HR manuals, responses to RFPs, technical specifications, and use cases.
However, one bone of contention for our client was the haphazard way terms such as Will, Shall, Must were used across the documents.
The existing business requirements documents were inconsistent. Shall and Will were used interchangeable, confusing readers, writers, and reviewers.
For example, sometimes Will meant a ‘nice to have’ requirement but not mandatory.
In other places, Will implied it was mandatory.
She also raised the point that, to her ears, Shall sounded dated and a bit high-handed.
“No one uses it in the real world,” she argued. “Can’t we use Will instead?”
Indeed, Shall can sound high-handed. But maybe that’s the point. It has an edge of authority you don’t get with Will.
Must was suggested as an alternative.
However, page after page of Must, Must, Must sounds like your nagging.
Of course, even if we agreed on the terms to use, it’s wasn’t as simple as Find/Replace All in MS Word
The requirements existed on the web, in PDFs, in hardcopies, in different systems, in different offices. So, it wasn’t a simple task.
Her goal was identify the correct terms, update the requirements, and provide guidelines for analysts in others offices.
“Let’s make sure to use the correct terminology, update the requirements, create guidelines, and move forward.”
To do this, we examined industry standard guidelines, style guides, and spoke to BAs here in Europe as well as in the States, UAE, India, Shanghai, and Australia.
We also asked business analysts on several LinkedIn groups for their thoughts. More on that later.
Using Shall in US v UK
A small detail.
The firm was based in Dublin, Ireland. The IT Director was from the US.
I mention this as you’ll hear shall used quite often in everyday speech in GB. Not all the time, but it creeps through.
Whereas, in the US, where I lived for 8 years, I rarely (if ever) heard it used in conversation.
A small thing, but maybe culture is something we need to consider when writing requirements for today’s readers.
Response from LinkedIn Business Analysts
So, which one should we use?
Ana Thompson, the head of Content Development at Klariti, decided to ask this on LinkedIn to get as much input as possible before went ahead.
She thought four, maybe five people would respond.
On one group, no one responded.
On another, 134.
Yeah, one hundred and thirty-four!
And counting!
The replies highlighted several points, such as cultural differences, industry preferences, and recommendations on when to use (and not use) different types of phrasing.
To put some shape on the responses, I’ve grouped them into different sections.
Reasons to use Will
“Will” should be used to state a fact and “Shall” to indicate a requirement
Helen McEvoy
Shall is used to say that something is expected to happen in the future
Will is used to express capability or sufficiency <the back seat will hold three passengers>
Chris Klein
Shall or must depending on the level of detail the requirements are at.
I prefer prioritizing requirements once using shall. Often depends on what system the client uses. For me will is not a solid enough statement.
Sarah A James
“Shall”.
It seems to be a seldom-used word, so it’s a little more distinctive than the alternatives. Either way, pick one and be consistent – don’t switch back and forth.
Ross Whiteford
I always use the MoSCoW prioritisation method. So I always use ‘Must’ for mandatory.
David Sibbald-Wall
In the organisation I work for, we agreed to write requirements with “shall”. The organisation is multi-cultural and people have different command of English, therefore we made clear decisions with respect to how requirements shall be formulated.
Katarzyna Kot
Reasons to use Must
Write ‘Must’
Why? Because it’s the most assertive.
The most common I come across is ‘should’ which seems the most natural for everyday use but in my opinion the least assertive.
Dan Hillary
I use ‘must’. That makes it clear that it is a requirement and not a suggestion.
Kristi Bente
Reasons to use Should
…most of the projects follow the must have, should have, and could have (MoSCoW) for categorization of a requirement. This helps in prioritizing.
In my opinion, it’s good to use the word “should” as it also suits the situation, when an analyst has to think from a system behavior (to-be state) perspective.
Shankar Ram Hariharan
I use to write “should”. It means that appropriate requirement should work exactly as written in the FSD, BRD.
Natalia Gorina
Write what the audience best excepts as “action” speak. I think “should” is as good as “shall”. But this debate approaches holy war status and I pay close attention to what my approvers and reviewers will accept. Personally, I wish they would focus on whether the statement satisfies the business need rather than; tom8toe vs toemotto.
Don Garland
Reasons to use Shall
“Shall”. Because it is directive.
“Will” is a promise.
Dagmar Ottevangers
Shall is grammatically correct only with “I” or “we” as subject of the sentence, so really isn’t appropriate for requirements. Avoid either shall or will by wording differently e.g. “provide ability to…” or something similar.
Angela Wood
I always use will for the requirement and must or should for the priority rating. That said if your client asks you to use something specific (which is probably a term that is consistent with the business) and you want them to extend your contract then use what has been requested. 🙂
Helen Thompson
Writing Agile User Stories
As a best practice my team uses ‘Shall’ in business and functional requirements and ‘Want/Need’ when writing Agile User Stories and Acceptance Criteria.
Shane P. O’Neil, Scrum Master Certified (SMC)
I usually use must for imperatives – compliance requirements, etc. Where there is an outside authority demanding something. From there, it depends on culture – Authoritarian cultures work better with Shall, vision casting cultures with will, some prefer requirements to be written in the present tense (this is how the system works).
With Agile user stories, the intent is to write with a person as the actor rather than the system as the actor. (I.E. “the Administrator would like to run this report so that they can get a head count of people coming to the convention”; rather than “The system will provide a report with a count of attendees.”)
Jason Schmidt
MoSCoW Prioritisation Method
Several Business Analysts highlighted the importance of using the MoSCoW method.
“The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. The term is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Would like but won’t get).” Wikipedia
However, not everyone is convinced.
Karl Wiegers criticized the MoSCoW method in the area of Software Development:
“It doesn’t offer any rationale for making the decision about how to rate the priority of a given requirement compared to others. MoSCoW is ambiguous as to timing, particularly when it comes to the “Won’t” rating. “Won’t” could mean either “not in the next release” or “not ever”. Such distinctions must be made clear so that all stakeholders share a common understanding of the implications of a particular priority rating.”
I tend to use Shall for my Must have (MoSCoW) requirement items so as to align with the meaning of the word – “expressing a h3 assertion or intention”.
I use Will to express requirements that have dependencies outside the current scope of work e.g. incorporating “AS-IS” / existing situations.
Emmanuel Mrakpor
Requirements do not necessarily follow proper Grammar.
However, each requirements statement MUST have an Actor, Action and Response with the Actor and Activity separated by a key word; MUST, SHALL, SHOULD, MUST NOT, SHALL NOT, SHOULD NOT, WILL, WILL NOT, and sometimes MAY. These key words provide clarity of importance to the requirement.
I have always coached to these 5: MUST, SHOULD, MAY, SHOULD NOT, MUST NOT.
Grant Street
I use MUST for no doubt that requirement MUST be met (switch out with SHALL depending on client), MAY for optional, and WILL NOT for exclusion and no doubt that some WILL NOT happen. But depending on what I am working on, for whom the work is being done, and to what level of writing I need to use to meet my audience I change my documentation to meet the needs of the client/project at hand.
Dave Matzinger
4 Different Types of Shall
At the same time, we researched the relative merits of using Shall in different kinds of documents. What should we look for? When could we use it? What mistakes did we need to avoid?
In terms of using Shall, Bonnie Mills, of quickanddirtytips.com, outlined four areas:
#1 Determined Shall
She explains that the British traditionally use Shall to express determination or intention on the part of the speaker. For example:
Evelyn Waugh: “One day you shall know my full story.”
As opposed to: “One day you will know my full story.”
The author sounds more determined in the first.
#2 Legal Shall
Shall in a legal sense often indicates explicit obligation.
If you’ve signed a lease, you’ve might see something like: “This lease shall commence on January 1.”
In general usage (everyday speech), you use must or should to express obligation: “You must pay your rent on time.”
#3 Lofty Shall
In famous songs or speeches. “We shall overcome” comes to mind.
At the end of the Gettysburg Address:
“…that we here highly resolve that these dead
shall
not have died in vain — that this nation, under God,
shall
have a new birth of freedom — and that government of the people, by the people, for the people,
shall
not perish from the earth”.
Bold mine.
#4 Polite Shall
Of course, Shall does have legitimate uses in American English.
You might hear it in a first-person question in which the speaker is being polite or offering an invitation: “Shall I take your coat, ma’am?”
https://www.quickanddirtytips.com/
Using Shall in Business Contracts
Ken Adams, on his excellent Contract Drafting blog, makes the point that, “In business contracts, the problem is overuse of shall. So I suggest that rather than simply dismissing shall out of hand as being archaic, it would be more productive to consider the pros and cons of retaining shall or dispensing with it, taking into account the distinctive characteristics and function of business contracts.”
He adds that “replacing shall with will would result in drafters using will to express both obligations and futurity. Use of one word to express different meanings is precisely what currently afflicts use of shall, so you’d in effect be replacing one form of overuse with another.”
https://www.adamsdrafting.com/
Using Shall in Legal Documents
Did you know that “shall” is the most misused word in all of legal language?
Wayne Schiess, on his legal writing blog, highlights that, in the current edition of Words and Phrases, “shall” alone is followed by 109 pages of case squibs, and “shall” phrases cover 45 more pages.
Yet its misuse is one of the most heavily repeated errors in all of law.
In most basic contracts, he recommends using “will” to create obligations, as long as you are careful to be sure any given usage can’t be read as merely describing future events.
He’s generally against “shall” because it is harder to use correctly and it is archaic.
Not Using Shall in Legal documents
Bryan Garner, Legal Writing in Plain English, 2001, takes a different angle.
“Shall” isn’t plain English.
But legal drafters use “shall” incessantly. They learn it by osmosis in law school, and the lesson is fortified in law practice.
Ask a drafter what “shall” means, and you’ll hear that it’s a mandatory word—opposed to the permissive “may”. Although this isn’t a lie, it’s a gross inaccuracy.
Often, it’s true, “shall” is mandatory. Yet the word frequently bears other meanings—sometimes even masquerading as a synonym of “may”.
In just about every jurisdiction, courts have held that “shall” can mean not just “must” and “may”, but also “will” and “is”.
Bryan Garner, Legal Writing in Plain English, 2001, pp 105-06.
https://www.plainlanguage.gov/
Using Shall as a question
The BBC makes the point that Shall is often used in questions in the first person singular and plural when making suggestions, making an offer or asking for advice:
‘Shall we go out for dinner tonight?’
‘Shall I get more tomato juice when I’m at the supermarket?’
‘What shall we do now? We’re clearly not going to get there by nightfall.’
https://www.bbc.co.uk/worldservice/
Using Shall to state an Obligation
The Economist points out that, “Shall is thought to primarily convey obligation (except for those few who still use it to mean the simple future in the first person). But this is not always so.
To cite Mr Garner’s, the legal writing scholar and editor of Black’s Law Dictionary, examples,
“the court shall enter an order” obligates the court to do something.
It adds that a shallful obligation can be unclear.
“Objections to the proposed modification shall be filed upon the debtor” is a common locution in legalese, but it does not impose an obligation; it says what must happen if one does have an objection—which one may not.
Explanatory shall: “The sender shall have fully complied with the duty to send notice when the sender receives electronic communication.” This is not imposing a duty, but explaining that operation X is complete only when condition Y obtains. It really just serves to define something, in this case defining when the sender has “fully complied with the duty to send notice”.
The “directory”, not “obligatory” cases when courts have held that shall really means should. “Anyone bringing a malpractice claim shall, within 15 days after the filing of the action, file a request for mediation.”
Incorrect use of Shall Grammar
Bryan Garner, the editor of Black’s Law Dictionary wrote that,
“In most legal instruments, shall violates the presumption of consistency which is why shall is among the most heavily litigated words in the English language.”
Those are some of the reasons why these documents compel us to use the word “must” when we mean “mandatory:”
- The Federal Register Document Drafting Handbook states “Use ‘must’ instead of ‘shall’ to impose a legal obligation on your reader.”
- The Federal Plain Language Guidelines referred to in the Federal Plain Writing Act of 2010, compel the FAA and every federal department to “use ‘must,’ not ‘shall’” to indicate requirements.
- FAA Plain Language Writing Order 1000.36, says avoid the word “shall” and use “must” to impose requirements, including contracts.
He adds, “What should you say if someone tells you that shall is a perfectly good word?”
Always agree with them because they’re correct! But in your next breath, be sure to say “yes, shall is a perfectly good word, but it’s not a perfectly good word of obligation.”
Examples: When to Use Shall and Will
Raymond E Urgo, provides a very detailed article on The Use of Shall and Will in Policies and Procedures Documents. In the second part of the article, he provides a breakdown of when to use Shall and Will. If you write policy or procedures. I highly recommend that you read this.
Examples of when to use shall and will
| Use shall or will to indicate | For Example |
| Futurity | If you are not satisfied within 30 days, Acme Corporation will refund your money in full. |
| h3 Promise | If you are not satisfied within 30 days, Acme Corporation will refund your money in full. |
| Threat | Violators will be prosecuted to the full extent of the law. |
NASA on Shall, Must, Will, Should
Next, we looked at NASA and its recommendations for writing clear requirements:
- Shall – usually used to dictate the provision of a functional capability.
- Must or Must not – often used to establish performance requirements or constraints.
- Is required to – used as an imperative in specifications statements written in the passive voice.
- Are applicable – used to include, by reference, standards or other documentation as an addition to the requirements being specified.
- Responsible for – used as an imperative in requirements documents that are written for systems whose architectures are already defined. As an example, “The XYS function of the ABC subsystem is responsible for responding to PDQ inputs.”
- Will – used to cite things that the operational or development environment are to provide to the capability being specified. For example, “The building’s electrical system will power the XYZ system.”
- Should – is not frequently used as an imperative in requirement specification statements. However, when it is used, the specifications statement is always found to be very weak. For example, “Within reason, data files should have the same time span to facilitate ease of use and data comparison.”
In disagreement with NASA, the US Government’s Plain Language group recommends against using the word shall entirely, as it is not clear to most readers what it means. There are hundreds of lawsuits that center around the meaning of shall.
US Navy Specification Writing Guidelines
The US Navy provides very detailed instructions on how and when to use Shall.
“When writing specifications we always state requirements in the future tense using the emphatic form “shall.”
Hence, the finished product SHALL be, SHALL produce, SHALL consume…
Government policy on this is stated in MIL-STD-961E.
The weaker auxiliary verbs “will,” “should” and “may” do not express a requirement.
In the case of “will,” the sentence places responsibility on the purchaser. “May” grants permission, and “should” states a preference.
“Must” is ambiguous, since it may express a presumption instead of a requirement.
For example:
John must love Deborah; after all, they’ve been happily married for over twenty years.
Correct usage of “shall” and “will” in specifications is extremely important, and is a frequent source of errors found in drafts.
Its guidelines also note that, “… people think that only sentences containing the word shall can express requirements, and their belief is reinforced by an ANSI/IEEE standard, 830-1984.”
US Navy – Specification Writing
When not to use Shall
At this point, you’re probably thinking, if I use Shall, all will be fine, right?
Maybe not.
Tyner Blain has an interesting angle that’s worth looking at.
“In English, shall and must mean the same thing – something is mandatory.
Should means, roughly “it would be a good idea.”
In fact, should is such an ambiguous term, you should never use it in requirements. [Bold mine]
I’ve worked with teams that used a MoSCoW rating system before – every requirement was identified as one of “must”, “should”, “could” (don’t not do it), or “would be nice.”
The problem with this approach is that the team is only accountable for the “must” requirements. At least in practice.
Personally, I’ve always disliked the word “shall” when writing requirements.
First, not everyone considers “shall” to be a mandate – but generally people do.
Second, I’ve always found the word shall to be too similar to should – which is a terribly ambiguous word in a requirement.
Once I started working with global teams, often with “limited” sharing of a common language, I began to get that feeling that something isn’t right, that maybe shall would cause a problem. Surely must is ok.
More at https://tynerblain.com/
When not to use Must
Sheldon Wolfe, on his Spec Writing blog, explains when to use shall and will but cautions against must.
CSI’s Manual of Practice states the way the words “shall” and “will” are to be used, and discourages use of the word must.
Shall is used as an imperative in reference to the work required to be done by a contractor.
Will is optional and is used in connection with acts and actions required of the owner or the architect engineer (A/E). The words “must” and “is to” are not recommended. (CSI Manual of Practice, FF/170)
If one follows the rule, there is no need for the word “must.”
He quotes a second source.
When an obligation on the part of the contractor is indicated, it should be associated with “shall.” The word “must” should not be used.
When there is an expression of intent on the part of the owner or engineer, use “will.”
Joseph Goldbloom, “Improving Specifications,” Civil Engineering, September 1992
Plain Language Recommendations
Then we looked at the Plain Language site. What did they have to say?
“Must” may be used to create requirements and prohibitions.
However, prohibitions should be drafted in the form of “X must not”, rather than “no X must”.
Drafters should not use “must” and “shall” together in the same Act or regulation. It could raise questions about whether different meanings are intended.”
Justice Canada’s Legislative Services Branch
“Shall” has three strikes against it.
- Lawyers regularly misuse it to mean something other than “has a duty to.” It has become so corrupted by misuse that it has no firm meaning.
- It breeds litigation. There are 76 pages in “Words and Phrases” (a legal reference) that summarize hundreds of cases interpreting “shall.”
- Nobody uses “shall” in common speech. It’s one more example of unnecessary lawyer talk. Nobody says, “You shall finish the project in a week.”
For all these reasons, “must” is a better choice, and the change has already started to take place.
The new Federal Rules of Appellate Procedure, for instance, use “must,” not “shall.”
Prof. Joe Kimble, Thomas Cooley Law School
Standards and Guidelines
Needless to say, there are standards and guidelines on when to use shall, must, and will.
Most agree, well, to a point.
NASA
NASA provides the following guidelines for shall and will:
- Shall — state a device or system’s requirements. For example: “The selected generator shall provide a minimum of 80 Kilowatts.”
- Will — state a device or system’s purpose. For example, “The new generator will be used to power the operations tent.”
ISO
On standards published by International Organization for Standardization (ISO), IEC (International Electrotechnical Commission), ASTM (American Society for Testing and Materials), IEEE (Institute of Electrical and Electronics Engineers), requirements with “shall” are the mandatory requirements, meaning, “must”, or “have to”.
“Whenever possible, requirements shall be expressed in terms of performance rather than design or descriptive characteristics.
This approach leaves maximum freedom to technical development.
Primarily those characteristics shall be included that are suitable for worldwide (universal) acceptance.”
Personally, I found these guidelines hard work. Maybe that’s just me. The full set of recommendations are in this PDF.
ISO – Specification Writing Guidelines PDF
IEFT
The IETF (Internet Engineering Task Force) defines:
- shall and must as synonymous terms denoting absolute requirements, and
- should as denoting a somewhat flexible requirement, in RFC documents.
DOD
On specifications and standards published by the United States Department of Defense (DoD):
“Shall” are mandatory requirements.
“Must” shall not be used to express mandatory provisions. Use “shall.”
“Will” declares purpose on the part of the Government or simple futurity.
“Should” and “May” express non-mandatory provisions.
IEEE
The IEEE provides the following guidelines. I’ve changed the formatting to make it easier to read.
Shall
“…to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to).”
Must
The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations.
Will
The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.
Should
The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).
May
The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).
Can
The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).”
Legal
Outside DoD, other parts of the U.S. Government advise against using the word shall for three reasons:
- It lacks a single clear meaning,
- It causes litigation, and
- It is nearly absent from ordinary speech.
The legal reference Words and Phrases dedicates 76 pages to summarizing hundreds of lawsuits that centered around the meaning of the word shall.
When referencing a legal or technical requirement, Words and Phrases instead favors must while reserving should for recommendations.
Technical and Business Requirements
So far, a lot of what we’ve covered relates to legal and government documents.
What if you’re writing technical requirements for IT systems or gathering requirements for business projects?
The members on the LinkedIn groups made some excellent points. Here’s a sample of the responses.
I used to write requirement as a client for the vendor to develop them. In those requirements, I used to prefer “should” (e.g. This button should open a pop up), as this was my request.
Currently I work on vendor’s site and I send the requirements to the client for approval. In this case, I use “will” (This button will open a pop up) as I describe the functionality that will exist and not the one I want/ imagine.
It is rather the point of view than the grammar, I believe.
Nikos Kokkinellis
One ‘must’ provide a glossary to declare the used terminology in your requirements document and create a shared understanding the h3ness and respective order of must, shall, will etc.
Bas de Kort MScBa
How does the choice effect categorisation of a defect?
Answer this question and you’ll understand when to use Shall, Should or Will.
“Will” is “external dependency” and you’d be raising a change request to an existing service, not a defect within your own project.
Shall will be a functional defect.
Should will be a cosmetic or equivalent defect.
Garrie Irons
The purpose of a requirements statement is to communicate. It is to communicate to the client that you understand their requirement. It is to communicate those implementing what needs to be implemented and then what will be used as a measure to confirm you have met client expectation.
I had one QA/BA person that was a grammar freak. Drove all the BAs crazy. As long as all understand the requirement that is what is important. Understanding is increased through consistency. So decide and be consistent.
Karina Honey
Personally, I’ve used the words Shall and Must interchangeably, I think they’re equally h3 for a Requirements and Business rules, which are typically the things documented in a ReqSpec document.
For non-functional Requirements (which are normally also in this document), I suppose you may use less h3 words such as Could/Can/Should
Andre Kasselman
Summary
So, what did we decide on?
We put together a 2 page cheat-sheet with examples. It’s intended to serve as a bare bones guide to writing requirements. As regards the wording, we’ve decided that:
- “Shall” – a binding provision. Mandatory.
- “Will” – a declaration of purpose. Not mandatory.
- “Should” – a recommended provision. Not mandatory.
Another way of looking at this is that:
- “Shall” indicates obligation. “You shall fix this light” (It’s an order) whereas
- “Will” indicates intention. “I will fix this light” (I intend to fix the light.)
One final thing.
Several business analysts suggested this.
Even though some readers may skip it, include a Glossary of Terms at the start of your requirements documents to provide a common language for all readers. This provides a frame of reference for readers, reduces ambiguities, and removes assumptions.
Finally, we’d like to thank everyone who commented on the LinkedIn groups.
It’s helped us refine the documentation set and ensure that future requirements use the same terms, phrasing, and formatting.
