A robot is a physical, dynamical system that senses, computes, and acts in the real world. Unlike purely software systems, robots must satisfy control-theoretic, physical, and safety constraints simultaneously. Requirements engineering is the discipline that translates informal stakeholder needs into precise, testable conditions on robot behavior and on its subsystems (mechanical, electrical, software, and control).

Let \( \mathbf{x}(t) \in \mathbb{R}^n \) denote the robot state, \( \mathbf{u}(t) \in \mathbb{R}^m \) the control input, and \( \mathbf{y}(t) \in \mathbb{R}^p \) the measured outputs. At a high level, a behavioral requirement is a statement about admissible trajectories \( \mathbf{y}(\cdot) \) and possibly about \( \mathbf{x}(\cdot) \) and \( \mathbf{u}(\cdot) \).

\[ \text{Requirement } R \text{ is satisfied} \;\Longleftrightarrow\; (\mathbf{x}(\cdot), \mathbf{u}(\cdot), \mathbf{y}(\cdot)) \in \mathcal{S}_R \]

where \( \mathcal{S}_R \) is a specified subset of all possible trajectories. Requirements include:

• Functional: what tasks must the robot complete (e.g., pick-and-place).
• Performance: how fast, how accurate, how smooth, etc.
• Safety: limits on forces, distances to humans, speeds, etc.
• Reliability and robustness: behavior under disturbances, uncertainty, and faults.

In a robot project, requirements connect the high-level Sense–Think–Act architecture to concrete design decisions: sensor selection, controller tuning, mechanical sizing, and software structure.

flowchart TD
  A["Stakeholder needs (speed, accuracy, safety)"]
    --> B["System-level requirements (formal, testable)"]
  B --> C["Subsystem requirements (mechanical, control, software)"]
  C --> D["Detailed design & implementation"]
  D --> E["Verification (tests vs. requirements)"]
  E --> F["Validation with users & environment"]
        

We model robot behavior over a finite horizon \( [0, T_{\max}] \). Let \( \mathcal{B} \) denote the set of all measurable trajectories \( \mathbf{y} : [0, T_{\max}] \to \mathbb{R}^p \). A requirement \( R \) is:

\[ R : \mathcal{B} \to \{\text{true}, \text{false}\}, \quad R(\mathbf{y}(\cdot)) = \begin{cases} \text{true} & \text{if } \mathbf{y}(\cdot) \in \mathcal{S}_R,\\ \text{false} & \text{otherwise.} \end{cases} \]

In many control-related requirements, \( \mathcal{S}_R \) is expressed as an inequality constraint on some function of the trajectory. For example, for a tracking task with reference \( \mathbf{r}(t) \) and tracking error \( \mathbf{e}(t) = \mathbf{r}(t) - \mathbf{y}(t) \), a typical accuracy requirement is:

\[ R_{\text{acc}}:\quad \sup_{t \in [0, T_{\max}]} \lVert \mathbf{e}(t) \rVert_2 \leq e_{\max}, \]

where \( e_{\max} > 0 \) is a design parameter. If \( R_{\text{acc}}(\mathbf{y}(\cdot)) = \text{true} \), the tracking error never exceeds \( e_{\max} \).

Another example is an integral performance requirement, such as a bound on the integral squared error (ISE):

\[ R_{\text{ISE}}:\quad \int_{0}^{T_{\max}} \lVert \mathbf{e}(t) \rVert_2^2 \, \mathrm{d}t \leq J_{\max}. \]

In practice, requirements engineering for robots means building a set \( \{R_1, \dots, R_N\} \) and ensuring that the closed-loop system can be designed so that:

\[ R_{\text{all}}(\mathbf{y}(\cdot)) := \bigwedge_{k=1}^N R_k(\mathbf{y}(\cdot)) = \text{true}, \]

i.e., all individual requirements are satisfied simultaneously. Detecting incompatibilities between requirements is a key early activity in the design process.

