Requirements Creep


Requirements creep refers to new requirements entering the specification after the requirements are considered complete. Any requirements appearing after this point are considered to be requirements creep.

Requirements creep has been tagged with a bad name, usually because of the disruption to the schedules and the bloated costs of product delivery. Without wanting to defend requirements creep, we do think it prudent to look at some of the causes of creep and to discuss how we can approach this problem.

First, most creep comes about because the requirements were never gathered properly in the first place. If the requirements are incomplete, then as the product develops, more and more omissions must of necessity be discovered. The users, aware that product delivery is now imminent, ask for more and more "new" functions. But are they really new? We suggest they are requirements that really were part of the product all along. They were just not, until now, part of the requirements specification.

Most creep comes about because the requirements were never gathered properly in the first place.


Similarly, if the users and the clients are not given the opportunity to participate fully in the requirements process, then the specification will undoubtedly be incomplete. Almost certainly the requirements will creep as delivery approaches and the users begin asking for functionality they know they need.

We have also observed creep that came about because the original budget (for political reasons) was set unrealistically low. When the incredibly noticeable creep set in, it was not so much a matter of the requirements creeping, but of the product bringing itself up to its correct functionality.

If changes that cause new requirements happen after the official "end" of the requirements processand they could not have been anticipatedthen this is unavoidable requirements creep.


Requirements also change. Quite often they change for the very good reason that the business has changed, or new technological advances have made change desirable. These kinds of changes are often seen as requirements creep. In truth, if changes that cause new requirements happen after the official "end" of the requirements processand they could not have been anticipatedthen this type of requirements creep could not have been avoided.

Whatever the reason, whether good or bad, you must be able to identify the reason for the creep. Moreover, you must be able to respond appropriately.

A little earlier in this chapter we spoke about the relevancy of requirements, and noted how the requirement must be both relevant to the product purpose and within the scope of the work. If requirements are creeping out side the scope or are not relevant to the product purpose, then we suggest you have serious cause for concern. Is the scope correct? Are the goals for the product correct and realistic? We cannot hope to diagnose your exact problem in this book, but we suggest you look long and hard at the root cause of your requirements creep.

The best way to minimize requirements creep is to engage in a good requirements process, with the active and enthusiastic participation of the stakeholders. That, and to start with a reasonably sized project. Anything less and you must expect some creep to happen to your requirements. When it does, identify the cause and use that knowledge to fine-tune your requirements process.

We have not spoken about the effect of requirements creep on your budget. Let's look at that issue along with another problem, requirements leakage.

Requirements Leakage

Requirements leakage refers to those requirements that somehow "leak" into the specification. Think of this as the way water can leak into a rowboat as you cross a lake. A little water may not harm you, but too much of it and your chances of getting safely to the other side are seriously diminished. You can also think about requirements leakage as unrecognized and uncontrolled requirement creep. Nobody knows where the requirements leaked from or who is responsible for them. Nobody wants to own them. And yet, leaking requirements have an effect on the budget. Either they are rejected or the project plan is adjusted to reflect the current reality.

Capers Jones reports for the average project, about 35 percent of the requirements appear after the requirements process is deemed to have ended. That is, about one third of all the requirements have crept or leaked into the specification.

Jones, Capers. Software Quality: Analysis and Guidelines for Success. International Thomson, 2000.


The effect of this insidious growth in the requirements is shown in Figure 11.5. The graph depicts the cost of delivering functionality. You should create a graph like this one to make everyone realize that functionality is not free. Look at what happens when the size of the product creeps up by 35 percent. The effort needed expands by a little more than that. And yet, this is the part of the product that somebody expected to get for free. When the requirements grow beyond what was originally anticipated, the budget must grow proportionally. But how often do you hear, "Just one more little thingit won't affect the budget"? It does affect the budget. Each requirement has a cost attached. So what to do about it?

Figure 11.5.

When you know the rate of productivity at your organization, it is a fairly simple exercise to convert the size of the product into the amount of effort or cost. When the size of the product increases (creeps), the amount of effort needed must also increase. It is this increase, which is due to uncontrolled requirements creep or leakage, that causes many projects to fall behind schedule or fail completely.


The Quality Gateway must ensure all requirements carry the name of the originator. Knowing who asked for it gives you the starting point from which to assess the need for the requirement. Next the Quality Gateway ensures each requirement carries valid customer satisfaction/dissatisfaction ratings. These ratings tell you the value your client/customer places on the requirement. If it is high, then creeping requirements might be tolerated (with an adjustment to the budget). The rationale attached to the requirement must also make sense. We have often found that leaking requirements do not make sense or are outside the scope. If you have the measurements we advocate attaching to your requirements, then you can confront the originator of the rogue requirement and justifiably reject its inclusion in the specification.

To stay in control means you have to, at all times, be aware of how much functionality you are delivering. This statement implies you measure the functionality of the product. Capers Jones advocates basing the development on a contracted number of function points at an anticipated cost per function point. Suppose we start with an average delivery rate of 16 function points per person-month.[1] So, for a 1,000-function-point product to be delivered, the cost is 62.5 person-months. If the functionality to be delivered creeps by 25 percent, that's 250 function points; to accommodate this growth, another 16 or so person-months has to be added to the budget. While this type of ongoing calculation does allow requirements to creep, it ensures that the creep is recognized, budgeted, and paid for.

[1] Please note this number is an average, and different technologies and application areas have an effect on it. So do your own in-house development skills.

We suggest you start your Quality Gateway with two peopleperhaps the lead requirements analyst and a tester. The gateway is meant to be a fast, easy test of requirements, not a laborious process involving half of the development team.


As a footnote to this point, we have observed that some government departments are starting to contract out their software at a rate per function point. The size of the product can be anything the government wants it to be, but the contracted cost per function point of delivery remains the same. This idea may work for you, too.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net