Business analysis is not for the faint hearted. At the heart of business analysis lie eliciting, analysing, validating and managing needs, value and requirements, no matter what approach and method is used. Requirements (written as user stories or otherwise), should align to the needs of the business whereas design definition represents the solution put in place to address those needs.
A smart and diligent Product Owner will never risk the possibility of misalignment between the solution design and the requirements, value and business needs. They often call upon the expert in this space, a good business analyst who will take due care to ensure that the design definition aptly meets the stated requirements and highlights areas of misalignment. To do so, the business analyst leverages a distinct tool in the toolkit, known as – ‘Requirements traceability’. Equipped with this tool, along with an analytical mind, the business analyst should continually review the design to ensure that the solution aligns with the requirements.
Time and effort invested by the Business Analyst in tracing the requirements against elements of the solution design help to confirm areas of alignment and flag areas of misalignment between the two. Managing traceability of needs, value and requirements against design helps identify a requirement or a set of requirements that is not met by the solution or a functionality. On the other hand, it also helps to identify areas within the solution or those functionalities that do not support any requirement.
Layering the solution design report on top of the traceability helps the Business Analyst to provide a managerial summary along with a stratified view that suits a broad spectrum of audience. In simple terms, while requirements traceability provides the fact, a solution design compliance report helps to publish those facts at various dimensions and helps decision makers to pull the right levers to fill the gaps. While the requirements traceability highlights the trace between each functional component of the solution design, and requirements, the solution design report summarises the extent to which the solution design meets the stated requirements.
A solution design report aids smarter impact analysis and informed decision making. It is good to provide a hawk-eye’s view and then dive into details. To start with, provide a view of the overall compliance of the solution design against the stated requirements. This will help identify the number of requirements that have been either fully met, or partially met or not met at all or those that have been removed from scope. The following pie-chart is a good example of that:
Requirements should be prioritised based on their value to the business as well as the complexity to deliver. It is important for decision makers to understand the extent of solution design compliance against the most critical requirements and the lower priority requirements. Your MoSCoW requirements prioritisation can be overlaid on the requirements delivered to see which key and critical have or have not been met. The following pie-chart provides an example of that:
The requirements can also be attributed against the functional areas of the business (or even personas) to give an indication on which areas the solution has initially met the requirements against best. This gives a greater insight into risk identification and risk management. Additionally, this can assist in ensuring key areas of the value stream are catered for.
Leveraging tools such as JIRA for requirements traceability and reporting on solution design compliance helps the Product Owner and Business Analyst provide the right information to Product Managers and key budgetary decision makers to ensure optimum alignment between key requirements and solution design. Traceability is the key to managing needs, value, requirements, context, stakeholders, and the solution. Solution design compliance reporting is the way to communicate the fundamentals of traceability to a wider audience.