{"title":"整合需求分析和安全分析","authors":"J. Atlee, J. Mcdermid","doi":"10.1109/ISRE.1995.1393410","DOIUrl":null,"url":null,"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?.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"33 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"2","resultStr":"{\"title\":\"Integrating requirements analysis and safety analysis\",\"authors\":\"J. Atlee, J. Mcdermid\",\"doi\":\"10.1109/ISRE.1995.1393410\",\"DOIUrl\":null,\"url\":null,\"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?.\",\"PeriodicalId\":354711,\"journal\":{\"name\":\"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)\",\"volume\":\"33 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1995-03-27\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"2\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/ISRE.1995.1393410\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ISRE.1995.1393410","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Integrating requirements analysis and safety analysis
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?.