Verifiable spacecraft requirements state necessary outcomes for named products, under defined conditions, with acceptance boundaries that objective evidence can prove or disprove. A useful pattern is: subject + shall + observable outcome + conditions + measurable limit. Each requirement then connects to its source, rationale, owner, applicability and planned verification method.
The 25 rewrites below show how that pattern works across performance, interfaces, environments, operations, reliability and verification. The numbers are illustrative rather than design recommendations. Replace them with values derived from the mission, applicable standards, interface agreements, analyses and margins for the real configuration.
What changes a vague statement into a verifiable requirement?
Good wording is necessary but not sufficient. The team needs to know what product is responsible, which condition activates the requirement, what observable result counts as success and which boundary separates pass from fail. NASA's good-requirement checklist also tests clarity, completeness, consistency, feasibility, traceability and verifiability. ECSS-E-ST-10-06C similarly treats identification, traceability, tolerances and verification as characteristics of a technical requirement.
| Element | Question to answer | Example |
|---|---|---|
| Subject | Which system, segment, subsystem or item carries the obligation? | The payload data interface |
| Outcome | What observable behaviour, performance or constraint is required? | Shall transfer science packets without loss |
| Conditions | When, where, in which mode and for which configuration does it apply? | During a ten-minute imaging pass at maximum packet size |
| Acceptance boundary | What result separates compliance from non-compliance? | At 1.1 Gbit/s with zero lost packets |
| Proof path | Which method and evidence can demonstrate that result? | End-to-end interface test and timestamped packet log |
Do not force rationale, design explanation and several obligations into the same sentence. Store the reason and assumptions beside the requirement. Split genuinely independent outcomes. If a threshold is still unknown, manage it as an owned TBR with a resolution action and date rather than disguising uncertainty with “sufficient” or “as required”.
Performance requirements: examples 1–5
| No. | Weak wording | Verifiable requirement | Why it is stronger | Method and typical evidence | Ambiguity or failure exposed |
|---|---|---|---|---|---|
| 1 | The payload shall take high-resolution images. | The imaging payload shall provide a ground-sample distance of 5 m or less at nadir from an orbital altitude of 500 km ± 20 km. | Defines the performance metric, viewing condition and applicable altitude. | Analysis supported by calibrated optical test data; optical-performance report and calibration record. | “High resolution” could mean pixel count, optical resolution or ground resolution under an unspecified geometry. |
| 2 | The computer shall start quickly. | The onboard computer shall enter the command-ready state within 60 s after its primary power input remains between 24 V and 34 V for 2 s. | Defines the start event, end state, power condition and elapsed-time limit. | Test; timestamped power and state-transition log from the flight-like computer. | Reviewers might time from different events or disagree about what “started” means. |
| 3 | The recorder shall store plenty of payload data. | The science-data recorder shall provide at least 256 GiB of usable payload storage after allocation of error-correction and system-reserved capacity. | Distinguishes usable capacity from advertised device capacity and names the data class. | Inspection and test; configured partition report plus write/read capacity test results. | Gross memory could pass on paper while the mission-usable partition remains too small. |
| 4 | The spacecraft shall point accurately. | The attitude-control system shall maintain an absolute pointing error of 0.10° or less, at 3σ on each axis, throughout a continuous 300 s imaging interval after the imaging-ready state is declared. | Names the error measure, statistical convention, axes, duration and start condition. | Analysis and test; validated simulation results plus hardware-in-the-loop pointing-performance report. | Accuracy, knowledge error, stability and jitter could be confused, or assessed over a favourable instant. |
| 5 | The payload shall use low power. | The payload shall consume no more than 120 W average power over a 10 min imaging sequence and no more than 160 W for any interval longer than 5 s at a 28 V spacecraft bus input. | Separates average and peak demand and defines sequence, duration and bus condition. | Test; calibrated voltage/current trace and calculated interval averages for the approved payload configuration. | A compliant average could conceal a peak that trips protection or violates a thermal assumption. |
Interface requirements: examples 6–9
| No. | Weak wording | Verifiable requirement | Why it is stronger | Method and typical evidence | Ambiguity or failure exposed |
|---|---|---|---|---|---|
| 6 | The payload shall support the spacecraft data bus. | The payload data interface shall transfer valid science packets to the onboard computer at 1.1 Gbit/s for 600 s with zero lost or malformed packets at the interface boundary defined in ICD-PL-001. | Defines direction, information unit, rate, duration, error criterion and controlled boundary. | End-to-end interface test; packet counter, error log, timestamps and test configuration record. | Electrical compatibility alone might be mistaken for successful application-data transfer. |
| 7 | The payload shall fit the spacecraft. | The payload, including flight connectors and installed tolerances, shall remain within the mechanical envelope defined by coordinate set ENV-PL-04 in ICD-PL-001 in all deployment states prior to separation. | Points to a controlled geometry, includes connectors and tolerances, and defines applicable states. | Inspection and analysis; as-built dimensional report and tolerance-stack model. | A nominal CAD shape could pass while a connector backshell or tolerance excursion clashes during integration. |
| 8 | All units shall use the same time. | The onboard computer shall timestamp payload packets to within ±1 ms of the spacecraft mission-elapsed-time reference while in nominal imaging mode. | Identifies the responsible item, reference, data, mode and allowed offset. | Test; common-reference timing capture and packet timestamp comparison report. | “Same time” does not define synchronisation accuracy, direction or the reference clock. |
| 9 | The payload shall not overheat the bus. | The payload shall conduct no more than 35 W into the spacecraft mounting interface when its baseplate temperature is 35°C in the worst-case hot imaging condition defined by THM-CASE-07. | Defines the interface quantity, boundary temperature and controlled analysis case. | Analysis correlated by thermal-vacuum test; thermal-model case and interface heat-flow result. | Internal component temperature and heat rejected into the spacecraft could otherwise be conflated. |
Environmental requirements: examples 10–13
| No. | Weak wording | Verifiable requirement | Why it is stronger | Method and typical evidence | Ambiguity or failure exposed |
|---|---|---|---|---|---|
| 10 | The spacecraft shall survive launch vibration. | The flight spacecraft shall meet all post-test functional and performance acceptance criteria after exposure on each of three orthogonal axes to the qualification random-vibration profile in ENV-SYS-002. | Defines the article, axes, controlled environment and observable post-exposure outcome. | Test; approved vibration procedure, calibrated accelerometer data and pre/post functional results. | “Survive” might mean no visible breakage while hidden performance degradation remains. |
| 11 | The radio shall work in hot and cold conditions. | The flight radio shall meet RF output-power, frequency-error and packet-error limits in RF-SPEC-004 while its baseplate temperature is stabilised at every 10°C increment from −20°C to +50°C in thermal vacuum. | Links “work” to named performance limits, temperature points and vacuum condition. | Thermal-vacuum test; chamber log, temperature-soak record and RF measurement report. | A single functional check at the temperature extremes could miss degraded performance within the range. |
| 12 | The avionics shall be radiation tolerant. | The avionics assembly shall meet its functional and performance requirements after accumulating 20 krad(Si) total ionising dose at the part locations represented by radiation case RAD-05. | Defines dose quantity, material convention, affected item and post-exposure acceptance basis. | Analysis and radiation test; transport model, dosimetry, test report and post-irradiation functional results. | Radiation type, shielding assumptions and the meaning of “tolerant” would otherwise remain open. |
| 13 | Optical surfaces shall stay clean. | Witness samples adjacent to the primary optical surface shall show a molecular-deposition increase of no more than 100 ng/cm² between final cleaning and launch-site encapsulation. | Defines the contamination measure, sampling location, limit and lifecycle interval. | Inspection and analysis; witness-sample measurements, handling log and contamination budget. | A visual inspection could miss molecular contamination that degrades optical throughput. |
Operational requirements: examples 14–17
| No. | Weak wording | Verifiable requirement | Why it is stronger | Method and typical evidence | Ambiguity or failure exposed |
|---|---|---|---|---|---|
| 14 | The spacecraft shall enter safe mode when needed. | The flight software shall command the spacecraft safe state within 30 s after detecting loss of valid attitude knowledge for 5 continuous seconds while outside launch and deployment modes. | Defines trigger persistence, response, deadline and excluded modes. | Software and hardware-in-the-loop test; injected fault, event log, command history and state trace. | A transient could cause unnecessary safing, or a persistent fault might never meet an undefined trigger. |
| 15 | The ground shall be able to command the satellite. | The ground segment shall deliver an authenticated time-tagged command to the spacecraft and receive its execution acknowledgement within 180 s during a scheduled contact with link margin of at least 3 dB. | Defines command type, security state, complete transaction, time and link condition. | End-to-end demonstration; ground log, spacecraft telemetry and correlated timestamps. | Uplink receipt could be reported as success even if the command is rejected or never executed. |
| 16 | The spacecraft shall downlink all images quickly. | The mission system shall make at least 95% of images accepted onboard during a target pass available in the mission archive within 6 h of the end of that pass under the nominal contact schedule in OPS-SCEN-03. | Defines the data population, destination, percentile-like completion threshold, deadline and scenario. | End-to-end operational test and analysis; image manifest, contact plan and archive timestamps. | “All” may be infeasible after rejected captures, and “quickly” gives no planning boundary. |
| 17 | Operators shall recover from a computer reset. | The onboard computer shall autonomously reload the last approved operational configuration and enter the command-ready state within 120 s after an unplanned processor reset in nominal mode. | Places the product obligation on the computer and defines configuration, mode, outcome and time. | Fault-injection test; reset cause, boot log, loaded configuration identifier and readiness timestamp. | A personnel task was masquerading as product behaviour, leaving autonomous recovery undefined. |
Reliability requirements: examples 18–21
| No. | Weak wording | Verifiable requirement | Why it is stronger | Method and typical evidence | Ambiguity or failure exposed |
|---|---|---|---|---|---|
| 18 | The spacecraft shall be highly reliable. | The spacecraft shall have a predicted probability of completing the 12-month primary mission of at least 0.95, excluding launch-vehicle failure and using the failure-rate assumptions baselined at CDR. | Defines mission duration, success measure, threshold, exclusions and assumption baseline. | Analysis; reliability block diagram, failure-rate source register, sensitivity analysis and approved prediction report. | Different analysts could include different mission phases or external failures and produce incomparable claims. |
| 19 | The command system shall be fault tolerant. | No single failure within the spacecraft command-reception path shall prevent reception and authentication of commands through both available ground-station links. | Defines the protected function, failure cardinality and required retained capability. | Analysis and test; FMEA/fault tree plus selected fault-injection demonstrations. | Redundant parts might share power, software or an antenna and therefore fail together. |
| 20 | The mission service shall have good availability. | The mission-operations service shall be available for command preparation and telemetry review for at least 99.5% of each calendar month, excluding approved maintenance periods announced at least 48 h in advance. | Defines the service functions, measurement window, threshold and allowed exclusion. | Analysis of operational monitoring; service-status log and monthly availability calculation. | Teams could exclude unplanned outages or measure only whether a server process was running. |
| 21 | The antenna deployment shall be dependable. | Each qualification antenna-deployment assembly shall complete 100 deployment cycles in thermal vacuum without a failed release, incomplete latch or deployment time exceeding 8 s. | Turns “dependable” into cycle life and three observable failure criteria under a stated environment. | Qualification test; chamber conditions, video, switch telemetry, deployment times and anomaly log. | A successful first deployment could conceal wear, marginal latching or slow release at temperature. |
Verification-focused requirements: examples 22–25
These examples show a common trap: naming a test or analysis without defining the product outcome it must demonstrate. Verification planning belongs beside the requirement, but “will be tested” is not itself a measurable product requirement.
| No. | Weak wording | Verifiable requirement | Why it is stronger | Method and typical evidence | Ambiguity or failure exposed |
|---|---|---|---|---|---|
| 22 | The unit shall pass EMC testing. | The transmitter assembly shall not cause the receiver noise-floor limit in RF-SPEC-006 to be exceeded while transmitting at maximum rated power in each operational band. | States the compatibility outcome, victim, limit source and operating condition rather than merely naming a test. | EMC test; calibrated spectrum plots, operating configuration and receiver noise-floor results. | A generic test could be completed without exercising the worst transmitter/receiver combination. |
| 23 | The structure shall be verified by analysis. | Every primary structural load path shall show a positive margin of safety against yield and ultimate failure for the limit loads and factors defined in LOADS-004. | Defines the physical outcome, coverage and acceptance boundary while leaving the approved method in the plan. | Analysis correlated by test; finite-element model record, load cases, material allowables and margin report. | An analysis can run successfully while omitting a load path, using the wrong allowables or reporting a negative margin. |
| 24 | The software shall be fully tested for packet loss. | The flight software shall detect every sequence gap in a stream containing up to 10,000 payload packets and shall report the first missing sequence identifier within 1 s of receiving the next valid packet. | Defines stimulus size, expected detection, reported information and response time. | Software test; controlled packet stream, injected gaps, event log and coverage record. | “Fully tested” is not finite and does not define the observable response to a loss. |
| 25 | The battery analysis shall show enough end-of-life capacity. | The battery shall retain at least 42 Ah usable capacity at the end of the 12-month mission for the temperature, depth-of-discharge and cycle profile defined in PWR-MISSION-02. | States the product performance, lifecycle point, limit and governing usage profile. | Analysis using cell-characterisation tests; test data, degradation model, mission profile and end-of-life capacity result. | An analyst could choose a favourable temperature or cycling history and still claim “enough”. |
How should you review a draft spacecraft requirement?
- Confirm necessity and source. Identify the stakeholder need, parent requirement, interface agreement, hazard, regulation or architectural decision that makes the statement necessary.
- Check level and ownership. Put the obligation on the product that can satisfy it and name the technical owner who can resolve questions.
- Separate the obligation. Keep one independently verifiable thought in each requirement and move rationale into its own field.
- Define conditions and boundaries. State mode, environment, configuration, duration, reference frame and tolerance where they affect acceptance.
- Attempt the proof path. Draft the method, level, article or model, success criteria and expected evidence. If that cannot be done, revise the requirement or resolve the missing design knowledge.
- Check the set. Look for conflicts, gaps, inconsistent terminology, duplicated limits and interface values that disagree across the boundary.
What should stay outside the requirement sentence?
Keep the requirement concise, but do not throw away its context. The controlled record should retain a unique identifier, source, parent and child links, rationale, assumptions, owner, applicability, lifecycle status, change history and verification plan. The requirements traceability and verification matrix guide shows how the statement connects to its method, evidence and closure status.
A method such as test, analysis, inspection or review of design normally belongs in the verification plan or matrix. Include implementation detail in the requirement only when the implementation is itself required—for example, because an external interface or safety control mandates it. Otherwise, state the needed outcome and allow the design team to trade solutions.
How Arc supports requirement quality
Arc keeps the statement beside its source, rationale, owner, architecture, interfaces, verification cases and evidence. Engineers can review proposed rewrites as diffs, see which connected items are affected and preserve the approved baseline. Machine assistance can flag vague terms or suggest acceptance criteria, while the engineering owner remains responsible for the technical value and proof path.
Related reading
Next, use the requirements traceability matrix and worked CubeSat verification example to organise proof, the engineering change impact assessment to control later revisions, and the SRR, PDR and CDR requirements-readiness checklist to assess maturity at reviews.
Frequently asked questions
What makes a spacecraft requirement verifiable?
A spacecraft requirement is verifiable when it identifies the subject, required outcome, applicable conditions and measurable acceptance boundary clearly enough to select a method, level, article or model, procedure and objective evidence.
Does every requirement need a number?
No. A functional or interface requirement may use an observable state, response or protocol rather than a numerical limit. The acceptance condition must still distinguish pass from fail without relying on words such as adequate, quickly or as appropriate.
Should the verification method appear in the requirement sentence?
Usually the requirement states the required outcome while the verification matrix records the approved method and evidence. Put a method in the sentence only when that method is itself part of the obligation; otherwise avoid unnecessarily constraining the solution.
Can one requirement use more than one verification method?
Yes. A requirement may need a combination such as test plus analysis, particularly when the complete operational environment cannot be reproduced in one activity. The matrix should show what each method proves and how the evidence combines into closure.