Abstract
Summary form only given. In developing software for safety critical systems, it is necessary to carry out both requirements analysis and safety analysis. During requirements analysis, the behavioural and functional requirements of the system's software components are defined, documented, and reviewed. In addition, the requirements analyst is responsible for identifying and documenting the system safety requirements that pertain to the system's software. Safety analysis techniques are used to determine whether or not the safety requirements are satisfied. Traditionally, safety analysis has been performed on designs of the system's software, including a high level design, and not on the system's software requirements specification. However, if the requirements are described in terms of an operational model, a safety analysis of the requirements is possible. Are there any requirements techniques that help with the problems of developing safety critical software? Are there any requirements techniques that hinder development of such software? Is it effective to perform parts of a safety analysis on the requirements specification, as opposed to delaying analysis until design or implementation? If so, what parts of a safety analysis should be done on the requirements specification, and what parts should be done on the design description?.
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.