the development of an embedded system
During the development of an embedded system, it is essential to consider requirements and specifications. In a design process is the first step to undertake is requirement analysis. On the report, the user makes recommendations on the documents which are then clarified and documented to generate equivalent specifications. Designers are often anxious regarding design and implementation; having a discussion with the clients is integral when constructing safety-critical systems. Activities derived at the first stage are essential as they impact the downstream results generated downstream in the system life cycle. For example, errors identified in the requirements and specification stages yet ignored are likely to cause further complication in the design stages. Therefore, any error detected requires engineers to revisit the requirements and specifications stages to fix the mistakes. However, the preference to visit significantly results in a waste of time and resources, and there is a possibility other specification errors will be identified. Several accidents encountered are traced to either wrong assumption about requirements, incomplete implementation of specification or requirement flaws. Some of these issues may pass as non-safety critical issues, but in the safety-crucial system, these errors are significant due to their implications in requirements and specifications. Thus, it is essential to correct the mistakes and ensure the generation of precise and accurate specification.
Stakeholders’ requirements are clarified and translated from the previous statement related to engineering-oriented language to advocate for proper architecture design and verification activities required for the specific system.
Requirements traceability enables tracking of information from the source of stakeholders‘ requirements to essential requirements and other system defining elements (see Applying Life Cycle Processes). Additionally, traceability is used to offer a better understanding of the extent of changes identified as input when impact analysis is conducted with the intent to propose engineering improvements or change requests.
Requirements elicitation requests user involvements and may be used to gain effectively stakeholders involvement and buy-in. The two techniques used prototyping and Quality Function Deployment (QFD). For additional elicit requirements, there is a preference to use focus groups, interviews and Delphi techniques.
The rationale of every requirement translates stakeholders’ demands to system requirements. Moreover, requirements rationale identify reasons why requirements exist, possible assumptions done, results of related design studies and other needed support information. This explains additional requirements analysis and decomposition. The requirements database hosts the rationale (Hull, Jackson, and Dick 2010).
Advantages of the system entail.
- There is a reduction on several requirements as the process helps with identification on any duplicates, thus reducing project risks and costs.
- Early identification of bad assumptions made.
- Removes poorly constructed stakeholder requirements presented as design requirements in disguise.
- By capturing the requirement rationale it improves the stakeholders communication (Adapted from chapter 8 of (Hooks and Farry 2000).