ECSS Software Verification (space-systems/ecss/software-verification)
Use when the task is ECSS-E-ST-40C software verification planning:
mapping requirement categories to verification methods, sizing
verification depth from criticality, and listing the records.
Domain quick reference
- ECSS-E-ST-40C (space software engineering) expects every software
requirement to be closed by a verification method: test, analysis,
inspection, or review.
- Method choice follows the requirement category: functional and
performance needs are proven mainly by test, resource budgets by
analysis, interface agreements by test and inspection, safety needs
combine test, analysis and review, and data items close by
inspection and review.
- Verification depth scales with software criticality; catastrophic
and critical software demand independent verification with formal
records.
- Verification records (test procedures and results, analysis reports,
inspection sheets, review minutes) are the evidence that each
requirement was verified, and acceptance is gated on complete
records.
- Independence of the verification activity grows with criticality:
higher categories are verified by people independent of the
development team.
Workflow
- Collect the software requirements with their category (functional,
performance, interface, resource, safety, data).
- Select the verification method for each requirement with
verify_method.
- Determine the verification depth, independence, and records for the
software criticality with verification_depth.
- Build the verification plan with plan_verdict and confirm every
requirement received a method.
- Close each requirement with its verification record before
acceptance.
Pitfalls
- Using test for every requirement instead of matching the method to
the requirement category.
- Verifying resource budgets by test only when analysis is the primary
method.
- Skipping independent verification for catastrophic or critical
software.
- Treating inspection as a depth level instead of a method.
- Closing a requirement without its verification record.
Behavior contract (gate 3)
The method-selection, depth, and plan-verdict logic is exercised by
the gate 3 contract test: scripts/test_software_verification_logic.py
against scripts/software_verification_logic.py (stdlib unittest,
offline). Run:
python3 scripts/test_software_verification_logic.py
Compliance
- ECSS standards are freely downloadable (ESA); cite the source and
paraphrase per standards-map.yaml.
- compliance: STANDARDS-REF, gated: false.
1---2name: software-verification3description: Use when you must plan the ECSS-E-ST-40C verification of spacecraft flight software: select the verification method (test, analysis, inspection, review) for each requirement category (functional, performance, interface, resource, safety, data), determine the verification depth and independence required by the software criticality, and list the verification records each method must produce. Produces the per-requirement method map, the criticality depth verdict, and the record list that closes the verification plan. Trigger: ecss verification, software test method, verification depth, verification records, requirement category, criticality, flight software, analysis inspection review.4license: Apache-2.05---67# ECSS Software Verification (space-systems/ecss/software-verification)89Use when the task is ECSS-E-ST-40C software verification planning:10mapping requirement categories to verification methods, sizing11verification depth from criticality, and listing the records.1213## Domain quick reference1415- ECSS-E-ST-40C (space software engineering) expects every software16 requirement to be closed by a verification method: test, analysis,17 inspection, or review.18- Method choice follows the requirement category: functional and19 performance needs are proven mainly by test, resource budgets by20 analysis, interface agreements by test and inspection, safety needs21 combine test, analysis and review, and data items close by22 inspection and review.23- Verification depth scales with software criticality; catastrophic24 and critical software demand independent verification with formal25 records.26- Verification records (test procedures and results, analysis reports,27 inspection sheets, review minutes) are the evidence that each28 requirement was verified, and acceptance is gated on complete29 records.30- Independence of the verification activity grows with criticality:31 higher categories are verified by people independent of the32 development team.3334## Workflow35361. Collect the software requirements with their category (functional,37 performance, interface, resource, safety, data).382. Select the verification method for each requirement with39 verify_method.403. Determine the verification depth, independence, and records for the41 software criticality with verification_depth.424. Build the verification plan with plan_verdict and confirm every43 requirement received a method.445. Close each requirement with its verification record before45 acceptance.4647## Pitfalls4849- Using test for every requirement instead of matching the method to50 the requirement category.51- Verifying resource budgets by test only when analysis is the primary52 method.53- Skipping independent verification for catastrophic or critical54 software.55- Treating inspection as a depth level instead of a method.56- Closing a requirement without its verification record.5758## Behavior contract (gate 3)5960The method-selection, depth, and plan-verdict logic is exercised by61the gate 3 contract test: scripts/test_software_verification_logic.py62against scripts/software_verification_logic.py (stdlib unittest,63offline). Run:64python3 scripts/test_software_verification_logic.py6566## Compliance6768- ECSS standards are freely downloadable (ESA); cite the source and69 paraphrase per standards-map.yaml.70- compliance: STANDARDS-REF, gated: false.
ashfordeOU