How to write good system requirements: examples and checklist

Why the wording of a requirement matters

A requirement is a contract between the people who ask for a system and the people who build it. Everything downstream reads it: the designer sizes a component against it, the test engineer writes a pass criterion from it, the change board weighs a change against it, and the customer accepts the system by it. Each of them reads the same sentence, usually without the author in the room. If the sentence can be read two ways, it will be, and the difference surfaces late: at a test that "passes" against a criterion nobody agreed, or at acceptance, when the customer meant something else.

Poor wording also breaks the rest of the model. A requirement without a value cannot be allocated to a component, because nobody can say whether the component meets it. It cannot be verified, so it shows up as a coverage gap in the traceability and the verification matrix. And when it changes, nobody can tell whether the linked design still holds. Writing requirements well is the cheapest quality work in a project: an hour on a sentence at the start saves a test campaign at the end.

The guide uses one running example, EO-1, a fictional 6U CubeSat that images farmland in four spectral bands. Its specification, SRS-001 EO-1 System Requirements Specification, has 32 requirements, most of them sound and three of them weak on purpose. It is the same model as the end-to-end MBSE example project. The stakeholder needs N1 to N3 quoted here are the ones the traceability guide adds to the model.

Stakeholder needs versus requirements

Requirements writing starts one step earlier, with the needs. A stakeholder need is what a user, operator, customer or regulator expects, in their own terms. A requirement is the engineering statement the system is designed and verified against. ISO/IEC/IEEE 15288 keeps the two apart in separate technical processes: stakeholder needs and requirements definition (6.4.2) and system requirements definition (6.4.3). The INCOSE Needs and Requirements Manual makes the same split and treats needs as items in their own right, not as rough drafts of requirements.

The difference shows in how each is checked. A requirement is verified: the system is measured against the statement. A need is validated: someone confirms that the system, in its intended use, does what the stakeholder wanted. A system can pass every verification and still fail validation if the requirements missed the point; the verification vs validation guide covers that gap. For writing, the practical consequence is simple: write the need first, then write requirements that would satisfy it if met, and link each requirement back to the need it answers.

The translation is rarely one to one. N2 becomes 1.6 Revisit Time, which is then decomposed into 1.6.1 Ground Track Repeat (3 days) and 1.6.2 Off-Nadir Imaging (25 degrees). Some requirements answer no need directly: 3.1 Orbit Average Power is derived from 1.5 Daily Collection Volume, because the imaging load sets the power the arrays must supply. No customer asked for 30 W, but the imaging they did ask for cannot happen without it.

The anatomy of a requirement

A requirement is more than its sentence. The sentence carries the obligation; a set of attributes around it carries the reasons, the plan for proving it and the bookkeeping. Both halves are part of writing it.

The statement

Most good requirement statements fit one pattern. ISO/IEC/IEEE 29148 (5.2.4) describes it as a subject, an action, an object and constraints on the action, with an optional condition in front; the INCOSE Guide to Writing Requirements recommends the same order and agreed templates for each kind of requirement.

Together: "The C&DH shall enter safe mode within 10 seconds of undervoltage detection." The order can move ("When undervoltage is detected, the C&DH shall…" puts the condition first, as in the EARS templates many teams use), but every part should be there or deliberately absent.

Three words carry most of the weight. Shall marks a binding requirement; will states a fact or an intent about something outside the system; should states a goal that is not verified. Whatever convention a project uses, define it once in the specification and keep to it. EO-1 1.1 Reference Orbit ("The mission assumes a 500 km sun-synchronous orbit…") is correctly written as an assumption, not a requirement: it is context for the requirements that depend on it, and the model stores it as a statement that is not scored or verified.

The attributes

Here is 3.1 Orbit Average Power as the EO-1 model records it, after the post-PDR change from 28 W to 30 W:

ISO/IEC/IEEE 29148 (5.2.8) lists attributes of this kind, and the INCOSE guide adds more; a project picks the ones it will actually maintain. The rationale is the one most often skipped and most often missed later. Without "26 W load, 15% margin", the next person to see 3.1 cannot tell whether 30 W is a hard physical limit, a customer number or a margin choice, and so cannot tell what a change to the load means for it.

