Problem definition, stakeholders and requirements

Most failed capstones do not fail in the lab. They fail in the first three weeks, when a team rushes from a vague idea to building hardware without agreeing what problem it is solving, for whom, and how success will be measured. This lesson covers the front end of a project: framing the problem, identifying and engaging stakeholders, turning needs into measurable requirements, prioritizing them, and tracing each requirement from need to test. ROB-360 lesson 2 covered requirements for robot software; here the scope is the whole system, including mechanical, electrical, operational and safety requirements, and the emphasis is on getting a term-sized project right.

From an idea to a problem statement

Partners usually arrive with a solution in mind rather than a problem. Port Willow Parks first asked Team Tern for "a beach-cleaning robot like the big tractors, but small". The team's first job was to understand the underlying problem. Through interviews and two site visits, they learned that the large sand-sifting tractor already cleans the lower beach weekly, but staff spend roughly 12 hours a week on foot collecting small litter near the boardwalk, picnic tables and dune fences, where the tractor cannot go. Staff also wanted data on where litter accumulates, to target bins and signage.

A good problem statement describes the need without prescribing the solution, names who has the need, and states why it matters. A common template is: who needs what, because why, under which constraints. Team Tern wrote: "Parks staff at Port Willow need a way to reduce the time spent collecting small litter on the upper beach and boardwalk edges, and to record where litter is found, because manual collection consumes about 12 staff hours a week in summer and gives no data for prevention; any solution must operate safely around beach users and wildlife and must be maintainable by parks staff." Note that this statement does not say "robot". A robot is the team's proposed solution, and the trade study in lesson 3 should compare it honestly against alternatives such as better bins or a hand-pushed sifting tool.

Problem statements also need boundaries. A term-long capstone cannot solve the full problem, so the team defines what is in scope and what is not. Tern will patrol only the upper beach and boardwalk edge, in daylight, in dry weather, at quiet times, and will collect items between about 2 cm and 15 cm that weigh under 200 g. It will not collect glass, needles or hazardous waste, which it will photograph and report instead. These boundaries become the operational design domain, a term borrowed from automated vehicles in ROB-420 lesson 1, and they protect the team from scope creep later.

Stakeholders

A stakeholder is anyone who affects or is affected by the project. Capstone teams tend to think only of the client, but robots in public spaces have many stakeholders. Team Tern listed parks staff who would operate the robot, the parks manager who controls the budget, beach visitors, families with small children, dog walkers, lifeguards, the municipality's risk manager and insurer, the local conservation group concerned about nesting shorebirds, the faculty advisor, the course instructor and the team itself.

Stakeholders differ in how much influence they have and how much they are affected. A power-interest grid sorts them into four groups: manage closely (high power, high interest, such as the parks manager); keep satisfied (high power, lower interest, such as the risk manager); keep informed (lower power, high interest, such as the conservation group and lifeguards); and monitor (lower power, lower interest, such as occasional visitors). The grid tells the team where to spend its limited time. It does not mean low-power stakeholders do not matter: beach visitors have little formal power over the project but their safety is a non-negotiable requirement.

To understand needs, teams use interviews, site observation, surveys and reviews of existing documents such as incident logs and maintenance schedules. Interviews work best with open questions about current practice, such as "Walk me through a typical litter round" or "What happens when you find something hazardous?", rather than leading questions such as "Would a robot help?". Observation often reveals needs people do not mention: Team Tern noticed that staff carry litter in a bag clipped to a belt and empty it every 20 minutes, which suggested the robot needed a removable bin of similar size. If you survey or interview members of the public and plan to publish or analyze the results as research, check with your institution whether research ethics review is needed; lesson 9 covers this.

Needs, requirements and specifications

Needs are statements in the stakeholder's language, such as "the robot must not scare the birds". Requirements translate needs into statements the engineering team can design to and verify, such as "the robot shall not enter the posted dune fence zone" and "the robot shall travel at no more than 0.5 m/s within 10 m of a detected bird". Specifications go further and describe how the design meets a requirement, for example the geofence implementation. Keeping these levels separate helps when requirements must change: a need is stable, while requirements may be revised as the team learns.

Requirements fall into several categories. Functional requirements say what the system must do: detect litter, navigate to it, pick it up, log its location. Performance requirements say how well: detection recall of at least 80 percent for target items, pick-up success of at least 70 percent. Interface requirements cover connections between subsystems and with the outside world: the bin must fit the parks department's standard bag, the robot must export a CSV report. Environmental requirements cover the conditions the robot must survive: sand, salt air, sun, temperatures from 5 to 35 \( ^\circ \)C, light rain. Safety requirements protect people, animals and property. Constraints limit the design space: budget, mass for one-person lifting, schedule and regulations.

Writing good requirements

A good requirement is necessary, unambiguous, measurable, achievable within the project, and verifiable by a stated method. The SMART acronym, specific, measurable, achievable, relevant and time-bound, is widely used, although for system requirements "testable" is often more useful than "time-bound". Requirements use "shall" for mandatory statements and avoid vague words such as "fast", "robust", "user-friendly" or "as much as possible". Each requirement should state one thing; compound requirements joined by "and" are hard to verify because they can half pass.

