Lesson 0.3: Writing Requirements and Separating Them From Constraints
Technical Context
"The intake should be fast" is not a requirement. It cannot be tested, it cannot be designed against, and two people reading it will picture different mechanisms. A requirement that cannot fail a test is not a requirement, it is a wish.
This lesson covers how to turn strategy into statements that a mechanism either satisfies or does not.
What Makes a Requirement Usable
A usable requirement has three properties.
It is measurable. There is a number and a unit, or a clear yes and no.
It is testable. You can describe, in one sentence, the test that would prove it.
It is about the robot, not the solution. "The intake must use compliant wheels" is a design decision disguised as a requirement. It rules out every other approach before anyone has compared them.
| Wish | Requirement |
|---|---|
| The intake should be fast | The intake acquires one game element in 1.5 s or less, measured from contact to secured |
| The robot should be strong | The robot resists being pushed by a 30 lb opponent without losing its scoring position |
| The arm should reach high | The end effector reaches 34 in above the tile surface with the robot frame fully inside the field perimeter |
| The drivetrain should be reliable | The drivetrain completes 50 full field traversals with no fastener loosening or wheel slip on the driven axle |
Notice that every requirement on the right implies a specific test.
Requirements Versus Constraints
These get confused constantly, and the confusion is expensive.
A constraint is a limit you did not choose and cannot negotiate. The starting size limit is a constraint. The list of legal motors is a constraint. The height of a field barrier is a constraint.
A requirement is something you decided the robot must do, derived from your strategy. Scoring in the high goal is a requirement, and it is one you could choose to drop.
The practical difference: when a design fails to meet a requirement, changing the requirement is on the table. When a design violates a constraint, the design is dead.
Teams routinely treat their own preferences as constraints. "We have to use mecanum" is not a constraint, it is a preference someone stopped questioning. Write the actual source next to every constraint: a rule number, a physical measurement, or a budget figure. If you cannot cite a source, it is a requirement in disguise, and requirements can be changed.
Deriving Requirements From the Scoring Table
Work backward from the points per second table you built in Lesson 0.2.
Suppose the table says the high goal is worth 6 points and you estimate a 9 second cycle. In a 120 second TeleOp with 20 seconds reserved for endgame, you have 100 seconds of scoring time, which is about 11 cycles, which is 66 points.
Now the requirements write themselves:
- The robot must acquire an element from the floor in 2 s or less
- The robot must travel from the acquisition zone to the scoring zone in 3 s or less
- The scoring mechanism must reach 34 in and release the element in 2 s or less
- The robot must return in 2 s or less
If any one of these cannot be met, the 9 second cycle estimate was wrong, and the whole strategy needs rechecking. That is the loop from Lesson 0.1 doing its job before anything was built.
Two students disagreeing about intake designs is unproductive until someone asks "which one acquires an element in under 2 seconds?" Then it is a question with an answer, and the answer comes from a prototype rather than from whoever argues longest.
Four Things Every Requirement Needs
A statement alone is not enough. A requirement that the team can actually work from carries four things, and a row missing any one of them will cause an argument later.
| Field | Why it exists |
|---|---|
| An id | So a notebook entry, a design review, and a test result can all cite the same thing. "R2 failed" is precise; "the drive requirement" is not. |
| A number and a unit | Without one, nothing can pass or fail. |
| A verification method | How you will know. Test means run it repeatedly and count. Measure means one instrument reading. Inspect means check against a list. Demonstrate means show it once, end to end. |
| An owner | A subsystem that answers for it. A requirement everyone owns is one everyone assumes someone else has. |
Plus a source, so a rule can be told from a preference.
Requirements Table
A number, a way to check it, and somebody who answers for it.
Every row has a number, a way to check it, an owner, and a source. That is the point where a design review can ask "show me R2" and get an answer rather than an opinion.
Ids beginning with R are requirements you chose and could drop; ids beginning with C are constraints you cannot negotiate, and their source should be a rule number or a physical measurement. Verification is how you will know: Test means run it repeatedly and count, Measure means one instrument reading, Inspect means look at it against a checklist, Demonstrate means show it once end to end.
Once R2 exists, a mechanism can be described as "satisfies R2", a test result can be recorded against R2, and a design review can ask to see R2 rather than asking whether the drivetrain feels fast enough. That thread from a decision to the evidence for it is what separates a team that can explain its robot from a team that built one.
Write Them Down Where People Will See Them
A requirements list stored in someone's notes does nothing. Put it on a whiteboard or a printed sheet in the build space, in this format:
R1 Acquire element from floor <= 2.0 s [strategy]
R2 Traverse field, acquire to score <= 3.0 s [strategy]
R3 Deliver to high goal <= 2.0 s [strategy]
R4 Reach height at end effector >= 34 in [field measurement]
C1 Starting envelope per manual [rule reference]
C2 Legal motors only per manual [rule reference]
C3 Total robot weight target <= 28 lb [team decision]
The bracket at the end is the source. C3 is marked as a team decision, which tells everyone it can be revisited if the reason is good enough.
Fill-in-the-Blank Practice
- A requirement that cannot be tested is really a
__________. - A limit imposed by the game manual that your team cannot negotiate is a
__________. - "The intake must use compliant wheels" is not a requirement because it specifies a
__________rather than a needed outcome.
Show answers
- wish (or preference)
- constraint
- solution (a specific design choice)
Exercise
Take three statements your team has made about this season's robot. Rewrite each one as a testable requirement with a number and a unit, then mark whether it is actually a requirement or a constraint, and write the source.
Ready to move on?
Sign in with Google to save your progress with Telemark, or continue without saving.
Stuck on this lesson?
Ask about anything on this page. It can see which lesson you have open and which part you are reading.