Quality characteristics of a good requirement

Style rules are easier to apply when you know what they protect. ISO/IEC/IEEE 29148 (5.2.5) names nine characteristics of an individual requirement, and the INCOSE Guide to Writing Requirements uses the same nine as its C1 to C9, each with a short definition and the rules that support it. The table puts each one as a question a reviewer can ask.

A requirement set has characteristics of its own that no single statement can show. ISO/IEC/IEEE 29148 (5.2.6) lists the set as complete, consistent, feasible as a whole, comprehensible and able to be validated; the INCOSE guide adds correct as C15 and numbers the set characteristics C10 to C15.

• Complete: the set covers the needs. EO-1 states what happens on an undervoltage (4.3) but its only safe mode recovery requirement is 2.5, which is unverifiable as written, so recovery is effectively unspecified.
• Consistent: no two requirements conflict, and terms and units are used the same way. 1.5 asks for 3.2 GB of image data per day and 5.4 for 3 GB received on the ground; they agree only because 5.4's rationale says "after compression". Without the rationale they look like a conflict.
• Feasible: the requirements can be met together. Each power requirement may be feasible alone, while 30 W orbit average, the array area and the mass budget together may not be.
• Comprehensible: a reader can tell what is expected of the system and how the requirements relate, which depends on structure, numbering and traceability as much as on wording.
• Able to be validated: the set can be shown to lead to a system that meets the needs, which is why each top-level requirement links back to a need.

The checklist: rules with before and after examples

The characteristics become usable through concrete writing rules. The INCOSE Guide to Writing Requirements numbers them (R1, R2 and so on); the NASA Systems Engineering Handbook (Appendix C) has a shorter checklist on the same lines. The table collects the rules that catch most problems in practice, with an example from the EO-1 specification for each. "Before" is the text as it stands in the demo; "After" is a rewrite. Values marked illustrative show the form, not results of EO-1 analyses.

A checklist is a reviewer's tool, not a writing template. Read each requirement once against the whole list rather than hunting for one rule at a time, and record the finding with the rule it breaks, so the author knows what to change. Rules also have false positives. A word-list check flags "every" in 1.6.1 as a universal qualifier, but "every 3 days" is a period, not a claim about all cases; a reviewer decides.

Write the verification method and acceptance criteria with the requirement

The verifiable characteristic is easiest to check at the moment the requirement is written: if the author cannot say how it would be shown to be met, it is not finished. Record two things with each requirement.

• Verification method: test, analysis, inspection or demonstration, and the level of assembly at which it is done (component, subsystem, system). EO-1 has all four: 3.1 is verified by test, 1.5 Daily Collection Volume by analysis, 3.4 Bus Regulation by inspection and 6.1 Contact Scheduling by demonstration. The RVTM guide explains how to choose among them.
• Success criteria (acceptance criteria): the observable result that counts as met, stated so that the test or analysis can be written from it. For 3.2 Battery Capacity: "Measured capacity of at least 77 Wh at C/2 and 20 °C." For 6.2 Image Delivery: "Products on the portal within 6 h for 95% of passes in rehearsal."

Writing the criteria next to the statement catches a class of error that is otherwise found only at the end. EO-1's 3.1 is verified by TC-06 Solar Array Power Test, which measures peak power on a solar simulator and passes at 72 W or more. The requirement, though, is about orbit-average power, and the model converts one into the other with the sunlit fraction (0.62) and the power path efficiency (0.6). A 72 W peak gives 72 × 0.62 × 0.6 = 26.8 W orbit average, which is below the original 28 W, never mind the current 30 W. The test threshold was not derived from the requirement. TC-06 measured 75.1 W and "passed", yet 75.1 W converts to 27.9 W, short of both values. Had the criterion been written from the statement, it would have read about 30 / (0.62 × 0.6) = 80.6 W peak, and the shortfall would have been visible at the first test. The change impact analysis guide follows the same finding through the change from 28 W to 30 W.

