The Safety Requirements Engineering Dilemma

Authors:
Daniel M. Berry
Affiliations:
Computer Science, Technion, Haifa 32000, Israel
Venue:
IWSSD '98 Proceedings of the 9th international workshop on Software specification and design
Year:
1998

Citing 2
Cited 2

Safeware: system safety and computers

Safeware: system safety and computers
Analyzing Safety Requirements for Process-Control Systems

IEEE Software

Software engineering for safety: a roadmap

Proceedings of the Conference on The Future of Software Engineering
Handling Obstacles in Goal-Oriented Requirements Engineering

IEEE Transactions on Software Engineering - special section on current trends in exception handling—part II

Quantified Score

Hi-index	0.00

Visualization

Abstract

A key idea followed in the software and system safety community is that an identified hazard is best dealt with by changing the requirements of the system so that the hazard does not even occur. This modus operandi creates a serious dilemma. The hazard identification, that is needed in order to know what hazards to avoid, is best done after the code has been written, because only then are the potential effects of any particular stimulus, event, etc. deducible. However, if the response to the identified hazard is to change the requirements, then this requirements change will happen only after the code is written. Such changes are both expensive and dangerous. So, a means to identify all hazards at requirements analysis time is needed.