Jul
26
Definition of a Requirement
July 26, 2007 |
I got asked the following question about the official definition of a requirement used by the IIBA (which is itself only a slight modification of the IEEE’s):
A requirement is1:
- A condition or capability needed by a stakeholder2 to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a system or system 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).
Can you explain the intent of #3 and how it differs from #1 AND #2?
In practical terms, it may help to think of it this way. When developers say “that’s not a requirement”, they generally mean it in the sense of #3—something that’s been placed in the requirements document that they’re working from. However, if the functionality is clearly needed to implement something in the requirements document, even if it’s not directly stated, it’s still a requirement in the sense of #2. If a stakeholder needs the solution to do something, even if it’s not even implied by the requirements document, it’s still a requirement in the sense of #1.
Comments
3 Comments so far
What I'm Reading- Enterprise Agility-The Big Picture (7): Vision and Release BacklogScaling Software Agility
- A New Agile PM Book?Herding Cats
- Dear ManagerTrials & Tribulations of a Business Systems Analyst
- What is requirements management?Business Analyst Blog
- Gartner and the Hype Cycle of Emerging TechnologiesCTO Blog
- It’s All About the FeedbackRuminations
- Who should lead SOA? Enterprise architects or business analysts?Service-Oriented Architecture
- Learning to say “No”EDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Learning About Process Case Study - Business ProblemTrials & Tribulations of a Business Systems Analyst
- 12 early warning signs of IT failureIT Project Failures
I’ve commented on the IEEE definition of “requirement” here.
The problem with the IEEE definition is that it is so broad that it encompasses design.
For example, I could maintain that implementing the system in Ruby on Rails is “needed by a stakeholder to solve a problem”, because it is the most cost-effective, maintainable implementation. Is it necessary (i.e. required)? No, but it is “needed”.
That’s why my definition of requirement states that the condition must be the least stringent condition that must hold to solve a stakeholder problem. What that really means is that a requirement does nothing more than restate the problem as a negative condition.
I.e., if the problem is, “It takes more than five minutes to purchase an item,” then the requirement is, “It shall take no more than five minutes to purchase an item.”
A requirement is an objective that is to be met implementing a behavior in the system.
Requirements can’t be read in isolation.
They are a supporting tool for a discussion between the client and the designer. Everyone knows that one-way communication is a certain path to misinterpreting things. If you send a document through and that’s that, there are always problems.
For example, what if you know you can’t afford a solution that involves building a brand new application, and that you need to get the results from enhancing existing legacy systems, with business processes tying it together. Pushing through the agnostic requirements specification will usually waste time and effort on a design you can’t afford.
If, on the other hand, documents are being written in the context of informed discussion you can take shortcuts like informing the specifications with design constraints and get to the end result quicker.
Don’t get me wrong; there’s a time and a palce for pure agnostic requirements. It’s just that there is room for other types as well.
Cheers