Remarks: This Software Requirements Specification is part of the SafeQP Certification Kit↑, but applies to the whole QP/C Framework family↑. This document is the best source of information about the underlying concepts and functionality of the QP/C Frameworks and the QP/C applications based on the frameworks.

Document Revisions

QP/C version	Document revision	Date (YYYY-MM-DD)	By	Description
7.3.4	A	2024-05-05	MMS	Initial release for IEC-61508 SIL-3 and IEC-62304 Class-C.
7.4.0	B	2024-07-30	MMS	Updated for QP 7.4.0.
8.0.0	C	2024-11-17	MMS	Updated for QP 8.0.0.
8.0.3	D	2025-03-27	MMS	Updated for QP 8.0.3.
8.1.1	E	2025-10-08	MMS	Updated for QP 8.1.1.

About this Document

DOC_SRS_QP

Software Requirements Specification (SRS)

Description
This Software Requirements Specification, with Unique Identifier: DOC_SRS_QP, defines the software requirements for the QP/C Framework component. The document specifies the concepts, interfaces, and functional behavior that QP/C provides to applications that integrate this component.

Scope
The scope of this SRS is limited to defining what the QP/C component shall do under normal operating conditions (the success viewpoint). It specifies the functional behavior, abstractions, and execution semantics that QP/C provides to an integrating application.

