This is an example Software Requirements Specification (SRS), illustrating the typical structure and the use of Spexygen commands to define the traceable requirement work artifacts.

Remarks: Please note the generated forward-traceability and the backward-traceability links (augmented with the brief descriptions) in the "work artifacts" and "code artifacts". Also, try clicking on the provided traceability links as well as searching the UIDs in the Doxygen "search" box.

Concepts & Definitions

Description of concepts and definitions...

Requirements

Definitions of formal requirements specifications with Spexygen commands.

[SRS_EXA_REQ_01]

My project shall provide a free function foo().

Description

Longer description of the requirement

Regulatory background

Across functional safety standards, a dedicated, traceable specification of software safety requirements is a central artifact for demonstrating that the software can achieve its claimed integrity levels, as summarized in the following table:

IEC 61508-3:2010 (Functional Safety of E/E/PE Systems)
[IEC 61508] requires that software safety requirements be explicitly specified, traceable to system-level safety requirements, and assigned appropriate safety integrity levels. The SSRS consolidates these software safety requirements for use in SIL-3 applications. The most relevant clauses are: IEC 61508-1:2010, 7.5 specification of E/E/PE system safety requirements, including allocation to software. IEC 61508-3:2010, 7.2 objectives for the software safety lifecycle and the need for a documented software safety requirements specification. IEC 61508-3:2010, 7.4.27.4.3 specification of software safety requirements and software safety integrity requirements, including assumptions about hardware, operating environment, and external risk-reduction measures.
IEC 62304:2006 + Amd1:2015 (Medical Device Software)
[IEC 62304] mandates a documented set of software requirements that reflect the results of risk management and support verification and traceability throughout the lifecycle. The SSRS captures the Class-C-relevant software safety requirements, including risk-control dependencies, safety constraints and assumptions of use. Key clauses are: 4.2 linkage to the risk-management process (ISO 14971) and risk-control measures. 4.3 software safety classification (Class-C) and its impact on the rigor of requirements. 5.2 software requirements analysis, requiring the derivation, documentation, and traceability of software requirements from system requirements and risk controls.
ISO 26262:2018 (Road Vehicles Functional Safety)
[ISO 26262] requires a structured hierarchy of safety requirements, from safety goals down to software safety requirements, with clear allocation and traceability. The SSRS provides the software safety requirements necessary to integrate the element into ASIL-D systems and to support the Safety Manual's Assumed Safety Requirements (ASRs). For a SEooC, the key clauses are: ISO 26262-3:2018, Clause 7 item-level safety goals and functional safety requirements that ultimately drive software safety requirements. ISO 26262-4:2018, Clause 6 technical safety requirements, including those allocated to software. ISO 26262-6:2018, Clause 6 specification of software safety requirements, including ASIL assignment, interface assumptions, timing and resource constraints, and required safety mechanisms.

Forward Traceability (truncated to 1 level(s))

[TUN_PRJ_free_fun_00] zero input test
[TUN_PRJ_free_fun_01] non-zero input test
[free_fun()] Free function brief description

[SRS_EXA_REQ_10]

My project shall provide a class Foo.

Description

Longer description of the requirement

Forward Traceability (truncated to 1 level(s))

[SRS_EXA_REQ_11] Class Foo shall provide a public attribute x.
[SRS_EXA_REQ_12] Class Foo shall provide a constructor.
[SRS_EXA_REQ_13] Class Foo shall provide a verify operation.
[SRS_EXA_REQ_14] Class Foo shall provide an update operation.
[SRS_EXA_REQ_15] Class Foo shall be a singleton.
[Foo] Class Foo brief description

[SRS_EXA_REQ_11]

Class Foo shall provide a public attribute x.

Description

Longer description of the requirement

Backward Traceability

[SRS_EXA_REQ_10] My project shall provide a class Foo.

Forward Traceability (truncated to 2 level(s))

[Foo::x] Attribute x of class Foo brief description
- [Foo::x_dis] Duplicate Inverse Storage for attribute Foo::x

[SRS_EXA_REQ_12]

Class Foo shall provide a constructor.

Description

Longer description of the requirement.

Attention: This is a attention note. Also shows how to add a "badge".

Backward Traceability

[SRS_EXA_REQ_10] My project shall provide a class Foo.

Forward Traceability (truncated to 2 level(s))

[TUN_PRJ_Foo_ctor_01] constructor test
[Foo_ctor()] Constructor of class Foo brief description
- [TUN_PRJ_Foo_ctor_01] constructor test

[SRS_EXA_REQ_13]

Class Foo shall provide a verify operation.

Description

Longer description of the requirement

Backward Traceability

[SRS_EXA_REQ_10] My project shall provide a class Foo.

Forward Traceability

[TUN_PRJ_Foo_verify_00] verify positive test
[TUN_PRJ_Foo_verify_01] verify negative test
[Foo_verify_()] Verify operation to check the class invariant
- [TUN_PRJ_Foo_verify_00] verify positive test
- [TUN_PRJ_Foo_verify_01] verify negative test
- [Foo::x_dis] Duplicate Inverse Storage for attribute Foo::x

[SRS_EXA_REQ_14]

Class Foo shall provide an update operation.

Description

Longer description of the requirement

Backward Traceability

[SRS_EXA_REQ_10] My project shall provide a class Foo.

Forward Traceability

[Foo_update_()] Update operation to update the class invariant

[SRS_EXA_REQ_15]

Class Foo shall be a singleton.

Description

Longer description of the requirement

Backward Traceability

[SRS_EXA_REQ_10] My project shall provide a class Foo.

Forward Traceability

[Foo_inst] Foo instance brief description (singleton)

Spexygen Example