Requirements management is a critical function for business analysis. Requirements management is focused on ensuring that the business users and stakeholders have the following information available:
- What is the status of various requirements, which requirements are still pending approval?
- What are the dependencies between requirements?
- How often does changes occur?
- What are the priorities of requirements?
- A central location of all changes available for anyone to access.
But the more important question to have answer to and where the real business value is delivered in requirements life cycle management is answering the following questions:
- Are the requirements impacting critical business processes?
- Which processes have recurring change?
- Are the requirements priorities aligned to key business processes?
- Which process will be impacted by which requirements?
On many projects where I have worked there are no tools available or requirements are just logged in lists and managed on various spreadsheets. There were no relationships established, no audit trail on the changes, no version control, a lack of well-defined requirements and no single version of the truth. Managing requirements without proper tools will not provide you with any business value to make informed decisions about priorities or impacts of changes on processes. This will also negatively impact the value chain process related to product development like customer communications, marketing and resource planning. Empirical?
It’s been said that nearly 70% of projects fail due to bad requirements management or lack thereof. Good requirements life cycle management is the foundation for successful projects. In today’s world of constant change and ever growing scope of projects it’s key to ensure you have a requirements life cycle management process that adds real value to your business analyses process and provides you with data to make informed decision to ensure your customer value is delivered.
With a well manage requirements management process you will have requirements available in one central location for anyone to view, this will ensure status reporting is always accurate, up to date and anyone can access it. Project scope changes can be tracked with an audit trail in place. Dependencies between processes and requirements are highlighted early on to ensure resource planning and change management can confirm their deliverables are aligned to the requirement plans.
Higher product quality can also be achieved with a well-managed requirements life cycle process as the customer value can be traced throughout the requirements life cycle. Understanding the customer value being required will ensure the product is built correctly according to the signed off scope and will lower the need for multiple versions of a product being build due to misunderstandings of requirements.
According to BABOK v3 the requirements life cycle management includes the following tasks:
Now that we understand what is involved in requirements life cycle management, I’m going to show you how to use a modern tool such as Azure DevOps specifically Azure Boards to manage your requirements and to be able to derive real business value from this activity and to make more informed decision based on accurate sensible data.
The Azure DevOps that I used was setup according to the CMMI process template with. This template allowed for multiple work items and a hierarchy to establish the relationship between work items, ensuring the complete requirements life cycle management can be tracked in one location with one tools set.
The first step in setting up your requirements are to ensure your application blueprint for business process with business process steps are documented and available in a spreadsheet. When creating the process blueprint you can use the below definitions as guidance to ensure your process and process step levels are correct.
Process Level
|
Definition
|
Business Process (L2)
|
The business process is the level that aggregates business-oriented functions or steps to a unit that is meaningful and comprehensive in the sense that the steps or functions incorporated are essential to fulfill a business mission related task. I. e. A business process begins with a specific customer's need and ends with the fulfillment of that need.
|
Process Step (L3)
|
A process step performed by a user or a piece of software together with other process steps forming a business process. From a user interaction point of view a process step is a single work task in a causal work flow without role change. A process step is typically identified by the fact that the task owner has got all necessary responsibilities to execute the task.
|
The current project I’m working on is an ERP with multiple modules. Below are some sample processes for our supply chain module as per our DevOps setup. You can see that the manage invoice and manage payments process (Epic) both have 5 process steps (Feature) linked to each process.
The key to getting your complete hierarchy correct on Azure Boards is to ensure your link type or related work fields are correctly done. When you are linking your Business Process (Epic) with your Business Process Steps (Feature) make sure the link type is Child.
What you will also see is that I have linked the ‘’Manage Invoice and Manage Payment’’ under the area as SCM. This will allow you to quickly run queries and see all your processes with their process steps in one view. Below is a query you can setup to see your supply chain blueprint directly from Azure Boards
Azure DevOps has many other customizations that can also be used. For example, the state for each work item type can be customized. This will allow you to track the completion of your process blueprint. I’ve updated the process states to illustrate additional tracking that can be done on Azure Boards.
If your supply chain stakeholders are still busy reviewing the Manage invoice process you can update the state to Active. Once a process has been signed off you can mark the process closed.
Also note that you can import your blueprint into Azure DevOps. This is a great feature that can save lots of time.
The next step in completing your hierarchy is to link your requirement to the process step (feature). I’ve created a new requirement under the Capture Invoice process step. You can see under the related work that I have linked this requirement with a parent link type to the Capture Invoice step.
Azure Board also allow you to customize the form. The fields that you see that are available are completely customizable. For example I’ve added the “Impact on User Experience’’, “Justification’’ ‘’Start Date’’, ‘’Finish Date’’ fields. These fields can also be set to be mandatory or optional. The state for requirements is also customizable. This requirement is still in New as the relevant documentation haven’t been completed and it’s not been approved by stakeholders.
I’ve captured the below additional requirement and linked it to the generate invoice reports. This requirement has been approved and as such the state is approved. You can also see that I have completed the field back log priority with a 2. This can also greatly assist you with manageing your requirements backlog.
To get a better visual I’ve added some more requirements. I’ve also included the Backlog priority field and the date fields.
Query Results:
Immediately you can see all the requirements link to your process step, what is their state, when should the requirements documents start and end, has it been assigned to anyone and what is the priority of the requirements according to the backlog.
It’s very easy to see that you don’t have a priority for requirement 33. Although the start date for documentation has already been planned. Thus, it’s easy to see your gaps in prioritization.
I’ve update both processes with some more requirements to expand our data set for discussion.
Looking back at our requirements life cycle management it’s easy to see how to accomplish all the task with Azure DevOps. I’ve also used other tools in the past (HPQC, Perforce) and the same methods can be applied in these tools to establish your blueprint for requirements management. The key is to have a hierarch with items that belong to each other.
To summarize let’s confirm each of the task in the requirements life cycle management and how it was achieved with Azure Boards.
Trace Requirements:
Each requirement was linked to a business process step clearly indicating where application changes were going to occur. Custom field are available to trace additional specific, UI impacts, start dates, contact name for SME. Additional link types can also be included. For example, there is a link between the invoice voiding change and the payment voiding changes. I’ve indicated this by linking the 2 new requirements together with a related link type.
You can also adjust the queries to directly look at the changes related to process steps rather than the complete hierarchy. Please note all queries can be exported to excel as well.
In this view you can expand and collapse the change to only look at changes in a specific process. Looking at the process step (Feature), Generate Invoice Reports it’s clear that there are key invoice reports missing that will impact customer value significantly. You can also still see the processes that are impacted by looking at the parent column on the right.
Maintain Requirements:
As Azure is a web-based tool, at any point in time you can get the correct information about the state of your requirements. Access can also be given to support teams to see which new change are coming and at which dates. This will ensure that requirements can be re-used by other streams to complete their deliverables.
Also, by clicking on the 3 dots next to the requirements you can bulk update fields on requirement like state.
Prioritize Requirements:
Looking at requirements with the hierarchy you can clearly focus on items that are critical and key for customer satisfaction. You can also evaluate the justification for the new requirements and consider this when assigning priorities. Looking at your Invoice process most of the changes are report related and might be quick wins you can get out first. On the payment process there are a couple of usability changes requested. Although important it might be better to focus on the Manage Payment Status process. As this is a key step in completion of payments.
Access Requirement Change:
With requirements up to date it’s very easy to see when they were added, by who and what are the state of each requirement. With all new requirements in the state of new, you can easily see what is still pending approval. You can also always refer to requirements that were rejected and wasn’t included in the scope.
Approve Requirements:
With Azure Boards and the option to customize the states of requirements it’s very easy to track where in the approval processes all your requirements are. The states that I have setup for my project can be seen below. But you can also use any other state that you prefer. With the backlog priority on each requirement you can also escalate requirements that are more urgent than others. You can also assign the requirements to specific users to see which approval is still pending.
By following the requirements life cycle management with a tool such as Azure Boards you will be able to derive real business value by having a requirements management process that you can depend on and have real time access to data to make informed decisions. Now the answers for the below critical questions can be provided.
- Are the requirements impacting critical business processes?
a. Yes, Manage Invoice and Manage Payments are both impacted with new changes.
b. Most of the changes for the Invoice process is reports.
c. On the Capture Payments step 2 usability changes are pending.
- Which processes have reoccurring change?
a. Both Manage Invoice and Manage Payment have multiple requirements pending.
- Are the requirements priorities aligned to key business processes?
a. Yes, Manage Invoice and Manage Payments are critical to supply chain stability.
- Which process will be impacted by which requirements?
a. This can be clearly seen in the hierarchy; you can even see which process step will be impacted by a requirement.
Author: Doré Sardinha
Doré has been working for 12 years in the IT project space. Specifically, on large scale ERP implementations for FMCG, mining and government companies. She was CBAP certified in 2014. She has a passion for doing business analysis work that brings value to clients and to understand customer requirements.