5. Software Requirements Engineering

Software engineering standards for critical software such as ECSS-E-ST-40C demand that software requirements for a software product are collected in a software requirements specification (technical specification in ECSS-E-ST-40C terms). They are usually derived from system requirements (requirements baseline in ECSS-E-ST-40C terms). RTEMS is designed as a reusable software product which can be utilized by application designers to ease the development of their applications. The requirements of the end system (system requirements) using RTEMS are only known to the application designer. RTEMS itself is developed by the RTEMS maintainers and they do not know the requirements of a particular end system in general. RTEMS is designed as a real-time operating system to meet typical system requirements for a wide range of applications. Its suitability for a particular application must be determined by the application designer based on the technical specification provided by RTEMS accompanied with performance data for a particular target platform.

Currently, no technical specification of RTEMS exists in the form of a dedicated document. Since the beginning of the RTEMS evolution in the late 1980s it was developed iteratively. It was never developed in a waterfall model. During initial development the RTEID [Mot88] and later the ORKID [VIT90] draft specifications were used as requirements. These were evolving during the development and an iterative approach was followed often using simple algorithms and coming back to optimise. In 1993 and 1994 a subset of pthreads sufficient to support GNAT was added as requirements. At this time the Ada tasking was defined, however, not implemented in GNAT, so this involved guessing during the development. Later some adjustments were made when Ada tasking was actually implemented. So, it was consciously iterative with the specifications evolving and feedback from performance analysis. Benchmarks published from other real time operating systems were used for comparison. Optimizations were carried out until the results were comparable. Development was done with distinct contractual phases and tasks for development, optimization, and the addition of priority inheritance and rate monotonic scheduling. The pthreads requirement has grown to be as much POSIX as possible.

Portability from FreeBSD to use its network stack, USB stack, SD/MMC card stack and device drivers resulted in another set of requirements. The addition of support for symmetric multiprocessing (SMP) was a huge driver for change. It was developed step by step and sponsored by several independent users with completely different applications and target platforms in mind. The high performance OpenMP support introduced the Futex as a new synchronization primitive.

Guidance

A key success element of RTEMS is the ability to accept changes driven by user needs and still keep the operating system stable enough for production systems. Procedures that place a high burden on changes are doomed to be discarded by the RTEMS Project. We have to keep this in mind when we introduce a requirements management work flow which should be followed by RTEMS community members and new contributors.

We have to put in some effort first into the reconstruction of software requirements through reverse engineering using the RTEMS documentation, test cases, sources, standard references, mailing list archives, etc. as input. Writing a technical specification for the complete RTEMS code base is probably a job of several person-years. We have to get started with a moderate feature set (e.g. subset of the Classic API) and extend it based on user demands step by step.

The development of the technical specification will take place in two phases. The first phase tries to establish an initial technical specification for an initial feature set. This technical specification will be integrated into RTEMS as a big chunk. In the second phase the technical specification is modified through arranged procedures. There will be procedures

• to modify existing requirements,

• add new requirements, and

• mark requirements as obsolete.

All procedures should be based on a peer review principles.

• 5.1. Requirements for Requirements
  • 5.1.1. Identification
  • 5.1.2. Level of Requirements
    • 5.1.2.1. Absolute Requirements
    • 5.1.2.2. Absolute Prohibitions
    • 5.1.2.3. Recommendations
    • 5.1.2.4. Permissions
    • 5.1.2.5. Possibilities and Capabilities
  • 5.1.3. Syntax
  • 5.1.4. Wording Restrictions
  • 5.1.5. Separate Requirements
  • 5.1.6. Conflict Free Requirements
  • 5.1.7. Use of Project-Specific Terms and Abbreviations
  • 5.1.8. Justification of Requirements
  • 5.1.9. Requirement Validation
  • 5.1.10. Resources and Performance
