Well, this post is going to be a little sacreligious given that my organization (IGS Systems Engineering, Architecture, and Test) are best known for our skill with managing requirements, but hey, you can't be a real blogger and toe the company line, right?
After recently reading some of Kurt Bittner's
and Walker Royce's
writing, I'm starting to think that the term "requirement" is a misnomer, and perhaps should be replaced with something more accurate like "specification".
But first things first, let's look at a definition of a requirement. I work for IBM so of course I'll take my definition from the Rational Unified Process:
requirement - A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.
I think the word here that the phrase that throws me for a loop is "must conform". That seems pretty absolutist, with the sort of inevitability that one usually associates with only death and taxes. The reason that I have a problem with this is that requirements (and use cases, for that matter) specify solutions
to problems, and not the problems
themselves, and for any given problem, there are a number of solutions, some better than others, but usually several that are good enough. If there are several good-enough solutions, is it really the job of the analyst to specify one of the solutions as a requirement to which the system must conform?
For instance (and I kid you not), I once saw the following listed as a requirement for an e-business application:
"The system shall run on an operating system that uses pre-emptive multithreading."
So, I guess I could say that I don't have a problem with that, but is it really a requirement? Let's look at RUP's definition again, piece by piece:
requirement - A requirement describes a condition or capability to which a system must conform; either derived directly from user needs ...
So was pre-emptive multi-threading derived from user needs? It certainly wasn't requested by the user. I was partially amused and partially curious, so I talked to one of the more senior analyst/architects on the project why this was specified and he told me that the previous system ran on a system with a sub-standard threading model, which hurt scalability and resulted in poor response times when too many users hit the system. So one could argue that indeed this requirement was derived
from a more general requirement: the system shall support up to x
many concurrent users while providing a response time of less than y
So if you were a developer on the system, which would be more valuable to you, a requirement that stated you must use pre-emptive multi-threading or a requirement that specified how many concurrent users you'd be expected to support and with what kind of response time?
To me it's obvious that the developer would value the latter, because it's truer to the essence
of the user needs than the former. Indeed it would be very possible that the development team could build the new system on any modern distributed computing platform (like WebSphere Application Server) and still have god-awful performance, simply because a complex system is a chain of components, where any link in the chain (or connection between two links) can create a performance bottleneck, so if you simply aligned to the multithreading requirement and promptly stuck your head in the sand, you're satisfying the letter of the law but not the spirit.
I really like Kurt's and Walker's view that you essentially have business needs/problems, and you have software solutions. In the example above I would break it down like this:
Business Problem: We expect x many users to need access the system during peak hours. How do we provide these users with a user experience that will allow them to do their job quickly and not become aggravated?
Specification: The system shall support up to x many concurrent users while maintaining a response time of less than y seconds, which studies have shown to be the threshold above which users become irritated.
This may spawn off a number of potential design decisions by the development team, such as which application server and database to use, and drive decisions to use performance-enhancing techniques like caching. But you've given them flexibility by stating a need and a specification of acceptable behavior, and not saddled them with an arbitrary design decision that may or may not address the underlying business need.
Now you may have noticed that I only covered the first half of the RUP definition and didn't cover "or stated in a contract, standard, specification, or other formally imposed document." There are some times when a requirement truly is a requirement, whether it states a problem or a solution, as in the case of legal requirements or requirements from a firm to a subcontractor, but I think that's enough for email@example.com