Client needs and measurable requirements

Every later decision in a capstone traces back to the requirements. If they are vague, the team cannot choose between concepts, cannot design to a target, and cannot prove at the end that the system works. If they are wrong, the team can build a perfect system that nobody wants. This lesson follows the TrailCount team from the city's one-sentence request to a baseline of twelve system requirements, each measurable, each traced to a need, and each with a planned way of proving it.

Needs are not requirements

A need is a statement of what a stakeholder wants to achieve, in their own language. A requirement is a statement of what the system must do or be, written so that an engineer can design to it and a tester can check it. The gap between the two is where most capstone projects go wrong. Clients rarely state needs completely, they often describe a solution instead of a need, and different stakeholders want different things.

The team's first step was to find all the stakeholders, not just the client. Ines Carvalho at Northway owns the product idea and will maintain the units. The City of Kingston's active transportation office is the end user of the data. City operations staff will mount the nodes on posts and will not tolerate frequent visits. Trail users are affected even though nobody asked them: they will walk past a box that watches them. Dana Okoye runs Northway's fleet dashboard and will receive the data. Professor Osei and the course itself are stakeholders too, with deadlines and assessment criteria.

Eliciting needs

Elicitation means drawing needs out of people who may not know how to state them. The team used four methods, and each found something the others missed.

• Interviews. Jonah and Lucas held a one-hour interview with the city's planner, using open questions: what decisions would you make with better counts, what do you use now, what went wrong with it, what would make a counter useless to you? The answer to the last question was revealing: a counter that cannot tell walkers from cyclists is almost useless, because the two groups need different infrastructure.
• Site visit. Keisha and Amira walked the counting site with a tape measure and a phone. The trail is 3.5 m wide, with a post 1.2 m from its edge, no power within 300 m, tree cover on the south side and snow clearing only on the trail surface. In summer, several hundred people pass on a weekend day; in January, a few dozen.
• Existing solutions. The team read the city's past reports. Counts came from short manual surveys twice a year and from a borrowed pneumatic tube counter that missed pedestrians entirely and was damaged by a snowplow.
• Observation. Jonah stood at the site for two hours on a Saturday and recorded every passage by hand. He saw groups walking side by side, cyclists overtaking pedestrians, dogs, strollers, runners and a mobility scooter. That list became the team's catalogue of hard cases.

From these sources the team wrote five needs, in plain language and without solutions: count people walking and cycling separately (N1); work all year at a trail site with no power (N2); send counts to the city without site visits (N3); protect the privacy of trail users (N4); and be affordable enough to deploy at about 40 sites (N5). Each need was confirmed with Ines and the city before the team went further.

What a good requirement looks like

Requirement-writing guides, such as the international standard for requirements engineering, ISO/IEC/IEEE 29148, and systems engineering handbooks, list similar characteristics. A good individual requirement is necessary (removing it would leave a need unmet), unambiguous (only one reading), verifiable (a finite, objective test, analysis, inspection or demonstration can show it is met), feasible (within the technology, budget and schedule), singular (one requirement per statement) and implementation-free (it says what, not how, unless the how is truly a constraint). A good set of requirements is complete, consistent and traceable.

Most teams adopt a consistent form: The [system or subsystem] shall [verb] [object] [measurable condition]. The word shall marks a binding requirement; should marks a goal; will marks a statement of fact or intent. Consistent use of these words matters because readers, including a client signing an acceptance, read them literally.

The fourth row needs judgment. Sometimes a solution really is a constraint. Northway already runs a network for its sensors, and the client might legitimately require that new products use it. If so, the requirement should say that and say why, so that later readers know it is a deliberate constraint, not an accident. The team asked, and Ines said Northway's network was preferred but not mandatory. The requirement stayed solution-free, and the team's trade study in lesson 3 decided how to meet it.

Kinds of requirements

Requirements fall into a few families, and checking each family is a quick way to find gaps.

• Functional requirements say what the system does: count, classify, record direction, aggregate into 15-minute bins, transmit, report health.
• Performance requirements say how well: accuracy, latency, range, speed span of targets.
• Environmental and physical requirements: temperature range, ingress protection, mounting, size, mass.
• Interface requirements: data formats, radio bands, power inputs, the dashboard's expected fields.
• Constraints: cost, schedule, regulations, standards, the client's preferred suppliers.
• Quality attributes, sometimes called non-functional requirements: reliability, maintainability, security, privacy, usability for installers.

Privacy deserves particular attention in this project. The city's need N4 became a constraint that shaped every concept: the node shall not capture, store or transmit images, and shall transmit only aggregated counts and health data. That single requirement removed camera-based concepts unless the team could show, to the client's satisfaction, that images never leave a sealed processor, and it gave the team a strong argument at every public presentation.

The TrailCount requirements baseline

The last column assigns a verification method to each requirement. The four classic methods are test (operate the system under controlled conditions and measure), analysis (calculation or simulation, used when testing is impractical, such as five days of darkness in summer), inspection (examine the design, drawings or code), and demonstration (operate the system and observe a qualitative result). Assigning the method while writing the requirement is a powerful check: if nobody can say how a requirement would be verified, it is not yet a requirement.

