I agree that “must” can sound bossy. I believe you acknowledged that it is unambiguous. Very few people that I’ve met can parse (language / documents / context) as effectively as you demonstrate in your examples.

Anecdotally, I’ve had people fail to parse “shall” and I’ve yet to have someone complain about “must” be too harsh. When documents are potentially going to be consumed by people for whom English is a second language, I’m going to stick to the unambiguous, because it keeps working for me. I do agree with your point, I just see it as the lesser of two evils (when compared to “ambiguity risk”).

Thanks again,
Scott (@sehlhorst on Twitter)

So what if one can get 21/41 for “shall” in the translation matrix?? This may be more idictative of the way in which languages are constructed than with an inherent confusion in the use of the word “shall” in English alone.

The perceived problem with “shall” is related to the associated word “should”. If you google translate the word “should” you get the same result of “devrait” in French as for “shall”. What seems to be happening here is that the translator is selecting the conditional in conjugation. This would be correct as, “shall” does imply a predition of futurity. That is … something SHALL occur IF some other condition prevails. I would grant that this could be used as an illustration of confusion and thus a reason to use “must”. However, I think that all this ignores the importance of context. The words “shall” and “should” have particular meanings with respect to contracting. I don’t believe that there is a confusion within this context which necessitates the use of the word “must”.

… You shall do something and if you don’t then the contract is not fulfilled.

… You should do something, but if you don’t than the contract would still be fulfilled.

This doesn’t show up in translation since only the word is translated, not the context. To simply say that something should be done represents the idea that it would be done. The word “must” gets 41/41 in the matrix because it is emphatic that something must be done regardless of conditions.

I suppose in a way, my main objection to the use of the word “must” is that it is too bossy.

… You shall do something and I expect you to do it.

… You must do something and you bloody well better do it and just to make certain I am going to stand here and watch you do it.

eduard alf

I also find that confusion abounds between Must/Should/etc as ways of stating requirements and Must/Should/etc as a priority system using MoSCoW.

Interesting discussion and I sort of agree with everyone to some extent.

I was raised with a Mil-Std requirements background. We has specific rules:
- shall is compulsory and failure to deliver will kill the project.
- should is a requirement, but we can find a workaround if it is not delivered on first release.
- could is a nice to have we’d like it if there is time and money to spare (yeah, like that ever happens).
- will is a statement of fact with zero cost to deliver (i.e. it already does this).

Since moving into business and a use case centric approach, I now prefer the precondition/postcondition active voice method of writing requirements (i.e. my requirements state what the system does, not what it must do). This had the advantage of removing unnecessary words from the requirement, and priority is tracked with e requirements management tool (as it should be). It is also a nicer way to present your requirements to the tester (IMO).

All functional requirement statements can be written in the form:
‘Upon’ ‘the system’ , within .

For example:
Upon receiving a request to display the menu, the system [shall display | displays] the system menu to the customer within 2 seconds.

Interface is needed when the system interacts with more than one actor, in order to clarify who gets the results (there may be two or more outputs to several actors).
Time limit is required in order to test the requirement.

Translating into MoSCoW terminology, mandatory was “Mo” and non-mandatory was “SoW”, and C was left out of the mix. To my mind, C doesn’t seem like a requirement, just a design consideration, and belongs in a later iteration cycle, during design.

In general relativity, there is the force of attraction (gravity) and repulsion (weak force?). The net effect of these two forces is to establish a field over the system life where at some point the forces are balanced. In between is a borderland, rather than a binary border. In deterining the age of life on Earth, this borderland situation leads various estimates. Whenever you see a distinct binary, try to think in terms of a pair of forces.

Beyond the border issue is the notion of software as a media. A radio signal is a mix of a carrier wave and a (program content) carried wave. Software as a media is code carrying, in an enterprise, business policy. Sadly, the term business rule was hijacked a long time before the distinction between database rules and business rules got clearer. The carrier vs carried paradigm should help.

It is said that programmers abstract away from requirements. This statement is true in that programmers have to think of many things distant from the tasks or activities being enabled at the interface. Again, carrier vs. carried.

We subsequently reverted to everything being a *must*, with the MoSCoW words (along with estimates of effort and value, and affinity to other requirements) helping drive selection for iterations.

Our experience with user stories also led to a more clearly stakeholder-centric first-person present-tense language:
“As a call-centre agent, when the client has confirmed the order, I am prompted with associated products to cross-sell”.

For projects where the first-person nature of this construct didn’t work, we can strip it down a little more:
“When the client has confirmed the order, call-centre agents are prompted with associated products to cross-sell”.
The affirmative nature of the present tense “are” means that we don’t have to say ‘must be able to’. By the same token, when we say “call centre agents cannot override the discount rate for new clients” — we don’t have to say ‘must not be able to’.

