Requirements documents fail in two ways. Some are so vague that engineers have to guess. Others are so long that nobody reads them.
I have written requirements as a business analyst and reviewed them as a product leader. The best ones separate the why from the what and keep both short.
How I split them
- The BRD explains the business problem and the outcomes
- The PRD describes what the product will do
- Functional requirements say what the system does
- Non-functional requirements set limits on speed, security, and scale
- Acceptance criteria make all of it testable