A finance director asks for "a dashboard". Six months later, the team delivers one, and it answers none of the questions the director actually had.
Nobody wrote bad code. The project went wrong in its first weeks, when nobody pinned down what the software was for. Software requirements analysis is the phase that does exactly that, and it is the cheapest place in a project to change your mind.
What is software requirements analysis?
Software requirements analysis is the work of finding out what a software system must do, for whom and how well, and writing it down clearly enough that everyone agrees on it before the building starts.
It sits near the start of the software development life cycle, right after planning has decided that a project is worth doing. Planning answers "should we build this?". Requirements analysis answers "what exactly are we building?". Design, the next phase, then works out how. In a well-run software development process, nothing gets designed or built until this phase has produced an agreed list of software requirements.
This post is part of our series on the phases of the software development lifecycle. It started at the end, with software maintenance, where every shortcut taken early on sends its bill. Here we go back to the beginning, because that is where most of those shortcuts are taken.
Why it matters more than it looks
Is a few weeks of interviews and documents really worth it, when the team could start building? The numbers say yes.
The Project Management Institute's Pulse of the Profession study found that nearly half (47%) of unsuccessful projects fail to meet their goals because of inaccurate requirements management (PMI). Not because of the technology, and not because of the developers, but because the team was building towards the wrong target.
A misunderstanding is also much cheaper to fix on paper than in code. Changing one sentence in a requirements document takes a minute. Changing the same thing after it has been designed, built, tested and released means reopening every one of those steps.
Who takes part in requirements analysis
Requirements analysis is a team effort, and the people around the table matter more than the templates they fill in:
- A business analyst runs the process: plans the interviews and workshops, asks the follow-up questions and turns the answers into requirements everyone can read. On smaller projects a product owner or a senior engineer plays this role.
- The business stakeholders: the people who pay for the system, use it every day or are affected by it, such as finance, operations, customer service or compliance.
- A decision-maker who can settle conflicts and say what goes into the first release. Without one, every disagreement waits for a meeting.
- An architect or senior developer from the development team, who spots early which requirements are expensive, risky or technically impossible, and asks about the things business people forget to mention, such as volumes, integrations and security.
A good business analyst is part translator and part detective. The first answer to "what do you need?" is usually a feature ("a dashboard", "an app"), and the analyst's job is to find the problem behind it.
The three layers of software requirements
Not every requirement is the same kind of statement.
Software requirements come in layers, and keeping them apart is one of the most useful habits in requirements analysis. Each layer answers the one above it, so you can always trace a feature back to the business reason for building it.
Business requirements: why the project exists
Business requirements describe the outcome the organization wants: shorter payment times, fewer manual errors, a new product line, compliance with a new regulation. They rarely mention software at all. They are the yardstick for the whole project: if a feature does not serve one of the business needs, it should have a very good reason to be on the list.
User requirements: what people need to do
User requirements describe tasks from the point of view of the people who will use the system: an accountant approves an invoice, a customer tracks an order, a manager compares regions. Agile teams usually write them as user stories ("As an accountant, I want to approve a matched invoice on one screen, so that I do not chase approvals by email"). This is also where customer requirements live when the users are your customers rather than your staff.
Software requirements: functional and non-functional
The software requirements are the detailed layer the development team builds and tests against. They come in two kinds.
Functional requirements say what the system does: match an invoice to a purchase order, send a reminder after five days, export a report. Non-functional requirements say how well it does it: how fast, how secure, how available, for how many users, on which devices. Non-functional requirements are the ones most often forgotten, and the most expensive to add later, because they shape the software architecture itself. A system designed for 50 users does not become a system for 50,000 by adding a feature.
Whatever the layer, a good requirement is specific enough to test. If nobody can say whether the finished software meets it, it is a wish rather than a requirement.
| Vague requirement | Testable requirement | What changed |
|---|---|---|
| The system should be fast. | Search results appear within 1 second for 95% of searches, with 500 people using the system at once. | A number, a share of cases and a load |
| Make invoicing easier. | An accountant can approve a matched invoice from one screen, with no more than three clicks. | A user, an action and a limit |
| The app must be secure. | Staff sign in with single sign-on and a second factor; customers' card data never touches our servers. | Named controls instead of an adjective |
| Support all browsers. | The last two versions of Chrome, Edge, Safari and Firefox, on desktop and mobile. | A list someone can test against |
| Reports should be flexible. | Managers can filter the monthly report by region, product and sales rep, and export it to Excel. | Which choices, for whom |
The international standard for this work, ISO/IEC/IEEE 29148, covers the processes and the content of requirements for "systems and software products (including services) throughout the life cycle" (ISO). Most teams never read it, and they do not need to. The table above captures its most practical lesson: write requirements someone can check.
The requirements analysis process, step by step
Every team runs software requirements analysis a little differently, but the same five steps appear in almost every project, whether it takes three days or three months.
1. Identify the stakeholders
Start with a list of everyone who will use the system, pay for it, feed it data, receive its output or approve it. Then add the people who are easy to forget: the support team who will answer users' questions, the compliance officer who has to sign it off, the team that runs the software system it must connect to.
A stakeholder discovered in month four brings requirements nobody planned for. A stakeholder discovered in week one is just another interview.
2. Gather the requirements
This step is often called elicitation, because requirements rarely arrive ready-made. They have to be drawn out. The usual techniques:
- Interviews with individual stakeholders, to understand their work and their frustrations in their own words.
- Workshops that bring several groups together, which surface conflicts early: sales wants one thing, finance another.
- Observation: watching people do the job today. The spreadsheet someone keeps on the side is often the most honest requirements document in the company.
- Studying what exists: the current system, its data, reports, support tickets and usage statistics.
- Prototypes and mockups: people react to a picture of a screen far better than to a description of one.
The goal is to understand the business needs behind each request, not to collect a list of features. "We need an export to Excel" usually means "we do the real analysis somewhere else", and that is worth knowing. For a product sold to the public, customer requirements also come from support tickets, reviews and sales calls.
3. Write them down
Software requirements that live only in people's heads change every time someone retells them. Write them down in a form the whole team can read and refer back to.
The format depends on the project. Agile teams keep user stories with acceptance criteria in a backlog. Larger or regulated projects write a software requirements specification (SRS), a structured document that also covers non-functional requirements, constraints and assumptions. Either way, add a glossary: half the arguments in a project come from two departments using the same word for different things.
4. Analyze and prioritize
Now the analysis proper begins. The business analyst checks the requirements for conflicts (two departments asking for opposite behavior), gaps (what happens when an invoice has no purchase order?), duplicates and anything that cannot be tested.
Then comes prioritization, because there is never time and budget for everything in the first release. A common method is MoSCoW: must have, should have, could have and won't have this time. The "won't have" list is as important as the "must have" one. It is how you tell stakeholders, politely and in writing, what they are not getting yet.
5. Validate and agree the project scope
Finally, the project team reviews the software requirements with the stakeholders: is this what you meant, is anything missing, can we build and test it as written? Walking through a prototype or a few concrete scenarios catches misunderstandings that a document review misses.
The result is an agreed project scope: what is in the first release, what is out, and the assumptions behind it. That agreement is what design, estimates and contracts are built on, so it deserves a signature, or at least a clear "yes" in writing.
How long does requirements analysis take?
Less time than most people fear, and more than most people plan.
For a first release of moderate scope, software requirements analysis (discovery and scoping, as we call it) usually takes one to three weeks in our projects, as part of a timeline of about six months from kickoff to launch (see our guide to custom software development). Large, regulated or heavily integrated systems take longer.
The biggest factor is not the size of the system but how quickly the answers come back. Expect to give the team several hours a week of your subject-matter experts' time. A requirements phase stalls when the one person who knows how invoicing really works is too busy to talk.
Requirements in an agile project: an iterative process
Does all this mean writing a 200-page document before anyone writes a line of code? No.
The Agile Manifesto values "responding to change over following a plan", and one of its principles is to "welcome changing requirements, even late in development" (Agile Manifesto). In an agile software development process, requirements analysis is an iterative process: the team agrees the big picture and the first release up front, then details the requirements for each iteration shortly before building it.
What agile does not mean is skipping the work. The questions still have to be answered; they are answered in smaller batches, closer to the moment they matter. The business requirements and the scope of the first release still need agreeing at the start, or the backlog turns into a wish list.
That is also why requirements management does not end when analysis does. Requirements keep arriving: from users after the first demo, from a new regulation, from a competitor's launch. Managing them means recording each one, deciding where it fits in the priorities and keeping everyone working from the same, current list.
Scope creep and other ways requirements analysis goes wrong
Most failed requirements phases fail in one of a handful of familiar ways.
- Scope creep. Small additions arrive one at a time, each reasonable on its own, until the project is twice its original size with the same deadline. The cure is not to refuse change but to make its cost visible: every new request gets an estimate and a place in the priorities before anyone starts on it.
- Features instead of problems. "Add a button that emails the manager" is a feature request. "Managers do not know when an invoice is waiting for them" is the problem, and there may be a better answer than a button.
- Forgotten non-functional requirements. Speed, security, availability and data volumes rarely come up unless someone asks. Discovering them after the design is done is one of the most expensive surprises in software development.
- The missing stakeholder. The team that runs the old system, the auditor, the call center. If they are not asked, their requirements arrive late and loudly.
- Nobody who can decide. When every conflict needs a committee, the analysis drags on for months, and scope creep follows.
- Gold plating. The team adds features nobody asked for, because they seemed like a good idea. They cost the same as requested features and serve no business requirement.
Scope creep deserves a second mention, because it is the most common of all. It rarely comes from bad intentions. It comes from requirements that were vague enough to stretch, which is one more reason to write testable ones.
Tools for requirements management
A small project can manage its software requirements in a shared document and a spreadsheet. As the project and the team grow, most organizations move them into dedicated project management tools, where each requirement can be linked to the tasks, designs and tests that implement it:
- Jira (Atlassian): the most common place for user stories, backlogs and the work that implements them.
- Confluence (Atlassian): a shared wiki for specifications, glossaries and decisions, often used next to Jira.
- Azure Boards (Microsoft): backlogs and work tracking for teams in the Microsoft ecosystem.
- Linear: a planning tool "purpose-built for planning and building products", popular with product teams that want something lighter.
- Jama Connect and IBM DOORS Next: dedicated requirements management platforms for regulated industries, where every requirement must be traced to its tests for an auditor.
The tool matters less than the habit. A requirement written clearly in a simple document beats a vague one in an expensive platform.
How we run requirements analysis at Stratoflow
Every engagement with us starts with a thirty-minute scoping call with an architect, not a salesperson. Bring the person who owns the system or the problem: we come with questions, not slides.
Within a week you get a written ballpark: a range with stated assumptions, the price model and the expected duration. Those assumptions are the first draft of the project scope, written down before any money is committed, so both sides can see what the number is based on. A discovery phase then turns them into detailed requirements, together with your people.
Good requirements also look past the feature list. When a major UK hotel bookings aggregator asked us to fix a search engine that had stopped scaling, we started by studying its detailed usage scenarios and statistics with the client. Those numbers, including the fact that 99% of its 200 million daily queries were read-only, became the requirements that shaped the new design, which now serves 300 million queries a day at 80% lower infrastructure cost (case study).
From then on you see working software every week, and your feedback in the weekly demo shapes the next iteration. Agreed scope changes are priced before the work starts, so the scope can move without the budget drifting out of sight.
Software requirements are the input for everything that follows: the software architecture, the estimates and the test plan. The next post in this series covers the software design phase, where they become a blueprint, and the series continues with software testing and maintenance. If you have a project and want to know what it would take to build, book a scoping call: you will leave with a written view of scope and price model, and an honest answer if we are not the right team for it.