Equally important — but intentionally out of scope for this document — are the behaviors required to detect, mitigate, or respond to failures. Those aspects are defined separately in the Software Safety Requirements Specification (DOC_SSRS_QP, which addresses the failure viewpoint and safety-related behavior of the QP/C component.

Regulatory background

Functional safety standards require formal, traceable, and verifiable requirements. This SRS fulfills that role for the QP/C component, ensuring that its externally visible behavior is clearly defined and suitable for integration into safety-critical systems.

Safety Standard	Software Requirements Specification Role
[IEC 61508-3:2010] Functional Safety of E/E/PE Systems	Must define both normal behavior and failure responses of the software. Requirements must be unambiguous, verifiable, and traceable to hazards and risk controls. Supports Safety Integrity Level (SIL) allocation and validation.
[IEC 62304:2006 + Amd1:2015] Medical Device Software	Central to the software development plan and risk management. Requirements must be linked to hazard analysis, and support class-based rigor (Class A/B/C).
[ISO 26262-6:2018] Road Vehicles Functional Safety	Requirements must support ASIL decomposition, traceability, and verification planning. Emphasizes interface definitions, failure modes, and non-functional constraints.
[ISO/IEC/IEEE 29148:2018] Requirements Engineering	Defines best practices for requirement structure, language, and classification. Introduces terms like shall, shall not, should, and may to indicate requirement criticality.

Audience
This Software Requirements Specification is primarily intended for:

Integrators and Application Developers who incorporate the QP/C component into their embedded systems and rely on its event-driven execution model, state machine services, and runtime mechanisms.

This requirements specification is also relevant to:

Quality-Assurance Engineers responsible for verifying that the QP/C component is correctly integrated and used according to its defined behavior
Test Engineers who design and execute tests for QP/C component functionality and its externally visible interfaces
Software Architects who define system architectures that include QP/C as a certified software component
System Engineers who analyze system-level behavior and interfaces involving QP/C
Hardware Engineers who must understand timing, interrupt, and execution-context assumptions made by the QP/C component
Project Managers and Functional Safety Managers who oversee development activities that depend on the correct use and integration of QP/C component.

Document Organization
After a high-level overview, this Software Requirements Specification describes the QP/C component in terms of its externally visible behavior, functional interfaces, and concepts. The document is organized into feature-oriented sections, each containing the associated formal requirements. This is followed by an Annex A with the explanation of concepts and definitions.

Feature-oriented sections are:

Explanation of concepts & definitions:

Annex A: Concepts & Definitions

Backward Traceability

FSM_QP_SDLC_01: Step-1 of the QP/C component SDLC shall review and update Software Requirements Specification (SRS) and Software Safety Requirements Specification (SSRS).

Document Conventions

Requirement definitions use consistent terminology to indicate whether something is mandatory, desirable, or allowed.

Use of "shall"

Shall is used to denote mandatory behavior.

Use of "shall not"

Shall is used to denote prohibited behavior.

Use of "should"

Should is used to denote a desirable behavior that should typically occur but might not happen all the time or might be optional in exceptional cases. The special cases are typically clarified in sub-requirements.

Use of "may"

May is used to denote allowed behavior that is optional but possible.

Definitions and Abbreviations

This document uses the definitions and abbreviations given in [IEC 61508-4:2010].

General Requirement UIDs

For traceability, this Software Requirements Specification uses the Unique Identifiers (UIDs) with the following structure:

 +---------------- [1] Work artifact class (e.g., 'SRS' for Software Requirement Specification)
 |  +------------- [2] Project identifier ('QP' for @QPX Framework or 'QA' for @QPX Application)
 |  |  +---------- [3] Work artifact ID
 |  |  |  +------- [4] Work artifact number
 |  |  |  |   +--- [5] Optional variant letter ('A', 'B', 'C'...)
 |  |  |  |   |+-- [6] Optional version number (1, 2, 3...)
 |  |  |  |   ||
SRS_QP_xx_yy[_A2]

Examples: SRS_QP_EVT_30, SRS_QP_SM_32

References

[IEEE 29148]	Requirement Specification Standard, ISO/IEC/IEEE 29148:2018
[IEC 61508-3:2010]	IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 3: Software requirements
[IEC 62304:2015]	IEC 62304:2006, Medical device software - Software life-cycle process, IEC 62304:2006 + IEC 62304:2006/Amd1:2015
[ISO 26262-6:2018]	ISO 26262-6:2018(en) Road vehicles - Functional safety - Part 6: Product development at the software level. International Standardization Organization.
[DOC_SSRS_QP]	Software Safety Requirements Specification
[DOC_SAS_QP]	Software Architecture Specification
[DOC_SDS_QP]	Software Design Specification
[PSiCC:02]	Miro Samek, Practical Statecharts in C/C++, CMP Books 2002. https://www.state-machine.com/psicc
[PSiCC2:08]	Miro Samek, Practical UML Statecharts in C/C++, 2nd Edition, Newnes 2008. https://www.state-machine.com/psicc2
[Cummings:10]	David M. Cummings, "Managing Concurrency in Complex Embedded Systems", 2010 Workshop on Cyber-Physical Systems. https://www.state-machine.com/doc/Cummings2006.pdf
[ROOM:94]	Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object-Oriented Modeling, New York, John Wiley & Sons Inc, 1994, ISBN 978-0-471-59917-3
[Samek:07]	Miro Samek, "Use an MCU's low-power modes in foreground/background systems", Embedded Systems Design, 2007, https://www.state-machine.com/doc/Samek0710.pdf
[CODE2:04]	Steve McConnell, Code Complete, 2nd Ed, Microsoft Press 2004.
[UML-2.5]	OMG, "OMG Unified Modeling Language (OMG UML) Version 2.5.1", formal/2017-12-05, 2017 https://www.omg.org/spec/UML.
[Sutter:10]	Herb Sutter, "Prefer Using Active Objects Instead of Naked Threads", Dr.Dobbs Journal, June 2010. https://www.state-machine.com/doc/Sutter2010a.pdf)
[SRP:90]	Theodore P. Baker, "A Stack-Based Resource Allocation Policy for Realtime Processes", IEEE Real-Time Systems Symposium, 1990
[OSEK:03]	OSEK/VDX, "Operating System Specification 2.2.1", osek-vdx.org, 2003 https://www.osek-vdx.org/mirror/os221.pdf
[PTS:07]	Rony Ghattas and Alexander G. Dean, "Preemption Threshold Scheduling: Stack Optimality, Enhancements and Analysis", Conference Paper, April 2007
[RMS/RMA:91]	Lui Sha Mark H. Klein John B. Goodenough, "Rate Monotonic Analysis for Real-Time Systems", Technical Report CMU/SEI-91-TR-6 ESD-91-TR-6, 2017 https://insights.sei.cmu.edu/documents/1021/1991_005_001_15923.pdf.
[DMS:91]	N. C. Audsley A. Burns M. F. Richardson A. J. Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", 1991 https://www.cs.cmu.edu/~ssaewong/research/audsley_DMS.pdf.
[Yiu:14]	Joseph Yiu, "The Definitive Guide to ARM Cortex M3 and Cortex-M4 Processors Third Edition", ARM Ltd., Cambridge, UK, June 2014.
[OOP-C:08]	Quantum Leaps, Object-Oriented Programming in C, https://www.state-machine.com/oop
[DbC:16]	Quantum Leaps, Key Concept: Design by Contract, https://www.state-machine.com/dbc

Overview