Because students are familiar with linear control, we now connect standard step-response specifications to formal requirements. Consider a single joint under closed-loop control, with transfer function from reference \( r(t) \) to position \( y(t) \) approximated by a second-order model:

\[ G_{\text{cl}}(s) = \frac{\omega_n^2}{s^2 + 2\zeta \omega_n s + \omega_n^2}, \]

where \( \zeta \) is the damping ratio and \( \omega_n \) the natural frequency. For a unit step input, the standard relations are:

\[ M_p = \exp\!\left( -\frac{\pi \zeta}{\sqrt{1 - \zeta^2}} \right), \quad T_s \approx \frac{4}{\zeta \, \omega_n} \quad (\text{2\% settling time}). \]

Suppose the system-level requirement is:
“For each actuated joint, the closed-loop position step response must have \( M_p \leq 10\% \) and \( T_s \leq 0.5 \,\mathrm{s} \).”

This becomes a joint-level requirement on \( (\zeta_i, \omega_{n,i}) \) for each joint \( i \):

\[ R_{\text{perf}, i}:\quad \exp\!\left( -\frac{\pi \zeta_i}{\sqrt{1 - \zeta_i^2}} \right) \leq 0.10, \quad \frac{4}{\zeta_i \, \omega_{n,i}} \leq 0.5. \]

Solving the overshoot inequality for \( \zeta_i \):

\[ \exp\!\left( -\frac{\pi \zeta_i}{\sqrt{1 - \zeta_i^2}} \right) \leq 0.10 \;\Longleftrightarrow\; -\frac{\pi \zeta_i}{\sqrt{1 - \zeta_i^2}} \leq \ln(0.10). \]

Since \( \ln(0.10) < 0 \), multiplying by \( -1 \) reverses the inequality:

\[ \frac{\pi \zeta_i}{\sqrt{1 - \zeta_i^2}} \geq -\ln(0.10). \]

One can solve numerically for \( \zeta_i \), obtaining approximately \( \zeta_i \gtrsim 0.59 \). The settling-time requirement then yields a lower bound on \( \omega_{n,i} \):

\[ \frac{4}{\zeta_i \, \omega_{n,i}} \leq 0.5 \;\Longleftrightarrow\; \omega_{n,i} \geq \frac{8}{\zeta_i}. \]

This illustrates how informal statements (“fast and without much overshoot”) become precise constraints on closed-loop pole locations, suitable for controller design and tuning.

Robotic systems must respect physical limits (joint ranges, torques, speeds) and safety margins with respect to humans and the environment. These are often captured as state and input constraints holding for all time.

Let \( \mathbf{q}(t) \in \mathbb{R}^{n_q} \) be the joint angles and \( \mathbf{\dot{q}}(t) \) their velocities. For each joint \( j \), we may have limits:

\[ q_{j,\min} \leq q_j(t) \leq q_{j,\max}, \quad \lvert \dot{q}_j(t) \rvert \leq \dot{q}_{j,\max}, \quad \lvert \,\tau_j(t) \rvert \leq \tau_{j,\max}, \quad \forall t \in [0, T_{\max}]. \]

These can be grouped into a safety requirement:

\[ R_{\text{joint-safe}}:\quad (\mathbf{q}(\cdot), \mathbf{\dot{q}}(\cdot), \tau(\cdot)) \in \mathcal{S}_{\text{joint-safe}}, \]

where \( \mathcal{S}_{\text{joint-safe}} \) is the set of all trajectories satisfying the inequalities above.

For human–robot separation, if \( \mathbf{p}_r(t), \mathbf{p}_h(t) \in \mathbb{R}^3 \) denote robot end-effector and human positions, a minimum distance requirement is:

\[ R_{\text{dist}}:\quad \lVert \mathbf{p}_r(t) - \mathbf{p}_h(t) \rVert_2 \geq d_{\min}, \quad \forall t \in [0, T_{\max}]. \]

Such requirements directly influence mechanical design (workspace and reach), controller tuning (to avoid aggressive motions), and the safety architecture (emergency stops, speed and separation monitoring, etc.).