Numbers in requirements should come from evidence, not guesswork. The 90-minute patrol came from the parks department's morning quiet period; the 70 percent grasp target came from a quick feasibility test with a borrowed gripper and from literature on low-cost grasping on deformable surfaces; the 0.5 m stopping distance came from the safety analysis in lesson 9. When a number is a guess, label it as a target to be confirmed, and revisit it at the next design review.

Prioritizing with MoSCoW

A capstone always has more possible requirements than time. MoSCoW prioritization sorts them into must have, should have, could have and won't have this time. Must-haves define the minimum viable system that meets the core need; if any must-have is missed, the project has failed its main objective. Should-haves are important but the system is still useful without them. Could-haves are desirable extras. Won't-haves are explicitly out of scope for this term, which is as valuable as the other categories because it prevents arguments later.

A common guideline is to keep must-haves to roughly 60 percent of the planned effort, so that the remaining effort provides contingency and room for should-haves. Team Tern's must-haves were autonomous navigation along a pre-taught route, detection of cans and bottle caps, pick-up of cans, a protective stop for people, and a litter log. Wrappers, which are soft and blow around, became a should-have. Automatic docking and charging was a could-have. Night operation, rain operation and glass handling were won't-haves.

Traceability

Traceability links each requirement backwards to the stakeholder need that justifies it and forwards to the design elements that satisfy it and the tests that verify it. A requirements traceability matrix records these links. It answers three questions examiners and partners ask: why is this requirement here, which part of the design meets it, and how do we know it is met? It also exposes problems. A requirement with no linked need may be gold-plating; a need with no requirement has been forgotten; a requirement with no test cannot be verified; a design element with no requirement may be unnecessary work.

# A small requirements traceability matrix: find gaps automatically
needs = {"N1": "Reduce staff collection time", "N2": "Record where litter is found",
         "N3": "Safe around visitors", "N4": "Protect nesting birds", "N5": "Maintainable by staff"}
reqs = {  # requirement: (need, priority, design element, test)
    "R1 navigate route":        ("N1", "Must",   "nav stack",     "T1"),
    "R2 detect cans/caps 80%":  ("N1", "Must",   "detector",      "T2"),
    "R3 grasp cans 70%":        ("N1", "Must",   "gripper",       "T3"),
    "R4 log GNSS + photo":      ("N2", "Must",   "logger",        "T4"),
    "R5 protective stop 0.5 m": ("N3", "Must",   "safety lidar",  "T5"),
    "R6 dune geofence":         ("N4", "Must",   "geofence",      None),
    "R7 grasp wrappers 50%":    ("N1", "Should", "gripper",       "T7"),
    "R8 LED status light":      (None, "Could",  "status LED",    "T8"),
}
covered = {v[0] for v in reqs.values() if v[0]}
print("needs without requirements:", sorted(set(needs) - covered))
print("requirements without a need:", [r for r, v in reqs.items() if v[0] is None])
print("requirements without a test:", [r for r, v in reqs.items() if v[3] is None])
must = [r for r, v in reqs.items() if v[1] == "Must"]
tested = [r for r in must if reqs[r][3]]
print(f"must-have test coverage: {len(tested)}/{len(must)} = {len(tested)/len(must):.0%}")

needs without requirements: ['N5']
requirements without a need: ['R8 LED status light']
requirements without a test: ['R6 dune geofence']
must-have test coverage: 5/6 = 83%

The script finds three problems in a few lines. Need N5, maintainability, has no requirement at all, so the team added "a parks technician shall replace the gripper fingers in under 10 minutes with standard tools". The status LED has no linked need; after discussion the team traced it to N3, because visitors and lifeguards should be able to see whether Tern is moving autonomously, which ROB-430 lesson 3 discussed. The dune geofence has no test, so the team planned a test in which Tern is commanded to a goal beyond the fence and must refuse. Real projects keep traceability in a spreadsheet, a requirements tool or the issue tracker, but the logic is the same.

Managing requirement changes

Requirements will change. Partners learn what is possible, tests reveal that a target is unrealistic, or a part arrives late. Uncontrolled change is scope creep; controlled change is good engineering. After the system requirements review in week 3, the team freezes a baseline and handles changes through a simple change log: what changed, why, who approved it, and what it affects in the schedule, budget and tests. Small capstone teams do not need a formal change control board, but they do need the discipline to record changes and to tell the partner and instructor. A requirement that quietly disappears before the final demonstration looks very different to an examiner from one that was formally descoped in week 8 with a recorded reason.

If the project involves an industry sponsor, check whether a nondisclosure or sponsored project agreement governs what the sponsor's requirements documents can be shared and published. US universities typically route such agreements through an office of sponsored programs or technology transfer, and students should not sign agreements on the institution's behalf.