Functional Requirements Specification
Chapter Ten
Syllabus topic Module 1, "Requirement Engineering: Functional requirements specification".
Pages 57 to 62 of 499
In one line
A functional requirement states one thing the system must do for a user, in words precise enough that a developer knows what to build and a tester knows how to check it; specifying them means writing each one down in a fixed, testable form, with an identifier and a source.
In the wording to use when asked: a functional requirement defines a behaviour of the system, a function it performs in response to an input or event, including the rules that govern it and the output it produces; the functional requirements specification is the numbered, testable statement of every such behaviour.
What makes a requirement functional
A functional requirement describes behaviour: something the system does when a user or another system asks it to. It usually has three parts, even when they are not written separately:
- an input or trigger: a student taps Place order;
- the processing, including the rules: check the slot is open, check the stock, take the stock;
- an output or result: the order is accepted with a number, or refused with a reason.
Everything that is instead about how well the system does things, how fast, how safely, how easily, on which devices, is a non-functional requirement and belongs in Chapter 11.
How to write one
The usual form is a sentence in which the system shall do something:
FR-13. The system shall let a student cancel their own order while its status is placed, and shall return its items to the stock.
"Shall" marks the sentence as binding. Some teams write "must", which means the same; what matters is using one word consistently, and not mixing in "should" or "may", which readers take as optional.
Seven rules make a functional requirement usable:
- One requirement per statement. A sentence with two unrelated "and"s is usually two requirements, and one of them will be forgotten in testing.
- Name who acts. "Orders can be cancelled" hides who may cancel them. "A student ... their own order" does not.
- Say what happens, not how it is built. "The system shall store orders in MySQL" is a design decision. The requirement is the behaviour the user sees; the design comes later and can change without the requirement changing.
- Make it testable. Somebody reading it must be able to design a test it passes or fails.
- State the rules exactly. Limits, conditions and exceptions are part of the requirement: "from 1 to 5 of each item", "15 minutes before the slot".
- Give it an identifier that never changes, even if the requirement is deleted: FR-1, FR-2 and so on.
- Record its source, as Chapter 9 explains.
Words that ruin a requirement
Certain words make a requirement impossible to test. Train yourself to find them in your own drafts.
Functional Requirements Specification
| Written | What is wrong | Better |
|---|---|---|
| The system should be fast | not a function; "fast" has no number | a non-functional requirement with a number (Chapter 11) |
| Ordering shall be easy | "easy" cannot be tested | the exact steps of ordering, with a limit on taps (Chapter 11) |
| Users can manage their orders | which users? what does "manage" include? | cancel (a student, own order, while placed) and change status (the counter) as separate requirements |
| The system shall handle stock etc. | "etc." hides the unstated rest | each stock behaviour stated separately |
| The system shall store orders in MySQL | a design decision | removed; the architecture records it |
| The system shall show relevant items | "relevant" to whom, by what rule? | "items that can be ordered now: switched on today with stock left" |
Other words to hunt for: appropriate, adequate, user-friendly, flexible, efficient, as required, and/or, if possible, normally.
Business rules belong inside
A business rule is a rule of the organisation the system must enforce. Rules like "orders for a slot close 15 minutes before it" or "at most 5 of one item" are not decoration; they are exactly what a tester checks and exactly where the application can be wrong. Write them inside the requirement they govern, with their numbers.
User stories and acceptance criteria
Agile teams often write requirements as user stories:
As a student, I want to order lunch before the break, so that I do not lose my break in the queue.
A user story names who wants something, what, and why. It is a good way to start a conversation, and a poor way to end one, because it leaves out the rules. So each story carries acceptance criteria: concrete conditions that must hold for the story to be done. A common form is given, when, then:
Given the pickup slot 12:40, whose cut-off is 12:25,
when a student tries to order for it at 12:25,
then the order is refused with the message that ordering for 12:40 has closed.
For an SRS in this paper, write the shall-statement form: it is what an examiner expects, and it reads as a specification. Add acceptance criteria in the given, when, then form wherever a rule could be misread. They double as test cases in Module 2 (Chapter 55).
Organising the list
Group the requirements by what the user is trying to do, not by screen and not by the order you thought of them. A group per feature area makes gaps visible: an area with a create but no cancel, or a list but no way to change what is listed.
Functional Requirements Specification
The worked project: the functional requirements
The worked team's specification, as it stood after the validation review of 25 August. Every rule in it is enforced by the application you will see in Module 2, which is why the numbers are so exact.
Accounts
FR-1. Register. The system shall let a person create a student account by giving a name of 2 to 80 letters, an email address at the college's own domain, and a password of 8 to 128 characters. It shall refuse an email address at any other domain, and an email address that already has an account. (Source: the principal's office, whose condition was that only college addresses may register; the survey.)
FR-2. Sign in and sign out. The system shall let a registered user sign in with their email address and password, keep them signed in for 8 hours or until they sign out, and let them sign out. When the email address or the password is wrong, it shall give the same message for both.
FR-3. Counter staff accounts. The system shall let the owner create a counter staff account with a name, an email address and a password.
The menu
FR-4. Today's menu. The system shall show anyone, signed in or not, today's menu: for each item its name, category, price, whether it is vegetarian, and whether it can be ordered now. An item with fewer than 10 portions left shall show how many are left; an item with none left shall show as sold out.
FR-5. Menu items. The system shall let the owner add a menu item, giving its name, category, price and whether it is vegetarian; change an item's price; and put an item on or take it off today's menu.
FR-6. Today's stock. The system shall let the owner set, for each item, the number of portions offered for pre-order today, from 0 to 1,000.
Ordering
FR-7. Place an order. The system shall let a signed-in student order one or more items that can be ordered now, from 1 to 5 of each item and no more than 10 items in all, for one pickup slot.
FR-8. Pickup slots. The system shall offer the pickup slots 12:30, 12:40, 12:50 and 13:00, on the canteen's own clock, and shall stop accepting orders for each slot 15 minutes before it.
FR-9. Stock. The system shall not accept an order for more of any item than is left, and shall reduce each item's stock by the quantity of every order it accepts. If any item of an order cannot be supplied, no part of the order shall be accepted.
FR-10. One order per slot. The system shall allow a student at most one active order, meaning placed, being prepared or ready, for each pickup slot.
Functional Requirements Specification
FR-11. Order number. The system shall give each accepted order a number, and show it to the student as soon as the order is accepted.
FR-12. My orders. The system shall show a signed-in student their own orders for today, with each order's number, slot, items, total and status, and shall refresh the status at least every 15 seconds while the page is open.
FR-13. Cancel an order. The system shall let a student cancel their own order while its status is placed, and shall return its items to the stock.
The counter and the kitchen
FR-14. The counter's list. The system shall show counter staff and the owner today's orders, all together or for one chosen slot, with each order's number, the student's name, the items, the total and the status.
FR-15. Moving an order on. The system shall let counter staff and the owner move an order from placed to being prepared, from being prepared to ready, and from ready to collected or to not collected, and shall refuse every other change of status. An order marked not collected shall not return its items to the stock.
FR-16. The kitchen list. The system shall show counter staff and the owner, for a chosen slot today, the total quantity of each item in orders that are placed or being prepared.
FR-16 is worth a note. It was not on the team's first list at all. It exists because the counter staff sent the team to the kitchen, and the head cook explained that what the kitchen needs is not an app but a count of each dish per slot before the rush (Chapter 5).
The owner
FR-17. Daily report. The system shall show the owner, for today or any chosen date, the number of orders in each status, and the quantity and takings of each item in collected orders, with the day's total takings.
Acceptance criteria for the rules most easily misread
The team wrote given, when, then criteria for the four rules that caused the most discussion at validation:
| Requirement | Given | When | Then |
|---|---|---|---|
| FR-8 | the slot 12:40, whose cut-off is 12:25 | a student orders for it at 12:24 | the order is accepted |
| FR-8 | the same slot | a student orders for it at 12:25 | the order is refused: ordering for 12:40 has closed |
| FR-9 | 2 portions of Veg Biryani left | a student orders 1 Veg Thali and 3 Veg Biryani | the whole order is refused, and the Veg Thali stock is unchanged |
| FR-10 | a student with a placed order for 12:40 | the same student orders again for 12:40 | the second order is refused |
| FR-15 | an order that is placed | the counter tries to mark it ready | the change is refused; it must be prepared first |
Functional Requirements Specification
Look at the FR-9 row. It says the thali is not taken when the biryani fails. That sentence is easy to miss and hard to build: it needs the database to treat the whole order as one unit that succeeds or fails together, which is what Chapter 45 builds and tests.
Do this for your project
- Group your candidate requirements by what the user is trying to do.
- Write each as "The system shall...", one behaviour per statement, naming who acts.
- Put every limit and condition inside the requirement, with its number.
- Hunt for the ruinous words (fast, easy, manage, etc., appropriate) and rewrite each.
- Remove anything that is a design decision, and move anything about "how well" to your non-functional list.
- Number them FR-1 onward, and never reuse a number.
- Write given, when, then criteria for every rule a reader could misunderstand.
Mistakes that cost marks
A list of screens instead of behaviours. "Login page, menu page, cart page" says nothing about what happens on them.
Missing the unhappy paths. A requirement for ordering with nothing about sold-out items, closed slots or duplicates specifies half a system.
Requirements the code does not meet. An examiner who reads your SRS and then uses your application notices the difference. Update the requirement or the code, and record which.
Design in the requirements. "Using a MySQL table" in a requirement ties it to one implementation.
Unnumbered requirements. Without identifiers they cannot be traced, prioritised or tested.
Quick revision
- A functional requirement is one behaviour: input, processing with its rules, output.
- Form: "The system shall...", one behaviour, the actor named, the rules and numbers inside, testable, numbered, with a source.
- Banned words: fast, easy, manage, etc., appropriate, user-friendly, and/or.
- Business rules go inside the requirements they govern.
- User stories (as a... I want... so that...) start conversations; acceptance criteria (given, when, then) make them testable.
- Group by what the user is trying to do; a group with a create and no cancel shows a gap.
Questions you must be able to answer
1. What distinguishes a functional requirement from a non-functional one? A functional requirement states what the system does, a behaviour with an input, processing and an output. A non-functional requirement states how well the system does it, such as its speed, security, usability or compatibility.
2. Rewrite "Users can manage orders" as proper requirements. It hides two different behaviours by two different users: "The system shall let a student cancel their own order while its status is placed", and "The system shall let counter staff move an order from placed to being prepared, from being prepared to ready, and from ready to collected or not collected, and shall refuse every other change of status."
Functional Requirements Specification
3. Why should a requirement not say how it will be built? Because the requirement is what the user needs and should stay true whatever the design. Tying it to a design decision, such as a particular database table, makes the requirement wrong whenever the design changes, and hides the actual need.
4. What are acceptance criteria, and write one for the worked project's cut-off rule. Concrete conditions that must hold for a requirement or story to be satisfied, often written as given, when, then. Given the slot 12:40 with its cut-off at 12:25, when a student orders for it at 12:25, then the order is refused because ordering for 12:40 has closed.
5. Why is FR-9's last sentence the hardest part of it to build? Because refusing the whole order when any item cannot be supplied means the stock taken for the earlier items must be put back automatically. The database must treat the order as a single transaction that either succeeds completely or leaves nothing changed.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself for the same subject.