This Software Requirements Specification (SRS [IEEE 29148]) describes the requirements for the QP Real-Time Embedded Framework (RTEF). The SRS contains the following Sections:
QP Real-Time Embedded Framework (RTEF) is a reusable software infrastructure and a runtime environment based on the Active Object (Actor) design pattern as well as Hierarchical State Machines to specify the internal behavior of Active Objects (a.k.a. Actors ([ROOM:94], [UML 2.5])).
This SRS document specifies the intended features of the QP Framework, as well as the interfaces to other software, such as QP Applications derived from the QP Framework, as well as the lower-level software providing services to the QP Framework.
This SRS document is primarily intended for:
This SRS can also be of interest to:
This SRS contains two types of requirements:
This SRS uses the Unique Identifiers (UIDs) with the following structure:
+++--------------- 1. work artifact class ('REQ' for Requirement) ||| ++------------ 2. Project identifier (here 'QP' for QP Framework or 'QA' for QP Application) ||| || ++-+++----- 3. work artifact ID (see note below) ||| || || || +--- 4. optional variant letter ('A', 'B', 'C'...) ||| || || || |+-- 5. optional version number (1, 2, 3...) ||| || || || || REQ-QP-xx-yy[-A2]
Examples: REQ-QP-01_30, REQ-QP-02_32
Requirement definitions use consistent terminology to indicate whether something is mandatory, desirable, or allowed.
Shall is used to denote mandatory behavior.
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.
Mayis used to denote allowed behavior that is optional but possible.
Must not is used to denote a constraint – behavior that is not allowed.
After a high-level overview, this SRS document contains sections devoted to specific feature areas. Each section starts with a description of the feature, followed by the associated requirements. The SRS ends with the summary of QP Application Requirements, which are essential assumptions made in QP for the proper functioning of the QP Applications.
[IEEE 29148] | "Requirement Specification Standard", ISO/IEC/IEEE 29148:2018 |
[QP-SAS] | QP Framework Software Architecture Specification (SAS) |
[QP-SDS] | QP Framework Software Design Specification (SDS) |
[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 |
[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 |
[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 |
[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) |
[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 |
[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 |