Exam practice

A functional requirement says what the product must do: a job it carries out. A quality requirement says how well it must do it, or in what conditions (speed, who can use it, on what device, how safely).
Functional, for example: show the date, time and room of each student’s next exam; show the whole exam timetable for a chosen class.
Quality, for example: works on a phone with a weak signal and loads in under 5 seconds; a student who has never seen it finds their next exam in under 30 seconds, without help; shows dates in Bikram Sambat, in Nepali and English.

Any six, such as:

1. The user and the problem: so every member builds for the same person and need.
2. Requirements, numbered, each with its test: so everyone means the same thing by “done”, and the product can be checked.
3. How it will be used, and the design (screens, tried on paper): so the builders build what the user can use.
4. Data, as a data dictionary: so every part reads and writes the data the same way.
5. The parts, with owners and interfaces: so members can build at once and the parts fit.
6. Testing: which tests, when they are run, when users test it.
7. Risks and limits: so the team plans for what could go wrong, and tells the user honestly.
8. The plan and decisions, dated: so nobody works from an old plan or re-argues a settled question.

An interface is the agreement on how two parts meet: the function’s name, what it is given, what it gives back, in what form and units, and what it does not do. With it written down, two people can build the two parts at the same time.
The Mars Climate Orbiter was built and flown by two teams. Their written interface said the thrusters’ push would be given in newton-seconds, but one program gave pound-force seconds, 4.45 times bigger. Each side’s software did what its own programmers expected, so neither alone looked wrong; the navigation calculations drifted, and in 1999 the spacecraft passed far too close to Mars and was lost. The mistake was at the interface, and the checks that would have caught it weren’t done. Writing the interface exactly is not enough: each side must keep to it, and it must be tested where the parts join.

• i.A in week 1; B, C and E can all be in week 2; D needs B and C, so week 3. The earliest finish is the end of week 3.
• ii.Only E can move: it can be in week 2 or week 3. A, B, C and D are on the longest chains (A → B → D and A → C → D).
• iii.No. The longest chain is three tasks that must happen one after another, so three weeks is the least possible. More people can share work done at the same time, but they can’t shorten a chain of waiting (Brooks’s point: some tasks can’t be split).

For example, a task is done when:

1. It works, for the case it was meant for: otherwise it isn’t finished at all.
2. Its own tests pass, written from the requirements: so it is checked, not just believed.
3. All the old tests pass too: a change can break something that worked (a regression), as version 5 of the milk program did.
4. The change log says what changed, and why, with the date and who: so anyone can later find which change caused a problem.
5. Another member has read it: two people understand every part, and a second reader catches mistakes the writer can’t see.

• Show what is happening / let people recognize instead of remember: show the farmer’s name, large, as soon as the number is typed, so a wrong name catches the eye; and show the saved line in full afterwards.
• Prevent mistakes: show the farmer’s usual amount (“usually about 3 liters”) and ask again if the liters are far from it, so an unusual entry gets a second look.
• Let people undo: make correcting a delivery easy, keeping the old line in the record, so a mistake found later costs little.

(A number that belongs to a real farmer can’t simply be refused; the design must make her notice it.)

• Success: whether, or how many, finished the task: whether it can be used at all.
• Time: how long the task took: whether it is quick enough (a quality requirement like Q2).
• Mistakes: how many wrong actions, and how many were noticed: where the design invites errors.
• Help needed: how often they had to ask: what the design doesn’t explain by itself.
• (Also a rating from 1 to 5: how it felt to them.)

The first few testers find most of the big problems, because those trouble almost everyone; later testers mostly find the same problems again. After fixing them, a new round of testers finds the problems the first ones were too stuck to reach, and checks the fixes worked. Two rounds of five learn more than one of fifteen.

The farmer brought 1.1 liters at 4.3% fat for 15 mornings: each delivery is 1.1 × 4.3 × 15 = Rs 70.95. Rounding each to Rs 71 and adding gives 15 × 71 = Rs 1,065. Adding the exact amounts gives Rs 1,064.25, which rounds once to Rs 1,064.
The team’s tests were written from the requirements, and R3 didn’t say how to round; so a test written from it couldn’t catch it. Only the user, comparing with her own method, found that the requirement was incomplete. The team rewrote R3 (“round once, after adding the exact amounts”), wrote it into the interface (payment() returns rupees not rounded), added test T6 for this case, and ran all the tests again.

For example:

Records can “seem” to show something that isn’t true: an old address, a relative’s move, a typing mistake, two people with the same name. Robodebt used a simple rule (averaging yearly income over fortnights) that was wrong for people whose income was uneven, and sent hundreds of thousands of people debts they didn’t owe, with no person checking and the burden on them to prove it. A program that stops an allowance on its own would hurt the people who most depend on it, often older and poorer people, who may not even know why their money stopped.
Better: the program lists the records that seem to show a move, for a ward officer to check; the person is asked, and told why; nothing stops until a person has decided, and the person can explain or appeal. The rule and its limits are written in the design document, and the program’s list is tested on past cases where the right answer is known.

For example: soil-moisture sensors to tell farmers when to water vegetables, in a village with little water.
Steps: sensors in a few fields send readings by SMS to a small computer at the cooperative; it sends each farmer a message, in Nepali, “Your field is dry: water today” or “No need to water”; farmers can reply STOP; an agriculture technician checks the advice each week.

• Intended, good: less water wasted; better harvests in dry weeks.
• Unintended, good: the readings show which fields drain fastest, useful for choosing crops.
• Unintended, harmful: a broken sensor says “wet” and a crop dries out (the farmer): reduce by flagging sensors whose readings stop changing, and telling farmers to check by hand too. Farmers without a phone get nothing (the poorest): reduce with a board at the cooperative showing each field. The data shows when fields are empty and owners away (theft): reduce by sending each farmer only their own field’s reading.

Decision: a trial on five fields for one season, comparing water used and harvests with five fields without sensors, before spending more.