What are the best practices for documenting and managing business requirements?

Before this is the ideation phase, where an idea to solve a problem or meet a need is born. Sometimes a need comes out of external necessity to meet changing conditions, and other times it is more organic or part of a deliberate innovation strategy. Capturing high-level information about the idea and how it came about can be useful for future reference. Also, any project charter, business case or similar document should be a living document that is subject to change control like the other documents. If the need, idea, potential benefits, costs, or any other notable item changes and materially affects the document, it should be updated and, if appropriate, re-approved or revalidated to ensure the project remains the best use of resources.

Ensure business requirements are clear, straightforward, and focused on a single aspect whenever possible. As you iterate and review timelines, some requirements may need to be moved out of scope. If a single requirement combines multiple needs, it can create problems during revisions or changes especially in cases where you are numbering requirements and associating them to related functional specifications in a waterfall approach.

Except for the first step, which is started to initiate the project (and should be reviewed and if necessary repeated at majoe project milestones or changes), all the other steps mentioned are not necessarily sequential, and may not be in the order suggested. Don't be distracted but the numbering of the steps or the suggestion that this is the 'final' step; requirements usually should be documented and managed at the same time as they are elicited. Trying to apply requirements management as an afterthought is haphazard at best; in larger, more complex projects, the requirements management framework often needs to be defined before the substantial requirements gathering and documentation begins.

As important as best practices are for reducing the instances of the pitfalls mentioned, human nature and varied experiences and perspectives mean that two people can read the same requirements documents and come to very different conclusions. Depending on the project, sufficient requirements documentation to allow a working prototype or minimum viable product (MVP) to be developed at high speed may be the most practical option. However, a prototyping or MVP approach may not be not suitable in all situations; for example, any software that human lives depend on will usually need the utmost requirements documentation and testing as part of suitable risk mitigation standards and compliance with applicable laws or industry regulations.