Eliminate requirements

• if you continuously receive requirements from customers and specialist departments,
• if product management and sales are always formulating new requirements, or
• there are new laws, standards and guidelines that lead to further requirements?

Of course, you could simply impose an acceptance stop and ignore changes, but then your customers would probably soon start looking for a new partner. So on the one hand you need to be open to additional requirements and on the other hand you need to be able to eliminate existing requirements that have not been implemented.

Completeness, stakeholder goals and system context in mind

If you want to eliminate requirements, you could start by checking them for formal completeness. If you work with a requirements management tool in your software development, then checking for completeness is fairly easy. You will quickly find requirements that are missing the description, the expected benefit, acceptance criteria or source information.

But what happens when you have identified these requirements? Can you simply delete them? Probably not. In fact, it is quite likely that additional effort will now be required, because how will you assess the importance of a requirement if it has not (or not yet) been fully formulated? Ergo: Eliminating requirements when information is missing is one way to reduce the amount of requirements. However, the additional effort to check and the risk of eliminating an important – not yet fully specified – requirement should be considered.

Do you know why it is important to know the stakeholders of your development and their goals? Stakeholder goals often result in requirements. If goals contradict each other, you should decide as early as possible – ideally within the framework of stakeholder communication – which goal is more important from which stakeholder and will subsequently be addressed. As a consequence, you can eliminate the requirements that would have been necessary to achieve the less important goals. By the way, goal diagrams are very suitable for visualising stakeholders and goals.

After the stakeholder goals, you could also look at defining the system context. With the system context you define the boundaries of your software and system development, i.e. you determine an area for which you want to capture requirements. For example, if you want to implement a new system A that communicates with system B, then it is irrelevant for your development whether there are requirements for system C. You could eliminate these requirements. You could eliminate these requirements.

Check requirements for redundancies and priorities

There are numerous causes that lead to redundant requirements:

• They are gathered by different people who do not have an overview of already existing requirements.
• They are formulated in such a way that they overlap in parts.
• Or the elicitation of the requirements is so far apart in time that the author is no longer sure whether he had already formulated a similar requirement earlier.

These causes lead to unconscious and unwanted redundancies. Eliminating these makes sense. Ideally, however, you should look out for deliberately created duplicates when checking. An unthinkingly deleted requirement A that is found in both component 1 and component 2 could otherwise be costly.

Prioritising requirements is a broad field. Does it also offer options for eliminating requirements? Let’s take a look at the practice. There are organisations in which most requirements are classified as “important”. From the point of view of the creator of a requirement, this is understandable, because he wants to ensure that his requirement is actually realised and the chances are much greater with a higher prioritisation than with a lower one. If an organisation now looks at the requirements with the lowest priorities in order to possibly eliminate them, then you can be sure that in the future with priorities such as “low, medium, high”, “1, 2, 3” or “must, should, could, won’t” every creator will permanently make sure that his requirement is classified in the highest level. This would mean that prioritisation itself would fail – not a good idea.

Are there perhaps other prioritisation procedures that could help reduce requirements? For example, the Kano Model with its basic, performance and enthusiasm characteristics provides valuable insights for prioritising requirements. Unfortunately, even with this qualitative model, it is not possible to derive how you can reduce the amount of requirements. You simply cannot do without basic features, because they are self-evident for the user, even if they are only consciously perceived if they are missing. You cannot do without performance features either, because these are explicitly demanded and compared by users. And no one does without enthusiasm features, because they are very difficult to identify and you don’t want to eliminate enthusiasm. So Noriaki Kano does not help you with requirements elimination.

Another option when evaluating requirements is absolute prioritisation. In this case, priorities are only assigned once, e.g. there is only one priority 108. If a requirement has priority 109, it is more important than the requirement with priority 108. Of course, such a form of prioritisation causes a lot of effort, but the result is always clear. For example, if you have assigned 4,000 different ratings, you could eliminate the lowest 100, 200 or possibly 500 requirements, right?

The release assignment and expiry date

Do you know requirements that were implemented 3 years after their survey? After 4 or 5 years? Is this the rule or the exception for you? If it is the rule, what about requirements that were collected 8, 9 or 10 years ago? In most organisations there is a point at which requirements only age but are no longer implemented. They are buried in requirements lists or product backlogs, almost with no real chance of being implemented. If new requirements are added every day, the chances are practically zero. What could you do alternatively? You could work with an implementation date, i.e. define a point in time when a requirement should be implemented. Maybe you could do this today by working with release assignments. The idea is identical. If you have assigned a requirement to a release, plan to implement it. If you keep postponing the realisation of a specific requirement, i.e. if you change the priority, it may happen that at some point you completely remove the requirement from the release planning and it disappears again into the depths of the product backlog. It might already be a candidate for elimination.

There is also a case where you cannot (yet) schedule the implementation of a requirement. If the request is still relevant, you could define a resubmission for it and decide later whether it should be converted in a specific release. If you want to move it again instead, it could also be a candidate for elimination. And what happens if you don’t believe in implementing a requirement? You can eliminate this requirement immediately.

As an alternative to release assignments, you could also work with an expiration date. When planning requests, this means that you always plan against the expiration date. For important requirements you define an early expiration date, for all other requirements you work with default values of x years and/or y months. To determine the default values, use your experience and see how many requirements you have realised over a defined period of time in the past. Alternatively, you can work with experience in implementing epics, features or user stories and establish an expiration date for each category or only for individual ones. When determining the default values, keep in mind that there are typically a number of additional requirements in the defined time period. Once you use the expiration date when working with requirements, you will no longer need to consider requirements that were not implemented within the specified time period.

Conclusion: Eliminate requirements

The elimination of requirements causes effort, but without this effort the number of requirements will continuously increase and the overview will be at least significantly more difficult. If you want to permanently reduce the number of your requirements, it makes sense to verify formal criteria, goals and system context. Checking unintended redundancies is also recommended. The prioritisation of requirements may also help in the selection of elimination candidates. Working with an expiration date is another option for eliminating requirements.

You don’t have to equate the elimination of requirements with a “deletion” of requirements. You can also add states such as “retired” or “archived” to requirements so that they remain in your requirements management without interfering with your continuous work with requirements.

Notes:

If you like the post or want to discuss it, feel free to share it with your network.

Michael Schenkel has published more articles in the t2informatik Blog, for example

What does t2informatik actually do? One click and you'll know.