Clearly, when the event triggering an activity is not caused by a person, then we typically resort to anthropomorphising the system:
“The document management system alerts owners of all documents left checked out for 24 hours or more”.
While we can shift the focus back onto the stakeholder involved, by redrafting to:
“As a document owner I am alerted when any of my documents are left checked out for 24 hours or more”
– or in the third-person:
“Document owners are alerted when any of their documents are left checked out for 24 hours or more”.
– this doesn’t specify what is doing the alerting. So making it stakeholder-centric is not always the clearest form.

Scott, thank you for writing about the issue, and hosting such a great discussion about it. Kudos! My respect goes to you and your work over the years, and I hope I cited you correctly.

@Rachel English: It depends on whether you are writing from a user perspective (use cases and the like) or a system perspective. See Scott(8). I’d say your style is perfectly well suited for the user perspective, although I’d avoid a “prior” and write what is prior before the other thing. Disambiguity requirements are much stricter if there’s a lot to loose, like money or lives. You might find the article instructive for your purposes, if you really need to write atomic functional requirements. Also see http://tr.im/kwN7 to find out whether a requirement is atomic.

@David Smith (15): There’s a place for the structure you mention, but only to complement various other structures. It’s hard to fit everything into ONE structure. See my wiki post mentioned at the top.

@Jeffrey Smith (16): I think we think along the same line of thinking :-)

@Julian: nice example. I can see what your context is, and why you chose to not use sentences like I do. I have worked for BA beginners most of the time, teaching BA practices. It seems all boils down to the salomonic answer: it depends! :-)

The ambiguities inherent in the requirements process are bad enough if you are dealing with only one natural language.

Where I work we have a very mature BA practice, with extensive organizational support. This includes 40+ in-house training courses, an accreditation program, enterprise-level BA standards / processes / tools, a formally sponsored community of practice, a formally sponsored BA Champion Group, all managed by a 3 person full-time Centre of Competency, etc. (I lead the Centre of Competency). We are also focussed on _solution_ rather than _system_ (as per BABOK 2.0), which means that many requirements describing process steps (for example) are executed by humans, not machines. A solution is comprised of people who execute processes using tools.

You said:
> I use the following two sentence structures:
> 1) “The System shall ” with everything outside of the brackets being literal.
> 2) “The system shall provide the capability to …”

In case 1, you said the benefit of “shall” is that it encourages the active voice and that it keeps a standard structure. We get these benefits through training and assessment. BAs learn to use the active voice and to use a single, simple structure for every requirement statement, and we have some organizational self-correction measures to maintain the standard.

Case 2 is trickier. We see this construction as destructive to effective communication and prioritization, and dangerous to the sustainability of our business. Our rationale: a capability is meaningless without understanding who will use it and the circumstances of that use. We have been burned by using this construction because it encourages the BA and stakeholders to break the association between what the solution must do and what the solution is supposed to achieve by doing it.

I’ll use a melodramatic example. Your government has a [date x] for you where [x=died]. In a requirement document, “The system shall provide the capability of editing DATE_OF_DEATH” is likely to be part of a long list of fields-that-can-be-edited, and unlikely to be associated with any particular process or task, though it might be associated with a screen.

In our company, we would have a Use Case called “Stop payment of death benefits to soldier’s family” with “Step 7. The USER edits DATE_OF_DEATH to match date supplied on FORM_2-973/W+a.” The narrative, preconditions, inputs, outcomes and postconditions are wrapped around the DATE_OF_DEATH field, and help define the impact it has on the stakeholders. We also try to trace the data-dictionary definition of DATE_OF_DEATH to each process, report and user that accesses it. (We usually get the process and report links, and find the users from there.)

That’s great, but the benefits roll in later, when somebody goes into the system to do a little maintenance on the DATE_OF_DEATH field. The cross-referenced solution documentation we produce helps the maintenance developer see the impacts of change – and means we are much less likely to make orphans starve.

Hey, I said it would be melodramatic. I don’t work in a life-and-death industry – but we know this kind of thing really happens.

As I said at the start – I agree with a lot of your post. We work really hard to make requirements boring-through-standard-structure, for instance. Thanks for the comments!

I find it quite helpful to have a single sentence structure for granular, atomic functional requirements (or 2 -3 different ones for different situations, see below). Where’s the difference to acceptance criteria, where a common form is Situation-Event-Result. Actually I got accustomed to do some kind of requirements speed reading with such specs.

First fixation: First 1 or two words – the actor in this sentence (different from use case actor!). I can skip this fixation most of the simes, see below)

