Module 22 · Core · 8 min read

Requirements gathering

You will be able to: Write testable requirements instead of wishes or solutions; Prioritise with MoSCoW and keep a requirement register; Trace each requirement to a design item and a test.

Read not done yet
Self-check: not taken not done yet
Lesson complete not done yet

A requirement is a statement of need that someone can test. 'The system must be user friendly' is a wish. 'A cashier can complete a cash sale in under 30 seconds after one hour of training' is a requirement. Write each one in a form such as: the [role] needs to [do something] so that [outcome], then add an acceptance test.

Requirement or solution?

Clients often describe solutions: 'add a column to our Excel stock sheet.' Ask why until you reach the need: 'the storekeeper must know what is in each warehouse without counting.' The need can be met in a better way than the original solution.

MoSCoW priorities

Must: the business cannot operate or comply at go-live without it.
Should: important, with a manual workaround for a short time.
Could: nice to have if time and budget allow.
Will not (this time): agreed to be left for later, and written down.

If more than about 60% of requirements are Must, the list is not prioritised. Challenge each Must with 'what happens on day one if we do not have it?'

The requirement register

ID	Requirement	Priority	Source	Fit-gap	Acceptance test
R-01	Sales invoices over AED 50,000 must be approved by the general manager before posting	Must	Owner	Configuration: Approval Rules	Invoice of AED 60,000 waits for approval; AED 40,000 posts
R-04	Warn or stop sales to a customer over their credit limit	Should	Accountant	Configuration: Credit Control	Test customer with AED 10,000 limit and AED 12,000 invoice is warned or refused
R-07	Invoices print in English and Arabic	Must	Sales manager	Configuration: print format and templates	Print preview shows Arabic version
R-09	Reps sell from the field with no signal and sync later	Must	Sales manager	Standard: Field Sales	Offline sale appears after Send now
R-12	Owner sees yesterday's sales each morning	Should	Owner	Configuration: Daily Owner Report	Report arrives by e-mail at the set time

Where requirements come from

Interviews and workshops, which tell you what people believe.
Documents and reports, which tell you what actually happens.
Observation, which shows the workarounds nobody mentions.
Regulation: VAT rules, invoice content and record keeping, which the accountant should confirm.

TipGive every requirement an ID and keep it. The same ID should appear in the blueprint section, the test script and the training outline. That chain is called traceability, and it is how you prove at sign-off that nothing was forgotten.

From wish to requirementThe owner says: 'I want better control of discounts.' Questions reveal the need: reps give up to 25% and nobody checks. The requirement becomes: 'A rep cannot give more than 10% discount on a sales invoice without manager approval.' Zeyto lets you set a personal Max Discount % per user and approval rules for documents, so this is configuration, and the acceptance test is an invoice with 15% discount raised by a rep.

Practise in the demo

Rewrite three vague wishes from a business you know as testable requirements with an acceptance test.
Open Settings, then Users & Permissions in the demo and find the personal limits (Max Discount % and similar).
Open https://demo.zeyto.app/demo-app/ and sign in with the demo login. This is a public demo with sample data, so nothing you do there affects a real business.

Open the live demo

Public demo company, sign in as admin / demoAdmin123. Data refreshes nightly.

Key takeaways

A requirement is testable; a wish is not.
Dig from the solution the client names to the underlying need.
Give every requirement an ID, a priority, a fit-gap class and an acceptance test.

Check yourself

3 questions on this lesson. Not timed, not the exam, and you can try again. Score 60% or more, and read the lesson, to complete it.