ORIGINAL RESEARCH Using obstacle analysis to identify contingency requirements on an unpiloted aerial vehicle Robyn Lutz Æ Ann Patterson-Hine Æ Stacy Nelson Æ Chad R. Frost Æ Doron Tal Æ Robert Harris Received: 16 March 2006 / Accepted: 26 September 2006 / Published online: 31 October 2006 Ó Springer-Verlag London Limited 2006 Abstract This paper describes the use of Obstacle Analysis to identify anomaly handling requirements for a safety-critical, autonomous system. The software requirements for the system evolved during operations due to an on-going effort to increase the autonomous system’s robustness. The resulting increase in auton- omy also increased system complexity. This investiga- tion used Obstacle Analysis to identify and to reason incrementally about new requirements for handling failures and other anomalous events. Results reported in the paper show that Obstacle Analysis comple- mented standard safety-analysis techniques in identi- fying undesirable behaviors and ways to resolve them. The step-by-step use of Obstacle Analysis identified potential side effects and missing monitoring and control requirements. Adding an Availability Indicator and feature-interaction patterns proved useful for the analysis of obstacle resolutions. The paper discusses the consequences of these results in terms of the adoption of Obstacle Analysis to analyze anomaly handling requirements in evolving systems. Keywords Contingency requirements Á Obstacle analysis Á Safety-critical software Á Requirements evolution Á Autonomy Á Anomaly handling 1 Introduction This paper describes the use of Obstacle Analysis to identify anomaly handling requirements for a safety- critical, autonomous system. The software requirements for the system continued to evolve during operations due to an on-going effort to increase system robustness. The objective of the requirements evolution was for the software to handle more faults and anomalous situations autonomously. The resulting increase in autonomy also increased complexity. One risk was that the added software complexity and interactions would result in missing, inconsistent, or poorly understood require- ments for handling anomalies. Obstacle Analysis was undertaken to mitigate that risk. The software for the system was developed in incre- mental builds. Requirements evolved rapidly with autonomous features being added regularly. Autonomy is the capability of a software system to make control R. Lutz (&) JPL/Caltech and Iowa State University, 226 Atanasoff Hall, Ames, IA 50011, USA e-mail: rlutz@cs.iastate.edu A. Patterson-Hine Á C. R. Frost Ames Research Center, Mail Stop 269-4, Moffett Field, CA 94035, USA e-mail: apatterson-hine@mail.arc.nasa.gov C. R. Frost e-mail: cfrost@mail.arc.nasa.gov S. Nelson NelsonConsulting/QSS, Ames Research Center, Moffett Field, CA 94035, USA e-mail: NelsonConsult@aol.com D. Tal USRA/RIACS at NASA Ames Research Center, Moffett Field, CA 94035, USA e-mail: dt97@cornell.edu R. Harris 255 Group, Inc. at Ames Research Center, Mail Stop 262-2, Moffett Field, CA 94035, USA e-mail: trebor@trebor.org 123 Requirements Eng (2007) 12:41–54 DOI 10.1007/s00766-006-0039-4