Apr
24
What is a Requirement?
April 24, 2006 |
For the BABoK, the IIBA adopted a slight variation on the IEEE definition, essentially replacing “user” with “stakeholder” and “system” with “solution”.
A requirement is :
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2).
Here are some of the others I’ve come across:
- Specification of what should be implemented.
- A condition to be achieved in the problem domain through an engineered artefact, such as a software application.
- A desired feature, property, or behaviour of a system.
- A complete statement of what the system is supposed to do.
- A requirement is something that the product must do or a quality that the product must have. A requirements exists either because the type of product demands certain functions or qualities, or because the client wants that requirement to be part of the delivered product.
- Translate the customer’s desire for a set of defined capabilities into a working product.
- An established need justifying the timely allocation of resources to develop a capability to achieve approved goals or accomplish approved missions or tasks.
- An externally observable characteristic of a defined system. The satisfaction of the requirement must be observable from a point of view that’s external to the system, and the requirement must satisfy some need of the potential customer or other stakeholder.
- Requirements describe the nature of the enterprise and how it uses information.
You can get from these two basic views of requirements.
One is project-centric. The project team contracts with the enterprise to enable it to exercise a new capability. If the system or solution can do what the enterprise asked, then the requirement is met whether or not that was a good idea.
The second is solution-centric. The solution-centric approach suggests that the enterprise should provide goals, not contracts, and the job of the project team is to get the enterprise to its goal.
You can guess which I prefer.
Comments
1 Comment so far
Bravo for raising the issue of what a requirement is. Organizations everywhere are struggling to come up with “good” requirements when they don’t even know what “requirement” means.
The problem with almost every one of these definitions is that they allow far too much to be categorized as requirements.
Take, for example, “Specification of what should be implemented.” This definition would entail that a detailed design specification consisting of class and collaboration diagrams would be a requirements document.
And let’s examine, “A complete statement of what the system is supposed to do.” If I write in a document that the system should present a blue 40 pixel by 40 pixel button, haven’t I entered the realm of UI design? But I have also stated (in very detailed UI design terms) what the system should do, so it would also qualify as a requirement (or part of one).
I have written about this problem here:
http://cauvin.blogspot.com/2006/04/poor-definition-of-requirement.html
My definition of requirement is here:
http://cauvin.blogspot.com/2005/06/definition-of-requirement.html
The key to my definition is the phrase “least stringent”. Let me know what you think.