23 Doneness
The last step in requirements engineering is determining both the “doneness” of the requirements, and of the product.
23.1. Waterfall
In the Waterfall model, doneness of the requirements means that all of the requirements have very high confidence, and that the requirements gathering-and-documenting process is ready to end, with the Requirements team moving onto their next project.
23.2. Agile
In an Agile project, there are two kinds of “done”, sometimes three.
A requirement may be considered gathered once you know about the requirement. You can then document it, and put that requirement’s document or documentation into the “backlog” (the things yet to do queue), or put it into the “requirements backlog”, to be later refined and moved to the regular backlog.
You may also reach the step in which there are no more requirements to gather and document. That’s when the whole project is done. What “done” means varies from company to company, and within a company, from project to project. In some companies and project, “done” means that the project is completely done, and that the requirements people can go to their next project, and that the developers have one more sprint, and then they go to their next project, and that the QA people have two more sprints to go, and then the project is completely over. In other companies and projects, “done” means that the backlog is completed, and that he project will go into “maintenance” mode, in which minor change requests will continue to come in, and sprints may shorten to as little as four hours, typically with a skeleton crew left on the project, even as low as a fractional developer, meaning one who is assigned to a project less than 40 hours per week.
23.3. Spiral
In the Spiral model, there are also two versions of “done”.
In any one loop around the spiral (meaning a given release cycle), doneness pertains to finishing the requirements set for the release (which relies heavily on prioritization and what the Sales department says will sell), and then completing the release.
All things come to an end, and for each product, there will be a last release, even in successful companies. (Even Apple stopped making Apples, and Microsoft stopped selling MS/DOS.) Sometimes a product comes to the end-of-life point because new sales are not expected to cover the costs of production and marketing, but sometimes because there’s a newer, better product, and the company doesn’t want to split the market. Ray Dolby, talking about that latter reasoning, said it this way: “Put yourself out of business before someone else does”.
23.4. One Last Extra Step
After everything is done, there is often one last step: A retrospective of the whole project to determine what could have been done better, so that the next project might go more smoothly.
23.5. Discussion Questions
- If your experience (if you have any in this regard) do internal projects get to “done”. If so, what percentage?
- Similarly, if you have experience with projects and customers, has “done” gone smoothly, or have there been hangups? If so, what?
