If something goes wrong with a software/hardware implementation then it is important to know what caused the problem. Sometimes the error lies in incorrect implementation of a specification but it is thought that a more common source of problems lies in earlier stages of the development process, where there may be mismatches between the requirements of the domain and the specification. For this reason, it is common (particularly in safety--critical applications) to find tightly monitored regimes of specification, in which the strategies of specification designers follow prescribed conventions and are closely constrained by regulatory reviewers. It would be useful if this process were as explicit as possible, making the design and reviewing process more open and accountable. One way of doing this is to provide formal descriptions of design strategies and to require designers to endorse their use of these by reference to appropriately formalised parts of the regulations. We examine how this may be done, using as a concrete example the domain of oil platform emergency shutdown systems.
|Title of host publication||Proceedings of ONR/ARPA/AFOSR/ARO/NSF workshop on Increasing the Practical Impact of Formal Methods for Computer-Aided Software Development|
|Number of pages||7|
|Publication status||Published - 1994|