Requirements Management. Insights from Karl Wiegers' Presentation

Best Practices in Requirements Management" by Karl Wiegers.

Foreword

Many business analysts have read Karl Wiegers' book "Software Requirements" or at least heard of it. For me, this book is the first among Business Analyst Books; it explained to me how to deal with some of the analyst's tasks and confirmed that I was solving others correctly.

It also emphasized that requirement development and management are not just about 'wrote some document/user story in Jira - linked related documents-handed over to the team' but about a deep understanding of the context of changes and all stakeholders, especially users.
Therefore, this presentation was one of those that I simply couldn't miss, after all, it's Karl, Karl! 😃
The discussion revolved around things that a business analyst encounters every day throughout the software development life cycle, one of the business analyst skills (sub-skills) - practices in requirements management. What is requirements management? How to manage changes? How to properly conduct an impact analysis of changes? How to choose a software requirements management system?
In this article, I will describe the main theses and their decryption.
Below is the first-person speech - from the presenter).

Requirements Management. Best Practices.

The speech will cover some practices that can benefit any team in requirements management. An important thing to remember during the presentation (reading this article - ed. BA Girl) is how detailed the requirements will be and how formal the approach to requirements management will be (whether it will be formal requirements specifications or a list of user stories) - it's up to you.
There is no "requirements police" that will come after you if you violate some of the rules for working with requirements or fail to follow certain recommendations.