Traceability

Traceability is the ability to follow each requirement backward to the need it serves and forward to the design elements and tests that satisfy it. It answers three questions that come up constantly. Why does this requirement exist? (Follow it back.) If the client changes this need, what else changes? (Follow it forward.) Have we proved everything we promised? (Check that every requirement has a passing verification.) A traceability matrix, often just a spreadsheet, holds these links.

Lucas wrote a small script that reads the requirement list and flags common problems before each review. It is no substitute for careful reading, but it catches mechanical errors quickly, and its rules mirror the characteristics above.

import re
# A small requirements linter and traceability check for the TrailCount node
VAGUE = ['fast', 'user-friendly', 'robust', 'easy', 'as needed', 'approximately',
         'sufficient', 'minimal', 'etc', 'and/or', 'reliable', 'quickly']
needs = {'N1': 'Count people walking and cycling separately',
         'N2': 'Work all year at a trail with no power',
         'N3': 'Send counts to the city without site visits',
         'N4': 'Protect the privacy of trail users',
         'N5': 'Affordable enough to deploy at 40 sites'}
reqs = [  # id, parent need, text, verification method (T, A, I, D)
    ('SYS-01', 'N1', 'The node shall classify each passage as pedestrian or cyclist with daily-total error within 5 % of a manual count.', 'T'),
    ('SYS-02', 'N1', 'The node shall record direction of travel for each passage.', 'T'),
    ('SYS-03', 'N2', 'The node shall operate from -30 C to +50 C ambient.', 'T'),
    ('SYS-04', 'N2', 'The node shall run 5 days with no solar input from a full battery.', 'A'),
    ('SYS-05', 'N3', 'The node shall send counts quickly to the dashboard.', 'D'),
    ('SYS-06', 'N4', 'The node shall not capture or store images.', 'I'),
    ('SYS-07', 'N2', 'The enclosure shall be robust.', ''),
    ('SYS-08', None, 'The node shall display a status LED.', 'I'),
]
problems = 0
for rid, parent, text, ver in reqs:
    issues = []
    words = [w for w in VAGUE if re.search(r'\b' + re.escape(w) + r'\b', text.lower())]
    if words: issues.append('vague: ' + ', '.join(words))
    if ' shall ' not in text: issues.append('no "shall"')
    if not re.search(r'\d', text) and ver in ('T', 'A'): issues.append('no measurable value')
    if not ver: issues.append('no verification method')
    if parent not in needs: issues.append('not traced to a need')
    problems += bool(issues)
    print(f"{rid}: {'OK' if not issues else '; '.join(issues)}")
covered = {p for _, p, _, _ in reqs}
print()
for n, text in needs.items():
    print(f"{n} {'covered' if n in covered else 'NOT COVERED'}: {text}")
print(f"\n{problems} of {len(reqs)} requirements need rework")

SYS-01: OK
SYS-02: no measurable value
SYS-03: OK
SYS-04: OK
SYS-05: vague: quickly
SYS-06: OK
SYS-07: vague: robust; no verification method
SYS-08: not traced to a need

N1 covered: Count people walking and cycling separately
N2 covered: Work all year at a trail with no power
N3 covered: Send counts to the city without site visits
N4 covered: Protect the privacy of trail users
N5 NOT COVERED: Affordable enough to deploy at 40 sites

4 of 8 requirements need rework

The script was run on an early draft, and it found four problems. SYS-05 used the word quickly. SYS-07 said robust and had no verification method. SYS-08 traced to no need at all: someone had added a status LED because it seemed useful. And need N5, affordability, had no requirement, so nothing in the design would ever have been checked against cost. One flag was a false alarm: SYS-02 contains no number, but direction is a binary outcome, and the team later added the 97 % figure anyway, because a direction requirement with no accuracy target cannot fail. The rewritten requirements are the ones in the baseline table above, with SYS-08 changed to a health-reporting requirement traced to N3.

Agreeing and controlling the baseline

In week 7 the team sent Ines and the city a requirements document with the baseline, the needs, the traceability and a short rationale for each number. They met, discussed SYS-09 (the city thought $450 was low; Northway thought it was high, and the team kept it as a target with an explicit review at the critical design review) and SYS-11 (Ines wanted over-the-air updates; the team warned that it was the riskiest requirement in the list). Both parties then agreed the baseline by email, and Lucas put it under change control.

Change control does not mean requirements never change. It means changes are deliberate. A change request states what changes, why, and its effect on cost, schedule, risk and verification. The team, the advisor and the client agree before the baseline is updated, and the document records a revision number and history. Without this, requirements drift silently, often through casual requests in meetings, and at the end nobody can say what the system was supposed to do.

Derived requirements

System requirements are only the top level. As the architecture develops, each system requirement is allocated to subsystems, producing derived requirements. SYS-04 (five days without sun) becomes requirements on battery capacity, average power, regulator efficiency and night-mode behaviour. SYS-01 becomes requirements on the radar module's detection probability and on the classifier's error rate. Derived requirements trace to their parents, so that if SYS-04 changes, the team can find every battery and power requirement that depends on it. Lesson 4 shows these allocations as part of the architecture.