From customer requirements to engineering requirements

1. Engineering problem

Customers describe needs (“it must be fast, safe and cheap”). Engineers need requirements: statements that say what the system must do, with numbers and tolerances, and that can be verified. Skipping this step is the usual cause of robots that work in a demo and fail at the customer’s site, because nobody wrote down the conditions the demo happened to meet.

2. When is this needed?

• At the start of any robot project, before choosing sensors, motors or a computer.
• When a customer and the engineering team disagree about whether the robot “works”.
• When a requirement changes: to see what else it affects.

3. Selection and design decisions

The path from need to requirement

1. Stakeholder needs: who uses, maintains, pays for and is affected by the robot; what each needs, in their words.
2. Concept of operations: a short description of a typical day: where the robot works, what it does, who is nearby. The handbook stresses that the concept of operations should be developed early.
3. Operational design domain: the conditions the robot is designed to work in (see the next guide).
4. Engineering requirements: each need becomes one or more “shall” statements with a value, a tolerance and a verification method.
5. Verification plan: for each requirement, how it will be shown to be met.

Functional and non-functional requirements

Writing rules (NASA Systems Engineering Handbook, Appendix C)

• “Shall” marks a requirement, “will” a fact or declaration of purpose, “should” a goal.
• Write “the product shall …”: one subject, one predicate, one thought per requirement.
• Give values with tolerances (less than, greater than or equal to, plus or minus).
• State what is needed, not how to provide it: free of implementation. Ask “why is this needed?”: the answer may be the real requirement.
• Use a positive form; avoid ambiguous terms such as “as appropriate”, “etc.”, “and/or”, “but not limited to”.
• Keep a rationale and the assumptions with each requirement; minimise TBD values, and mark estimates “to be resolved” (TBR) with who resolves them and by when.

4. Advantages and disadvantages

• Detail vs flexibility: precise requirements make design and testing possible, and make later change visible and costly; leaving a value open (TBR) lets the design proceed but must have an owner and a date.
• Requirement vs design: “the robot shall use a 2D LiDAR” is a design decision. Write the need (“detect a 0.3 m high obstacle at 3 m”) and choose the sensor in the design step.
• Few vs many: a short, well-formed set that is traceable beats a long list nobody reads.

5. Requirements and constraints

• Every requirement needs a verification method: analysis, inspection, demonstration or test (the handbook’s verification matrix columns).
• Requirements must be consistent: a payload, speed and runtime requirement together fix the battery; check them as a set.
• Customer-owned numbers (such as doorway width) should be measured on site, not assumed.

6. Architecture

stakeholder needs ─▶ concept of operations ─▶ operational design domain
                                  │
                                  ▼
              engineering requirements (shall, value, tolerance, rationale, verification method)
                                  │
                                  ▼
                   allocation to subsystems ─▶ design ─▶ verification against each requirement

7. Implementation

1. Interview stakeholders and write needs in their own words; keep them separate from requirements.
2. Write the concept of operations as a short story for a typical shift, including the unusual events (a blocked corridor, a power loss).
3. Draft requirements as “The robot shall …” with a value and tolerance; one per statement.
4. Run a checker over the list (below) and review by hand for implementation and ambiguity.
5. Add rationale, source (which need or standard), and verification method to each.
6. Review the whole set for conflicts (speed vs stopping distance, payload vs runtime).

import re
VAGUE = ["as appropriate", "etc.", "and/or", "but not limited to", "user-friendly", "fast", "robust", "reliable", "easy", "adequate", "sufficient", "minimal", "optimal", "flexible"]
def lint(req):
    low = req.lower()
    found = []
    if not re.search(r"\bshall\b", low):
        found.append("no 'shall'")
    found += [f"vague term '{w}'" for w in VAGUE if re.search(r"\b" + re.escape(w), low)]
    if not re.search(r"\d", req):
        found.append("no number")
    if low.count(" shall ") > 1:
        found.append("more than one 'shall'")
    if " shall not " in low:
        found.append("stated negatively")
    return found
reqs = ["The robot shall be fast and reliable.",
        "The robot shall carry a 10 kg payload at 1.0 m/s on a 5 degree slope for 8 h.",
        "The robot shall stop and shall notify the operator.",
        "The robot shall not collide with people."]
for i, r in enumerate(reqs, 1):
    print(i, lint(r) or "ok")

Printed (checked by the site’s tests):

1 ["vague term 'fast'", "vague term 'reliable'", 'no number']
2 ok
3 ['no number', "more than one 'shall'"]
4 ['no number', 'stated negatively']

Reading it: requirement 1 uses vague words and no number; 2 is a good form (numbers for payload, speed, slope and duration); 3 hides two requirements in one sentence; 4 is negative and has no number: replace it with a measurable form such as “The robot shall keep at least 0.5 m from any person detected at 1.0 m/s”. The checker finds form defects only; it cannot tell whether a number is right.

8. Real examples

• “The robot must be safe around people.” becomes: maximum speed near people, minimum clearance, stopping distance from full speed, and which safety function (safety-rated or not) provides the stop.
• “It should run all day.” becomes: runtime of 8 h at a stated duty cycle with a stated payload and a 20 min charge allowed.
• “Needs to find its way around.” becomes: localisation error below a limit over a stated route, in a stated environment, with a recovery requirement when localisation fails.

9. Failure scenarios

• Requirements that are goals: “as fast as possible”.
• Several requirements in one sentence, so one can fail while the sentence passes.
• A requirement that names a solution, which freezes a design choice nobody evaluated.
• No verification method, so “done” is an opinion.
• Assumed conditions (doorway width, floor type) never written down.

10. Troubleshooting

1. For a requirement that nobody can test: ask “how would we show this is met?”; if there is no answer, rewrite it.
2. For a requirement that keeps changing: find the underlying need and the condition behind it.
3. For two requirements that conflict: write both with their rationale and decide with the stakeholder; record the decision.

11. Validation

• Every requirement is a single “shall” statement with a value or a clear pass/fail condition.
• Every requirement has a rationale, a source and a verification method.
• A reviewer outside the project can say how each one will be tested.
• The checker output above matches (executed by the site tests).

12. Engineering checklist

• Needs and concept of operations written first
• One “shall” per requirement, with value and tolerance
• Free of implementation and vague words
• Rationale and assumptions recorded
• Verification method for each requirement
• TBD/TBR values owned and dated
• Set reviewed for conflicts

13. Further references

• NASA Systems Engineering Handbook, Rev 2 (S. R. Hirshorn, L. D. Voss and L. K. Bromley, NASA, 2017): ntrs.nasa.gov/citations/20170001761. Appendix C, “How to Write a Good Requirement – Checklist”, and Appendix D, “Requirements Verification Matrix”, were read on 2026-11-05; the section on the concept of operations is cited from the same document.
• The “shall / will / should” convention and the rule that a requirement states what is needed, not how, are from Appendix C of that handbook.

Related on FixTheRobot

• Engineering Trade-offs and Safety Cases Navigation · Lesson
• Measuring Navigation: Success, Efficiency, Safety and Comfort Navigation · Lesson