Decomposition Of Requirements

The first time I heard of the decomposition of requirements, I thought it must be a bad thing. I imagined a set of requirements that have passed their prime, letting the natural decay process overcome them with grace and dignity. Since then, I've obviously embraced its true meaning but I wonder how stakeholders think of the phrase when I use it casually during a workshop. 

Basically, the process describes the unfolding of a requirement into separate components. Often, the business analyst will need to ensure this breakdown has traceability. That is to say that you can easily ...

- review the original requirement from the component
- review the components from the original (sometimes called a parent)
- review a brother / sister component of the same parent

There are many reasons to decompose a requirement and the level of decomposition is determined by the business analyst. The business analyst will factor the decomposition decisions based upon things such as requirement validation, contractual/regulation needs, structure of related downstream tasks and many other potential factors. 

©2015 Dwayne Wright