Skip to content

Lab 06 — Developing a Basic Scope Statement

At a glance

Learning objectives

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

  1. Convert a stakeholder's request into a bounded scope statement.
  2. Identify ambiguity in requirements and rewrite it as something testable.
  3. Write acceptance criteria that a different person could verify.
  4. Use exclusions as a way of controlling scope, not as a disclaimer.

Scenario

A mid-sized retailer has asked for an e-commerce platform to sell its products online. It currently sells through two physical shops and a telephone ordering line. The business owner's request, in her own words:

"We need a proper online shop. Customers should be able to browse, see what's in stock, buy things, pay by card, and track their delivery. It should work on phones because most of our customers use phones. We should also be able to run discounts. And it has to look professional — our competitors' sites look much better than ours."

Further facts gathered in a discovery conversation:

  • The retailer keeps stock records in a desktop accounting package. It can export a file on demand, but it has no programming interface.
  • Two staff will manage products and orders, part-time, alongside the shop floor.
  • Payment must go through the bank's payment gateway, which the retailer already uses for the telephone line.
  • Deliveries are handled by two courier companies; tracking numbers are provided by each courier through a website, not an interface.
  • The retailer will advertise the site to its existing customer list of about 4,000 people.
  • There is no in-house technical staff. The project will be delivered by a small external firm.
  • The retailer has asked for the site to be live "before the winter season", roughly four months away.
  • The accounting package is licensed to one computer in the back office.

Your role

You are the business analyst on the external delivery firm. You must produce the scope statement that the retailer's owner will sign, and that your firm will be held to.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

Treat the request and the facts above as the complete information available. Where the request is ambiguous, your job is to expose the ambiguity, not to resolve it by guessing — record the ambiguity, state the options, and say who must decide.

Tasks

Task 1 — Extract the requirements

List every requirement implied by the request. Keep the retailer's own wording in a "as requested" column so you can show later what was actually said.

Task 2 — Find the ambiguity

For at least five requirements, write down what is ambiguous and at least two plausible interpretations. These are the classic examples to look for, but find them yourself from the text:

  • what "in stock" means when the stock file is only exported on demand
  • what "work on phones" means — responsive website, or an installable application
  • what "run discounts" covers — simple percentage codes, or complex promotions
  • what "track their delivery" requires when couriers have no interface
  • what "look professional" means to the person paying for it

For each, state which interpretation you would assume if forced, and what it would cost to be wrong.

Task 3 — Write the scope statement

Produce a scope statement containing:

Element Content
Business need Two or three sentences
Product scope description What the site is, in bounded terms
In scope Numbered list of what will be delivered
Out of scope Numbered list, each with a one-line reason
Deliverables The concrete things handed over
Assumptions Beliefs the plan depends on
Constraints Limits you must work within
Acceptance criteria Testable conditions for acceptance overall

Task 4 — Write acceptance criteria for three requirements

Choose three in-scope requirements and write an acceptance criterion for each in the form "a can and occurs". A different person, with no access to you, must be able to test it.

Then rewrite any criterion that fails this test, and note what you changed.

Task 5 — Set the scope boundary against the date

The retailer wants the site live in four months with two part-time staff. Choosing from your in-scope list, mark each item required for launch or defer to phase two, and justify the split. State explicitly what you would say to the owner if she insists on everything at launch.

Deliverable

  1. A requirements table with the retailer's wording alongside your interpretation.
  2. An ambiguity register: requirement · ambiguity · interpretation A · interpretation B · decision owner.
  3. A scope statement with all eight elements from Task 3.
  4. Three acceptance criteria, each testable by a third party.
  5. A launch-versus-phase-two split with justification.

Hints and guidance

  • Ambiguity is not a fault in the customer. A non-technical request describes an outcome; turning it into a testable requirement is your job.
  • Exclusions must be plausible. An exclusion nobody would have assumed is not worth listing; five that a reasonable person would have assumed are.
  • Acceptance criteria name an actor and a result. "Supports discounts" fails; "a shop administrator creates a percentage discount code and an order using it is charged the discounted amount" passes.
  • The date is a scope decision. With fixed time and fixed staff, the only variable left is scope. Making that trade explicit is the deliverable, not a failure.

Self-check criteria

Check How to verify it
Every request line is accounted for The request's clauses each appear as a requirement or an exclusion
Ambiguities are exposed, not silently resolved At least five entries, each naming a decision owner
Exclusions are plausible A third party would call at least three of them surprising
Acceptance criteria testable Each names an actor and an observable result
Launch split is justified Each deferred item has a reason, not just a label
Constraints and assumptions are separate No item appears in both lists

Reflection

  1. Which ambiguity would be most expensive to get wrong, and who should decide it?
  2. Did any "requirement" turn out to be a solution to a different problem? Give an example.
  3. The accounting package is licensed to one computer. Why does this belong in the scope statement rather than in a technical design?
  4. What would you do if the owner refused to sign a scope statement with exclusions in it?
Model discussion points
  1. Usually the stock question, because "in stock" drives the entire browsing and checkout experience and the accounting package cannot answer it in real time. The decision belongs to the owner, because it trades customer experience against her back-office process.
  2. "It should work on phones" and "look professional" are the usual answers — both are statements about outcomes the owner values, translated by the requester into a technical instruction.
  3. Because it constrains the design before any design exists: stock availability can be shown only as frequently as the file can be exported, which limits what the site can promise. That is a scope constraint, and hiding it in a design document means the owner discovers it late.
  4. Proceed with a written statement of the assumptions you are working to and the consequences if they are wrong, escalated to whoever owns the commercial risk. A project with no agreed boundary does not become safer by being unsigned — it becomes unmeasurable.

Extension challenge

Rewrite the scope statement as a two-page document for the shop-floor staff who will manage products and orders, rather than for the owner. Then state what you had to remove, what you had to add, and what the exercise reveals about treating "the scope statement" as a single document.