System-level requirements are typically too abstract to implement directly. They must be decomposed into requirements for subsystems and components, while maintaining traceability: each low-level requirement must be linked back to some higher-level need.

Example: “The robot shall complete a pick-and-place cycle in at most \( T_{\text{cycle}}^{\max} = 2 \,\mathrm{s} \) with positioning error below \( 1 \,\mathrm{mm} \).” If the end-effector must traverse a path of length \( L \), the average speed must satisfy:

\[ \bar{v} = \frac{L}{T_{\text{cycle}}} \geq \frac{L}{T_{\text{cycle}}^{\max}}. \]

If joint velocities are bounded by \( \lVert \mathbf{\dot{q}}(t) \rVert_2 \leq v_q^{\max} \) and the robot Jacobian is \( \mathbf{J}(\mathbf{q}) \), then \( \bar{v} \leq v_q^{\max} \, \sup_{\mathbf{q}} \sigma_{\max}(\mathbf{J}(\mathbf{q})) \), where \( \sigma_{\max} \) is the largest singular value. This couples requirements on cycle time to kinematic and actuator capabilities.

The decomposition from system-level to component-level can be visualized as a refinement tree:

flowchart TD
  R0["System: cycle time <= 2 s, error <= 1 mm"]
    --> R1["Planning: feasible trajectory \nwith length L and no collisions"]
  R0 --> R2["Control: tracking error bound, \novershoot <= 10%"]
  R0 --> R3["Actuation: joint speed <= v_q_max, \ntorque <= tau_max"]
  R2 --> R4["Controller bandwidth >= omega_bw_min"]
  R3 --> R5["Motor sizing, gear ratios, \nand thermal limits"]
        

A good requirements document includes explicit links: e.g., “R3 is derived from R0 and R1” and “this test case verifies R2 and R4”. Such traceability is essential in safety- and mission-critical robotics.

Formal methods often express requirements using temporal logics (e.g., Linear Temporal Logic, LTL) over discrete-time traces. Without going into algorithmic model checking, we can still exploit the idea that many robot requirements have common patterns:

• Invariants: “always safe”.
• Reachability: “eventually reach a goal”.
• Response: “if event A happens, eventually response B occurs”.

Consider a discrete-time sequence of outputs \( \mathbf{y}_0, \mathbf{y}_1, \dots \) sampled at period \( h \). Using temporal operators “always” \( \square \) and “eventually” \( \lozenge \), an invariant safety requirement can be written as:

\[ \varphi_{\text{safe}} := \square \left( \lVert \mathbf{p}_r - \mathbf{p}_h \rVert_2 \geq d_{\min} \right), \]

whereas a simple task requirement might be:

\[ \varphi_{\text{goal}} := \lozenge \left( \lVert \mathbf{y} - \mathbf{y}_{\text{goal}} \rVert_2 \leq \varepsilon \right). \]

A response requirement for emergency stop could be:

\[ \varphi_{\text{stop}} := \square \left( \text{obstacle\_detected} \Rightarrow \lozenge_{[0, N_{\text{stop}}]} \left( v = 0 \right) \right), \]

where \( \lozenge_{[0, N_{\text{stop}}]} \) denotes “eventually within \( N_{\text{stop}} \) sampling steps”. These formal patterns provide a mathematically precise semantics for requirements and can, in more advanced courses, be checked automatically on models or logged data.

We now show a minimal Python implementation for trajectory-based requirements. The idea is to represent requirements as objects that can be evaluated on sampled time-series data from simulation or experiments, e.g., stored as NumPy arrays.

import numpy as np
from dataclasses import dataclass
from typing import Protocol, Dict, Any

class TrajectoryRequirement(Protocol):
    def check(self, t: np.ndarray, signals: Dict[str, np.ndarray]) -> bool:
        ...

