I’m admitting it in public – I don’t finish all of my requirements documents! Is that shocking? When you think about the purpose of requirements, this should not be a surprise. Requirements describe a business need in enough detail for a delivery team to build a solution.
My favorite saying related to agile is “just enough” requirements. In traditional, waterfall methodologies there was an assumption that requirements could be “finished” and, after signoff, would not be changed. This was virtually impossible, but we tried time and time again to create a “complete” requirements document. Let’s think about why finishing is not so important.
Models are Always Incomplete or Imperfect
Models are often used for requirements: data models, process models, business models all are extremely valuable in visualizing business needs and facilitating discussions about the details of each need. But a model by its very nature is simply a representation of a business or process. It never perfectly reflects all of the complexity of the underlying business. When a model stops facilitating better understanding, stop working on it.
Solution Requirements
Solution requirements include screen designs (e.g. mockups, wireframes) which are used to confirm agreement about the solution look and feel. But has your final product ever ending up looking exactly like your screen design? No, because as your development team builds the solution, they have ideas for improvements and may find some of the suggested design components are not efficient or technologically feasible. Draft screen designs as simply and efficiently as possible (maybe just sticky notes on a flip chart). You probably don’t have to revise them as the design changes and once the solution has been built, there is no reason to update the solution requirements. That would be a waste of time. More unfinished, yet useful, requirements.
Finishing is Overrated When it Comes to Requirements
Some models and requirements documents will be used as system documentation for future enhancements, these are useful to finish. But anything that will be discarded after the product is built may not need to be finished. It feels wrong to leave a model or document uncompleted, but once you get the value from it, let it go. Use diagrams, models, and text to clarify communications, facilitate discussions, and show the delivery team the needs and solution ideas and then tweak and adjust the coded solution as it evolves to a valuable product for your organization.