If you are currently sitting with a list of requirements and trying to work out whether something is a business requirement, a functional requirement, or a technical requirement, you are not alone. Sorting out the distinction between business vs functional vs technical requirements is one of those tasks that sounds straightforward until you are actually doing it on a live project with stakeholders pulling in different directions. I have been in that position more times than I can count, and the confusion almost always costs the project something: time, trust, or scope discipline.
The framework below is the one I use in practice. It is not theoretical. It is the result of working through this problem on real projects in government, health, utilities, and education over 25 years, including one project where getting the levels wrong nearly derailed a platform selection decision entirely.
The Three Levels and What Each One Actually Does
Business Requirements
Business requirements describe what the organisation needs to achieve and why. They are written in business language, not system language. They capture intent, context, and the user or group affected. A business requirement does not say anything about how a system will work. It might say that clinical staff need to deliver remote services to clients in regional areas without requiring additional hardware at either end. That is a business requirement. It tells you the outcome needed. It says nothing about platforms, protocols, or integrations. Business requirements are owned by the business sponsor or senior stakeholder and documented by the BA. They form the foundation for everything that follows. If you want to go deeper on how to elicit them properly, the article on eliciting business requirements covers that process in detail.
Functional Requirements
Functional requirements describe what the solution must do to meet the business need. They translate business intent into specific, observable behaviours. A functional requirement might state that the platform must allow a clinician to launch an assessment tool from within the session interface without switching applications. That is testable, specific, and traceable to the business requirement about simplicity and remote delivery. Functional requirements sit in the middle of the hierarchy, and in my experience this is where the most damage happens. They are close enough to delivery that people assume they understand them, but abstract enough that misinterpretation is common. The BA typically owns this layer, and it is where most of the elicitation, refinement, and negotiation time is spent. For practical guidance on writing them in document form, the functional requirements document example is worth reviewing alongside this article.
Technical Requirements
Technical requirements describe how the solution must be built, hosted, secured, or integrated to satisfy the functional and business needs. They answer the question: what constraints and specifications must the implementation meet? A technical requirement might state that all data must be encrypted in transit and at rest, hosted within a specific geographic region, and compliant with ISO 27001. These are not things the business expressed directly. They are derived from the business requirements when you interrogate the non-functional implications, the regulatory context, and the integration landscape. Technical requirements are typically owned by solution architects or ICT governance teams. My role as a BA is not usually to write them, but to ensure they are captured, that they are traceable to the functional and business requirements above them, and that stakeholders understand the constraints they impose. For more on this, the non-functional requirements guide covers the overlap between technical and non-functional requirements in detail.
How the Three Levels Relate to Each Other
| Level | What it answers | Language used | Typical owner | Example |
|---|---|---|---|---|
| Business requirement | Why and what outcome | Business language | Sponsor / senior stakeholder | Clinicians must be able to deliver remote assessments without additional hardware |
| Functional requirement | What the solution must do | System behaviour language | Business analyst | The platform must allow assessment tools to launch within the session interface without switching applications |
| Technical requirement | How it must be built or constrained | Architecture and compliance language | Solution architect / ICT lead | Data must be encrypted in transit and at rest and hosted in-country on ISO 27001 certified infrastructure |
The relationship between these levels is vertical. Business requirements sit at the top and generate functional requirements. Functional requirements generate technical requirements. If you cannot trace a technical requirement back through a functional requirement to a business requirement, it is worth asking whether it belongs in scope at all. A requirements traceability matrix is the practical tool for maintaining that linkage throughout the project lifecycle.
A Worked Example: Platform Selection for Organisation A
I worked on a project for Organisation A, a large education body delivering allied health services to students across metropolitan and regional schools. The project involved selecting a telepractice platform to replace a patchwork arrangement: a general-purpose video conferencing tool, manual use of third-party assessment software, and multiple devices per session. The business requirements were clear from the outset. Clinicians needed to deliver standardised assessments remotely, with a setup simple enough to work reliably in low-bandwidth environments, and compliant with data privacy obligations. Those requirements came directly from the allied health service leads and the ICT governance group.
When I started translating those into functional requirements, the first point of friction appeared. The ICT team pushed back strongly on the idea of introducing a new platform. Their position was that the organisation already had a collaboration tool licensed across the enterprise and that a purpose-built clinical tool was an unnecessary cost. On paper, this was a reasonable argument. The licences were paid for, the team was familiar with the tool, and deployment was already complete. The problem was that the functional requirements told a different story once I had worked through them with the clinical leads.
The assessment tools clinicians needed required integration at the session level, not manual coordination between separate applications. The session workflow using the existing tool required over nine steps and multiple devices, which was a direct barrier to the business requirement about simplicity and reliability in regional settings. The clinical requirement for test fidelity controls, including disabling self-view and tracking response behaviour, could not be met by a general-purpose tool. None of that was speculation. It came from the functional requirements documentation, which I had worked through carefully with the clinicians before the ICT team’s objection surfaced.
I did not dismiss the ICT team’s concern. Cost and familiarity are legitimate stakeholder positions. But once the functional requirements were documented and mapped to the business outcomes, the evaluation became much more transparent. The governance group could see that the lower upfront cost of the existing tool came with higher operational cost, greater support burden, and real equity risk for students in regional settings. The technical requirements, including data residency in-country, end-to-end encryption, and ISO 27001 certification, then became the final layer. These were derived from the business requirement for privacy compliance and the functional requirement for secure session management. The technical team confirmed which platforms could meet them, and that confirmation closed the loop from business need to implementation constraint.
The ICT team’s position had to be formally revisited at governance level. That was uncomfortable, but it was the right outcome. The decision was revised in favour of the purpose-built platform, justified by the functional and technical evidence rather than clinical preference alone. The requirements hierarchy did what it is supposed to do: it made the decision defensible.
Common Mistakes Worth Avoiding
- Writing functional requirements as business requirements. If your business requirement says the system must send an automated email, you have already jumped a level. Back up and ask what outcome the business actually needs. The email is a solution choice, not a need.
- Letting technical requirements drive functional ones. This happens when an ICT team presents constraints before requirements are fully defined. Technical constraints are real, but they should shape implementation, not replace requirements thinking.
- Leaving the functional layer empty. Some projects go straight from a business case to a technical specification. The functional requirements layer is where user needs are made concrete. Skipping it is where misunderstandings get built in.
- Mixing all three levels in a single document without labelling them. In smaller projects this is tempting, and it works up to a point. But when you mix levels without labelling them, you create confusion about what has been agreed and at what level of detail.
- Assuming ownership is fixed and exclusive. In practice, BAs often help write functional requirements that touch on technical territory, and technical teams often surface business constraints. Ownership is about accountability for quality and sign-off, not about who types the words.
How Agile Changes the Picture
In agile delivery, these three levels do not disappear. They travel differently. Business requirements often live in epics or outcome-based objectives. Functional requirements are expressed through user stories and acceptance criteria. Technical requirements appear as non-functional constraints attached to stories or as architectural decisions recorded in a backlog or decision log. If you want to understand how user stories relate to this hierarchy in practice, the article on how to write user stories and acceptance criteria is a useful companion read.
The BA’s job in an agile context is to make sure that the intent at each level is not lost as work moves from sprint to sprint. It is easy for a team to build something that satisfies the user story but drifts from the original business intent. Keeping that vertical traceability alive, even informally, is part of what makes BA work genuinely valuable in agile environments rather than just process overhead.
Getting the distinction between business, functional, and technical requirements right is not an academic exercise. It is the mechanism that lets stakeholders agree at the right altitude, gives developers something solid to build against, and means the final solution can actually be traced back to a real business need. When I have seen projects go wrong in this area, it is almost never because people did not know the theory. It is because the middle layer was skipped, the levels were blurred in a single document, or a stakeholder pushed a technical constraint into the requirements conversation before the functional picture was clear. Keep the hierarchy visible, keep each level owned, and you give yourself and your project team a fighting chance of building the right thing.
Frequently asked questions
What is the difference between business requirements and functional requirements?
Business requirements describe what the organisation needs to achieve and why, written in business language without reference to systems. Functional requirements describe what a system or solution must do to meet that need, written in specific and testable behaviour language. Business requirements are outcome-focused; functional requirements are capability-focused.
What are technical requirements in business analysis?
Technical requirements define how a solution must be built, hosted, secured, or integrated to satisfy the functional and business needs. They cover things like encryption standards, data residency rules, performance thresholds, and platform compatibility. They are derived from functional and business requirements and are typically owned by solution architects or ICT leads.
Who is responsible for writing functional requirements, the BA or the developer?
Functional requirements are typically written by the business analyst, working with input from stakeholders and subject matter experts. Developers use them as the basis for design and build decisions. In agile teams the boundary is less formal, but the BA is usually accountable for ensuring functional requirements are clear, complete, and testable.
Can a requirement be both functional and technical?
Yes, sometimes. A requirement such as data must be stored in-country sits at the boundary between functional and technical. What matters in practice is that the requirement is captured, attributed to a business need, and assigned a clear owner rather than labelled with perfect precision.
How do business, functional, and technical requirements map to agile user stories?
In agile delivery, epics typically represent business requirements, user stories represent functional requirements, and non-functional or architectural constraints represent technical requirements. The labels change but the hierarchy remains the same. BAs help ensure user stories can be traced back to business outcomes and forward to technical constraints.
Try Ash, Your Virtual BA
If you are working through a requirements list right now and trying to sort out which level each item belongs at, Ash can help you think it through. Paste in your requirements, describe your project context, and Ash will help you identify whether you are working at the business, functional, or technical level, spot what might be missing from each layer, and flag anything that looks like a level mismatch before it causes problems downstream. Try Ash Virtual BA and get your requirements structured with confidence.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.