Enrichment · Arts and Creativity

If you cannot test it,
it is not a requirement.

Every competition robot has to fit the rules and do what the team set out to build. This organizer keeps one record per requirement: where it comes from, the statement written as “The robot shall …”, its priority, what you will measure against which limit, how you will verify it and what you actually measured. It catches untestable words and measurements past their limits, and shows how many must-haves are met before inspection.

Add a requirementWhat you get
$5one-time · every device you sign in on
Buy · $5

Included with the Caveat Academy pass and Whole-school licenses. Or get it in the Arts & Creativity collection, $69 for 38 items.

Requirements

The worked example is made up: six requirements for a competition robot, with made-up limits. Use the numbers in your own game manual. Saved on this device only.

Loading the requirement form. If nothing appears, turn on JavaScript.

What you get

Enrichment · Arts & Creativity$5

What you finish with
A record per requirement: ID, source and rule number, category, a shall statement, priority, what is measured, the limit and its value and unit, the verification method, the measured value, the result and four quality checks. Shows must-haves met, requirements not met (counting measurements past their limit) and not checked, and a count by category; flags untestable words, no “shall”, two needs in one, a missing limit, a measurement past its limit and a must-have rule not yet checked.
Who it is for
Middle and high school robotics team members, especially design and build leads; robotics coaches and engineering teachers.
Format
Browser organizer with a saved record per requirement. Prints one requirement, the whole requirements table for the team notebook or a blank sheet; downloads a spreadsheet (.csv); exports and imports a file.
Access
$5 one-time, yours on every device you sign in on; the tool opens once you are signed in with it. Included with the Caveat Academy pass and Whole-school licenses. Also in the Arts & Creativity collection ($69) and the Enrichment Suite pass ($119), and 1 more bundle. Everything you type stays in this browser; nothing is sent to Caveat.
Where it lives
The Arts & Creativity space in Caveat Enrichment.
Support
Questions about access, an order or a correction: team@caveatacademic.com.

How to use it

  1. Read the robot rules in your game manual and add every rule with a number in it as a must.
  2. Add your team’s goals as should or could requirements.
  3. For each one, decide what you will measure and how before you build.
  4. Measure the real robot and enter the value and the result.
  5. Fix the flags, then print the table for your engineering notebook.

Add a requirement

How engineers write requirements

From a rule to a checked requirement1Read the rulesList every robot rule that hasa number in it.2Write “shall”One need per sentence, with anumber and a unit.3Pick a methodInspect, test, analyze ordemonstrate. Decide before you4Measure itRecord the real value, notwhat the drawing says.5Compare and fixPast the limit means not met,however close.From a rule to a checked requirement1Read the rulesList every robot rule that has a numberin it.2Write “shall”One need per sentence, with a number anda unit.3Pick a methodInspect, test, analyze or demonstrate.Decide before you build.4Measure itRecord the real value, not what thedrawing says.5Compare and fixPast the limit means not met, howeverclose.
Writing requirements this way is how engineers make sure a design can be checked. A robot that weighs 41.2 pounds against a 40-pound limit does not pass inspection.

Shall, should, could

Engineering requirements use “shall” for something that must be true. Sorting needs into must, should and could (sometimes called MoSCoW) helps a team decide what to build first when time runs short.

Testable or not

“Fast” and “strong” mean different things to different people. A requirement names a quantity, a limit and a unit, such as a pickup in at most 2 seconds, so anyone on the team can check it the same way.

Four ways to verify

Inspection looks or measures; test runs it under set conditions; analysis uses calculation or a model; demonstration shows it working. Choose before you build, so you design something you can check.

Sources

  1. NASA: Systems Engineering Handbook, NASA/SP-2016-6105 Rev2, Appendix C on how to write a good requirement, and verification methods (nasa.gov).
  2. INCOSE: Guide for Writing Requirements (incose.org).
  3. IEEE/ISO/IEC 29148: Systems and software engineering, requirements engineering (characteristics of good requirements).
  4. Clegg, D., and Barker, R. (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley. The origin of MoSCoW prioritization.

The worked example is made up and its limits are not from any real game manual. Always use your competition’s current rules. Nothing you type is sent to Caveat. Support: team@caveatacademic.com.