If you are trying to work out how to structure your requirements analysis for the project in front of you, the most useful thing I can offer is not a framework or a definition. It is a set of concrete requirements analysis examples drawn from real sectors, with the friction points left in. Every project I have worked on across 25 years in government, utilities, health, education, and enterprise has had at least one constraint that complicated the work, one stakeholder who pushed back, or one decision that had to be revisited. That is normal. The examples below reflect that reality.
Before diving in, it is worth being clear on what requirements analysis actually involves in practice. It is not just writing down what stakeholders say they want. It is interrogating those statements, identifying gaps and conflicts, and producing something that a delivery team can actually work from. If you want a grounding in the distinction between the types of requirements you will be working with, the article on business vs functional requirements is a useful reference point before you work through the examples below.
Banking and Financial Services: Mobile Banking App
I worked on a requirements engagement for a regional bank that had recently completed a merger. Both legacy institutions had their own mobile banking apps, each with a loyal user base and very different feature sets. The brief was to define requirements for a single consolidated app. The stakeholder group included product owners from both legacy organisations, an IT security lead, and a compliance officer. Within the first workshop, it became clear that the two product owners had fundamentally different views on what the consolidated app should prioritise.
One wanted to carry forward a bill payment scheduling feature that their customers relied on heavily. The other argued that the feature added technical complexity and should be dropped in the first release. I had to facilitate several additional sessions to resolve this, and ultimately the decision came down to customer data: usage analytics showed that bill scheduling accounted for 34% of active sessions on one of the legacy platforms. The feature stayed in scope.
Requirements captured for this project
- Functional requirements: Account balance and transaction history, funds transfers, bill payments with scheduling, and mobile cheque deposit were all defined as in-scope for release one.
- Non-functional requirements: Response time under two seconds for all primary functions at peak load, with 99.9% availability during business hours. These were negotiated upward from an initial draft that set no specific targets.
- Regulatory requirements: GDPR compliance for all customer data held or processed within the app, including explicit consent flows for marketing preferences and data retention rules aligned to the bank’s legal obligations.
- Security requirements: Multi-factor authentication, session timeout controls, and encrypted data transmission were specified as non-negotiable constraints from day one.
The friction here was real and productive. Without it, a high-value feature would have been dropped based on opinion rather than evidence.
Healthcare: Electronic Health Record System
On a regional hospital network project, I was brought in to support requirements analysis for an EHR system rollout across five sites. The existing situation was a patchwork of local systems, spreadsheets, and paper-based records that made cross-site patient care genuinely difficult. The clinical staff I interviewed were exhausted by the current process, but they were also deeply sceptical of anything that would add to their administrative burden.
The point of friction came during a workshop with nursing staff. The initial requirements draft had specified a structured data entry screen for patient observations. The nurses pushed back hard, arguing that the screen layout did not match their workflow and would force them to enter the same data twice. They were right. I revised the requirements after observing two ward rounds and mapping the actual sequence of tasks nurses performed. The final requirements specified a streamlined entry flow that eliminated the duplication, and this became one of the most cited improvements in the post-implementation review.
Requirements captured for this project
- Functional requirements: Patient data entry and retrieval, prescription management, appointment scheduling, and cross-site record access were all specified with workflow context rather than abstract descriptions.
- Compliance requirements: Role-based access controls, audit logging, and data handling standards aligned to relevant patient data privacy legislation were defined with input from the information governance team.
- Usability requirements: Target training time of under two hours for clinical staff was written into the requirements as a measurable acceptance criterion, not just a preference.
- Interoperability requirements: The system had to exchange data with the existing pathology and radiology platforms using standard messaging formats, which required a separate technical elicitation session with the IT architecture team.
Retail and E-Commerce: Omnichannel Platform
A global retailer I worked with wanted to unify its in-store and online customer experience under a single platform. The business case was strong: customers who engaged across both channels spent significantly more. The requirements analysis started well, but engagement metrics after the initial soft launch were lower than projected. I was asked to investigate.
User research revealed the problem clearly. Customers were abandoning the loyalty redemption flow because they had to log in separately on the app, the website, and at the point of sale terminal. Nobody had flagged single sign-on as a requirement in the original scope because it had been assumed to be handled by the platform vendor. It was not. The requirement had to be formally raised as a change, scoped, and prioritised before the next release cycle. It was also a good reminder that assumptions made during elicitation need to be surfaced and tested explicitly.
Requirements captured and revised
- Functional requirements: Unified purchase history, loyalty point earning and redemption, and personalised promotions accessible across in-store, web, and mobile channels.
- Integration requirements: Real-time sync with the inventory management system and point-of-sale platform to ensure product availability was accurate at the point of customer interaction.
- Performance requirements: The platform had to sustain peak traffic equivalent to three times average daily load during promotional events, based on historical data from the previous two peak trading seasons.
- Authentication requirements: Single sign-on across all customer touchpoints, which was added as a formal requirement after the post-launch investigation.
Manufacturing: Automated Inventory Management
A mid-sized manufacturer I supported was experiencing recurring stockouts on critical components, which was stopping production lines. The root cause analysis pointed to manual reorder processes that depended on individual staff members spotting low stock and raising purchase orders. The requirements analysis for an automated inventory system should have been straightforward. It was not.
The warehouse manager was resistant to automation, not because he disagreed with the goal, but because he had been through a failed system implementation two years earlier and had no trust in the IT team’s ability to deliver. I spent time acknowledging his experience, involving him directly in defining the reorder threshold logic, and making sure his team’s knowledge of supplier lead times was built into the requirements rather than left to system defaults. That engagement turned him from a blocker into one of the most useful contributors to the requirements process.
Requirements captured for this project
- Functional requirements: Real-time inventory tracking, automatic reorder triggers at defined stock thresholds, and dashboards showing current stock levels and outstanding purchase orders.
- Scalability requirements: The system had to handle a 40% increase in SKU volume without performance degradation, based on the manufacturer’s three-year growth plan.
- Compliance requirements: Specific handling rules for hazardous materials, including minimum safety stock levels required by regulation, were defined with input from the health and safety team.
- Reporting requirements: Analytics on stock movement patterns, supplier performance, and reorder accuracy were specified to support quarterly procurement reviews.
Government and Public Sector: Citizen Services Portal
I have done a significant amount of work in government digital transformation, and citizen services portals are one of the most politically charged requirements contexts I know. On one engagement with a local authority, the project was initiated to reduce the backlog of paper-based applications for services including planning permissions, benefit claims, and licence renewals. The councillors sponsoring the project wanted a fast delivery. The IT team wanted a phased rollout. The public consultations revealed something neither group had prioritised: mobile accessibility.
The majority of respondents who completed the public survey did so on a mobile device, and a significant proportion indicated they did not have regular access to a desktop computer. This shifted the requirements substantially. What had been framed as a desktop-first portal with a responsive design consideration became a mobile-first build with accessibility compliance as a hard requirement, not an afterthought. The sponsor pushed back on the timeline implications, and we had to facilitate a prioritisation workshop to agree which services would go live in phase one versus phase two.
Requirements captured for this project
- Functional requirements: Online submission and status tracking for tax-related queries, licence renewals, planning applications, and public records requests, with each service mapped to its current manual process before being specified digitally.
- Accessibility requirements: Compliance with WCAG 2.1 AA as a minimum standard, verified through user testing with participants who used assistive technologies.
- Security requirements: Identity verification, data encryption in transit and at rest, and role-based access for council staff processing applications.
- Performance requirements: Real-time application status updates and a target page load time of under three seconds on a standard 4G mobile connection.
Techniques That Adapt Across Industries
Across all five of these projects, the elicitation and analysis techniques I used shifted depending on the context. The table below summarises what worked well in each sector and why.
| Sector | Primary Technique | Why It Worked |
|---|---|---|
| Banking | Stakeholder workshops with usage data review | Resolved opinion-based disagreements with evidence |
| Healthcare | Workflow observation and focus groups | Surfaced workflow pain points that interviews alone would have missed |
| Retail | Post-launch user research and assumption mapping | Identified a missed requirement that had been assumed away during elicitation |
| Manufacturing | Structured interviews with SMEs and threshold logic workshops | Built resistant stakeholder trust by involving him in defining the detail |
| Government | Public consultation and prioritisation workshops | Shifted the solution direction based on actual user behaviour data |
If you are working on requirements elicitation right now and want to go deeper on technique selection, the guide on types of elicitation techniques for the business analyst covers the full range with practical guidance on when to use each one. And if you are at the point of writing your requirements up formally, the article on business requirements analysis covers the specific mistakes that undermine otherwise solid analysis work.
The one thing every one of these projects had in common was that the requirements that mattered most were not the ones that came out of the first conversation. They came from the second or third conversation, from observing actual work, from someone pushing back, or from a post-launch finding that forced a revision. Requirements analysis is not a linear process you complete once and hand over. It is iterative, political, and deeply dependent on your willingness to stay curious when the first answer does not feel quite right.
Frequently asked questions
What is a requirements analysis example in business analysis?
A requirements analysis example is a documented case where a BA identifies, structures, and validates what a system or process must do to meet a business objective. Real examples include specifying functional and non-functional requirements for a mobile banking app, an EHR system, or a citizen services portal. Each example involves elicitation, gap analysis, and stakeholder sign-off rather than simply writing down what people request.
How do you do requirements analysis step by step?
Start by understanding the business problem and the stakeholders who have a view on it, then elicit requirements through interviews, workshops, observation, or document analysis depending on the context. Analyse what you have gathered to identify gaps, conflicts, and unstated assumptions before structuring the requirements into a format the delivery team can use. Validate everything with stakeholders and be prepared to revise as new information surfaces.
What is the difference between functional and non-functional requirements in requirements analysis?
Functional requirements define what a system must do, such as allowing a user to transfer funds or submit a planning application. Non-functional requirements define how well the system must do it, covering performance, security, availability, and usability. Both are essential and need to be captured during requirements analysis, not treated as an afterthought.
How does requirements analysis differ across industries?
The core process is the same but the constraints, compliance obligations, and stakeholder dynamics shift significantly depending on the sector. Healthcare projects carry patient safety and data privacy obligations that shape every requirement, while manufacturing projects often involve operational staff who are sceptical of system change and need to be involved in defining the logic. Government projects frequently surface accessibility and mobile requirements through public consultation that were not in the original brief.
What techniques are used in requirements analysis?
Common techniques include stakeholder workshops, one-to-one interviews, workflow observation, document analysis, focus groups, prototyping, and post-launch user research. The right technique depends on the complexity of the project, the maturity of your stakeholders, and what information you are trying to surface. Most experienced BAs use a combination of techniques rather than relying on a single approach.
Try Ash, Your Virtual BA
If you are working through requirements analysis right now and need to structure what you have gathered into something usable, Ash can help you move faster. Ash is a BA-trained AI assistant that understands the difference between business, functional, and non-functional requirements, knows how to handle conflicting stakeholder input, and can help you produce a structured requirements document from your notes and elicitation outputs. It is built specifically for BA work, not generic content generation. Try Ash Virtual BA and see how quickly you can move from raw elicitation notes to a requirements set you can actually hand over.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.