Do Requirements Really Change?

In my last post, I discussed change and how it is always present in projects. In this post I would like to discuss a particular area of change: what we often call changing requirements. Changing requirements are typically blamed for most ills in software projects. How can this be resolved

with my earlier assertion that change is useful? We’ll give it a try.

I asserted earlier that one might consider embracing change. Get to know it better. Become intimate. So let us look at what is often meant by changing requirements.

A way to describe changing requirements is that the requirement R was ABC and now it is ABZ. Damn. It changed. The key word in this description is ‘now’. Exploring the issue of time in changing requirements is important.

Now we all understand that the cost of change is higher the later the change is in the development process. Correct? Typical numbers are that it costs an order of magnitude more as you move through each phase: requirements gathering, design, implementation, or deployment. But this is derived from phased thinking. If much shorted cycles are used, as suggested by agile development, then the temporal distance is much shorter. In other words there is much less opportunity for change. Woo-la, we have less changing requirements.

‘But: but: .but’ you say. ‘Things will change even so. ‘ Yes. I agree. But those changes are really new requirements and must be treated as any new requirement. New requirements are more easily noticed as something that may have a negative impact on schedule. Changing requirements are not so easily noticed as such.

In agile development we typically ask that the work be set for the duration of the iteration or sprint, typically 2-4 weeks. This means no changes in requirements during the iteration for the work being done during the iteration. Work to be done in the future is free to change as much as needed.

Now I have simplified a little and there are other issues that surface when this occurs. But in general what I suggest is true. By adopting time-boxed development we have changed the changing requirements problem to a new requirements problem.

And something else shows up. When we adopt this technique, the work must be specified in smaller hunks, often called stories in agile development. The construction of these smaller hunks also gives us leverage in changing requirements.

Remember our requirement R? It initially was ABC. If we have to decompose it, it will result in three stories (sub-requirements, features, use cases, stories: it is a fractal, repeating process) we can call Story A, Story B, and Story C. When the change in requirement R is made we see that Story Z is replacing Story C. If only stories A and B have been completed then the change has very little cost. If story C has been completed then Story Z is just a new requirement.

Another situation occurs when development discovers that implementation of some requirement is unexpectedly delayed. It may be much harder than estimated, the critical resource is unexpectedly not available, or any of a large number of thing that can happen. Since agile is time boxed a good agile team will negotiate with the PM to reduce the scope of the work. This is done in order for the team to deliver some value, perhaps not as much as planned but more than nothing.

In this case the work will be split into what can be accomplished in the iteration and what will be put off until later. I prefer to think of it as creating a new requirement or budding off a new requirement. The new requirement is really new only in the sense of tracking. What has surprised me is how often that new requirement is often not the next most valuable thing to be done.

This mechanism of splitting and decomposing aids considerably the work at finding the highest value work to be done next. Think about how this might apply to your projects!