Key points
- Business requirements definition is the stage, before any system gets built, where you clarify "what do we want to solve, from a business standpoint?"
- Before deciding what the system should do, you first organize the problems and goals of the business itself.
- Interviews and business flow diagrams feed into a document called the "business requirements document."
What are "business requirements"?
Business requirements aren't "features the system should have" — they're the business side's wishes and goals: "what problem do we want to solve?" and "what do we want to achieve?"
For example, "we want to cut the time from order to shipment in half" or "we want to eliminate mis-shipments caused by data-entry errors" are both business requirements. At this stage, "what kind of system to build" hasn't been decided yet.
Teacher Pochi's hintIt's like telling a contractor, before any renovation begins, "our family is growing so we want more rooms" or "we want more storage so it's easier to keep tidy" — communicating how you want to live. The specific fixtures haven't been decided yet.
Where it fits within upstream process
Business requirements definition is the very first activity in upstream process. The purpose it settles here — "why are we building this system?" — becomes the foundation for every stage that follows.
📝Business requirements definition
→
⚙️System requirements definition
→
🖥️Basic design
Why interviews matter
Business requirements definition depends heavily on interviewing the people who actually do the work day to day. Those people often haven't fully articulated what's really bothering them, so an SE needs to keep asking questions to draw out the real problem underneath.
Teacher Pochi's hintIt's similar to a doctor who doesn't stop at "where does it hurt?" but also asks "since when?" and "when does it hurt most?" to track down the cause. What matters is digging past the surface-level request to the real problem behind it.
The role of business flow diagrams
In business requirements definition, you draw out and compare the current business flow ("As-Is") with the flow you're aiming for once the system is in place ("To-Be").
📄Current process
(As-Is)
🔍Identify problems
✨Ideal process
(To-Be)
Putting it into a diagram prevents misalignment among stakeholders and makes clear exactly what needs to improve, and how.
Deliverable: the business requirements document
The results of the interviews and business flow diagram analysis are compiled into a document called the "business requirements document."
📘 What goes in the business requirements document
Business goals
Current problems
The ideal business process
Scope of what will be systematized
This document becomes the foundation for the "system requirements definition" that follows.
Practical pitfalls to watch for
Taking a request at face valueBehind a vague ask like "make the system easier to use" is usually a more specific problem — dig for it, or you'll end up with requirements that miss the point.
Talking to only one stakeholderThe way work actually gets done often varies by team, so interviewing just one person risks missing gaps or requests that conflict with each other.
Use a method like KJ to organize inputWriting down every point raised during interviews on sticky notes, then grouping the related ones, makes it easier to surface the underlying issue.
Summary
Business requirements definition is the starting point of upstream process — the stage where you clarify "why are we building this system?" Leave this vague, and the system requirements definition and design that follow will drift as well.
Related topics:
🏠 Back to top
Learn IT Fundamentals with Teacher Pochi