Recently, a formal requirements method called SCR (Software Cost Reduction) was used to specify software requirements of mission-critical components of three NASA systems. The components included a fault protection engine, which determines how a spacecraft should respond to a detected fault; a fault detection, isolation and recovery component, which, in response to an undesirable event, outputs a failure notification and raises one or more alarms; and a display system, which allows a space crew to monitor and control on-orbit scientific experiments. This paper demonstrates how significant and complex requirements of one of the components can be translated into an SCR specification and describes the errors detected when the authors formulated the requirements in SCR. It also discusses lessons learned in using formal methods to document the software requirements of the three components. Based on the authors' experiences, the paper presents several recommendations for improving the quality of requirements specifications of safety-critical aerospace software.
Applying a Formal Requirements Method to Three NASA Systems: Lessons Learned
2007-03-01
12936855 byte
Aufsatz (Konferenz)
Elektronische Ressource
Englisch
NASA lessons learned: moving to a more formal process
NTRS | 2005
|NASA Procurement Lessons Learned
NTIS | 2011
|NASA Materials Related Lessons Learned
NTIS | 2002
|NASA Materials Related Lessons Learned
NTRS | 2003
|NASA Procurement Lessons Learned
NTRS | 2011
|