Seven Categories of Requirements Rikard Edgren
I like to use categorizations to structure my understanding of a subject; and after the simplifications are made and I think I understand it well; the structures can be ripped apart, and you get a bit less confused by the complexity of reality.
There are many forms of requirements, these are some a tester should look out for:
Explicit Requirements
These are the requirements found in the requirement documents. You are probably using them in your testing, making sure that they match the functionality.
This is a quite small part of software testing as I see it.
Implicit Requirements
These are requirements that can be found by combining different requirements that are intertwined.
They could originate from general statements like the program should never crash, or the program should be easy to use, which has implications for many other requirements.
They could also become very large, e.g. support all possible input, or support Python scripting.
They are an effect of vague requirements, and they are a natural part of software development; it would be insane to document everything in advance. Tester can deal with it and understand what is important.
Unspoken Requirements
These are things that many users expect from a program, but they are seldom listed in the requirements document.
Typical examples are behave in same way as other applications on this platform, not leave any garbage files after running, or be appealing to most users.
Incorrect Requirements
The writers of the requirement documents don’t know everything in the world, sometimes they are wrong.
There can be small errors, e.g. inconsistencies between requirements, and huge mistakes, because they didn’t understand the user’s true needs.
Changing Requirements
Sometimes requirements need to be changed, which is something that testers shouldn’t object (too much). The requirements are most likely changed in order to make a better product, and that’s what we all are working for. But when they are changed, or added at a late stage, it can be difficult to challenge them, and test them really good, simply because you are under time-pressure.
We can’t do more than our best, but that’s often enough.
Vague Requirements
I used to dislike vague requirements that were very difficult, almost impossible, to test, but now I think they are good to have.
Not that you should be vague on purpose, but quality attributes like usability, performance etc. can never be detailed and capture the important thing: that customers will be more than satisfied.
It gives you a challenge as a tester; you need to use your feelings and imagination to come up with test ideas, and results that point to a positive or negative indication of result. You can’t hide between some numbers, and must stand for if you think the requirement is met or not.
Hype Requirements
These can be difficult to handle. Often they come in the shape of specifying too much detail, e.g. save settings in an XML file, just because XML is hype (this was 10 years ago, so replace with SOA or the cloud or the hype your company believes in, right now.)
They might be out-of-place, put there in order to be allowed to start the project, but they can also be important, exploiting the hype, or just being a perfect match for this specific application.
As a tester, it’s often not much more to do than accept the hyped requirements, especially if it is accepted (or initiated) by the developers.
But probably you need to learn more about the hype, often there are (at least some) good things inside them.
And regardless of how well all these categories of requirements are implemented and tested, will the application be really, really, super good?
Really good thoughts Rikard!
You got me into thinking about this; and when I started think about it some more I could come up with a couple more requirement categories that testers should look out for.
The eighth type of requirement:
Unwanted Requirements
These are the requirements that often can be found in the requirement documents but no one (in the development team) wants them.
These requirements have a tendency to be creepy, because they should be included but often end up as late as possible. Examples of such requirements are:
“Support for color blind people” – which might needed in order to support disability laws or regulations;
“It must be possible to integrate with product XYZ” – a requirement that came out of a late dinner between a customer and the Product Manager;
“The product should be ISO XYZ compliant” – a requirement that no one can understand because the ISO-regulation in question has no connection to the product (this might have happened due to some mistake from someones behalf and has now become that persons mission).
And even a ninth type:
Wanted Requirements
These are the requirements that a lot of people in the development department wants in the product, but there are no customers that wants this.
Not an uncommon scenario is that the development department has persuaded someone in the product management that “this is really needed” for good reasons, but they might have exaggerated the positive sides a bit in order to get acceptance. These requirements might be cumbersome from a testing perspective because they might put you in a situation where your reports can hurt the credibility of the Wanted Requirement; and therefore hurt your relationship with the wishers.
And a tenth type:
Impossible Requirements
The name says it all. This can sometimes collide with Unwanted Requirements. You might argue that these requirements should not even be valid, but my experience is that such requirements still have a tendency to be included and never changed according to the real world.
An example of such requirement is “The product should support 10 000 simultaneous users” – a requirement that everybody in the development team knows is an impossible and unachievable requirement given the time and perhaps due to technical debt and/or other limitations.
Especially look out for these requirements where you as a tester might become a target when it is discovered that the requirement isn’t fulfilled. E.g., take the performance requirement above, the developers might just do nothing about this and it is still up to you to prove this by doing some performance tests.
I agree, very nice topic!
I’d like to add the following categories:
— Vast Requirements —
When one requirement covers a too big area. Project management and developers tend to be quicker about saying that they have covered the requirement, even if they know it is vast and hard to say when you are fully done. Testers often get stuck in trying to reach the 100% coverage. This is very close to the Vague requirement.
— Compliance Requirements —
When a requirement states that it should comply with a certain standard such as IEEE, ETSI, ANSI etc. In some cases the compliance is stated on a high level, therefore missing all the optional paths that the compliance can take. Most often you comply partly and might state on your own what you actually comply to. Many of these compliance requirements have a set of tests that can be run to assist with compliance. Still, I’ve found some articles with tests that can be run on a product that states compliance, but are in fact loopholes. So, compliance is a tricky thing.
Thanks for very good additional categories!
There is also a 13th category:
Sensational Requirements (from Ulf Eriksson’s book “Test och kvalitetssäkring av IT-system”)
These are requirements that you don’t know about until you try the product and realize: “If we could do this it would be super good!”
A good product will fulfill the requirements the users didn’t know they wanted.
I like the fresh look towards requirements. Every tester shouuld be aware of the different angles.
However, what is the practical use of this? A requirement can be in more then one category. For example, a explicit requirement can also be a changing- and a hype requrement and even an impossible too!
My idea is that the requirements other then explicit should be made explicit one way or the other. At the end we have to give a GoNoGo advise to the customer and that will be based on testing if the explicit requirements are met.
@Bert:
I can clearly see a practical use of these categories: they are heuristics!
This helps me think of what impact the requirements might have. And therefore I can react upon them in ways I would not have done if I hadn’t thought of the categories.
It is not a matter of explicitness, it is more a matter of complexity. The requirements all have properties, the categories above helps us in finding out the properties and lets us decide if it matters or not.
Good observation Bert, that requirements can belong to several categories (maybe I should have used another term than categories.)
There are probably no direct practical use of this; it doesn’t seem meaningful to tag each and every requirements with these categories.
However, as Henrik pointed out; they can indirectly be of practical use since the categories might have helped you understand (thecomplexity of) requirements a little more.
I don’t think it is feasible to make all requirements explicit; it would simply take too much time.
Rather make sure (or hope!) that developers and testers will consider the most important of the non-explicit; and that any deviations are messaged.
I have realized that what I call Unspoken Requirements is called Implicit Requirements elsewhere.
What I call Implicit Requirements is better called Combinative Requirements.
A collegue of mine mentioned another category of requirements that should not be underestimated… namely Chrome requirements. They are just for show, they have usually no meaning and are just used for demonstration or sales pitch.
And here is number 15 and 16, that are more applicable to the whole view of the set of requirements:
Contractual Requirements – this is when developing software to the letter of the requirements document. User satisfaction is secondary, the important thing is that the paying customer agrees that the requirements are met, and pays as agreed.
These requirements must be very specific, and the importance of requirements negotiator skill should not be underestimated.
This style can work well for very specific needs, but for more general purposes, you need a lot of luck.
Aiding Requirements – these are created in order to help the development team when building the software. They can be vague, but mean something important. They can be discarded, if other oppurtunities are found more appropriate.
They are a tool, not a result evaluator.
They help generate understanding of the problem to solve, and are well suited to be created by diverse roles collaborating.