systems engineering//requirement

A requirement is a written statement of what a system must do or be, precise enough that a test can show whether it is met; it is used as the unit of agreement between a customer and a builder, between system engineers and the teams who design each part, and between the builder and a certifier, who checks that every requirement was implemented and verified. Writing that *the drone must be precise* states a wish. Writing that *in steady wind up to 8 m/s, the horizontal position error in hover shall be under 0.5 m 95 % of the time, measured against an RTK reference over 10 minutes* states a requirement: it says what, how much, under which conditions and how it will be checked.

A requirement is a written statement of what a system must do or be, precise enough that a test can show whether it is met; it is used as the unit of agreement between a customer and a builder, between system engineers and the teams who design each part, and between the builder and a certifier, who checks that every requirement was implemented and verified. Writing that the drone must be precise states a wish. Writing that in steady wind up to 8 m/s, the horizontal position error in hover shall be under 0.5 m 95 % of the time, measured against an RTK reference over 10 minutes states a requirement: it says what, how much, under which conditions and how it will be checked.

Each of those four parts closes a door to argument. Without the condition (8 m/s wind) the requirement can be met in a calm lab and failed on the first windy day; without the statistic (95 %) a single gust settles nothing; without the method (RTK, 10 minutes) the builder and the customer measure different things and both are right. A requirement missing any part cannot be verified, and one that cannot be verified cannot be signed off.

A system requirement spawns derived requirements for every part that contributes to it. The 0.5 m above becomes a sensor accuracy, a latency limit, an estimator error and a control tracking error, and the tool that does the split is the error budget: allocate the total among the sources so that their combination fits, and each team receives a number it can design and test against.

Traceability is the thread that keeps requirements honest: each requirement knows the design elements and code that implement it and the tests that verify it, and each piece of code traces back to a requirement. It is what lets a team answer, when a requirement changes, which modules and tests must change with it, and what certification standards such as DO-178C audit (V-model).

Safety requirements come from hazard analysis, done before the functional ones, and carry an integrity level that decides how much evidence their verification must produce (functional safety).

A requirement says what the system must achieve and leaves the how to design. A line such as use a Kalman filter is a design decision written in the wrong document; it removes the option of a cheaper solution that would meet the real need (flyswatter rule).

Learned components strain the form, since their behaviour is specified by data rather than by statements; their requirements are usually written at the boundary (accuracy on a defined dataset, behaviour in a defined operating domain) and paired with monitors.

Requirements are the input of systems engineering and the yardstick of verification.