Project studies by IBM, GTE, TRW, and several other large corporations have shown that an error in requirements detected in later phases of the software development life cycle increases costs by:
- 500% for architectural design
- 1,000% for coding
- 2,000% for unit testing
- 5,000% for acceptance testing
- 10,000% for maintenance
With such an impact on project costs, there is no wonder that few software development efforts come in under budget and on time.
Similarly, changing requirements create the same problem. According to research reported by Capers Jones in Assessment and Control of Software Risks (Yourdon Press, 1994), “Creeping requirements changes average about 1% per month.” This makes software testing so much harder.
For a project of any magnitude, you simply must plan ahead for this. During a large requirements analysis such as a year-long process where some coding and prototyping is underway, the expected requirements changes may amount to an extra month of work. If your customer, users, and management aren’t expecting this, they will be unhappy with your performance – not to mention any additional cost. As a developer or tester, if you aren’t expecting the modifications, you may not finish the job.
My advice to you is get the word out. Warn the customer. Warn your boss. Make sure all parties understand up front that the requirements document is subject to change, and that major changes will incur increased costs.
Requirements should include details about:
- Functionality
- External interfaces
- Performance
- Portability
- Security
- Constraints
Good requirements are:
- Correct
- Unambiguous
- Complete
- Consistent
- Prioritized
- Verifiable
- Modifiable
- Traceable
- Hard to come by
In the context of software testing, requirements are extremely important because they provide the objective specifics about the software. The “verifiable” characteristic of good requirements refers directly to testing. If we can create a test case for a feature, then it is testable. If the requirement is to0 ambiguous, then we can’t test the intended feature.
However, we should not be so naive to think that requirements are a fixed target. They will evolve as they are built and the user becomes aware of features that he/she wants. Users change their mind…frequently. And even with iterative design sessions, we should view requirements engineering as a negotiation process, where potential users of the system explore and fully understand the requirements, agreeing on what they want and what they need.
As Steve McConnell says in Code Complete, “A plan to follow the requirements rigidly is actually a plan not to respond to your customer.”
If your customer does not understand that requirements modifications are normal and that delivery times and cost estimates must also change, then escalate this misunderstanding immediately. Do your best to educate everyone that will listen, even if they are not directly on the project team.
There are going to be errors and changes in requirements. It is reality in the software development world. I’ve seen it over and over and over in my 20+ yrs developing. Big projects…small projects…waterfall projects…agile projects…extreme programming…Ruby on Rails…COBOL on 370…dBase III on DOS…C++ on Netware…Java on LAMP…Assembler on PDP-11…I’ve been there and done that with scope creep and bad requirements.
I recommend that you study the finer points of use case engineering. Help your colleagues to understand how accurate and thorough use cases help not only the designers, but the developers, testers, and customers as well. Writing good scenarios into solid specifications is like having a firm concrete foundation on which to build a house. It will help your software development efforts and inevitably lower costs and improve quality.
Most software testing efforts involve checking functionality against the specifications. It will be a moving target if you don’t invest adequately in proper requirements analysis. And of course, you must continue to control the spec process throughout the SDLC. Don’t let the customer get away with scope creep without some pushback. And put it in writing to all project stakeholders. You will probably still be changing the specs, but at least you have warned everyone of the ramifications.
Just be careful when you tell your boss, “I told you so” after costs are 10 times what the original estimate. They don’t always appreciate our candor and alacrity.