M8-T1: System requirements engineering

Learning objectives

After this lesson, you should be able to:

• Derive stakeholder needs and hazards from a concept of operations.
• Write requirements that are unambiguous, measurable and verifiable, with condition, threshold, statistic and method.
• Recognise and fix common requirement defects.
• Run a simple automatic lint on a requirements set.

Conceptual explanation

Established The practices follow common systems-engineering guidance (for example the INCOSE guide to writing requirements and the NASA Systems Engineering Handbook). The example requirement values are illustrative, not recommended values for any real system.

Start from the concept of operations (ConOps): who operates the UAV, in which environment (indoor, urban canyon, forest, open field), for how long, with what payload, what failures must be tolerated, and what the vehicle must not do. From the ConOps derive needs (what stakeholders require) and hazards (what can go wrong and hurt people, property or the mission). Requirements are then written to satisfy needs and mitigate hazards.

A well-formed requirement has these parts:

Engineering intuition

Ask of every requirement: could two engineers read it, build independently, and both pass the same test? Words like “fast”, “accurate”, “robust”, “reliable”, “as appropriate” and “etc.” fail that test. Numbers without a statistic fail too: “position error below 2 m” could mean always, on average or in 95 % of samples, which are very different designs and very different amounts of testing.

The condition is where navigation requirements most often hide risk. A GNSS-denied accuracy requirement is meaningless without the duration, the speed, the environment (texture, lighting, dynamic objects) and the sensor set. Writing the condition forces the team to state the limits of the claim, which later becomes the operational limitation (see the last lesson of this module).

Mathematical formulation

Statistical statements need a sample size to verify. To show that a requirement “error ≤ $L$ with probability at least p” holds with confidence $C$ by $n$ independent trials with $k$ failures allowed, the success-run theorem for $k=0$ gives

With a failure allowed the binomial bound (Clopper–Pearson) applies. This is why “99.9 % success” cannot be demonstrated by a handful of flights: the requirement writer must decide whether it is to be shown by flight test, by simulation with validated models (many runs), or by analysis, and write that in the requirement’s verification method. Continuous error metrics are usually stated as percentiles of the error over time or over runs; state which, because the sample unit (per sample, per segment, per flight) changes the effective sample size and the correlation between samples.

$p$

required success probability (or percentile level).

$C$

confidence level of the demonstration.

$n$

number of independent trials.

Architecture and data flow

ConOps and hazard analysis → needs list → system requirements (each with ID, text, rationale, verification method, owner, parent need or hazard) in a version-controlled file → allocation to subsystems (next lesson) → test cases (traceability matrix) → results. The requirements file is the input of the traceability checker and of the review. Requirement changes go through the change-control process of the configuration management lesson.

Real-world UAV applications

• Writing the navigation requirements for a GNSS-denied inspection UAV.
• Reviewing a supplier’s specification for a perception sensor.
• Deriving test cases and flight-test cards from requirements.
• Stating the operational envelope in which a claim is made.

Implementation example

This runs as shown. A requirements linter: it flags weak words, missing numbers, missing conditions, missing statistics and missing verification methods, then computes the zero-failure sample size for statistical requirements. The example requirements are illustrative.

import re, math
WEAK = ['accurate', 'accurately', 'fast', 'robust', 'reliable', 'as appropriate', 'etc', 'user-friendly', 'adequate', 'sufficient', 'minimal', 'quickly', 'efficient', 'where possible', 'and/or']
STAT = ['percentile', 'mean', 'maximum', 'rms', 'probability', 'at all times', 'never', 'median']
reqs = {
 'R-1': "The UAV shall navigate accurately without GNSS.",
 'R-2': "The navigation system shall keep the horizontal position error below 2.0 m at the 95th percentile over any 5-minute interval without GNSS, in daylight, with wind below 8 m/s. Verification: flight test against a motion-capture reference.",
 'R-3': "On loss of visual odometry the system shall detect the loss within 0.5 s and transition to a landing or hold behaviour. Verification: fault injection in SIL and HIL, then flight test.",
 'R-4': "The system should be robust and respond quickly to failures, etc."}
def lint(text):
    t = text.lower(); issues = []
    if 'shall' not in t: issues.append("no 'shall' (obligation unclear)")
    issues += [f"weak word '{w}'" for w in WEAK if re.search(r'\b' + re.escape(w) + r'\b', t)]
    if not re.search(r'\d', t): issues.append('no number (not measurable)')
    if re.search(r'error|accuracy', t) and not any(s in t for s in STAT): issues.append('error quantity without a statistic')
    if not re.search(r'\b(in|during|over|within|on|with|without|below|above|when)\b', t): issues.append('no condition')
    if 'verification' not in t: issues.append('no verification method')
    return issues
for k, v in reqs.items(): print(k, lint(v) or 'OK')
assert lint(reqs['R-2']) == [] and lint(reqs['R-3']) == [] and len(lint(reqs['R-1'])) >= 3 and len(lint(reqs['R-4'])) >= 4
n_zero = lambda p, c: math.ceil(math.log(1 - c) / math.log(p))
print("zero-failure trials: 95 % @ 90 % confidence:", n_zero(0.95, 0.90), "; 99 % @ 95 %:", n_zero(0.99, 0.95), "; 99.9 % @ 95 %:", n_zero(0.999, 0.95))
assert n_zero(0.95, 0.90) == 45 and n_zero(0.99, 0.95) == 299

Common engineering mistakes

Failure modes

Debugging approach

1. Run the linter on the whole set before each review.
2. Write the test for each requirement immediately; if you cannot, rewrite the requirement.
3. Ask a colleague who did not write it to restate it in their own words.
4. Check the sample size implied by each statistical requirement.

Practical exercises

1. Rewrite “the UAV shall hover steadily” as a verifiable requirement.
2. List five conditions that must be stated for a GNSS-denied accuracy requirement.
3. Compute the number of zero-failure trials for 97 % at 90 % confidence.
4. Derive three needs and two hazards from a ConOps for a warehouse inventory UAV.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• INCOSE Systems Engineering Handbook
• NASA Systems Engineering Handbook (NASA/SP-2007-6105)

What’s next