Turn a Mission into Requirements

The capstone begins with a mission, not a robot shape.

Choose a bounded autonomous robotics problem such as:

• move materials between two stations;
• inspect a simulated environment;
• sort objects;
• follow a route and report measurements;
• assist with a repetitive classroom or lab task.

Do not choose a mission that requires uncontrolled public operation, unsafe hardware, private data, or access you do not have.

Mission statement

Write one sentence describing the outcome.

Then convert it into requirements.

Weak:

The robot should be fast and safe.

Testable:

• complete the simulated route within 45 seconds;
• remain inside the defined motion boundary;
• enter a stopped state within the specified test condition after a stop input;
• reject stale localization data older than the configured threshold;
• record mission state and fault events.

Functional requirements versus design choices

A requirement says what the system must accomplish.

A design choice says how you plan to accomplish it.

Requirement:

The robot shall detect the target object within the defined test area.

Design choice:

Use a camera and color thresholding.

Do not lock yourself into a solution before the problem requires it.

Constraints

Include:

• environment;
• available power;
• size/mass assumptions;
• computation;
• sensors;
• human control;
• safety boundary;
• privacy/data;
• time;
• budget or material limits.

Build the requirement set

Create at least:

• five functional requirements;
• three safety/human-control requirements;
• two performance requirements;
• two interface/data requirements;
• two constraints.

Give every requirement an ID such as R-01.

The IDs will connect architecture and tests later.

Requirements need measurable verbs

Compare:

The robot should navigate safely.

with:

The robot shall remain inside the defined operating boundary and enter the safe-stop state within the required response interval after loss of valid localization.

The second statement is longer because it names behavior that can be tested.

Strong requirements define enough of these elements to become inspectable:

• trigger or operating condition;
• system behavior;
• measurable limit;
• evidence or verification method;
• important exception or boundary.

Build a requirement set across layers

For a delivery robot, requirements might include:

The requirements force the capstone to remain a system, not a list of favorite technologies.

Before drawing architecture, reject any requirement you cannot imagine verifying.