Skip to content

Lesson 1 — Requirements and Scope Management

At a glance

  • Module: 05 — Scope & Requirements Management
  • Level: Intermediate
  • Estimated time: 45 minutes
  • Example project: the analytics dashboard and the LMS

Learning objectives

By the end of this lesson you should be able to:

  1. Distinguish functional from non-functional requirements, and explain why non-functional requirements are usually the harder problem.
  2. Select an elicitation technique that suits a given stakeholder group.
  3. Rewrite a vague requirement as a statement that can be verified.
  4. Recognise scope creep and gold plating, and respond to each proportionately.

Prerequisites

Introduction

Ambiguous scope is the most reliable way to make a project unhappy. Everyone agrees on what "the system" will do, discusses it in words that mean different things to different people, and discovers the disagreement months later when it is expensive.

Scope management is the discipline of making the boundary explicit: what is included, what is excluded, and how you will know whether something has been delivered. It is less about writing documents than about removing ambiguity at the point where it is cheapest to remove.

1. Functional and non-functional requirements

A functional requirement states what the system must do. A non-functional requirement states how well it must do it — quality attributes that constrain the whole system.

Type Example Failure looks like
Functional Students can submit an assignment file Feature is missing
Non-functional A submission completes in under 5 seconds at exam-period load Feature exists but is unusable when it matters

Non-functional requirements are harder for three reasons: they are cross-cutting (a performance budget applies to everything), they are easy to state vaguely ("the system must be fast"), and they are often the real reason a project fails. A system that has every feature and collapses at peak load has met its functional requirements.

Common categories worth checking on every project: performance, capacity, security, accessibility, availability, maintainability, and regulatory compliance.

Public service information system (illustrative)

The public service information system is mostly content and forms — a modest functional scope. Almost all of its difficulty is non-functional: accessibility to a legal standard, availability on low-end devices, and clarity for a general audience. A team that plans only the functional scope will underestimate the project badly.

2. Eliciting requirements

Different stakeholder groups need different techniques. Choosing badly produces requirements that are technically complete and practically useless.

Technique Works when Fails when
Interviews Few, knowledgeable stakeholders You need consensus, not opinions
Workshops Conflicting views must be resolved Participants cannot decide anything
Observation The real process differs from the described one Work is infrequent or sensitive
Document analysis Rules are written down (policy, regulation) The documents are out of date
Prototyping Users cannot articulate what they want The prototype is mistaken for the product

Observation is the most under-used. People routinely describe a process that is not the process they follow; watching once reveals more than three meetings.

3. Writing verifiable requirements

A requirement is useful only if you can test it. The test is simple: can two people independently agree on whether this is met?

Vague Verifiable
"The dashboard should load quickly" "The dashboard's default view renders within 2 seconds for a dataset of up to one million records"
"Students should find events easily" "A student can locate an event by title or date in at most two interactions from the home page"
"The system must be secure" "All API access requires authentication; sessions expire after 30 minutes of inactivity"

Each rewrite names a subject, a condition, and an observable outcome. That is what makes it checkable, and checkable requirements are what acceptance criteria are built from.

4. Scope creep and gold plating

Scope creep is uncontrolled growth in scope — usually accepted one small request at a time, without any adjustment to time or cost. Gold plating is the team adding quality or features nobody asked for.

Both are dangerous for the same reason: work is added without agreement, so the plan silently becomes wrong.

The proportionate response to a scope request is not refusal. It is to make the trade-off explicit and let the person who owns the priorities choose: add it and drop something, add it and move the date, or do not add it. Refusing outright damages relationships; absorbing it silently destroys the plan.

Key terms

Term Meaning
Requirement A condition or capability the system must satisfy
Functional requirement What the system must do
Non-functional requirement How well it must do it — a quality attribute
Acceptance criteria Testable conditions a deliverable must meet to be accepted
Elicitation Discovering requirements from stakeholders and evidence
Scope baseline The approved scope statement, WBS, and dictionary
Scope creep Uncontrolled incremental growth in scope
Gold plating Adding unrequested features or quality

Worked example

Task: turn a vague request into verifiable requirements. The stakeholder wording is realistic; the project is the illustrative analytics dashboard.

Step 1 — Capture the request verbatim. The planning office says: "We need the dashboard to be fast and easy to use, and it should show everything that matters."