@dataclass
class MaxTrackingError(TrajectoryRequirement):
    ref_key: str
    out_key: str
    e_max: float

    def check(self, t: np.ndarray, signals: Dict[str, np.ndarray]) -> bool:
        r = signals[self.ref_key]
        y = signals[self.out_key]
        e = r - y
        e_norm = np.linalg.norm(e, axis=1)  # assume shape (N, p)
        return float(np.max(e_norm)) <= self.e_max

@dataclass
class MinSeparation(TrajectoryRequirement):
    r_key: str     # robot position
    h_key: str     # human position
    d_min: float

    def check(self, t: np.ndarray, signals: Dict[str, np.ndarray]) -> bool:
        p_r = signals[self.r_key]   # shape (N, 3)
        p_h = signals[self.h_key]   # shape (N, 3)
        d = np.linalg.norm(p_r - p_h, axis=1)
        return bool(np.all(d >= self.d_min))

def check_all_requirements(
    t: np.ndarray,
    signals: Dict[str, np.ndarray],
    requirements: Dict[str, TrajectoryRequirement]
) -> Dict[str, bool]:
    results = {}
    for name, req in requirements.items():
        results[name] = req.check(t, signals)
    return results

# Example usage with sampled trajectories:
N = 1000
t = np.linspace(0.0, 2.0, N)
# Fake 1D position reference and output
r = np.ones((N, 1))  # constant 1 m
y = r + 0.002 * np.sin(10.0 * t)  # small oscillation

# Fake positions for robot and human
p_r = np.column_stack([0.5 * np.ones(N), 0.0 * t, 0.0 * t])
p_h = np.column_stack([0.0 * t, 0.0 * t, 0.0 * t])

signals = {
    "ref": r,
    "y": y,
    "p_r": p_r,
    "p_h": p_h,
}

reqs = {
    "tracking": MaxTrackingError(ref_key="ref", out_key="y", e_max=0.01),
    "separation": MinSeparation(r_key="p_r", h_key="p_h", d_min=0.2),
}

results = check_all_requirements(t, signals, reqs)
for name, ok in results.items():
    print(f"{name}: {'OK' if ok else 'VIOLATED'}")
      

In a ROS-based system, the signals dictionary could be obtained from recorded topics (e.g., from a rosbag), allowing automatic regression testing of requirements after each software change.

In embedded or real-time robot control software, requirements are often checked online to trigger safety actions. The following C++ snippet illustrates checking a simple invariant (distance to human) and a response requirement (stop within a given reaction time in samples).

#include <vector>
#include <cmath>

struct Vec3 {
    double x, y, z;
};

double distance(const Vec3& a, const Vec3& b) {
    const double dx = a.x - b.x;
    const double dy = a.y - b.y;
    const double dz = a.z - b.z;
    return std::sqrt(dx * dx + dy * dy + dz * dz);
}

class SafetyMonitor {
public:
    SafetyMonitor(double d_min, int stop_steps)
        : d_min_(d_min),
          stop_steps_(stop_steps),
          steps_since_obstacle_(-1) {}

    void update(const Vec3& p_r, const Vec3& p_h, double v, bool obstacle_detected) {
        // Invariant: minimum separation
        double d = distance(p_r, p_h);
        if (d < d_min_) {
            // Requirement violation: trigger emergency stop
            triggerEmergencyStop("Separation distance violated");
        }

        // Response-type requirement: if obstacle detected, stop within stop_steps_
        if (obstacle_detected) {
            if (steps_since_obstacle_ < 0) {
                steps_since_obstacle_ = 0;
            }
        }

        if (steps_since_obstacle_ >= 0) {
            if (v > 0.0 && steps_since_obstacle_ > stop_steps_) {
                triggerEmergencyStop("Reaction time requirement violated");
            }
            ++steps_since_obstacle_;
        }
    }

private:
    void triggerEmergencyStop(const char* reason) {
        // Implementation-specific: log, cut power, activate brakes, etc.
        // For illustration, we might set flags or send messages.
        // In a real robot, this function must be thoroughly tested.
    }