The lesson generalizes: a pass criterion should be traceable to the requirement's value by arithmetic someone can check, and the arithmetic belongs in the rationale or the verification plan, not in an engineer's memory.

Handling TBD and TBR values

Early in a project some values are not known yet. Leaving the requirement out hides the gap; inventing a number hides the uncertainty. The usual practice is to write the requirement with a placeholder and track the placeholder as an open item.

• TBD (to be determined): no value yet. "The thermal design shall keep the battery cell temperature at or above TBD °C while charging."
• TBR (to be reviewed, sometimes "to be resolved"): a best current value that is not confirmed. "…within 60 seconds" with 60 marked TBR.

Prefer TBR with an estimate over a bare TBD wherever there is any basis for a number: designers can work to an estimate, and a value that later moves is a change, which the traceability will follow. Each open item needs three things, or it is not being managed:

1. An owner, the person who will close it.
2. A due date or milestone, normally before the design decisions that depend on it.
3. A closure plan: the analysis, test or decision that will set the value.

The EO-1 specification has three open items. 3.5 Battery Thermal Control is a TBD owned by the Thermal Engineer and already overdue. 2.4 Target Slew ("through 30 degrees within 60 seconds") is a TBR owned by the ADCS Lead, and 5.3 Downlink Link Margin ("at least 3 dB link margin at 10 degrees elevation") is a TBR owned by the Comms Lead; both carry working values that the designs use while the analyses finish.

Count the open items at each milestone and expect the count to fall. A requirements baseline with many open TBDs is a baseline in name only. The review criteria in the NASA Systems Engineering Handbook ask, from the system requirements review on, that open TBD and TBR items be identified with a plan and schedule for closing them. The tracking belongs in an attribute or a register, not only in the text: a "TBD" typed into a sentence has no owner and no date, and nothing reminds anyone to close it.

Requirement types

Classifying requirements helps reviewers ask the right questions and helps the set stay complete. The categories below are the common ones; ISO/IEC/IEEE 29148 and the INCOSE guide describe similar sets, and many projects add their own.

The line between functional and performance requirements is often drawn inside one sentence: many requirements state a function with its performance, as 4.3 does. That is fine as long as the sentence still holds one obligation. Interface requirements are covered in more depth in the interface control document guide, and the functions behind functional requirements in the functional analysis guide.

Worked example: reviewing the EO-1 specification

A review of SRS-001 against the checklist splits the 32 requirements into three groups. Most pass. A few have small findings worth a sentence each. Three need rewriting.

An automatic check of the same specification agrees with the review: 29 of 32 requirements score as good, and the three weak ones need rework. The findings for 2.5 list each broken rule by name and number, which is what an author needs to fix it. The check also marks what it cannot decide: on 3.1, correctness and feasibility wait for a reviewer because the text changed after the last review.

Small findings

• 1.6.2 Off-Nadir Imaging, "up to 25 degrees off nadir": "up to" reads as a maximum, but the intent is a capability the spacecraft must have at any angle from 0 to 25 degrees. A wrong reading would let a design that only images at nadir comply.
• 1.6.1 Ground Track Repeat, "its ground track": a pronoun with only one possible referent, so the finding is minor. The "every" in the same sentence is a false positive of a universal-qualifier rule.
• 1.5 Daily Collection Volume has a method (analysis) and success criteria ("Simulated daily volume of at least 3.2 GB over a 30-day plan") but no linked analysis yet. The wording is fine; the verification is not done.
• 3.1 Orbit Average Power is well written, but its text changed after approval, so its correctness and feasibility need a reviewer's judgment again. Feasibility is the real question: the arrays as designed give about 28 W orbit average.

Three rewrites

2.5 Safe Mode Recovery. "The spacecraft should recover from safe mode quickly and resume imaging as appropriate" breaks at least six rules: "should" instead of "shall", two obligations joined by "and", "quickly" with no value, the escape clause "as appropriate", no closing period, and no verification. The rewrite keeps the one outcome that matters to the customer and gives it a value:

The spacecraft shall resume imaging within 6 hours of a safe mode entry.

