HOW TO WRITE SRS FOR AN EMBEDDED SYSTEM ACCORDING TO IEEE 29148 STANDARD
HOW TO WRITE SRS FOR AN EMBEDDED SYSTEM ACCORDING TO IEEE 29148 STANDARD
Software is the brain of an embedded system because it has to perform main decision making based on the incoming data. Due to such an important and critical role, requirements analysis and development of embedded software in an organized way becomes imperative. Outcome of requirements It is the document which is mutually signed by System Engineers, Software Developers, Program Management and Software Testers. In this article we will discuss how to write some basic SRS document for embedded system according to IEEE 29148:2018 standard.
Layout of SRS
First of all layout of SRS should be agreed upon between all stakeholders. One of the suggestive outline is given in 8.4.2 of IEEE 29148:2018 standard. We will follow this outline and will explain each heading and put some example content under every heading.
Sample Project
In this article we are writing sample SRS for mission computer software of a generic aircraft. It is a very basic level SRS and you can tailor it for your specific project.
1. Introduction
Give a brief description of whole project whose software under consideration is a part. For example we are writing SRS for application software of a mission computer of an aircraft. It is a generic aircraft and main purpose of mission computer is to navigate the aircraft through waypoints according to the pilot inputs.
1.1 Purpose
Define the purpose of the software under consideration. In our case this software has to take inputs from the pilot through throttle and display buttons, navigate the aircraft along the waypoints by moving the surfaces through servo motors and display flight data of every moment to the pilot.
1.2 Scope
Name of the software is mission computer application software. It will get inputs from various sensors like Air Data Computer (ADC), Inertial Navigation Sensor (INS), Radar, etc. and will generate output for servos.
1.3 Product Overview
1.3.1 Product Perspective
In this section define the software relationship with other related products in the periphery. For our example system we will draw a block diagram as given below:
As you can see in the above diagram that software under consideration is shown gray. And all the products interacting with the software are shown with un-filled blocks along with communication protocol and number of channels.
It is important to note that FPGA resides on the same host processor card. So separate SRSs may be written for uProcessor Application software and FPGA software because they are separate CSCIs. However they both can be covered in one SRS and at Software Detail Design (SDD) level they can be treated separately.
1.1.1 Product Functions
In this section provide summary of the major functions that software will perform, preferably draw use case diagram. For our example use case diagram is given below.
1.1.2 User Characteristics
Describe general characteristics of intended user of the software system. In our example pilot is the user of Mission Computer having complete knowledge of how to fly the aircraft.
1.1.3 Limitations
Provide description of items that will limit the software options. In our example software under consideration is mission and safety critical so it should comply with DO-178C standard.
2. References
Give reference to other documents or standards which are related to this SRS. For our example references are given below
- System Requirements Specification (SyRS) of Mission Computer of Generic Aircraft.
- IEEE 29148:2018 Systems and Software Engineering – Lifecycle Processes – Requirements Engineering
- DO-178C Software Considerations in Airborne Systems and Equipment Certifications
- IEC 62304 – Medical Device Software – Software Lifecycle Process
- MIL-STD-882E System Safety
3. Requirements
3.1 Functions
Define the functional requirements of the software in conformance with the use case diagram given in product functions section.
3.1.1 Power on Initialization
First of all at power on of mission computer, software should check the health status of all the sensors and systems attached with it and report on display in case of any error.
3.1.2 Data Acquisition
Checksum of every packet of data coming from all the sensors will be verified and in case of any error, it will be reported on display.
3.1.3 Compute Navigation
Main purpose of mission computer is to navigate the aircraft through waypoints towards final destination. Various states of navigation are shown in the following state chart:
It is an over simplified state chart just giving a bird eye view of main functionality of mission computer whereas for actual software requirements it can be drawn in very precise details in order to capture detailed and specific requirements.
In similar fashion all the use cases will be explained with each and every detail. UML diagrams including state chart, activity diagram and sequence diagram needs to be drawn where ever applicable in order to furnish the requirements with clarity and details.
3.2 Performance Requirements
Specify performance related requirement of the software in this section. For our example, software should complete all the tasks assigned to it within 25ms both in normal and peak workload conditions.
3.3 Usability Requirements
Define requirements for proper use of the software in this section.
3.4 Interface Requirements
Define in details all inputs and outputs from the software system according to the block diagram given in product perspective section. These details can also be covered in separate document called ICD (Interface Control Document) and in SRS only reference to that document can be provided.
For our example, some of the generic interface requirements are given in the following table
3.5 Logical Database Requirements
Specify any information needs to be stored by the software. For our example, mission computer software needs to store whole mission data related to sensors health and waypoints related data in the built in flash drive in order to perform post mission analysis.
3.6 Design Constraints
Specify any constraints on the system design due to some external standards
3.7 Software System Attributes
Mention required attributes for the software system. For our example following attributes are required
- Reliability
As it is a mission and safety critical application so software should be highly reliable
- Availability
Software should be available 100% of the time and in case of any failure scenario, it should have alternate path.
- Maintainability
Software should be modular having layered architecture so that it could be maintained in lesser time.
4. Appendices
4.1 Assumptions and Dependencies
Factors affecting the requirements should be mentioned here.
4.2 Acronyms and Abbreviations
| ADU | Air Data Unit |
| ICD | Interface Control Document |
| INS | Inertial Navigation System |
| SRS | Software Requirements Specification |