Suppose you are working on a dynamic project with rapidly changing requirements but with a relatively low level of risk. In that case, you can simplify the recommendations or completely ignore some of them. In other words, how to conduct requirements work is your decision (sometimes it's also coordinated with stakeholders).
But if the risks are high, if the team is distributed, and the product needs to be certified by external regulators - these practices will help you perform better.

Let's define the terminology

We'll refer to all work with requirements as requirements engineering. Requirements engineering, in turn, is divided into requirements development and requirements management.
Requirements Development is divided into requirement elicitation (not gathering requirements, as they are not just "gathered" (well, maybe a little), but rather discovered, invented).

Requirements Management

Requirements management (project requirements management) begins immediately after the first requirements appear because as soon as they appear, something needs to be done with them and there needs to be an understanding of what to do if they start to change.

Basic requirements management practices:

Establishing a requirements baseline
Document version control (it doesn't necessarily have to be an official document, it can be any description of requirements in a tool like Confluence, for example)
Acceptance and enforcement of change management processes
Requirements change impact analysis
Tracking the status of each requirement
Requirement tracing
Storing requirements in a requirements management tool.

It doesn't matter much what type of requirements you choose for the project: requirements specifications, a list of functional requirements, user stories, acceptance tests, or something else - these requirements need to be managed.
Before choosing practices, evaluate what you will gain from them, whether there is time for their implementation, and what will happen if some of the practices are omitted. From project to project, the answers to these questions vary, and the list and degree of "strictness" of practices may change, depending on the business analyst's choice.
Let's look at the practices in more detail.

Creating a Requirements Baseline

Creating a requirements baseline (requirements baseline) is the starting point for making changes. A baseline is a verified, accepted, and agreed-upon list of requirements for a specific product release or development iteration.
In other words, if the product owner defines several user stories that will be ready for the next release, they establish the iteration's requirements baseline.
Usually, someone should "sign off" on the requirements - now, this doesn't necessarily mean a physical signature but rather the agreement of key stakeholders that they:

Agree that these specific requirements serve as a sufficient basis for starting development.
Agree that any changes made undergo the accepted change management process.
(nobody likes this part) - Agree that the introduced requirements may serve as grounds for reviewing commitments. After all, changes are never free, and even just discussing and analyzing requirements that are not implemented also takes time.
And it's important for all participants in the "sign-off" process to understand what this entails, what exactly they are agreeing to.
Once the baseline is established, then you can:
Start the formal change management process.
Managers commit to deadlines.
Managers allocate the necessary resources for implementation.
(Project requirements management is difficult to carry out without a baseline - ed.)

Requirements Version Control

When a team works with different versions of requirements, problems arise. It's also not ideal when they have one document version but the content differs.
Therefore, requirements management is more effective when version control systems are used (or requirements management systems where versioning is tracked) to ensure that:

Requirements are up-to-date.
Participants in the requirements development/detection process have access to the latest version of requirements.
Only those with the authority make edits to the requirements.
Store requirements where all stakeholders can easily find them, preferably using an appropriate system. (Requirements on sticky notes are easy to find, but a sticky note can come off and get lost for some time.)
It's also useful to have a requirement identification scheme, for example:
Version #1 can be called "version 1.0 draft 1".
#2 = "version 1.0 draft 2".
#n (approved) = "version 1.0 approved".
#n+1 (draft again) = "version 1.1 draft 1" or "version 2.0 draft 1".
This scheme (naming convention) will help you distinguish document versions.

Change Management for Requirements

Uncontrolled changes to requirements can lead to rework, decreased quality, increased technical debt, and unpredictable development timelines. Therefore, requirements management needs to be "strengthened" by defining a formal process for managing requirement changes. It may include the following stages:

Proposal;
Review;
Approval;
Implementation.
Also, it's important to:
Define statuses for proposed changes (more on this later);
Include change impact analysis;
Decide which tool to use for making changes.
I have a philosophy that any change request should follow a process. When I worked at Kodak, stakeholders could approach me, and I would tell them - sounds useful, put it in the tracker. And these changes never materialized because people thought that 1 minute of time was too much for these changes. (Of course, you can enter ideas into the tracker yourself, but in any case, edits should follow the process).
And remember, changes may require adjusting commitments.
Possible statuses for a change request (describing the life cycle of a request):
Submitted;
Evaluated (assessing the impact of the change - what effort it will require);
Approved (when decision-makers (leadership) agree to the necessary expenses), or Rejected if they do not agree;
Change made;
Verified;
Closed;
Canceled.

When working with such a process, you can track the distribution of change requests over time, as well as understand how many change activities are happening. When I applied this process, it was useful for us to know how quickly we could process change requests. This greatly improves the requirements change management process.

However, do not define too many statuses. Once, I worked with a team that defined 20 statuses, but it wasn't helpful. If the change management process is too complicated, people won't follow it and will try to implement changes bypassing it.

Advice on Dealing with Changes (Change Control Board/Configuration Control Board)

It's impossible to manage requirements if it's unclear who and how makes decisions about changes. Someone must make decisions about which changes to implement. Officially, this group is called a change control board. When you hear the word "board," sometimes thoughts of a bureaucratic process that consumes a lot of time may come to mind.

But it shouldn't be like that. It should be a group of interested parties, no more than necessary, to make a business decision. Sometimes it's just one product owner, but on larger projects, it's usually several people representing different areas of interest, such as development, project management, testing, client, etc. (business analysis, surely, is included too - ed. BA Girl)

These individuals must have the authority to make decisions. In other words, they are not just advisory. Also, the board should have a charter describing the purpose of the board, the scope of authority, who is on the board, how often the board meets, how decisions are made, etc.

The change control board can:

Request impact analysis of changes.
Make decisions about changes and communicate those decisions further.
Prioritize the implementation of changes and choose which release they will be included in.

Requirements Change Impact Analysis

Sometimes, when a business analyst receives a change request and begins to analyze it, peeling away layer by layer, they realize that the problem is much bigger than it seems. Therefore, it's important to accurately assess how much the change will affect the system/process. Requirements change management is impossible without a proper assessment of the impact of these changes.

Several points to consider before saying "let's add it to the user story backlog and say 'of course, we'll do it'":

Determine if there is a conflict with existing requirements (those describing features at any stage of development - those already done, those currently in development, or those planned).
Determine what designs, code, test cases will change.
Assess the impact on the user interface, database, reports, reference information, etc.
Determine which third-party systems may be affected.
What plans or documents need to be updated?
Is the requirement even feasible?
Will the change affect system performance or other quality attributes?
Will it overload technical resources?
Will any part of the already completed work need to be discarded?
Do the changes violate business rules?
How much work is needed to implement the change?

Such a checklist will help in working with requirements - it will more accurately define the real scope of changes and their impact on the project.

Project Status Tracking

"Hey, how's the subsystem coming along?"
"Good, it's already 90% done."
"So, it was also 90% two weeks ago?"
"Yeah, but now it's definitely 90%."
"They say all projects are 90% done :)"

Define what exactly corresponds to the statuses you have defined for the requirements change management process to accurately understand what they mean.

Capabilities of Requirements Management Tools

When choosing a requirements management tool, pay attention to whether the tool can:

Store the history of requirement changes.
Store attributes of requirements for convenient filtering.
Link requirements to each other (which helps in impact analysis).
Make requirements accessible in a web version - for stakeholders to access at their convenience.

The reason why so much emphasis is placed on requirements management is the desire to reduce the number of "surprises" on the project. (From experience, surprises at the end of a project usually mean bad news and indicate that something went wrong and someone will be unhappy.)

Also, Karl Wiegers listed his books:

P.S. Karl Wiegers shared a piece of advice for business analysts during a Q&A session: Find real users and work with them. Requirements should be user-oriented, not feature-oriented. (It is unfortunate to manage requirements for features that aren't needed and don't solve any business or users' issues.)

P.P.S. Want to know what good requirements are? I listed and explained the Quality Characteristics of Software Requirements.