• 5.2. Specification Items
  • 5.2.1. Specification Item Hierarchy
  • 5.2.2. Specification Item Types
    • 5.2.2.1. Root Item Type
    • 5.2.2.2. Build Item Type
    • 5.2.2.3. Build Ada Test Program Item Type
    • 5.2.2.4. Build BSP Item Type
    • 5.2.2.5. Build Configuration File Item Type
    • 5.2.2.6. Build Configuration Header Item Type
    • 5.2.2.7. Build Group Item Type
    • 5.2.2.8. Build Library Item Type
    • 5.2.2.9. Build Objects Item Type
    • 5.2.2.10. Build Option Item Type
    • 5.2.2.11. Build Script Item Type
    • 5.2.2.12. Build Start File Item Type
    • 5.2.2.13. Build Test Program Item Type
    • 5.2.2.14. Constraint Item Type
    • 5.2.2.15. Glossary Item Type
    • 5.2.2.16. Glossary Group Item Type
    • 5.2.2.17. Glossary Term Item Type
    • 5.2.2.18. Interface Item Type
    • 5.2.2.19. Application Configuration Group Item Type
    • 5.2.2.20. Application Configuration Option Item Type
    • 5.2.2.21. Application Configuration Feature Enable Option Item Type
    • 5.2.2.22. Application Configuration Feature Option Item Type
    • 5.2.2.23. Application Configuration Value Option Item Type
    • 5.2.2.24. Interface Compound Item Type
    • 5.2.2.25. Interface Container Item Type
    • 5.2.2.26. Interface Define Item Type
    • 5.2.2.27. Interface Domain Item Type
    • 5.2.2.28. Interface Enum Item Type
    • 5.2.2.29. Interface Enumerator Item Type
    • 5.2.2.30. Interface Forward Declaration Item Type
    • 5.2.2.31. Interface Function Item Type
    • 5.2.2.32. Interface Group Item Type
    • 5.2.2.33. Interface Header File Item Type
    • 5.2.2.34. Interface Macro Item Type
    • 5.2.2.35. Interface Typedef Item Type
    • 5.2.2.36. Interface Unspecified Item Type
    • 5.2.2.37. Interface Variable Item Type
    • 5.2.2.38. Requirement Item Type
    • 5.2.2.39. Functional Requirement Item Type
    • 5.2.2.40. Action Requirement Item Type
    • 5.2.2.41. Generic Functional Requirement Item Type
    • 5.2.2.42. Non-Functional Requirement Item Type
    • 5.2.2.43. Requirement Validation Item Type
    • 5.2.2.44. Specification Item Type
    • 5.2.2.45. Test Case Item Type
    • 5.2.2.46. Test Platform Item Type
    • 5.2.2.47. Test Procedure Item Type
    • 5.2.2.48. Test Suite Item Type
  • 5.2.3. Specification Attribute Sets and Value Types
    • 5.2.3.1. Action Requirement Condition
    • 5.2.3.2. Action Requirement Name
    • 5.2.3.3. Action Requirement State
    • 5.2.3.4. Action Requirement Test Context Member
    • 5.2.3.5. Action Requirement Test Fixture Method
    • 5.2.3.6. Action Requirement Test Header
    • 5.2.3.7. Action Requirement Test Run Parameter
    • 5.2.3.8. Action Requirement Transition
    • 5.2.3.9. Action Requirement Transition Post-Conditions
    • 5.2.3.10. Action Requirement Transition Pre-Condition State Set
    • 5.2.3.11. Action Requirement Transition Pre-Conditions
    • 5.2.3.12. Application Configuration Group Member Link Role
    • 5.2.3.13. Application Configuration Option Constraint Set
    • 5.2.3.14. Application Configuration Option Name
    • 5.2.3.15. Boolean or Integer or String
    • 5.2.3.16. Build Assembler Option
    • 5.2.3.17. Build C Compiler Option
    • 5.2.3.18. Build C Preprocessor Option
    • 5.2.3.19. Build C++ Compiler Option
    • 5.2.3.20. Build Dependency Link Role
    • 5.2.3.21. Build Include Path
    • 5.2.3.22. Build Install Directive
    • 5.2.3.23. Build Install Path
    • 5.2.3.24. Build Linker Option
    • 5.2.3.25. Build Option Action
    • 5.2.3.26. Build Option C Compiler Check Action
    • 5.2.3.27. Build Option C++ Compiler Check Action
    • 5.2.3.28. Build Option Default by Variant
    • 5.2.3.29. Build Option Name
    • 5.2.3.30. Build Option Set Test State Action
    • 5.2.3.31. Build Option Value
    • 5.2.3.32. Build Source
    • 5.2.3.33. Build Target
    • 5.2.3.34. Build Test State
    • 5.2.3.35. Build Use After Directive
    • 5.2.3.36. Build Use Before Directive
    • 5.2.3.37. Constraint Link Role
    • 5.2.3.38. Copyright
    • 5.2.3.39. Enabled-By Expression
    • 5.2.3.40. Glossary Membership Link Role
    • 5.2.3.41. Integer or String
    • 5.2.3.42. Interface Brief Description
    • 5.2.3.43. Interface Compound Definition Kind
    • 5.2.3.44. Interface Compound Member Compound
    • 5.2.3.45. Interface Compound Member Declaration
    • 5.2.3.46. Interface Compound Member Definition
    • 5.2.3.47. Interface Compound Member Definition Directive
    • 5.2.3.48. Interface Compound Member Definition Variant
    • 5.2.3.49. Interface Definition
    • 5.2.3.50. Interface Definition Directive
    • 5.2.3.51. Interface Definition Variant
    • 5.2.3.52. Interface Description
    • 5.2.3.53. Interface Enabled-By Expression
    • 5.2.3.54. Interface Enum Definition Kind
    • 5.2.3.55. Interface Enumerator Link Role
    • 5.2.3.56. Interface Function Definition
    • 5.2.3.57. Interface Function Definition Directive
    • 5.2.3.58. Interface Function Definition Variant
    • 5.2.3.59. Interface Function Link Role
    • 5.2.3.60. Interface Group Identifier
    • 5.2.3.61. Interface Group Membership Link Role
    • 5.2.3.62. Interface Include Link Role
    • 5.2.3.63. Interface Notes
    • 5.2.3.64. Interface Parameter
    • 5.2.3.65. Interface Parameter Direction
    • 5.2.3.66. Interface Placement Link Role
    • 5.2.3.67. Interface Return Directive
    • 5.2.3.68. Interface Return Value
    • 5.2.3.69. Interface Target Link Role
    • 5.2.3.70. Link
    • 5.2.3.71. Name
    • 5.2.3.72. Optional String
    • 5.2.3.73. Requirement Non-Functional Type
    • 5.2.3.74. Requirement Reference
    • 5.2.3.75. Requirement Reference Type
    • 5.2.3.76. Requirement Refinement Link Role
    • 5.2.3.77. Requirement Text
    • 5.2.3.78. Requirement Validation Link Role
    • 5.2.3.79. Requirement Validation Method
    • 5.2.3.80. SPDX License Identifier
    • 5.2.3.81. Specification Attribute Set
    • 5.2.3.82. Specification Attribute Value
    • 5.2.3.83. Specification Boolean Value
    • 5.2.3.84. Specification Explicit Attributes
    • 5.2.3.85. Specification Floating-Point Assert
    • 5.2.3.86. Specification Floating-Point Value
    • 5.2.3.87. Specification Generic Attributes
    • 5.2.3.88. Specification Information
    • 5.2.3.89. Specification Integer Assert
    • 5.2.3.90. Specification Integer Value
    • 5.2.3.91. Specification List
    • 5.2.3.92. Specification Mandatory Attributes
    • 5.2.3.93. Specification Member Link Role
    • 5.2.3.94. Specification Refinement Link Role
    • 5.2.3.95. Specification String Assert
    • 5.2.3.96. Specification String Value
    • 5.2.3.97. Test Case Action
    • 5.2.3.98. Test Case Check
    • 5.2.3.99. Test Name
    • 5.2.3.100. UID
• 5.3. Traceability of Specification Items
  • 5.3.1. History of Specification Items
  • 5.3.2. Backward Traceability of Specification Items
  • 5.3.3. Forward Traceability of Specification Items
  • 5.3.4. Traceability between Software Requirements, Architecture and Design
• 5.4. Requirement Management
  • 5.4.1. Change Control Board
  • 5.4.2. Add a Requirement
  • 5.4.3. Modify a Requirement
  • 5.4.4. Mark a Requirement as Obsolete
• 5.5. Tooling
  • 5.5.1. Tool Requirements
  • 5.5.2. Tool Evaluation
  • 5.5.3. Best Available Tool - Doorstop
  • 5.5.4. Custom Requirements Management Tool
• 5.6. How-To
  • 5.6.1. Getting Started
  • 5.6.2. Glossary Specification
  • 5.6.3. Interface Specification
    • 5.6.3.1. Specify an API Header File
    • 5.6.3.2. Specify an API Element