Client needs, requirements and specifications

Dale Thibodeau's first email listed seven wishes in plain language. None of them could be designed to or tested as written. 'Move a lot of water' does not say how much, against what head, or from how deep. 'Quiet enough to run beside homes' does not say how quiet, measured where. The team's first real engineering task is to turn those wishes into requirements: statements that are specific, measurable and verifiable, that trace back to a real need, and that leave as much freedom as possible in how they are met.

This lesson follows that translation. It covers how the team gathered needs, how a house of quality connected needs to engineering characteristics, how targets were set from data, and the requirements document that came out of it.

Gathering needs

Needs come from people, and the people who matter are rarely the ones who write the purchase order. For the TDX-150 the team identified four groups. The cooperative's board approves the money and cares about cost and reliability. Dale manages the equipment and cares about maintenance, storage and transport. Volunteer crews set up and run the pumps, often at night, in rain, after a long shift at their regular jobs. And residents live beside the pumps for days at a time. Each group sees the problem differently, and a design that satisfies the board but frustrates the crews will sit in a shed.

The team used three methods. First, interviews: Émilie and Rafael spent an evening at a volunteer fire hall with six firefighters who had worked the last flood, asking open questions about what went wrong and what they did about it, rather than asking what features they wanted. Second, observation: Dale let the team watch a training session in which two volunteers set up a rented 150 mm pump from a trailer, timing each step. The set-up took 34 minutes, eleven of them spent finding and connecting the right hose fittings. Third, data: the cooperative's incident log from the last flood listed every pumping job, with the depth of water, the distance to discharge and how long each pump ran.

Open questions produce better information than feature lists. Asked 'what would you like the pump to have?', firefighters suggested a bigger engine and wireless monitoring. Asked 'tell us about the worst job in the last flood', one described running a rented pump in a basement stairwell to reach a flooded sump, with exhaust building up until the crew felt unwell. That story became a safety requirement and, in lesson 8, the highest-priority failure mode in the team's analysis.

Kinds of requirements

Requirements come in several kinds, and mixing them up causes trouble. Functional requirements say what the product must do: pump water, prime itself, run unattended. Performance requirements say how well: 90 litres per second at a given head. Constraints limit the solution without being goals in themselves: the skid must fit the cooperative's existing trailers, and the engine must meet emission rules. Interface requirements describe how the product connects to other things: hose couplings compatible with the cooperative's existing 150 mm lay-flat hose, forklift pockets sized for its warehouse forklift. And regulatory requirements come from law and standards: CSA Z432, the Canadian standard for safeguarding of machinery, and for the engine, Canada's off-road compression-ignition engine emission regulations, which are aligned with the US EPA Tier 4 standards.

It also helps to sort needs by how customers react to them, an idea from the Kano model. Basic needs cause dissatisfaction when missing but little delight when met: the pump must not leak fuel. Performance needs give more satisfaction the better they are met: more flow, longer run time. Delighters are unexpected features that customers did not ask for but value: Hannah's idea of colour-coded, captive hose fittings that cannot be lost, which would have saved eleven minutes in the observed set-up. The team cannot afford every delighter, but it is important to recognize that basic needs are never traded away.

The house of quality

Quality function deployment is a structured way of connecting what customers want to what engineers can measure. Its central chart is the house of quality, shown in the figure. Customer needs, with their importance, run down the left side. Engineering characteristics, the measurable quantities the design team controls, run across the top. Each cell records how strongly a characteristic affects a need, using the conventional scale of 9 for strong, 3 for medium and 1 for weak. The roof records how characteristics interact with each other, and the bottom row gives each characteristic's technical importance.

The importance ratings came from a short survey the team sent to the board, Dale and the crews, each person scoring each need from 1 to 5. The relationships came from a team discussion, with Owen and Farah checking the engineering. The technical importance of each characteristic is the sum, down its column, of each need's importance multiplied by the relationship strength:

# House of quality for the TDX-150 dewatering skid: technical importance of engineering characteristics
needs = {   # customer need: importance 1-5 from the cooperative's survey
    "moves a lot of water": 5, "starts pumping quickly": 4, "handles debris": 4,
    "fits our trailer": 5, "runs all night unattended": 4, "quiet near homes": 3,
    "two volunteers can set it up": 4, "affordable": 3}
chars = ["flow at 18 m", "priming time", "solids size", "wet mass", "run time per tank",
         "noise at 7 m", "set-up time", "unit cost"]
# relationship strengths 9 strong, 3 medium, 1 weak, 0 none (rows = needs, columns = characteristics)
R = [[9, 1, 0, 1, 3, 1, 0, 3],
     [0, 9, 0, 0, 0, 0, 3, 0],
     [3, 1, 9, 0, 0, 0, 0, 1],
     [1, 0, 0, 9, 3, 3, 1, 1],
     [3, 0, 1, 3, 9, 0, 0, 1],
     [3, 0, 0, 3, 1, 9, 0, 3],
     [0, 3, 0, 3, 0, 0, 9, 1],
     [3, 0, 1, 3, 1, 3, 1, 9]]
w = list(needs.values())
raw = [sum(w[i] * R[i][j] for i in range(len(w))) for j in range(len(chars))]
total = sum(raw)
order = sorted(range(len(chars)), key=lambda j: -raw[j])
print("Engineering characteristic   score  share")
for j in order:
    print(f"  {chars[j]:24s} {raw[j]:5d}  {raw[j] / total:5.1%}")
