← Back to Resources

Requirement analysis

“If you think good requirements are expensive, try bad ones.”

Somewhere between "we understand who our stakeholders are" (see the Understanding Stakeholders resource) and "let's start coding," there's a step almost every student team wants to rush through: figuring out, precisely, what the system actually has to do. This is requirement analysis, and rushing it is the single most reliable way to end up rebuilding a feature three times.

---

What is requirement analysis?

Requirement analysis is the process of figuring out, documenting, and validating what a system needs to do (and just as importantly, what it doesn't need to do) before you commit to building it. It sits right after you've identified your stakeholders, and it turns "vague wishes from various people" into something concrete enough to design and build against.

It's usually split into two halves:

• Functional requirements — what the system should do. "Users can reset their password." "The system generates a weekly report." These are the features.
• Non-functional requirements — how the system should behave while doing it. Performance ("the page should load in under 2 seconds"), security, accessibility, scalability, availability. These are frequently the ones students forget entirely, and they're often the ones that decide whether a client is actually happy with the result.

Why is this important?

There's an old rule of thumb in software engineering, sometimes attributed to IBM's systems research in the 1980s: the cost of fixing a defect grows by roughly an order of magnitude at each stage of the project it survives to. A misunderstanding caught during a requirements conversation might cost you an awkward five minutes. The same misunderstanding caught after the client sees a finished feature can cost you days of rework, a damaged relationship, and in your case, a much worse grade. The exact multiplier is debated, but the direction is not: the earlier you catch a wrong assumption, the cheaper it is.

Weak requirement analysis is also the quiet cause behind a lot of the pain covered in the Root Cause Analysis resource: those late-stage "requirement changes" your client springs on you are very often not the client changing their mind at all. They're the client finally seeing something concrete enough to realise the requirement was never actually captured correctly in the first place.

The requirement analysis process

Roughly, this breaks down into four stages that you'll usually cycle through more than once:

1. Elicitation — actively drawing requirements out of your stakeholders. Common techniques:
   • Interviews — one-on-one conversations, best for depth and for stakeholders with strong opinions or context.
   • Surveys / questionnaires — good when you need input from many end users at once.
   • Workshops — get several stakeholders in a room together; disagreements surface immediately instead of three weeks later over email.
   • Document analysis — look at what already exists: old systems, spreadsheets, competitor products, existing processes.
   • Observation — watch people actually do the task the system is meant to support. People are notoriously bad at describing their own workflow accurately; watching them do it catches things they'd never think to mention.
   • Prototyping — sometimes the fastest way to find out what someone wants is to show them something wrong and let them correct you.
2. Analysis — take everything you've gathered and look for gaps, contradictions, and ambiguity. Different stakeholders will often give you requirements that quietly conflict. This is where you reconcile them, or escalate the conflict back to the stakeholders rather than silently picking a winner yourself.
3. Specification — write the requirements down in a form your team can actually build from. This might be a requirements document, but very often for student and agile-style projects it takes the shape of user stories and use cases — see the User Stories & Use Cases resource for how to turn a requirement into something buildable.
4. Validation — go back to your stakeholders and confirm you understood them correctly, before you build. This step gets skipped constantly, usually because teams are eager to start coding, and it is the single cheapest insurance policy in the whole process.

Common pitfalls in student projects

• Treating the first thing a stakeholder says as the requirement. "I want a login page with a forgot-password link" is a solution, not a requirement. The actual requirement underneath is usually something like "users need a secure way to recover access to their account." Stating the solution too early can hide better solutions from you. This is exactly the trap the Root Cause Analysis resource is about — treat what you're told as a symptom worth digging into, not gospel.
• Ignoring non-functional requirements until testing, when performance or accessibility problems are much more expensive to fix.
• Writing requirements that are impossible to test. "The system should be user-friendly" tells your future self nothing about whether you succeeded. "A new user can complete sign-up in under 3 clicks without instructions" does.
• Never writing anything down, and relying on memory of a conversation from three weeks ago. Requirements drift in people's memories, including your own.
• Gold-plating — building extra features nobody asked for because they seemed cool. This eats time you don't have and adds complexity nobody wanted.

Tips

• After every stakeholder conversation, write a short summary and send it back to them: "Here's what I understood, let me know if I got anything wrong." This single habit catches an enormous number of misunderstandings early, for almost no cost.
• Distinguish "must have," "should have," and "nice to have" requirements from the start (this is the basis of the MoSCoW method). It makes scope decisions under time pressure much less painful later.
• Keep a running requirements document, even an informal one, that the whole team can see and that updates as things change. A shared understanding beats a perfect one that only lives in one person's head.
• Budget real time for this. It's tempting to treat requirement analysis as a box to tick in week one so you can "get to the real work." It is the real work; the code is just the eventual output of it.

References

Sethi, R. Software Engineering: Basic Principles and Best Practices — covers requirements engineering as a discipline, including elicitation and specification.

Jama Software — A Guide to Requirements Elicitation for Product Teams

Software Testing Help — Top 10 Requirements Elicitation Techniques