A business requirement is a formal document that addresses the need of the stakeholders for the project or product. There is no standard format to present the business requirement. However, it should cover the product or project description in enough detail to discuss, analyze, document and validate.
A business requirement can be presented in any of the following ways
- A table or a spreadsheet
- A diagram (workflow)
- A graph
- A model ( entity-relationship diagram)
- A prototype or simulation
- A structured sentence or text template
How to organize and present a business requirement
Step 1) Categorize the requirements
Step 2) Gather and arrange requirements in a logical order. So when stakeholders review the requirements, it is easy to navigate and also identify missing items.
Step 3) Prepare a list of the requirements that is meant to be reviewed by specific stakeholders.
For example, if a stakeholder is from technical background then he would like to know only the technical aspect of the product
Step 4) If tracing requirement to each other is difficult then use unique identifiers, ease in traceability.
Step 5) In certain scenarios, you might have to present same requirement in different ways for different stakeholders. For example, one stakeholder prefers a graphical format while other prefers a structured sentence format
Step 6) Prepare a table of content for all the requirements, it helps stakeholder to easily track requirements
Step 7) Use tools that help in presenting and categorizing the requirements
Step 8) In your requirement document, remove all unnecessary requirements, and organize requirement documents by process flow
Step 9) Map the requirements you have gathered to a particular step in a process flow, this will help reviewers to relate requirement to process flow
Step 10) Use a table for presenting complex requirement. Use bullet points to highlight the key aspect of requirement
Useful tips for presenting requirements
For better presentation and tracking of requirements for stakeholder, here are some tips that might be helpful to BA.
- Categorizing requirement is time-consuming and may not be feasible for every organization to create new category each time. For best practice, it is recommended that there should be a standard set of categories which can be commonly used by BAs, stakeholders, subject experts and technical teams
- Your requirement should be prepared in context to your audience. Understand who are the key players, influencers and decision makers. (Stakeholders, technical staff, developers, etc.)
- Define one requirement at a time. Each requirement should be atomic
- Avoid ambiguity by avoiding acronyms like etc., approx., and so on
- Do not refer to a requirement that is yet to be defined
- Avoid duplicate and contradictory statements
- Break complex requirement into manageable and reviewable points
- Avoid describing how the system will do something only mention what system will do
