Scott Selhorst of Tyner Blain did some research using a novel research method on how ambiguous shall and must are. The bottom line: if for any reason it might not be clear to some reader that shall means mandatory, use must (consistently throughout the spec, of course, and put the convention in your requirements management plan).
I think the shall (as opposed to must) dates back to the old MIL-STD 498, or even DOD-STD 2167A. And anyone who "grew up" BA-wise in the military or air traffic control fields like me, is very accustomed to the shall, and must might sound too harsh. But, hey, here's my favourite answer to that: "You're writing a spec, and you're not gonna win the literature Nobel prize for it!"
Interesting enough, as Scott points out in his article, in many languages other than English shall is not really used for the meaning of mandatory. In German, for instance, the meaning of shall is much closer to should than must. And we all know what happens in waterfall projects when acceptance testing is due and the developer has implemented only half of the should requirements...
_BW_besser.jpg)
Posts
6 comments:
Have a preface and number the axillary verbs:
1. Vap
2. Dap
3. Slap
It doesn't matter what word you use. The numbers will clarify where globalism and localization confuses.
You might look at www.expertchoice.com. They use a linear programming approach to stakeholder demands. Prioritize the spaces, put the requirements in those spaces.
Say you end up with a region satisfying four stakeholders with cell AA45 within that space. Put the cell reference in the requirement. Link it, since everyone believes stakeholders change their minds frequently.
I use both shall and must in my specs, so I disagree that one should be used in every case. The way I distinguish between the two is this:
- shall describes the eventual behaviour of the system (e.g. the system shall require the user to enter an email address)
- must describes a constraint on the system (e.g. the email address must be less than 255 characters or else our twelve-year-old database system will be corrupted)
The risk with an LP (linear programming) approach is that by 'globally optimizing' you risk failing to 'locally optimize' for any one of multiple stakeholders / markets. Coming up "a little bit short" in all you markets can crush you. You may be better off dominating one market at a time.
Scott, my particular approach is to code for each stakeholder/market using aspect-oriented programming. Every prioritization leaves some shorted. I'm just suggesting the linear programming approach when we are going to short some stakeholders. The real problem is that we will convince ourselves that we are not doing that.
Thanks to all commenters, and sorry for the delayed reaction. I finally figured out how to edit my blog from work.
@Ryan: It certainly is a good idea to define the meaning of the words. I can follow your definitions right away.
@Scott: Agree. It seems to boil down to making a conscious decision about which stakeholder to ignore.
@davd locke: I believe that the "liablilty" information given by should, shall, must and the like is only a small portion of all priority information. The majority of priority information should be given by detailed specification of
- dates ("needs to be in effect on Nov 1, otherwise...")
- places ("we need this in the oversees versions only, because...")
- conditions ("we want to have it in case solution x is not viable")
- ...
and most of all clear levels of performance or resource saving targets, like
- "we achieve goal x, if ..."
- "we will fail if ..."
- "we will not survive, if ..."
- "we would excel, if ..."
and so on.
I'm not sure whether using prioritized spaces is useful for supporting complex decisions (both business and IT related) that needs to be made by system engineers. It certainly is easy to handle for programmers, i. e. softcrafters.
Post a Comment