A requirement is anything that is needed or wanted.
Requirements can be conditions, features and functionalities that are needed to solve a problem, respond to external forces such as a competitor product or fulfill some regulatory constraints.
Because a requirement can be defined as a feature that is needed in a business solution, it is very easy for the requirements list to grow and quickly become confusing and unmanageable.
What is Requirements Tracing ?
Requirements tracking is method that is used to ensure that the requirements and designs are aligned to each other.
It is used to keep track of each change that has been made to the requirements.
It keeps track of the changes that have been made to both the requirement and how that requirement is related to other requirements.
Requirements tracking is used to ensure that the requirements conforms to the solution need and it helps with the scope, change, risk, time, cost, and communication management.
Requirements tracking helps to identify any implemented functionality that is required by the solution and any missing functionalities.
This is important because if you don’t consider the relationship between requirement,s it is often difficult to accurately represent the business needs.
How to you trace requirements ?
Requirements tracking can be a tedious task but there are a few elements that can help and they include the following :
a. Level of importance: each requirement in a solution is supposed to provide value and as a business analyst you have to keep track of each of those requirements.
Keeping track of these requirements can get complicated as the requirements grow especially if the level of requirement formality is high.
So you have to ensure that you assign the right level of importance to each requirements, to differentiate the must have’s from the nice to have’s.
b. Relationships: there are several relationships to consider when defining the traceability approach and they are:
i: Derive: this is when one requirement is derived from another requirement because there is a link between the two requirements.
An example of this is when a solution requirement is derived from a business requirement.
ii: Depends: this is when one requirement depends on another requirement. Dependent requirements are codependent by nature.
There are two types of dependent relationships and they are:
i: Necessity: this is used when it is only rational to implement a particular requirement if a related requirement is also implemented.
ii: Effort: this is used if it is easier to implement one requirement only if another requirement is also implemented.
c. Satisfy: this is when implementing a functionality satisfies a requirement of the solution. e.g the relationship between a functional requirement and a solution component that is being implemented.
d. Validate: this is used to validate if a solution fulfills a requirement and it is confirmed by the relationship between the requirement and the test case.
Where are the traced requirements stored ?
Once the requirements have been traced, they have to be stored in a repository.
The repository chosen would depend on the organizational standards and examples of common requirements repositories include Azure DevOps and Kabanize.
Some of these applications have built in functionalities that can help with requirements tracking and management.
Such as linking related requirements, and creating Epics, Features, Spikes, Enablers and User Stories.
Before the requirements can be stored, they would have to be well documented and maintained in accordance with the business analysis approach.
The repository can be used to trace numerous requirements which can be difficult with manual methods.