A Good BA Knows the Importance of Control
7 Key Benefits of Requirements Management
I once was at a lunch with a group of product managers who were kicking around end-result visions of an upcoming Feature.
In reality, their Feature was more of an Epic – they were actually starting with nothing but a good idea, expressed as the Feature’s title. Somehow, they succeeded in justifying the project to gain sign off and budget by the executive steering committee. At some point, there had to be a discussion on the purpose of the Feature, yet no record of what came out of that discussion existed.
Misunderstanding this tenet of the Agile Manifesto: Working software over comprehensive documentation seems to be a common mistake among new agile teams, believing that eliminating documentation altogether adheres to this principle. This couldn’t be further from the truth. Somewhere, someone needs to document something: requirements, business rules, pre-conditions, use cases or user stories, acceptance criteria, etc.
Although I wasn’t there at lunch in a BA capacity, I couldn’t help but ask questions about what they most wanted to see at the end of development. I asked about integration with other systems. I questioned end user roles. I wanted to know as a peripheral business user, how this new feature would prove to be an improvement over the existing process. The elicitation resulted in more than several would-be requirements written on the back of just as many cocktail napkins.
If I had been the BA, I would have asked for those napkins before leaving the restaurant so they’d not be lost or forgotten. Instead, I reminded them to transcribe their notes directly onto the Feature in the portfolio management tool back at the office.
The requirements they had identified were by no means complete, crafted well, or yet known to be feasible, but once they underwent documentation – they became tangible artifacts of evidence associated with the impending project. At this point, for the project they were discussing, the Requirements Lifecycle began right there, at that table of stakeholders who became engaged in the documentation of requirements.
Because requirements are the spine for the development of any application and until the application is Live, the changes are unpredictable. BAs therefore, play a crucial role in managing the project requirements – benefiting both the development team and the business owners. Fixing the issues during development is much easier and less costly to fix as a part of a change request or defect backlog.
Most of us don’t think of a requirement having its own lifecycle.
However, as I noted in describing my lunch with the product owners, management of the requirements begins from the moment a customer articulates and provides their need, or from when a product development process starts. It includes managing the definition, elaboration and changing requirements during the development cycle and systems development, e.g. traceability.
Did you know the Requirements Management Lifecycle, is a distinct and specific knowledge area of the BABOK©?
Whether or not you plan to attain CBAP certification, improving your understanding and skill set in the area of requirements engineering and management is as important as knowing how to elicit them in the first place.
There’s no doubt that keeping a handle on established requirements that morph or spawn additional requirements can prove challenging. The problem becomes more difficult by a lack of defined process to capture all requirements in the right way. Essentially, Requirements Management is the set of processes in systems and software engineering that interfaces with requirements engineering.
As the requirements undergo analysis and refinement, a good BA knows the importance of control. By identifying and monitoring the needs of the business and the stakeholders, and to apply the most suited and accepted solution, requirements management helps in understanding the effects of the change requests on the current state and also helps in linking the business goals and objectives to the actual solution that is constructed and delivered.
The BABOK® knowledge area of Requirements Life Cycle Management includes the following five distinct Business Analysis tasks:
Trace Requirements: BA analyzes and maintains the relationships between requirements, designs, solution components, and other work products for impact analysis, coverage, and allocation.
Maintain Requirements: BA ensures that requirements and designs are accurate and current throughout the lifecycle and facilitates reuse where appropriate.
Prioritize Requirements: BA assesses the value, urgency, and risks associated with particular requirements and designs to ensure that analysis and/or delivery work is done on the most important ones at any given time.
Assess Requirements Changes: BA evaluates new and changing stakeholder requirements to determine if they need action within the scope of a change.
Approve Requirements: BA works with stakeholders involved in the governance process to reach approval and agreement on requirements and designs.
In order to appreciate why these tasks rank towards mandatory activities, it’s important to understand the benefits they provide.
Key Benefits of Requirements Management
1. Granularity: Doc to doc is not sufficient. Data is at risk of marbleizing. No control results in sacrifice of clarity. 2. Attributes: Every class or type of requirement has attributes that yield more information and warrant capture.For example, these are classifications of requirements:
Front-end requirements belong to the class of Functional Requirement and as such contain their own attributes (additional requirements) that also warrant capture:
User Interface Attributes
3. Collaboration: When workers spread out geographically, that is to say, they are not co-located; a requirements management repository assists with necessary collaboration and minimizes risk of lost information.
4. History and Security: This level of management ensures accountability by affording controlled access, versions, and static records of who changed what.
5. Hierarchy: By organizing for traceability, it allows all stakeholders ease of access to reference points.
6. Traceability: Controls change requests, scope and provides visibility on both.
7. Reporting: An enterprise level Requirements Management tool gives teams the ability to obtain automated metrics & status reporting. However, resourceful BAs can achieve results by establishing a Requirements Repository to hold artifacts. By creating a Requirements Management Plan document, the BA can then track the requirements within a requirement artifact once the artifact is approved/accepted.
This is especially useful in the Waterfall methodology and for large/complex projects.
Requirements Management Status Reports identify the status of the requirements repository.
Status reports typically include traceability coverage
Including requirements not traced to parent and/or children requirements
Requirements traced to Deliverables, etc.
Reports are a snapshot of the current state of the requirements repository:
what is planned to start within the next reporting period
So, we can see that the purpose of requirements lifecycle management is to ensure that all stakeholders, solution requirements, and designs align to one another and that the solution implements them. It involves a level of control over requirements and how those requirements become implemented in the actual solution and delivery.
It also helps to ensure that business analysis information is available for future use.
In conclusion the requirements lifecycle:
begins with the representation of a business need as a requirement
continues through the development of a solution
ends when a solution and the requirements that represent it are retired.(vs implemented)
In other words, the management of requirements does not end once a solution reaches implementation. When managed appropriately throughout the life of a solution, requirements continue to provide value.
The definition of weak requirements: incomplete, incorrect, unclear, unnecessary, too broad, misunderstood, or redundant. They are THE number one reason for project failure.