Requirements Analysis Phase of SDLC: Steps and an Example

The requirements analysis phase is the second phase of the software development life cycle, between planning and design. It takes the project brief and works out what the software has to do, who it's for and what it leaves out, then writes that down in a form engineers can estimate and testers can check.

The example below is the invoicing tool from my walk-through of all seven SDLC phases, built for a made-up plumbing firm of about twelve people. The office manager types each invoice into a Word template and phones the customers who pay late.

What the requirements analysis phase is for

The goal of the requirements analysis phase is to settle what gets built and what doesn't, so design starts from decisions instead of guesses.

People search for requirements gathering and requirements analysis as if they were two phases. I treat gathering as the first step of analysis. The analysis is deciding which asks the project will meet, in what order, and how you'll know each one works.

Two kinds of requirement come out of it. Functional requirements say what the software does, like turning a finished job into an invoice. Non-functional requirements say how well it does it: speed, security, who can see what, which devices it runs on.

I've seen plenty of teams write the first kind and forget the second.

Inputs and the deliverable

The requirements phase starts from the project brief and ends with a requirements document and a ranked backlog of user stories, each with acceptance criteria.

Three inputs go in:

• The brief - the problem, what's in and out of scope, a rough budget and one measure of success.

• The users - time with the people who'll use the software every day, who often aren't the people paying for it.

• Today's workaround - the spreadsheet, template or paper form in use now. It shows the real requirements better than an interview does.

The requirements document is the reference: goals, users, scope, what's out, non-functional requirements and open questions. I'd write the full business requirements document only when a contract or a regulator will read it.

The backlog is what the team works from. It's ranked, the top items are detailed enough to build, and the rest stay rough until they get close, which is what I'd call a healthy backlog.

Who leads requirements analysis and who takes part

The product manager leads requirements analysis, or the product owner on a Scrum team, but the phase needs several other people in the room.

The Scrum Guide makes the product owner accountable for effective Product Backlog management, including creating and ordering backlog items, and says the product owner is one person, not a committee.

Plenty of companies split the work between the product manager and the product owner, with the PM on the why and the PO writing the stories. Either way, one name owns the ranking.

The others:

• Users say what the work is actually like.

• The sponsor says what the money is for, which is often a different answer.

• Engineering says what's feasible and what it costs, by estimating.

• QA reads every acceptance criterion and asks how they'd test it.

• A designer sits in on the user interviews, because design starts the day this phase ends.

The four steps of requirements analysis

Requirements analysis runs in four steps: elicit, analyze, specify and validate. Validation usually sends something back to the start.

The diagram as text

• The project brief goes in: the problem, scope, a rough budget and one measure of success.
• Elicit: watch the users do the task.
• Analyze: sort what you heard, find conflicts and gaps, and rank.
• Specify: user stories with acceptance criteria, plus the out-of-scope list.
• Validate: the users read the stories back and the engineers estimate the top of the backlog. A story nobody can estimate goes back to elicitation.
• The phase hands design a requirements document and a ranked backlog.
• In agile the analysis carries on every sprint.

1. Elicit

Elicitation means getting the requirements out of the people who have them. Interviews help. Watching someone do the task helps more, because people describe the process they think they follow, and a field visit shows you the one they actually follow.

Ask about the last time they did the task, not what they'd like the software to do.

2. Analyze

Analysis sorts what you heard. Split functional from non-functional, find the asks that conflict, find the gaps nobody mentioned, and drop anything that doesn't move the brief's measure of success.

Then rank. The Agile Business Consortium's MoSCoW guide sorts requirements into Must Have, Should Have, Could Have and Won't Have this time. Its test for a Must is to ask what happens if the requirement isn't met. If the answer is to cancel the project, it's a Must.

It recommends keeping Must Haves to typically no more than 60% of the effort. It calls a plain 1, 2, 3 ranking weaker, since it handles items of similar importance less well and invites long arguments over whether an item belongs one place higher or lower.

I'd still rank the top ten strictly. Having that argument with the sponsor now costs less than having it mid-sprint.

3. Specify

Specification writes each requirement down so it can't be read two ways. For most teams that means a user story with acceptance criteria.

I'd write the criteria as Given-When-Then. Martin Fowler describes it as an approach Daniel Terhorst-North and Chris Matts developed as part of behavior-driven development: the given part is the state before, the when part is the behavior, and the then part is the change you expect.

