When to use Must v Shall in Business Requirements

mustvshall

Do you use the word “shall” in everyday speech?

Can you tell the difference between “shall” and “will”? In what context should you use each word?

Anyone whose job involves writing requirements, proposals, or legal text will have encountered this dilemma. From where I’m sitting, shall is dated and, in many case, used incorrectly. But it’s the safe option for many writers and they stick to it.

The difference between the two can be seen in this example from Bartleby:

You shall have your money

expresses a promise (“I will see that you get your money”),

whereas…

You will have your money

makes a prediction.

Who uses Shall?

I started my writing career in
London. Using “shall” was normal. It sounded fine to most people’s ear. However, when I moved to the US, it became a real thorn, especially when writing requirements.

Bartleby mentions that “Americans use shall chiefly in first person invitations and questions that request an opinion or agreement, such as Shall we go?

Personally, I think this may have passed. Many Americans I know say, “Will we go, now” or simply “Let’s go.”

Why use Shall?

In theory, the word “shall” is more precise and exact than “Will”. This is not always the case. The reality is that few people use “shall” in their daily conversation and you run the risk of sounding haughty, arrogant or pretentious if you adopt this tone in your writing. It sounds like you’re talking down to someone – giving them an order.

When a reader encounters “shall”, their reaction is, “you have to get this 100% right or else…”

It carries a veiled threat that if you fail to meet your obligations, you will be punished. When I encounter the word shall, I can’t help feeling that the writer is stuffy, pedantic. The type to split hairs. The tone is definitely not pleasant. My impression is that this will be a difficult customer to please and not someone I would volunteer to work with.

You can improve your documents by dropping “shall” and using “must” or “will” instead. This changes the tone and creates a much more receptive readership.

Why use Must?

The Plain English Network has made great strides in persuading government agencies, especially in the
UK, to adopt more user-friendly text and to root out archaic writing styles.

Yes, there are writers, lawyers and style police who’ll persuade you to use “shall”, otherwise contractors will fail to meet their obligations. In truth, this is a crude instrument to use. More than likely the agency doesn’t have much confidence in their own project management personnel and is resorting to using the RFP specifications to fight the contractor every moment they deviate (or appear to deviate) from the specs. Contractors can play this game too and claim that specifications are ambiguous and contradictory.

The good news is that many government bodies now use “must” to convey obligations. The word “must” tells the reader what you expect from them. The voice is firm but neutral. The condescending tone is no longer there.

Why use Will?

If “must” sounds to aggressive or inappropriate, consider using “will”, especially when indicating an obligation that will occur in the future. For example, “after the servers are networked, you “will” install the security software.”

Thousands of templates to jump start your project

Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan