Debate: The Danger of "Negative" Requirements
I recently read a thought-provoking thread on the IIBA LinkedIn forum, relating how business analysts should state requirements. The conversation centered around one main topic: Is it advisable to define a system by stating what it shouldn’t do, or should we avoid “negatively framed” requirements?
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 in the area, cyclists are banned from using the path downhill—as it’s likely they’d lose control and collide with an unsuspecting passerby. A picture of the start of the hill is shown above. Trust me, it’s much steeper than it looks in the picture!
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—wherever possible—it is always better to define requirements in terms of the required behavior, using positive language. Taking the example above, perhaps the real rule/requirement is “Pedestrians only.”
I believe that relying purely on verbalized requirement statements is risky; it’s far better to have a range of requirement artifacts, 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.
