Documenting requirements: BRD, FRD, user stories and models

Traditional documents

• BRD (business requirements document): business problem, objectives, scope (in and out), stakeholders, current and future state, high-level requirements, assumptions, constraints, risks, success metrics.
• FRD/SRS (functional requirements document / software requirements specification): detailed functional and non-functional requirements, business rules, use cases, data requirements, screen mock-ups, integrations, reports.

Agile: user stories

Format: As a [user], I want [goal] so that [benefit].

As a loan officer, I want to see all of an applicant's documents on one screen so that I can verify an application in under 10 minutes.

Acceptance criteria (often in Given/When/Then form):

Given an application with all mandatory documents uploaded
When the loan officer opens the application
Then the PAN card, Aadhaar, salary slips and bank statements are shown in tabs
And each document shows its upload date and verification status

Given a mandatory document is missing
When the loan officer opens the application
Then a "Missing: bank statement" warning is shown at the top

Good stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Large stories (epics) are split by workflow step, user type, business rule or data variation.

Use cases

A use case describes an interaction between an actor and the system to achieve a goal: actor, preconditions, main success flow (numbered steps), alternate flows, exception flows and postconditions. Useful for complex flows and for test design.

Modelling

• Process maps / flowcharts and BPMN (business process model and notation) with swimlanes for each role, showing tasks, decisions (gateways), events and hand-offs. Map the as-is (current) process, find pain points (delays, duplicate work, manual steps), then design the to-be process.
• UML: use case diagrams (actors and goals), activity diagrams (flows), sequence diagrams (interactions between components over time), class diagrams (data structures).
• Data models: entity-relationship diagrams; data dictionaries (field names, types, rules, sources).
• Wireframes to clarify screens.

Traceability

A requirements traceability matrix (RTM) links each requirement to its source, design, test cases and status, so nothing is missed and changes can be assessed for impact.

Check yourself

• Write a user story with three acceptance criteria for "apply filter by city" on a job portal.
• What's the difference between a BRD and an FRD?
• Why map the as-is process before designing the to-be process?