Write the out-of-scope list here too, with a reason next to each item. A line without a reason gets argued again at every review.

4. Validate

Validation checks that the spec says what the users meant and that the team can build it.

The users read the stories back in their own words, and the engineers estimate the top of the backlog.

Bill Wake's 2003 article on INVEST says a good story is estimable, and that a story the team doesn't understand is hard to estimate. A story nobody can estimate goes back to elicitation.

Requirements analysis in agile vs waterfall

In waterfall, requirements analysis happens once and ends in a signed baseline; in agile, the first pass covers only the first release and the analysis carries on every sprint.

A waterfall spec tries to be complete before design starts. After sign-off, a change goes through change control, which is slow on purpose. I'd only run requirements that way for a spec that is genuinely known and stable, which is where I draw the line between agile and waterfall anyway.

In a traditional project, the MoSCoW guide says, every requirement is treated as a Must Have and the end date typically slips when problems come up. DSDM, the method behind the guide, fixes time, cost and quality and negotiates the features instead.

Scrum's own guide calls backlog refinement an ongoing activity that breaks items into smaller, more precise ones. The Agile Manifesto's principles say business people and developers must work together daily throughout the project.

The invoicing tool at this phase

For the invoicing tool, requirements analysis turns a one-page brief into a short requirements document and a ranked backlog, with every story tied to the brief's one measure of success, days from job complete to payment received.

The PM spends a morning beside the office manager while she bills last week's jobs. She copies each customer's name and address from the job sheet into the Word template, works out the tax, saves a PDF and attaches it to an email. The retyping is what she wants gone.

The owner, who is the sponsor, wants to see at a glance who owes the firm money. Both asks serve the measure of success, so both stay.

The top of the backlog comes out in this order:

1. "As the office manager I can turn a completed job into an invoice without retyping the customer's details."

2. The owner sees which invoices are unpaid and for how long.

3. A customer pays online from a link in the invoice email.

The out-of-scope list keeps the brief's exclusions, payroll and accounting. It adds two things the office manager asked for, recurring invoices and an automatic reminder when an invoice goes overdue. Both wait for a later release, because the first should show whether faster invoicing alone moves the number.

The top story's acceptance criterion reads:

• Given a completed job with the customer's details on file

• When the office manager creates its invoice

• Then the details are filled in, the right tax rate is applied, and the invoice goes to the customer by email as a PDF

One non-functional requirement makes the document: only office staff can see customer details and invoices.

The office manager reads the stories back, and the engineers estimate the top ones. A story about part payments comes back with no estimate, because nobody knows whether it means deposits or installments. The office manager answers in a minute, deposits on large jobs, and it becomes a small story below the payment link.

Common mistakes in requirements analysis

The requirements analysis mistakes I see most often are writing down solutions instead of problems and calling everything a Must.

• Solutions as requirements - "Add a dashboard" is a design decision. "The owner can see who owes money each Monday" is a requirement, and it leaves the designer room.

• Everything is a Must - If every item is a Must, nothing is ranked.

• Words nobody can test - "Fast" and "user-friendly". Replace each with a number or cut it.

• No out-of-scope list - Anything left unwritten counts as in scope to someone.

What AI changes in the requirements phase

AI makes first drafts of user stories and acceptance criteria cheap, so the work in this phase moves from writing requirements to checking them.

Two of the prompts Atlassian suggests in its guide to Rovo in Jira suit this phase: brainstorm edge cases to test for during QA, and give feedback on where a work item description could be more clear. Atlassian warns on the same page that the quality, accuracy and reliability of AI output may vary.

I'd let a model draft, but I get more out of it as a critic. Give it the stories and ask what's ambiguous and what's missing. In my experience it finds edge cases fast, like a customer with no email address or a job billed to two people.

It can't do the ranking. That depends on what the users showed you and what the sponsor will pay for.

When the feature you're specifying is itself AI, a requirement like "drafts accurate replies" can't be tested. It needs a quality number and an efficiency number, measured on a labeled set of real examples and signed off before the build starts, the way I'd pin the success metrics of a first AI project.

A requirements analysis checklist

Before the requirements phase hands over to design, check that:

• Every story traces back to the brief's measure of success.

• QA can write a test from every acceptance criterion.

• The engineers have estimated the top of the backlog.

• The out-of-scope list gives a reason for each item, and the sponsor has read it.

• Non-functional requirements are written down, with numbers.

• The users have read the stories back and recognize their own work.

• Each open question has an owner and a date.