Step 2 — Separate what is knowable from what is not. "Fast" and "easy to use" are non-functional and untestable as stated. "Everything that matters" is not knowable yet — that is an elicitation problem, not a specification problem. Do not pretend otherwise.

Step 3 — Replace vagueness with conditions. For "fast": the default view renders within 2 seconds for up to one million records. For "easy to use": a new user can locate a named measure in at most two interactions without training.

Step 4 — Resolve the unknowable by eliciting, not guessing. Instead of listing measures, run a prototype session: show three candidate measures and ask which one would change a decision. The requirement becomes the dashboard must support a defined set of measures that the planning office has confirmed against real decisions, with the set explicitly revisable.

Step 5 — Write the acceptance criteria. For the refresh requirement: given a completed nightly load, the displayed figures reconcile with the source system for a sample of 20 records. Now two people can independently agree whether it is met.

Step 6 — Record what is excluded. State explicitly that export, alerting, and historical trends are out of scope for the first release. The exclusions are what prevent the second round of "but I assumed".

Common misconceptions

“Non-functional requirements can wait”

They cannot, because they constrain the design. Performance, security, and accessibility targets chosen late mean rebuilding work that was already correct for the wrong targets.

“More requirements mean a better specification”

A long list of unverifiable statements is worse than a short list of verifiable ones. Length is not completeness; checkability is.

“Refusing scope changes protects the project”

Refusal makes scope a fight rather than a decision. The protection comes from making the trade-off visible, so that the person who owns priorities makes the choice knowingly.

Practical activity

Rewrite ten requirements. Take a feature area from an example project — and if you do not have one, invent a plausible stakeholder request in a single sentence.

  1. List five functional and five non-functional requirements.
  2. Mark every one that is currently unverifiable, then rewrite it so two people could agree on whether it is met.
  3. Pick one and write its acceptance criteria.
  4. List three exclusions that a reasonable stakeholder might assume were included.

What "good" looks like: at least four requirements that had to be rewritten, and exclusions that someone would genuinely have objected to. Label any invented detail as illustrative.

Self-assessment

  1. Why are non-functional requirements often the real reason a project fails?
  2. A stakeholder says the dashboard should be "fast". What is your next question, and why?

  3. A sponsor asks for one extra feature late in the project. What is the proportionate response?

  4. Apply it — LMS acceptance. One requirement in the signed-off list reads: “The system must be responsive and user-friendly for students and staff.” The project is at acceptance, and the teaching office and the vendor disagree about whether it has been met. Both are reading the same sentence.

    Hint: A strong answer gives a measurable threshold, names how it will be checked, and says what must be agreed before the work is done rather than at acceptance.

Show answers
  1. Because they are cross-cutting, usually stated vaguely, and invisible until the system is under real conditions. A team can deliver every functional requirement and still produce a system that fails at peak load, excludes users who rely on assistive technology, or cannot be secured — and each of those is a failure of a non-functional requirement.
  2. "Fast for what, at what data size, on what connection?" Speed is only meaningful relative to a workload and a threshold. Without that, the requirement cannot be verified and cannot constrain any design decision — so it will be discovered to be unmet later, at cost.
  3. Ask what it replaces. State the cost in the plan's own terms — the schedule or scope effect — and let the sponsor choose which existing work to drop or whether to move the date. The feature may well be worth it; the point is that the trade-off is made by the person who owns the priorities, not absorbed silently by the team.
  4. The sentence cannot be verified as written, which is why two reasonable readers disagree. Split it into statements two people could independently agree on: for responsiveness, a non-functional requirement such as the 95th-percentile page load staying under two seconds with 500 concurrent users, measured by a named tool against a defined environment; for “user-friendly”, a task-based criterion such as a first-time student completing course registration in under five minutes without help, verified by observing a stated number of representative users against a stated success threshold. Note where the two differ: one is a property of the system, the other of the experience, and they need different evidence. The agreement that matters — threshold and method, made with the person who will accept the work — belongs at requirements time. Deciding the threshold now, at acceptance, guarantees an argument about rework.

Summary

  • Functional requirements say what the system does; non-functional requirements say how well, and are often the harder and more decisive problem.
  • Choose elicitation techniques that match the stakeholder group; observation is under-used.
  • A requirement is useful only if two people could independently agree whether it is met.
  • Scope creep and gold plating both add work without agreement; the response is a visible trade-off, not refusal.

Further learning

Next

Continue to Lesson 2 — Work Breakdown Structure.