5 Deadly Mistakes in Requirements Management and How to Overcome Them

This article looks at the different ways to tackle the 5 Deadly Mistakes in Requirements Management (with Examples)

Every major standard, certification, and regulatory organization mentions the need and importance of well-defined requirements in the product development process.

Indeed, there are a number of sources that are devoted to requirements and best practices.

However, years of experience have shown that companies still struggle not only with writing but also with managing requirements and integrating them into their product development process.

Requirements Management Mistakes and Ways to Overcome Them

Enlisted below are the 5 deadly mistakes that we have observed within the area of requirement management and requirement engineering.

Let’s Explore!!

1) Elicitation – Lack of Proper Communication

Over the years we have seen the struggle with the requirements starting right at the beginning of the projects.

There are many reasons through which things can get off to a rocky start, not the least of which is lack of communication and understanding between stakeholders.

I was once involved with an organization that had overhauled their internal product development process to address the discontinuities between what the sales and marketing teams were requesting and what they felt on the what the engineering teams were delivering.

The first project they kicked off with the new process resulted in almost the exact same issue as before the organizational process development was overhauled.

This was just because they did not address the root problem first: Communication lapse.

The solution was to implement a pre-requirement “stakeholder needs” document. This is where all the stakeholders can see their requests in their own words.

In addition to capturing the requests in the stakeholders’ own words, we must include a measure of acceptance.

This is a description of what it may look or feel like to the end user. We then trace these desires or needs to the measurable stakeholder requirements.

The creation of this document before the actual requirements work starts will help our stakeholders see how their original concepts are translated into a more formal stakeholder requirement.

2) Unspecified Utilization of Related Requirements

The vast majority of my projects over the years have not been siloed.

All of the engineers can see all of the project documents if they want to and know where to go to find them. This open and transparent environment is well received, and it provides a context where the elements are within the grand scheme of a project.

One of the drawbacks of this situation is that in the early stages of development, some teams make plans to share system resources without really discussing and integrating with the subsystem owners.

Most often we find that this was the result of hallway conversations or impromptu cross-department meetings not getting recorded or communicated out properly.

The problem arises when the resource has to change but the second non-formal team who was planning to use that resource was not kept abreast of the changes.

Here is an easy example: Mechanical engineers need an air temperature sensor in a certain area of the system. The computer group has an off-the-shelf device going into that area and one of their engineers mentioned that it has onboard sensors.

The “mechanical guys” investigate and decide that this satisfies their needs, hence they include it in their design plans.

Six months later, during cost downs, the device is replaced and no one mentions it to the mechanical guys and they don’t find it out until testing.

Processes can be implemented to minimize these issues and there are now tools that will allow you to integrate these checks within your requirements management software.

Our solution is to implement a cross-team check for all the requirements you plan to make use of, and not just the ones within your subsystem or area of responsibility.

In the above example, our mechanical team will flag that requirement and if it was modified or changed, they will get notified.

The bottom line is to make sure that you have a method in place to track the shared or complementary functions as0 communication lapses can happen.

Recommended Reading => Top 20 Requirements Management Tools

3) Design by the Requirement

A reoccurring theme for young or inexperienced companies is designed based on requirements.

Teams will focus on what the device will look like and not on what the device needs to do. It is common for people to start specifying the screen sizes, the number of buttons, workflows, and the other items before the specific needs of the device have been defined.

Designs can and will become requirements but in the form of design documentation and not as an individual requirement at high levels.

For example, certain stakeholders in the organization may specify that a device will have a capacitive touch screen. This could be an example of a design by the requirement.

Performance specifications, workflows, and environmental requirements can all play into a decision for control systems like this.

However, in this case, those design decisions are removed from the engineers by the specific requirement within a high-level document.

The best way to handle these items is to divide the requested feature into functional and design requirements.

From our above example we can ask questions about why a touch screen is required from a performance perspective and at the same time develop the design concept documents for their aesthetic and workflow requirements.

The technical specifications will guide the engineers on performance and what they need, and the concept artwork & the workflow studies solve more formative issues such as feel and process flow.

4) Avoiding Changes

Every organization I have been in has agonized over-specification changes after something has been signed off.

The catch-22 is that these same organizations don’t want to wait for the comprehensive requirements document in the first place, hence the high-level documents are being written at the same time as design work is being done.

No matter how good your team is, it cannot design and build something when you cannot or will not tell them what it will be.

There is a wonderful Dilbert cartoon where the boss tells Wally that he has to start on the design because they did not have time to work on the requirement.

That is very funny right up until that is what your boss really does, then you just get a little sad.

The truth is that things always change on the path of completing a project. We should learn to embrace the changes and prepare for them.

The needs of clients will change, and we learn things as engineers and designers. All of this gives us more information and knowledge to build a better project.

Unfortunately, for these kinds of issues, there is no shortcut or a quick fix. Establishing and maintaining traceability between the different levels of specifications is the only way to know which elements are affected when something changes, especially when those changes affect multiple teams.

5) Use of Word and Excel

Throughout the years, I’ve seen that almost all the organizations default to Word and Excel to support their requirements process at some point. Word and Excel are cheap and easy ways to start writing requirements.

Almost everybody in the organization knows how to use these tools.

However, very quickly the document versioning starts becoming a real problem, and traceability matrices, often maintained in Excel, become an inextricable combination of columns with references to disconnected documents. Maintaining both the Word documents and the Excel matrices in sync is a strenuous task.

Without even addressing the standard compliance, if you plan on making changes to your project (which you should), then traceability is a must, and this is when a requirements management system like Visure Requirements becomes necessary to make it an affordable task and ease the burden.

The requirement management tool becomes the single source of truth for keeping all data accessible and interconnected.

About the Author

This article was written for STH by Fernando Valera, Chief Technical Officer at Visure Solutions, Inc.

Fernando Valera completed his degree in Computer Engineering at the Complutense University in Madrid, Spain. He has since been dedicated to the field of Requirements Management and Requirements Engineering.

He has participated in the deployment of Requirements Engineering methodologies, processes, and tools in companies in many countries, in sectors such as automotive, medical devices, banking and finance, aerospace and defence, and IT, training over 500 people in total.

He was relocated in 2012 to Visure Solutions, Inc. headquarters in San Francisco as CTO, where he currently leads the company’s efforts to bring state-of-the-art Requirements ALM Platform to help customers address compliance needs and bring high-quality products on time and on budget.

Have you ever faced any of the above issues in your project? Feel free to share your experiences with us in the comments section below!! We would love to hear from you.