Most projects experience requirements creep -- changes to requirements which had supposedly been settled upon. Creep is a major cause of budget and schedule overruns, which in turn cause stress, mistakes and damaged reputations. So how can you avoid requirements creep and its side effects?
Creep continues to plague projects despite decades of attention directed toward defining requirements. Whether couched in terms of "systems analysis," "structured analysis," "object-oriented analysis," "business analysis," or variations on "requirements," these contributions to requirements definition have made marginal gains without appreciably curtailing requirements creep.
I've found that creep persists because these conventional approaches keep missing the critical component I call "REAL" business requirements. Let's take a familiar example.
The ATM example
A surprisingly large number of speakers and authors on requirements use automated teller machine (ATM) examples. Rather than making up my own ATM example, I've simply listed some of the typical requirements stated by these other authorities. An ATM must:
- Require the customer to insert their card.
- Read the encrypted card number and ID data from magnetic strip.
- Require the customer to enter a PIN (personal identification number).
- Match the entered PIN to a calculated PIN or PIN on file.
- Accept envelopes containing deposits or payments.
- Dispense cash in multiples of $10.
- Display selected account balances.
- Transfer indicated amounts between the customer's accounts.
- Issue printed receipts.
- Return the customer's card.
Most people I ask agree that those are the requirements.
If those are the requirements, then what are these?
- Provide secure, confidential access to banking services at a time and location convenient to the customer.
- Reliably, quickly and easily confirm the identity and account of the customer.
- Enable the customer to perform ordinary bank transactions involving accounts quickly, accurately and safely.
- Provide the customer with documented evidence of transactions at the time of the transactions.
I would contend ...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
that the latter are the REAL requirements -- business deliverable whats that provide value when they are delivered or satisfied. Business requirements are the requirements of the user, customer or stakeholder; therefore I treat these terms as synonymous with "business." Business requirements are conceptual and exist within the business environment, so they must be discovered. There are many possible ways to satisfy the REAL business requirements.
In contrast, the former list actually consists of requirements of a product or system. Meeting the product requirements provides value if and only if it actually meets the REAL business requirements of the user, customer or stakeholder.
Let me add two notes to anticipate frequently asked questions. First, I use "REAL" in all capitals to emphasize and distinguish in a way that survives reformatting, which destroys italics, bold and underlining in the requirements we end up with (as opposed to those we start with, which are generally modified until they're more accurate and complete -- including those additions and changes identified through the process called creep).
Second, I recognize that use case advocates often consider use cases to be the user's requirements and vice versa. In fact, use cases are merely a format which can be used to document user or business requirements, but use cases usually document the expected usage of a product, system or software.
Two creep scenarios
Indeed, an ATM could be created which would satisfy all the items on the former list and not satisfy the latter, in which case the ATM would not provide value; additional requirements would be defined to overcome the discrepancy and people would call it creep. Invariably, this process is a form of trial and error, trying some additional product features until value is provided by meeting the (typically unarticulated) REAL business requirements. For many projects, this type of creep is embedded within typical iterative development and thus may not actually be characterized as creep.
Consider a somewhat different scenario. Let's say the customer has signed off on an ATM system we developed that indeed meets those former requirements. Then the customer requests some other capability, for example, that we enable the ATM to identify customers biometrically with fingerprints or retinal scans. That's classic creep, isn't it? People would say the requirements have changed appreciably after we thought they'd been established. Undoubtedly it will take a lot more time and money to implement this type of change than if we'd known about it in the first place.
Both of these forms of creep are commonly attributed to constantly changing business conditions -- and, frankly, both the changing and the creep are often considered inevitable. This premise that it's impossible to ascertain the requirements is the basis for some supposed "best practices" for development methodologies, which actually make a virtue of not discovering the requirements and turn change and its resulting creep into a self-fulfilling prophecy.
Let me suggest instead that the REAL business requirements haven't changed nearly so much as our awareness of them. Had we in fact explicitly identified the REAL business requirements, instead of focusing only on the product design, we could have been attentive to all the ways, including biometrics, which would enable us to "reliably, quickly and easily confirm the identity and account of the customer."
The cause of requirements creep
In most requirements books and in common usage, product requirements are referred to as the requirements. Often they are just called "requirements" but they may be characterized as "product," "system," "software" or "functional" (and its associated "nonfunctional") "requirements," and sometimes they are called "business requirements" even though they in fact describe a product.
A widely held conventional model does use the term "business requirements," which are considered to be only a different level of detail or abstraction. That is, the conventional model considers business requirements to be high-level and vague, mainly objectives, which decompose into detailed product requirements. Thus, if you have a requirement which is detailed, it's considered a product requirement, and if it's high-level and vague, it's considered a business requirement.
Conventional wisdom is that creep is caused by (product) requirements which are not sufficiently clear or testable. Lack of testability is usually due to lack of clarity. In fact, while clarity and testability are important, much of creep occurs because the product requirements, regardless of how clear and testable they are, don't satisfy the REAL business requirements, which haven't been defined adequately.
All the detail in the world on the product requirements (how to deliver) cannot make up for not knowing the REAL business requirements (what is needed). The key to avoiding requirements creep is to realize that REAL business requirements are not high-level and vague, but must be defined in detail. They do not decompose into product requirements; they are qualitatively different. How is a response to what, and when the whats aren't adequately defined, hows can only be based on presumptions. In contrast, detailed REAL business requirements map to product designs, which don't creep nearly so much.
Making the change
I think it's safe to say that all conventional requirements methodologies acknowledge the need to know the user's, customer's or stakeholder's requirements -- and think they are addressing them. However, requirements creep continues because of the flawed conventional model that erroneously presumes that the user's objectives decompose into detailed requirements of a product we can create.
Thus, the most common requirements definition question ("What do you want?") actually invites the stakeholder to describe/design a product which presumably will meet their needs. Focusing on the product hows prevents adequately discovering the business deliverable whats the product must satisfy to provide value. It also frequently interferes with customer cooperation and creates adversarial situations, which further impede finding out the whats.
This leads to creep, which ironically often results in finally finding out the REAL business requirements. By recognizing what's really happening, we can apply three key methods to avoid much of the highly inefficient back and forth of creep:
- Adopting this more appropriate model enables us to go directly to discovering more of the REAL business requirements, rather than being backed into them through creep.
- Learning about the business and how to better pay attention to the business people helps us understand needs from their perspective.
- Applying the powerful "problem pyramid" tool (which will be discussed in a later article) will help guide more direct and accurate identification of the problem, value measures, causes and business requirements that provide the value by addressing the problem.
We can usually avoid requirements creep by mapping the detailed REAL business requirements to a product feature that will satisfy those requirements and thereby provide value.
About the author: Robin F. Goldsmith, JD, has been president of consultancy Go Pro Management Inc. since 1982. He works directly with and trains business and systems professionals in requirements analysis, quality and testing, software acquisition, project management and leadership, metrics, process improvement and ROI. Robin is the author of the Proactive Testing and REAL ROI methodologies and also the recent book Discovering REAL Business Requirements for Software Project Success.
