If the business analyst on a project does classical requirement decomposition, many of the concerns regarding how a project aligns to relevant organizational strategic objectives takes care of itself. The classic decomposition being ...
Business Requirements (relevant strategic objectives can be found here)
Stakeholder Requirements (must align upward)
Solution Requirements (must align upward)
Transition Requirements (should align upward)
That is to say that the hierarchy of business > stakeholder > solution requirements should have traceability as well as the possibility that two requirements of the same category should have traceability to each other when appropriate.
The business analyst uses business requirements as the starting point for all requirements traceability. This also means that anything that relates to a requirement (testing, software bug analysis, development tasks) will also be traceable back to one or more established business requirements. If a business requirement changes, the BA can perform forward traceability to see what effect that change may have on the system, product or process.
So the requirements lifecycle starts with the business need, ends sometime after the solution is deployed and is the lungs of the project everywhere in-between. There are those that will argue that the requirements lifecycle never ends as long as the solution or process they are linked to survives. This can be true but it is an outlier use case. In the vast majority of software development solutions, the requirements of a past project are normally stored in some dusty folder of a network drive or SharePoint library.
© 2016 - Dwayne Wright