"Shall" we require?
Does anyone know the history of the shall statement in requirements?
I hear people now and then complain about that word. I personaly don't like it as it's not a commonly used word in English. To that point, a client this week pointed out that when sending requirements off-shore to developers that do not speak English as a first language, it is important that requirements are written in basic English (think elementary/middle school). The requirements need to be written using words commonly taught in English language classes, and "shall" is probably not one of those words. Granted the other side of the argument was that if every requirement says "shall", the developer is probably going to figure out quickly what it means.
So I suggest, why not use "will" or "must" instead?
But that all aside, I'm curious, what is the history of using "shall" in requirements? A quick search did not land me with any obvious answers to it so far.
I hear people now and then complain about that word. I personaly don't like it as it's not a commonly used word in English. To that point, a client this week pointed out that when sending requirements off-shore to developers that do not speak English as a first language, it is important that requirements are written in basic English (think elementary/middle school). The requirements need to be written using words commonly taught in English language classes, and "shall" is probably not one of those words. Granted the other side of the argument was that if every requirement says "shall", the developer is probably going to figure out quickly what it means.
So I suggest, why not use "will" or "must" instead?
But that all aside, I'm curious, what is the history of using "shall" in requirements? A quick search did not land me with any obvious answers to it so far.
posted by Joy at 12:08 AM
1 Comments:
I agree, shall just imposes 'extra' verbiage that does not provide much value. Ultimately saying more with less is the goal and of course, in the most basic and understandable English.
In fact, for Requirements specifications; use cases, assumptions, business rules etc., I use present tense/active voice statements. It has been standard at the last two co's I've worked at over the last 5 years. I find this to be cleaner and ultimately the requirement of the system is for it to do 'something', not that it 'will'; b/c once developed, ideally, you would have to go back and remove will or must from the requirements, and what a maintenance nightmare!
For example:
1. The user logs into the system.
2. The system validates the user information.
is cleaner and more concise than;
1. The user must log into the system.
2. They system must validate the user information.
If you are referring to higher level feature requirements, such as from a product management level or relating to the general performance requirements, I have seen it in many forms, particularly the use of MUST, WILL or Should is often used; however I've seen these in the present tense too.
I think for ANY company, the key is consistency and clarity.
Thanks for all of the great information.
M
Post a Comment
<< Home