An Ounce of Prevention: Published in IEEE Software, May/June 2001, pages 5-7

Iteration Zero: clarifying intentions and requirements
Iteration Zero
The first step in any project is what is called Iteration Zero. Its purpose is to set the foundation for the iterations that are to follow. This initial stage, that should last no more than four to eight weeks, should produce clear conclusions that will drive the rest of the project. It begins by clarifying intentions to make sure all stakeholders agree on the business drivers behind the investment.
A clear consensus is essential. Then, initial requirements are gathered in the form of user-stories explaining who needs what kind of information. Once this is done the target solution is designed. But not with the aim of having an ultimate solution that will address all present and future requirements forever.


What does that ounce of prevention look like?
While the underlying dynamic of defect-cost increase has not changed, our understanding of how to detect upstream defects has improved considerably. Not too many years ago, we thought that the best way to detect requirements defects was to capture an exhaustive set of requirements in a monolithic requirements specification and then to subject that specification to intensive reviews. Although industry data suggests that this approach is cost-effective compared to the alternative of jumping straight into early prototypes and then fixing requirements vagueness at construction time, we now know of numerous alternatives that are often preferable to the monolithic-requirements specification approach:

• Involve end users as early as possible.
Involve end users as early as possible. Several studies have found that end user involvement is key to stable requirements and software project success.

• Create a throwaway prototype.
Create a throwaway UI and put the prototype in front of real end users. Get feedback. Revise the prototype until the end-user is excited about the system. Then build the system. This approach correlates with good requirements stability and low system cost.

• Deliver the software incrementally.
Write production code for a small segment of the system. Put that functionality in front of the user. Revise the requirements, design, and code until the user is excited about the system. This approach does not entirely eliminate the defect-cost increase dynamic, but it shortens the feedback loop from requirements to user feedback in a way that reduces the number of downstream dependencies that will be based on erroneous upstream work. This sort of incremental delivery approach correlates with high user satisfaction and lower total development costs.

• Conduct a requirements workshop.
Fast requirements elicitation techniques such as joint application development sessions are an effective way to shorten the time required to collect accurate requirements while simultaneously reducing requirements volatility downstream.

• Perform use case analysis.
Rather than being satisfied with the users’ first explanation of what they want a system to do, examine the system’s expected usage patterns to better understand users’ real needs.

• Create the user manual first.
Some organizations have had good success creating their user manuals as a substitute for or supplement to a traditional requirements specification. End users seem to be better able to understand the contents of a user manual than a traditional requirements specification, and requirements elicitation goes more smoothly.

New twists on old sayings
Software engineering advances by periodically reexamining questions that we think we’ve already answered. An ounce of prevention is still generally worth a pound of cure, but some recent developments have improved the “ounces of prevention” at our disposal. I find it encouraging that so many good techniques have emerged in the past few decades.

-------------------
Before We Start
-------------------

Early Plan
Review the plan with the client. Review with the client or project sponsor and walk through the road-map of work. Presumably you did this with them before they agreed to start the project, but do it again anyway.
Point out extreme maximums and minimums for each requirement, corresponding constraints, prerequisites and dependencies.

Startup Conditions
Create clear Startup Conditions Checklist - Explain what each activity and deliverable is.

Black spots - vague requirements
Show examples from past projects so the client will have a picture in their heads of what they’ll be receiving. Call attention to points in the project that are likely to be difficult. Assure the client that this is common, and you’ll guide them through it. Ask them to have patience and a sense of humor while we clarify all project aspects.

Stakeholders
Get a list of everyone who will be involved in any way. Ask the client to provide a list of all people for contact in their project team. Ask them to indicate who should be interviewed as a stakeholder, who has final-decision power, who has all the information, etc.

Gather inspiration.
Monitor the competition and analyze the best solutions on the market.
Begin collecting specification, user manual, marketing brochures of competitive similar solutions —anything that can help to create create an idea for your project.

An Ounce of Prevention: Published in IEEE Software, May/June 2001, pages 5-7