I recently read a thought-provoking thread on the IIBA LinkedIN forum, relating how Business Analysts should state requirements. The conversation centred around one main topic: Is it advisable to define a system by stating what it shouldn’t do, or should these “negatively framed” requirements be avoided.
There’s no hard and fast answer on this, and there are certainly varying views on what constitutes a well-written requirement. However, I firmly believe that it is highly preferable to define systems in terms of what they can do (rather than what they can’t).
I’ll illustrate this with a real life—but non IT—example. I live in Portsmouth, on the south coast of the UK. Near the seafront, there’s a really steep hill. Given the number of pedestrians that are in the area, cyclists are banned from using the path downhill (as it’s likely they’d lose control and collide with an unsuspecting passer-by). A picture of the start of the hill is shown below. Trust me, it’s much steeper than it looks in the picture!
Should negative requirements be avoided?
Think about this picture with your “BA hat on”. There’s a real-world requirement there (expressed as a rule) that says “No cycling, no skateboarding”. It’s painted in bright white paint on the path. That’s a clear requirement, right?
Wrong. In isolation this requirement is extremely ambiguous. It tells us two forms of transport that aren’t allowed – but it doesn’t really confirm which are allowed. In fact, on reading this requirement, some people may assume that it implies that:
– Scooters are allowed
– Rollerblades are allowed
– Aircraft are allowed to taxi down this path
– Tanks are allowed
– Zorbing is allowed
– Etc, etc
Now, in this instance most of us would apply common sense and say “Well, if skateboarding isn’t allowed, then rollerblading down there probably isn’t a good idea either”. However, in the world of analysis, that kind of ambiguity causes issues when a solution designer comes to architect a solution. What about a sledge in winter? Or a Segway? Are these allowed? Extrapolate this into the world of projects, and you can imagine the challenge and cost that imprecise requirements can cause.
My view is that it is always better – wherever possible – to define requirements in terms of the required behaviour, using positive language. Taking the example above, perhaps the real rule/requirement is “Pedestrians only”.
I also believe that relying purely on verbalised requirement statements is risky; it’s far better to have a range of requirement artefacts, including some models. A good quality logical data model (or a ‘class model’ if you’re using UML) will help a great deal. This can help implicitly show negative requirements (Theoretical example: if a data model shows that “one student can attend only one class” then it is implied, but also perfectly clear, that they can’t attend more than one).
What are your views? I’d love to hear them. Please add a comment below.
This article was originally published on stickyminds.com on 24/08/2012
Hi Adrian
A subject close to my heart!
I completely agree that it’s best to supplement verbal requirements statements with other artefacts such as data models, and your example shows why.
I’m surprised that you think “No cycling, No skateboarding” implies that scooters, tanks etc are allowed. In my opinion in doesn’t imply any such thing – but the fact that you do think so illustrates the fact that ambiguity is in the eye of the beholder. People often write things which they think are clear but which others interpret differently.
There are some types of construction in English which are inherently ambiguous. They often include negatives, absolutes and/or implied subordinate clauses. My favourite is the one you can see at the escalator in every London Underground station: “Dogs must be carried”. My reaction is always “Damn, I left my dog at home, I’ll have to use the stairs!”
Another interesting class of statements in English is where the same (or a similar) construction is used by different people to mean opposite things. For example “there is no question that skateboarding is allowed” – some people would take this to mean skateboarding is definitely not allowed, some that it definitely is allowed. Or “rollerblades should be substituted for scooters”. It’s tempting to react to this by saying that people who use English “incorrectly” (i.e. differently from ourselves) are wrong and should learn to use it properly, but of course that is no actual help.
I think English is very underrated as a tool for requirements specification, but I also think BAs in general are not nearly well enough trained in spotting potential ambiguities and writing clearly.
Nick
Hi Nick,
Thanks for your reply, and your very valid observations.
I must confess to playing “devil’s advocate” by suggesting that “no skateboarding..” etc implies that other forms of transport are allowed. In reality, a rule excluding one thing does not *logically* imply that other things are acceptable. To use a rather facetious example, a “no smoking” sign doesn’t imply that other addictive behaviors are allowed–it just bans one of them. However, there are other rules and norms around it (some stated/some legal/some unstated and cultural).
The same is true of requirements. Some people will think something is so obviously excluded, that there’s no need to state it. For example “It’s *so obvious* that smoking is illegal in a bar, that we don’t need a sign”. Which is fine, unless a patron arrives from another country and has a different expectation.
… which is really just a long way of saying I completely agree with your statement that “ambiguity is in the eye of the beholder”.
In fact, I’ve made a minor tweak to the article to reflect this (I’ve added… “It could be read to imply that…”. Your challenge was a very good one 🙂
Your point about use of English language is a good one. I’d build on this and say that a basic understanding of logic helps address ambiguity. It can help uncover misunderstandings about cause/effect, and also helps add to precision. It helps unpick (incorrect) statements like “Some European people have black hair. You have black hair, therefore you must be European”
Thanks again for the comment Nick,
Kind regards, Adrian.
Excellent article Adrian and an even refreshing take provided by Nick. Goes to show that there is more to Requirements Elicitation than meets the eye.
I wish they would apply that same logic to ‘Quiet Zones’ on trains!!!
The signs usually say something along the lines of “Please show consideration for other passenger by not using mobile phones, headphones or personal stereos etc., in this peaceful area”.
I personally feel that the “don’t talk at the tops of your voices” is adequately implied; however some people either misunderstand, or (more usually) deliberately choose to believe that doing so is acceptable because “it doesn’t say no talking on the sign”.
Stealing Adrian’s train of thought (pun intended) from the original article, does it therefore mean that playing a movie at top volume on your laptop is acceptable? Whistling? Playing a musical instrument? Sounding of a klaxon? The list is endless!
Surely a sign more along the lines of “Silence Only” would better encompass the expectation of passengers (like me) who actually want/need the quiet time?
Thanks Adrian – an article that picks up one of my biases. I wish that English grammar and logic were required subjects for BAs. In fact, for anybody who writes as part of their job.
I have another story to illustrate ambiguity. I don’t know where I read it, so many of your readers may well have seen the same blog or website that I saw it on. It goes as follows:
A woman sends her husband shopping with the instruction: “Get a brown bread and, if they have eggs, get 6.” The husband comes home with 6 loaves of bread and when the wife wants to know why, he says, “They had eggs.”
Ambiguity is most certainly in the eye of the beholder!
As an NLPer I am very anti negative requirements. Just by saying “don’t do x” you are putting the idea of x in the mind of the reader. The developer or business might never have thought of x until you mentioned it in the negative. There is always a positive to a negative. Always, even if it means prescribing a number of positive alternatives.
Fiona, it suddenly dawned on me that I never replied to your comment. Sincere apologies 🙂
Thanks for the comment. You make a really good point — as a friend of mine always says, if you say “don’t think of apple pie”, what’s the first thing that springs to mind? Apple pie of course!
Stating requirements in the positive is more precise. The art is to write requirements that are both precise and concise, so that they are easy to read and unambiguous. For me, it helps to use a mixture of techniques — mixing the written word with, say, models. A well written model can add a lot of precision, but it depends on the audience of course!
Thanks again for the comment, take care — Adrian.