2nd fixation: 3rd word – says something about priority (this information can be put elsewhere, but I find it valueabe to read a spec’s”content” only, without distracting tags. makes sense if there are requirements with different auxiliary verbs, not just one)

3rd fixation: usually the strong verb (sometimes called process verb) – clearly indicating WHAT has to happen)

4th fixation: rest of the sentence – everything else I have to know to understand the requirement.

You can read a spec with better understanding at much higher speed (I dare to say at least 4 times faster) compared to a nice-sounding spec with varying sentence structures. Might be less boring, but hey, this is a spec and you will never win a Nobel Prize in literature for it! ;-)

WRITING lots of “the system shall”s IMOisn’t really an issue: we have word processors and other tools (like speech recognition) that help with tasks like that.

I use the following two sentence structures:
1) “The System [shall | should | can] [verb] [objects] ” with everything outside of the brackets being literal.
2) “The system [shall | should | can] provide [whom] the capability to [verb] [objects] …”

[Note from Scott Sehlhorst: I edited the above per Rolf's request - the comment system had stripped out some content that was formatted with greater-than and less-than symbols. This stripping is in place to prevent malicious people from embedding javascript or other code into comments on the site. "em" "i" "strong" "b" "ul" "ol" "li" "blockquote" "cite" "a" and maybe some other html codes are all supported when well-formed - so feel free to use those (note that if you include multiple "a" (anchor) links in a post, the system will probably flag it for manual review before publishing. Sorry for the confusion! Tyner Blain actually uses the default "protection" of comments that is part of the standard Wordpress installation, so we're not doing anything fancy.]

where 1 indicates some action that is required to be performed by the system-under-spec. Example: “The system shall display date X”. No. 2 indicates, well, a capability, that has to be provided by the system-under-spec. Example: “The system shall provide the capability of editing date X”. NOTE that it does not help to write something like “the USER shall edit date X”, as this is requires something from the user, not the system. This might seem like hair-splitting, but I have seen lawyers quarrel over this difference.

my 0.02

(re: your @Simon response) – Really good point about conflation of axes. Personally, I’ve had success going with a different approach:
1) Prioritize benefits as “pain and gain” – i.e. reducing negatives and adding positives, combining those to reflect a notion of utility – see my previous article on the Stakeholder Value Delivery Matrix, adapted from work by Roger Burlton.
2) Deal with business and implementation constraints as constraints – i.e. they bound the solution space.
3) When you can estimate costs, use those to drive a prioritization by bang for the buck – see my previous article on prioritizing sprints part 2. The discussion on that one (and part 1) provides good insights into the next level of detail (e.g. dealing with strategic initiatives and other orthogonal “priorities” that don’t map cleanly to a benefits matrix).

I don’t think one single-axis prioritization scale provides any more clarity than another. The C/E/O scale is the same as MoSCoW, where C=M, E=S, and O=CW. I would expect that providing the same clarifying language in the MoSCoW framework would yield the same results. I’ve written MoSCoW docs for clients before, where that was their institutional policy, and the equivalent clarifications were included in the doc.

I do agree that managing expectations is critical, and that everything can’t be “top priority.” I remember in the dark ages, when working as a developer on a project, when the project manager introduced “Very High” as a new priority, to try and tease apart the massive bucket of “High” priority items.

I am not inclined to believe that omitting the words, and relying on the readers to “fill in the blank” is a less ambiguous way to write, but I am open to the possibility, especially considering that more than one person has suggested it.

@Simon: Where I work, we have tried a lot of prioritization techniques, and discovered that they only work if you prioritize on three distinct axis: benefits of change, implementation constraints and business constraints. Most methods (like MoSCoW) conflate these three, and ask the stakeholders to assign a single priority to encompass all of them at once. This can result in insane decisions. For example, oxygen and water are extremely expensive to send into space with astronaughts. If the perspective / bias of the stakeholder is implementation constraints, these will have a low priority. If the perpective is benefits, they are neccessary. If the perspective is business constraints, they are part of a negotiation about the number of astronaughts we can afford to send.

Critical: Highlights a ‘bare essential’, without which the end-to-end solution/service will not be of value to the business. If the supplier doesn’t do this, they’re out.
Expected: These are important rather than critical. We expect these requirements to be met but non-conformance does not make a bid non-compliant. The supplier should do this and it’s included in the price.
Optional: Considered to be of lower relative importance or relates to a future aspiration. We want to know about this but it’s not in the price.

Using this categorisation really focuses the business customer to think about what is important to them. Until then we often used MoSCoW to categorise requirements but it doesn’t make the customer think enough about their requirements. Customer’s will respond “all my requirements are mandatory”!

So, the method of prioritising requirements also depends on the customer and the audience.