    double d_min_;
    int stop_steps_;
    int steps_since_obstacle_;
};
      

In a full system, instances of SafetyMonitor would be integrated in the control loop running at a fixed period, using estimates of positions and velocities from the robot state estimator and environment perception modules.

Java is often used in simulation tools or higher-level orchestration layers. Here we show how to encode a reachability requirement and log whether it is satisfied for a simulated trajectory.

public interface TrajectoryRequirement {
    boolean check(double[] t, double[] y);
}

public class ReachGoalWithinTime implements TrajectoryRequirement {
    private final double yGoal;
    private final double epsilon;
    private final double tMax;

    public ReachGoalWithinTime(double yGoal, double epsilon, double tMax) {
        this.yGoal = yGoal;
        this.epsilon = epsilon;
        this.tMax = tMax;
    }

    @Override
    public boolean check(double[] t, double[] y) {
        for (int k = 0; k < t.length; ++k) {
            if (t[k] > tMax) {
                break;
            }
            double e = Math.abs(y[k] - yGoal);
            if (e <= epsilon) {
                return true; // requirement satisfied
            }
        }
        return false;
    }
}

// Example usage in a simulation context
public class RequirementDemo {
    public static void main(String[] args) {
        int N = 1000;
        double[] t = new double[N];
        double[] y = new double[N];
        double T = 2.0;

        // Simple ramp trajectory y(t) = t, sampled uniformly
        for (int k = 0; k < N; ++k) {
            t[k] = T * k / (N - 1);
            y[k] = t[k];
        }

        TrajectoryRequirement req =
            new ReachGoalWithinTime(1.0, 0.01, 1.5);

        boolean ok = req.check(t, y);
        System.out.println("Reachability requirement: " + (ok ? "OK" : "VIOLATED"));
    }
}
      

Such requirement objects can be attached to simulation test cases, enabling automated regression checks: after each change to control or planning code, the test suite verifies that key requirements are still satisfied.

MATLAB, together with the Control System Toolbox and Simulink, is well suited for control-oriented requirement checks. The following MATLAB script checks whether a closed-loop system meets overshoot and settling-time specifications using standard step response metrics.

% Plant and controller (example)
s = tf('s');
G = 1 / (0.1 * s + 1);          % simple first-order plant
Kp = 5;
C = Kp;                         % proportional controller

T_cl = feedback(C * G, 1);      % closed-loop transfer function

% Step response info
info = stepinfo(T_cl);

Mp_allowed = 10;    % percent
Ts_allowed = 0.5;   % seconds

req_overshoot = (info.Overshoot <= Mp_allowed);
req_settling  = (info.SettlingTime <= Ts_allowed);

if req_overshoot && req_settling
    disp('Requirements satisfied: overshoot and settling time within bounds.');
else
    disp('Requirements violated:');
    fprintf('  Overshoot = %.2f%% (allowed %.2f%%)\n', info.Overshoot, Mp_allowed);
    fprintf('  Settling time = %.3f s (allowed %.3f s)\n', info.SettlingTime, Ts_allowed);
end
      

In Simulink, one can connect the robot model (or an axis model) to a Step block and use Assertion blocks to enforce inequalities, such as abs(error) <= e_max or speed <= v_max. When an assertion fails, Simulink reports a violation, making the requirements executable and automatable.

In this lesson, we introduced requirements engineering as a foundational activity in robot system design. We formalized requirements as predicates on trajectories, connected classical control specifications to explicit inequalities on closed-loop dynamics, and expressed safety constraints as invariants on states and inputs. We discussed decomposition and traceability from system-level needs to subsystem requirements and sketched common formal patterns (invariant, reachability, response) using temporal operators.

We also demonstrated how requirements can be made executable in software: Python scripts that check logs, C++ and Java components that guard real-time operations, and MATLAB/Simulink workflows that integrate requirements into control design and simulation. These ideas will be used throughout the rest of the chapter, where we move from requirements to concept generation, co-design, and prototyping for full robot systems.