%0 Journal Article %1 lutz03 %A Lutz, Robyn R. %D 2003 %J Journal of Systems and Software %K safety requirements empirical %N 2 %P 155--161 %R 10.1016/S0164-1212(02)00057-2 %T Operational anomalies as a cause of safety-critical requirements evolution %U http://www.sciencedirect.com/science/article/B6V0N-48F5SBP-7/2/e979c717d78a0de0fcf2297e142bcab4 %V 65 %X This paper reports the results of a small study of requirements changes to the onboard software of seven spacecraft subsequent to launch. Only those requirement changes that resulted from operational (i.e., post-launch) anomalies were of interest here, since the goal was to better understand the relationship between critical anomalies during operations and how safety-critical requirements evolve. The results of the study were surprising in that anomaly-driven requirements changes during operations were rarely due to previous requirements having been incorrect. Instead, changes involved new requirements either (1) for the software to handle rare but high-consequence events or (2) for the software itself to compensate for hardware failures or limitations. The prevalence of new requirements as a result of post-launch anomalies suggests a need for increased requirements-engineering support of maintenance activities in these systems. The results also confirm both the difficulty and the benefits of pursuing requirements completeness, especially in terms of fault tolerance, during development of critical systems.

@article{lutz03, abstract = {This paper reports the results of a small study of requirements changes to the onboard software of seven spacecraft subsequent to launch. Only those requirement changes that resulted from operational (i.e., post-launch) anomalies were of interest here, since the goal was to better understand the relationship between critical anomalies during operations and how safety-critical requirements evolve. The results of the study were surprising in that anomaly-driven requirements changes during operations were rarely due to previous requirements having been incorrect. Instead, changes involved new requirements either (1) for the software to handle rare but high-consequence events or (2) for the software itself to compensate for hardware failures or limitations. The prevalence of new requirements as a result of post-launch anomalies suggests a need for increased requirements-engineering support of maintenance activities in these systems. The results also confirm both the difficulty and the benefits of pursuing requirements completeness, especially in terms of fault tolerance, during development of critical systems.}, added-at = {2006-09-17T06:41:48.000+0200}, author = {Lutz, Robyn R.}, biburl = {https://www.bibsonomy.org/bibtex/21c65ab4946bbf98e3d44a2bde4a6be61/fink08}, citeulike-article-id = {282226}, description = {From CUL on Sept 16}, doi = {10.1016/S0164-1212(02)00057-2}, interhash = {cf075e7010c143c52b28a3d5a868c1bf}, intrahash = {1c65ab4946bbf98e3d44a2bde4a6be61}, journal = {Journal of Systems and Software}, keywords = {safety requirements empirical}, month = {February}, number = 2, pages = {155--161}, priority = {2}, timestamp = {2006-09-17T06:41:48.000+0200}, title = {Operational anomalies as a cause of safety-critical requirements evolution}, url = {http://www.sciencedirect.com/science/article/B6V0N-48F5SBP-7/2/e979c717d78a0de0fcf2297e142bcab4}, volume = 65, year = 2003 }