The rationale should say where 6 hours comes from (N1 asks for same-day crop stress alerts, and 6.2 allows 6 hours from downlink to delivery). If the steps of the recovery matter on their own, such as re-acquiring Sun pointing or reporting the cause, each becomes its own requirement. Method: test, by fault injection on the flatsat; success criterion: imaging resumes within 6 hours in each injected safe mode entry.

3.5 Battery Thermal Control. "The thermal design shall keep the battery warm enough (TBD)." has a vague term, a TBD in the text and a bracket. The fix separates the obligation, the open value and the reason:

The thermal design shall keep the battery cell temperature at or above 0 °C while charging.

The 0 °C is illustrative: lithium-ion cells are commonly not charged below freezing, but the real limit comes from the cell data sheet and the thermal analysis. Until that analysis sets it, the value is a TBR owned by the Thermal Engineer, with a due date before the thermal design review. The rewrite also exposes a gap the original hid: there is no requirement for the discharge temperature range, which needs its own statement.

6.4 Operator Interface. "The operator interface shall be user friendly and/or easy to use." has two subjective terms and an "and/or". Usability can be specified, but only through observable tasks:

The operator interface shall let a trained operator book a ground station contact in no more than 5 minutes.

The task and the time are illustrative. A real set would list the few tasks that matter (book a contact, upload a target list, read the latest health telemetry), each with a time and an error limit, measured in a demonstration with operators who completed the training.

Common mistakes

Try it in Holarch

In an LML project, each requirement is an entity of class Requirement with the attributes described above: Rationale, Status, Priority, Criticality, Owner, Source, Verification Method, Verification Level, Success Criteria and the TBD/TBR fields.

1. Create the demo with Manage Projects → Project Files ▾ → New Demo Project. Its specification holds the three weak requirements and the open TBD/TBR items used in this guide.
2. Open Needs & Requirements → Quality, choose the document in the scope list and click Check Quality. Each requirement is scored on the nine characteristics, and the suggestions name the rule numbers from the INCOSE guide that a word list or pattern can check. Correct and Feasible need a reviewer: click the mark to record the decision.
3. Rewrite 2.5 as above and run the check again. The combinator, escape clause and vague-term findings disappear.
4. Open Needs & Requirements → TBD/TBR to see the open items with owners and due dates, and Close one once its value is settled.
5. For a second opinion on the characteristics a rule cannot decide, use ✦ AI ▾ → AI Requirement Check; every verdict and rewrite is shown for review before anything changes.

The full reference is in Requirement Quality and the TBD/TBR Register docs.

Download the checklist

The requirement quality checklist with EO-1 before-and-after examples (CSV) holds the checklist rules with their review questions and examples, for use in a review or as a starting point for a project's own writing rules. The same file is offered by the traceability guide.

Questions about writing requirements

Shall, must or will?

Any convention works if the specification defines it and keeps to it. The most widespread one uses "shall" for binding requirements, "will" for facts and intentions about things outside the system, and "should" for goals that are not verified. Some government style guides prefer "must" for plain-language reasons. Mixing them inside one specification is the real problem.

How many requirements should a system have?

There is no right number. A small spacecraft may have a few dozen system requirements and a few hundred below them; a large program has thousands. More useful questions are whether every requirement traces to a need or a parent, and whether every need has requirements under it.

Are user stories requirements?

A user story records a need and its purpose in the user's terms. It plays the role of a stakeholder need, and its acceptance criteria are close to verification criteria. For a system that is built, integrated and verified as hardware and software together, the stories still need to be turned into requirements that can be allocated and tested.

Can a tool check requirement quality?

A tool can check the mechanical rules reliably: modal verbs, combinators, vague words, escape clauses, pronouns, missing links. It cannot know whether 30 W is the right value or whether the arrays can deliver it. Use the automatic check to clear the mechanical findings before a review, so the reviewers spend their time on correctness and feasibility.

Where to go next

• Requirements traceability and change impact: link these requirements to needs, design and tests, and follow a change.
• Functional analysis: turn the requirements into functions and allocate them.
• Requirements verification matrix: plan the verification method for each requirement and record the results.
• Needs and requirements in Holarch: documents, quality checks, baselines and traceability in one model.