Our vBulletin migration is complete.
Welcome vBulletin users! All content and user information from the Micro Focus Forums (vBulletin) site has been migrated to this site. READ MORE.

The Requirement Bell Curve

Micro Focus Contributor
Micro Focus Contributor
0 0 4,284

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.

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.  

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.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.