Have you been on a technical project where you ask yourself why a specific functional requirement gets implemented only to realize that a dependent requirement wasn’t causing unexpected results when it came time to test or move to production?
What I am talking about is requirements traceability.
At a high level, business analysts can, and should associate or identify relationships between requirements. How deep that analysis goes depends on the project, time to develop and other factors.
At a deeper level, the ability to trace requirements backward and forward requires additional tracking attributes to make informed decisions, or plans or action.
For example, how often do we spend time to trace a business requirement back to a corporate objective or goal? How often do we initiate an assessment as to which functional requirement traces back to a business requirement and so forth. Business analysts either invest no time, a little time or a lot of time on this activity.
So the first step is to make sure a requirement is traced requirements that depend on it and the requirements upon which it depends. The whole purpose of requirements tracing is having the power, from a requirements relationship perspective to assess the impact of a change on a given requirement on its associated requirements. How many times have you seen a requirement get changed, and its meaning gets totally changed, without a peek into the impact on the dependent requirements? I have seen it often. I have also learned from that experience. I am sure we, as business analysts, all have learned from that experience. What is the lesson? Don’t make willy-nilly changes to requirements without a thorough review of all dependent requirements.
If a requirement has no dependencies, then make the change if no other information is available in assessing the impact of the change. But even with available information, a BA shouldn’t make a change without first assessing the business value of the change and the feasibility of that change, for example. In this case, if the feasibility of the change is low, meaning harder and costly to implement, and the business places a lower value on that change, a BA should mark that requirement as being implemented later on or prioritized a little down the list.
I admit, traceability is often on a primary focus in most cases. In some environments, it has to be, such as a regulatory environment, for example.
Traceability is harder when you need to identify a requirement and its relationship with a business requirements, a corporate objective, a solution requirement, a test case that will validate the requirement, and so on. As you can see from the items above, making a change to a requirement with the potential to have so many associated requirements becomes a primary focus in order to assess whether a change can be made to it.
Traceability is important. Software tools can help with traceability. To learn more about what Smoothcube is doing in this domain, drop a line to us using our contact form.
Innovate. Implement. Inspire.