Documenting requirements

Once you're done with the steps described previously, it's time to refine all the requirements you've gathered, but putting them in a single document is impractical because they typically consist of many artifacts: architecture and workflow diagrams, wireframes, spreadsheets, checklists and other forms of specialized documentation.Requirements are produced and consumed by all stakeholders, and a broad set of them will need to read your document. This means that you should write it for the target audience so that it brings value for people of various technical skills from customers, salespeople, and marketers, through designers and project managers, to software architects, developers, and testers.Sometimes it makes sense to prepare two versions of the document, one for the people closest to the business side of the project, and another, a more technical one, for the development team. However, usually, it's enough to just have one document written...