Module 6 · Business Analysis Fundamentals
Writing requirements
Write requirements that can be built and tested, separate functional and non-functional requirements from business rules, and prioritise with MoSCoW.
About 25 minutes
The problem
The first requirements list for Ashgrove's billing change came back from a workshop looking like this:
- The system should be user-friendly.
- Invoices should be sent quickly.
- It should integrate with everything.
- Reports should be good.
Every line sounds reasonable, and none of them can be built or tested. How quick is "quickly"? What's "everything"? A supplier could deliver almost anything and claim to meet them, and the firm would have no way to object. Vague requirements are how projects end in arguments.
The concept
Types of requirement
| Type | Says | Example for Ashgrove |
|---|---|---|
| Business requirement | the goal, in business terms | Reduce average days to pay from 45 to 30 within 12 months. |
| Functional requirement | what the solution must do | The system shall show a due date on every invoice. |
| Non-functional requirement | how well it must do it: speed, security, availability, usability | The overdue report shall load in under 5 seconds. |
| Business rule | a policy that applies whatever the solution | Invoices are due 30 days after issue. Reminders are not sent to clients on a payment plan. |
Good requirements are testable
A requirement is good when someone could write a test that it passes or fails. Check each one against these questions:
- Specific: one requirement per statement, with no "and/or" bundles.
- Measurable: numbers instead of "quickly", "easily" or "good".
- Unambiguous: two readers would build the same thing.
- Solution-free where possible: say what is needed, not how to build it.
- Traceable: linked to the business requirement it serves.
Use "shall" (or "must") for requirements, and keep each one short.
MoSCoW prioritisation
Not everything can be in the first release. MoSCoW sorts requirements into:
- Must have: without it, the solution fails its purpose.
- Should have: important, but there's a workaround for now.
- Could have: nice if time allows.
- Won't have (this time): agreed to be out of scope, for now.
The test for a Must: "If this isn't delivered, would we still go live?" If the answer is yes, it isn't a Must. A list where everything is a Must hasn't been prioritised.
Example
The workshop's vague lines, rewritten:
| Vague | Testable |
|---|---|
| Invoices should be sent quickly. | Invoices shall be issued within 5 working days of the end of each month. |
| It should be user-friendly. | The accounts officer shall be able to produce a month's invoices in under 2 hours after one training session. |
| It should integrate with everything. | The system shall import payments from the bank's CSV statement. |
| Reports should be good. | A report shall list every unpaid invoice past its due date, with client, amount and days overdue, sortable by each column. |
Each rewrite can be tested: time it, count it, or check the report against the data.
Walkthrough
- Sort Ashgrove's needs from your interviews into business requirements, functional, non-functional and business rules.
- Rewrite every vague statement until it passes the testability questions.
- Give each requirement an ID (FR-01, NFR-01, BR-01) and link each to the business requirement it serves.
- Run a MoSCoW session with the managing partner and the accounts officer. Challenge every Must with "would we still go live without it?".
- Record the Won't haves too, with the reason. It stops them reappearing as surprise demands later.
Practice
Task
8 minRewrite these four vague requirements as testable ones, one per line, each using shall and including a number or a precise condition:
- Reminders should go out in good time.
- The overdue report should be fast.
- Only the right people should see client billing.
- It should be easy to record time.
Your work is checked for
- Four requirements, each on its own line using 'shall' or 'must'
- At least three include a number (a time, a count or a limit)
- No vague words left (good time, fast, easy, user-friendly, quickly, right people)
- The access requirement names roles
Task
6 minPrioritise these Ashgrove requirements with MoSCoW. Write one per line in the form Requirement | Must, Should, Could or Won't | reason: due dates on invoices; automatic email reminders; a client payment portal with card payments; an overdue report; importing bank payments automatically; a mobile app for lawyers.
Your work is checked for
- Six lines in the form Requirement | priority | reason
- At least one Won't (have this time)
- Not everything is a Must: at most three Musts
- Due dates are a Must (nothing can be overdue without them)
Check your understanding
Answer every question to check.