Eliminating requirements

by | 01.03.2018 | Software development | 0 comments

Do you know the feeling when the amount of requirements to be realised is already too large and new requirements are added every day? What can you do if you continuously receive requirements from customers and specialist departments, if product management and sales constantly create new requirements or if there are new laws, standards and guidelines that lead to additional requirements? Of course, you could simply stop acceptance and ignore changes, but it’s likely that your customers will soon be looking for a new partner. So you need openness to additional requirements on the one hand, and the ability to eliminate them on the other. And according to which criteria can requirements be eliminated?

Verifying formal criteria, goals and system context

If you want to eliminate requirements, you could start checking them for formal criteria. If you are working with a requirements management tool in your software development, it is quite easy to check for formal criteria. You can quickly find requirements that lack description, expected benefits, acceptance criteria, or sources. But what happens once you have identified these requirements? Can you simply delete them? Probably not. In fact, it is quite likely that additional effort will be required, because how do you assess the importance of a requirement if it has not (or not yet) been fully specified? Ergo: Eliminating requirements with missing formal information is one way to reduce the amount of requirements. The additional effort of reviewing and the danger of eliminating an important – not yet fully specified – requirement should, however, be considered.

Do you know why it is important to know the stakeholders of your development and their goals? Stakeholder goals often create requirements. If goals contradict each other, then you should decide as early as possible – ideally within the framework of stakeholder communication – which goal is more important for which stakeholder and will be implemented subsequently. 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.

Following the goals of the stakeholders, you could also look at the definition of the system context. With the system context you define the limits of your software and system development, i.e. you determine an area for which you want to capture requirements. If, for example, you define that 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.

Reviewing redundancies and priorities

There are numerous reasons for redundant requirements. Requirements are captured by different people who do not have an overview of existing requirements. Or they are drafted in such a way that they overlap in parts. Or the requirements are collected so long apart that the author is uncertain whether he has already formulated a similar requirement before. Reviewing redundancies is a good way to eliminate requirements. When checking, however, you should pay attention to whether the redundancy is possibly intended. It could happen that several components in a system are to execute the same function simultaneously or a redundant function is called in the event of an error. The number of requirements can therefore be reduced by unintended redundancies.

The prioritisation of requests is a broad field. But does it also offer options for eliminating requirements? Let’s take a look at practice. There are organisations where most requirements are considered “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 significantly 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 future, with priorities such as “low, medium, high”, “1, 2, 3” or “must, should, could, won’t”, every creator will permanently ensure that his requirement is classified at the highest level. This would be a failure of prioritisation in itself – not a good idea.

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

Another option when evaluating requirements is absolute prioritisation. Priorities are assigned only once, so there is for example 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, then you might be able to eliminate the lowest 100, 200, or possibly 500 requirements, right?

Release assignment and expiration 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 requirement 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 repeatedly postpone the realisation of a specific requirement, i.e. if you change the priority, you may at some point remove the requirement completely from release planning and move it back to the 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

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.

Michael Schenkel
Michael Schenkel

Head of Marketing, t2informatik GmbH

Michael Schenkel is a graduate business economist and is passionate about marketing. He has a certificate for excellent hiking characteristics, Odenwaldtour in classes 6a/6b and since 1984 the Seahorse. He likes to blog about requirements engineering, project management, stakeholders and marketing. And he will certainly be delighted if you meet him in the real world for a cup of coffee and a piece of cake or for a virtual get-together.

Share This