# A quick check that every need is served by at least one strong relationship
for i, n in enumerate(needs):
    if max(R[i]) < 9:
        print("No strong link for need:", n)
# Roof: correlations between characteristics (+ helps, - conflicts)
roof = {("flow at 18 m", "wet mass"): "-", ("run time per tank", "wet mass"): "-",
        ("noise at 7 m", "wet mass"): "-", ("flow at 18 m", "unit cost"): "-",
        ("priming time", "set-up time"): "+"}
print("Conflicts to resolve:", [f"{a} vs {b}" for (a, b), s in roof.items() if s == "-"])

Engineering characteristic   score  share
  flow at 18 m                92  17.2%
  wet mass                    92  17.2%
  run time per tank           72  13.4%
  unit cost                   68  12.7%
  priming time                57  10.6%
  noise at 7 m                56  10.4%
  set-up time                 56  10.4%
  solids size                 43   8.0%
Conflicts to resolve: ['flow at 18 m vs wet mass', 'run time per tank vs wet mass', 'noise at 7 m vs wet mass', 'flow at 18 m vs unit cost']

Two characteristics tie at the top: flow at the rated head, and wet mass. That result surprised the team. They had expected flow to dominate, because moving water is the point of the product. But mass affects four needs at once: fitting the trailer, being quiet (heavier canopies insulate better), running all night (fuel weighs about 0.84 kg per litre) and cost. The roof shows why mass will be the hardest characteristic to control: almost every improvement elsewhere adds weight.

The house of quality also checks completeness. Every need has at least one strong relationship, so every need is served by something the team can measure. If a need had no strong link, it would mean the team had no engineering characteristic that clearly delivered it, and either a characteristic was missing or the need was being ignored.

Setting targets from data

A characteristic becomes a requirement when it gets a target value. Targets should come from data and analysis, not from guesses or from rounding to an impressive number. The team's targets came from four sources.

For flow, the team analysed the incident log. Of the 61 pumping jobs in the last flood, the largest common case was a flooded underpass or lift station with water to be lifted about 6 m and discharged through about 60 m of hose to a storm drain or the river. The cooperative wanted to clear a typical underpass of about 8,000 m³ in under a day. Moving 8,000 m³ in 24 hours needs about 93 litres per second on average. The team set 90 L/s at a total dynamic head of 18 m as the rated point, matching Tidewater's 150 mm self-priming wet end at its best efficiency, and accepted that very large jobs would use two skids.

For suction lift, the incident log showed most jobs within 6 m of the water, a few up to 7.5 m. Since the physics limits suction lift at sea level to well under 10 m, and practical pumps lose flow well before that, the team split the requirement: full flow at 6.0 m, and the ability to prime, at reduced flow, at 7.5 m. Lesson 6 shows why that split was wise.

For mass, the cooperative's single-axle trailers are rated for a total of 1,360 kg, and the trailer itself weighs about 360 kg. Allowing 50 kg for hoses and fittings carried with the skid leaves 950 kg for the skid with a full tank. For run time, crews wanted to fill the tank at the end of an evening shift and find the pump still running in the morning, with a margin; 24 hours became the target. For noise, the team took a reading of the rented pump that had caused complaints, about 82 dB(A) at 7 m, and chose a target of 75 dB(A) at 7 m, which corresponds roughly to halving the perceived loudness.

The requirements document

Each requirement has an identifier, a target and a verification method. The method matters: a requirement that cannot be verified is a wish. Some are verified by test, some by analysis, some by inspection and some by demonstration with real users. The table is also short. Twelve requirements is enough for a capstone; a production specification would have many more, but each additional requirement must be designed for, verified and tracked, so a short list that captures what matters is worth more than a long list nobody reads.

The team also wrote a section of the document headed 'not required'. The skid will not be road-legal on its own; it rides on the cooperative's trailers. It will not pump sewage or chemicals. It will not be remotely monitored in this version, although the control panel will have space for a modem. Writing these down prevented two weeks of argument about telemetry and kept the budget for the things the client actually needed.

Good and bad requirements

The test of a requirement is whether two engineers, reading it separately, would design and test to the same thing. 'The pump shall be easy to set up' fails that test. 'Two trained volunteers shall set up the skid, from parked trailer to water flowing, in 20 minutes or less, demonstrated three times with different crews' passes. A good requirement states one thing, says what is measured and under what conditions, gives a number with units, and says how it will be shown.

Requirements should also avoid stating solutions. 'The skid shall use a vacuum priming pump' is a design decision dressed as a requirement, and it would have prevented the team from considering submersible pumps, which need no priming at all. Where the client genuinely needs a particular solution, for example because the cooperative's mechanics already service one engine brand, that becomes a constraint and is labelled as one, with its reason recorded.

Traceability

Each requirement should trace to a need, and each need to at least one requirement. The team kept a simple trace table linking each R-number to the needs it serves and the source of its target. Later, each design decision and each test will be linked to requirements too, so that at the final review the team can show, for every requirement, how it was met and how that was verified. Traceability sounds bureaucratic, but it answers the question every reviewer asks: 'why is this here, and how do you know it works?'