Requirements with an expiration date

There are too many requirements. We just can’t manage all the new ones that keep coming all the time. I’m talking about requirements you receive from clients and interested parties. Requirements that arise when the product management team creates competitive comparisons – which leads to even more requirements. Requirements arising from marketing and sales teams attempting to improve sales opportunities. New laws, norms, rules, voluntary additions – they all lead to requirements. It’s easy to lose track. The number of requirements is just too large. So now what? How can you reduce or eliminate requirements? What criteria will you use to proceed? In the face of all these questions, have you ever thought about attaching an expiry date to requirements?

Evaluating formal criteria

Reducing requirements involves evaluating them according to formal criteria. That means evaluating if every requirement has a source, a description text, an expected use or qualification criteria. If you are working in projects with a requirement management system you will soon find requirements that do not satisfy your formal criteria. It’s possible that your software could remind you of the fact that a requirement still needs to be declared as defined if the formal criteria have not been captured yet. That would mean that you have to invest in the formal description of the requirements before you can start thinking about the requirements volume and only then can you reduce these requirements. Eliminating requirements using formal criteria can be the means for reducing requirements, but it’s not the only one.

Evaluating the system context

Defining the system context is one of the first tasks to consider when developing a system. The system context helps you determine the parameters of your development, in other words you set the framework in which you can capture requirements. When you are defining, for example, that you want to build a new system C that should be integrated into system B, it doesn’t matter whether there are new requirements for system A. It is irrelevant. If there are requirements for communication between system B and system C it is your responsibility to define whether these requirements are within their scope or not.

If you have defined the system context at the beginning of a project you can ask if every new requirement falls within the framework provide. If not there is no reason, from projects’ perspective, to pursue these requirements any further. If you define the system context too late or if the system context changes due to a shift in the scope you can evaluate available requirements and if necessary eliminate them. Of course you can always transfer the established requirements into a different project – at the end of the day the number of requirements can always be reduced using this method.

Organisations often have to deal with too many requirements. Perhaps it’s time for a change?

Organisations often have to deal with too many requirements. Perhaps it’s time for a change?

Evaluating the goals

Do you know the stakeholders of your development and their goals? These goals give rise to requirements. If the stakeholder goals contradict each other then you have to decide at some point in your development which goal is more important – goal diagrams are useful in this regard. Ideally you should make this decision early and communicate it with affected stakeholders. Consequently you can reduce the volume of requirements that correspond to the subordinate goals.

Checking for unconscious redundancy

Checking for redundancy (i.e. requirements that are formulated in a similar way and which mean the same thing) is a good opportunity to get rid of requirements. There are many reasons why redundant requirements pop up: requirements tend to be understood differently by different people especially when they do not know that similar requirements already exist. Or so much time passes between each elicitation session that the author cannot remember the past requirements. The most important point to think about when checking for redundancy is to make sure that redundancy is not intentional. It is also possible that the total system made up of several partial systems is carrying out the same functions at the same time or that a redundant function is being carried out due to an error. The volume of requirements can easily be reduced by eliminating unconscious redundancies.

Evaluating priorities

Requirements tend to be prioritized. It’s common that prioritization that includes phrasing like: “high, medium, low” or “must, should, could, won’t” often lead to the requirement invariably being classified as high priority. That is because the author of the requirements fears that a low priority requirement could never be realized. If an author were to be worried that his requirement has not been deemed high priority he would be tempted to mark his requirements as “super important”.

There are organizations that work with absolute priorities and ones that are only issued once. This has the advantage that every requirement is just as important as all the others. A requirement with priority level 863 is more important than a requirement with priority level 716. If the requirements list contains 1000 elements you can easily identify which requirements are more important and which are less so. Some organizations have absolute importance independent of the actual volume of available requirements. This makes it easier to express that requirement xyz priority level 2,000 is twice as important as abc priority 1,000. Unfortunately recognizing this is helpful in the prioritization and not in reducing the number of requirements because it is hard to decide what the priority limit should be when new requirements are constantly being added.

Besides the qualitative filters there are also analytical prioritization methods such as the “Wiegers’sche priority matrix” or the “Kano model” with basic, advanced and excitement properties. These methods are more expensive than simple prioritization methods, but they generally deliver meaningful results. Unfortunately it is hard to determine how you can use the results to reduce the requirements. As a producer you should not leave out basic markers because clients and users need them, they tend to only be noticed if they are absent. But you should also not leave out performance markers because clients tend to ask for them explicitly and would be dissatisfied if they were absent. And you shouldn’t leave out excitement markers because they offer the best opportunity to stand out from the competition. They are not easy to elicit so if you have identified excitement markers, don’t eliminate them.

Delivery date, Reiteration and Expiry Dates

Have you ever worked with requirements expiry dates? Why not? Have you ever found that a requirement you formulated two years ago actually got realized? Yes? What about three years ago? If your answer is yes again then congratulations, you are in a very elite group. But how many requirements did that apply to? Those kinds of requirements were probably the exception, not the rule. Maybe your projects don’t even run for two or three years. Perhaps you don’t continually add new requirements during a project. Or you work in a team that works very well and have to document less. But most organizations reach a point at which requirements begin to age. They get stuck in the backlog or in the requirements lists without the chance of ever being realized. And new requirements get added every day. The mountain is always growing.

What can you do? You can set a deadline by which the requirement must be realized. Alternatively you can assign requirements to future development releases. Perhaps you’re already doing so, but probably not for every requirement. There are two reasons for that:

  1. You can’t measure the requirements at present. But if you determine that requirements are relevant you could work with a template. In this way you will be able to decide if and when a release needs to be realized based on your knowledge.
  2. You don’t believe that the requirement will be realized. Why would you keep the requirements then? You could just eliminate them (or mark them as “rejected” or “archived” so that they continue to exist but they do not affect the everyday work.

An expiry date is an alternative to a deadline. You don’t need an explicit template. When you plan requirements in future releases you will always be working with an expiry date in mind. But how far in the future should an expiry date be? You could simplify the entire exercise by saying that every requirement that has not been realized within x or y years/months will no longer be considered. Or you could try to think in terms of volumes. Ask yourself things like: how many requirements do you manage in your requirements management system and how many of them can be realized within a certain period? And how many requirements will be added during this period? Or you can find the answer depending on the requirements. An epic can’t be implemented as fast as a story. The implementation in a new database for an existing system takes time and effort than changing the color of an existing button. You also need to decide whether you can set an expiry date for every level of granularity or just for stories.

Conclusion

You probably don’t use a template or an expiry date when dealing with requirements yet. Even if organizations often wrestle with requirements, questions about the timing of a template or a suitable use of an expiry date are not easy to answer. The reduction of requirements takes effort but without this the mountain of requirements will continue to grow, making working with requirements ever more difficult and causing you to lose track of them. If you want to continually reduce the requirements permanently then a change in thinking is called for. Templates and expiry dates are interesting possibilities for reducing or eliminating requirements. Try it out.

 

Note:

Many of these thoughts come from an exchange I had on XING with  Till-J. Faßold, Olaf Barheine and Rainer Wendt. You can find the conversation here (German only).

My name is Michael Schenkel – and I believe in tools, if they are useful. Tools that support users in their work, tools that provide a common working environment for all types of roles in a project.

Tags:
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *