Requirements have a shape – a bell curved shape. The more “agile” an organization is, the flatter the curve will be… but the curve is always there.
Small…
Generally requirements start as a small definition of business need. They might originate from any number of sources… a different requirement, an email, an image, a defect… but they have a small seed of a start, then grow. As those who manage requirements, we should be defining just enough detail to explain the need to others then stop – any additional detail captured is “waste” until the need is agreed to.
Bigger…
Once the high level need is captured, supporting detail is added to assure the need is clear and provides the right clarity for different roles in the organization – user, executive, developer, business analyst, tester… This process will happen with varying detail for each organization. If the organization is very “agile” the level of definition may be light. If the organization is more structured and follows rigorous upfront processes, the requirement will be defined in depth with different perspectives (use cases, functional specs, technical requirements…). The key here is to only define as much upfront as needed, anything more is “waste”… keep the curve belly as short as practical.
Small again…
Once the target need is understood and you have consensus from those who need to provide it, priority requirements are broken down into “units of delivery”. This is done to accommodate the team working to deliver – their schedule, their staffing… Sure, there is often overlap between requirements (units of need) and stories (units of delivery), but the main point is that the development team creating the software works in small consumable bits that provide attainable mini-functions. They don’t work to deliver requirements.
I can guess what your next question might be… so what?…yes, the idea of a “Requirements Bell Curve” is not earth shattering or paradigm shifting. Having a model does however aid in conceptualizing something that is generally a bit more abstract…
We undertake software projects to provide business value. We define the need, then work to deliver it. They key is to only define as much as is truly needed to understand, achieve consensus and drive delivery. Any effort beyond that is waste…Work to keep your “Requirements Bell Curve” as flat as possible. If you’re looking for a great tool to help – check out Atlason our website.
