How do you know when a requirement is obsolete?

Requirements & Requirements Management

How do you know when a requirement is obsolete?

By |

Requirements obsolescence is an issue brought about by disruption in technology.

Complex development projects can include hundreds of requirements and span multiple years. In that time, a lot can change in the market and with a product’s intended use and design.

So how should you go about questioning requirements identified at the beginning of a project to determine whether they should make it into the final product?

We put this question to three requirements experts in a recent webinar on disrupting requirements, and here’s what we learned.

Focus on the Requirement’s Purpose

First of all, when considering if a requirement is legitimate or obsolete, Colin Hood, Principal at Colin Hood Systems Engineering, urges to identify the purpose of the requirement itself.

To do this, you must separate the “what” from the “how.” Ask yourself: Is the requirement a basic statement on what you’re trying to do? Or does the requirement state how to do a certain thing?

So long as the requirement is a problem statement outlining the desired outcome you want to achieve – i.e., the former of the two questions above – it shouldn’t have a specific lifespan and could likely exist forever.

In this case, it would be the responsibility of the product owner to decide if and when this requirement would go into the backlog and eventually be realized in the evolving product.

On the other hand, if you answered affirmatively to the second question – meaning the requirement’s purpose is to tell you how to execute a solution – the requirement may face obsolescence very quickly.

The Problem with a Solution-Based Requirement

Requirements that are solution-based are often technology-dependent. With the rate of change occurring in today’s world, technology is easily disrupted. What was once necessary may no longer be supported.

Furthermore, requirements that focus on how to get work done take you into the solution domain too quickly and can restrict the design phase.

Christer Fröling, Scandinavian Marketing Lead at the Reuse Company, cautions that when gathering requirements, going from the problem side to the solution side too quickly can cause you to miss important contextual information and yield low-quality requirements. The results can include inaccurate cost estimates and costly overruns due to an incomplete scope of the problem.

Bottom line: You don’t want your team spending time and budget working on an obsolete requirement.

Understanding the Purpose

Michael Jastram, Sr. Solutions Architect at Jama Software, reminds us that functional modeling can also be used to separate the general function from how it is being done on a technology level.

This distinction could help you salvage a seemingly obsolete requirement by uncovering a real understanding of what the requirement aims to achieve apart from how the requirement suggests it be executed.

In addition to making some requirements obsolete, change affects a lot of the development process. To hear requirements experts discuss and debate what that means for the requirements-gathering process, traceability and the future of requirements, listen to our webinar, Disrupting Requirements: Finding a Better Way.

Jama Software
Latest posts by Jama Software (see all)