Among the many challenges of developing the BABOK is figuring out what to do when we realize that the industry, or worse yet parts of the industry, have widely adopted unclear terminology. The problem is even worse when we encounter instances where different segments of the industry have adopted different terminology.
One example is the term “nonfunctional requirements” Many experts hate this term, as it implies that the requirements in question don’t do anything. I happen to agree with them–I much prefer “quality” or “quality of service” requirements. However, since BABOK 1.6 was published it’s become pretty clear to me that this battle was lost long ago, and nonfunctional is the term overwhelmingly accepted in software development. I’m not yet 100% sold, mostly because there’s one other problem with the word nonfunctional–it’s a very product-centric term. For instance, look at ISO 9126. A lot of those requirements, which are a pretty good summary of “nonfunctional” requirement types, can apply just as well to a process.
Now, in this case I think I have a reasonable solution, which would be to accept the term nonfunctional as the industry standard, and suggest the term “quality requirement” be used when working on non-software solutions. However, there’s an equally problematic term for me, which is “requirement type”. In practice, requirement type is used very loosely. In software development, there’s “functional” and “nonfunctional” which are genuinely different types, but then the water gets muddied as we start trying to extend them outward to talk about user requirements, business requirements, and so forth. In many cases, what we’re talking about is really downward traceability–from high level to low level requirements. A better term than requirements type would be the scope of the requirement. I struggled with alternative terms for a while, like level of detail or abstraction, but neither term was right.
Personally, I find this concept much more intuitive than type. For one thing, I’ve found that the term “business requirements” is controversial because some people say there are no “non-business” requirements. If we talk about them as a type I can see the point. If by business requirements we understand that the requirements are being expressed with a scope or level that is relevant to the business as a whole, though, the distinction becomes more clear. We can also understand how we narrow the scope of a business requirement to reach the lower-level requirements that it implies, and, conversely, how if we begin working by trying to define narrowly-scoped requirements, we can’t relate them back to the higher-level requirements that justify the project.
So what’s wrong with this concept? The biggest problem is that I invented the term yesterday. I’m not pretending it’s unprecedented–the Zachman Framework has the same concept, although it refers to different levels of requirements scope as “Rows”. It’s just that I’m fighting against years of usage if I try to introduce this term. The other problem I have is that there is no generally accepted term for different kinds of requirements. Use Cases, Data Models, Process Diagrams–these seem to be something that would be much better described as a requirement type. If only that word wasn’t being used to mean something else.
Kevin Brennan, CBAP
VP, Body of Knowledge
No related posts.
Recent Comments