When you gather the project stakeholders, be sure to include the testing organization in the process. Performance testing expert Jim Pensyl believes strongly that testers should be involved at project kick-off. "Only the testing organization can tell you if the requirements are testable," he says. "Why not then use [their] deliverables for the source of truth in status and estimation refinements?" Developer David Gelperin agrees: "Experienced testers and technical writers should be active participants in the cross-functional teams tasked with requirements development."

This is an important time to listen to the development team's feedback. Says Jared Richardson, author of Ship it! A Practical Guide to Successful Software Projects, "If you don't include us on the time line generation, don't expect us to meet the time line. If the general contractor on a building project doesn't ask the brick mason or the electrician how much time they need, how do they expect to generate a realistic schedule? They can't. If you don't include developers and testers when you're generating your time lines, don't think you'll hit them." Even after you get the right people to talk about what the software needs to do, you still have another hurdle to overcome: getting those requirements recorded with the right amount of detail. Where do you draw the line between micromanagement and detailed instructions?

3.SUPERFICIALLY COMPLETE: Define Requirements With "Enough" Detail

Although developers uniformly insist that they want the right amount of detail in the software specifications, they often disagree on how much is "enough". One set of developers wants the minimum: a rough idea of the business problem to be solved. Anything more than that, they feel, is meddling with developer creativity, and a waste of time. One developer gave the example of "an automated system to help us do our taxes" as a fine specification.

At the other extreme is the explicit requirements document. Peter Nairn, a software tester in the United Kingdom, says he worked on one successful project that had superlative requirements documentation. In addition to a rigorous definition, Nairn says, the requirements were prioritized within the requirements document itself. "There were three levels of priority: Must, Shall and Should. Must meant the system could not go live without; Shall meant that the system would be degraded by not having it and there would be financial penalties for not meeting the requirement; and Should meant that these were nice to haves and would enhance the system." The requirement spec thus read something like this: "The system Must [1.1] have the ability to do xxx and Shall [2.3] be able to yyy and Should [3.3] be able to zzz." The numbers in square brackets referenced an appendix to the document with definitions. Explains Nairn, a little wistfully, "The whole thing made traceability easy, prioritization easy, phasing of implementation easy — and costing a nightmare! Once the requirements were agreed, phases agreed, project costed and price agreed, everyone knew what was going to be done."

That doesn't mean that every software requirements document should be 200 pages long. The appropriate level of detail varies by job description, by application domain, and certainly by corporate culture. Even then, you should expect contradictions. Your quality assurance department usually wants a lot of detail. Jim Hazen, a professional QA tester in Colorado, wants requirements defined well enough for him to write test cases. That means, he explains, "They have a level of information beyond the typical, 'We want an application to do X, Y and Z'. They should have information that states more of what the requirement is to do (the What) and the way it is to do it (the How)." The software requirements are supposed to enable developers to improve application consistency (especially in large projects) and to reduce the guessing game of, "What does the user want?" Damon worked on one project that used Use Cases as its requirements repository.