Advertisement

Supporting the Validation of Adequacy in Requirements-Based Hazard Mitigations

  • Bastian TenbergenEmail author
  • Thorsten Weyer
  • Klaus Pohl
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 9013)

Abstract

[Context and motivation] In practice, validating functional safety requirements is mainly done by means of reviews, which require large amounts of contextual information about hazards, such as safety goals or the operational conditions under which the hazard occurs. [Question/problem] This information is often scattered across a plethora of artifacts produced particularly during requirements engineering and safety assessment. In consequence, there is a risk that not all relevant information is considered during reviews, leading to subjective and misjudged results. [Principal ideas/results] In order to improve the consideration of all relevant information necessary to validate functional safety requirements, we propose a diagrammatic representation integrating all relevant contextual information. [Contribution] We hypothesize that reviewers are more likely to base their judgment on the relevant contextual information about the hazard, which increases objectivity and confidence in review results. To support this hypothesis, we report preliminary results of an empirical study.

Keywords

Safety requirements Hazards Validation Safety assessment Mitigation Adequacy Safety-critical embedded systems 

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    Leveson, L.: Safeware: System Safety and Computers. Addison-Wesley, Boston (1995)Google Scholar
  2. 2.
    Firesmith, D.: Engineering Safety Requirements, Safety Constraints, and Safety-Critical Requirements. J. Obj. Tech. 3, 27–42 (2004)Google Scholar
  3. 3.
    Leveson, L.: Engineering a Safer World. MIT Press, Boston (2011)Google Scholar
  4. 4.
    Allenby, K., Kelly, T.: Deriving safety requirements using scenarios. In: Proc. 5th Int. Symp. Requirements Eng., pp. 228–235 (2001)Google Scholar
  5. 5.
    Ericson II, C.: Hazard Analysis Techniques for System Safety. Wiley, New York (2005)CrossRefGoogle Scholar
  6. 6.
    ARP4761: Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment. SAE International (1996)Google Scholar
  7. 7.
    ISO26262: Road Vehicles - Functional Safety. International Organization for Standardization (2011)Google Scholar
  8. 8.
    Bishop, P., Bloomfield, R., Guerra, S: The future of goal-based assurance cases. In: Proc. Workshop on Assurance Cases, pp. 390–395 (2004)Google Scholar
  9. 9.
    Whyte,D.: Moving the goalposts: the deregulation of safety in the post-piper alpha offshore oil industry. In: Proc. 47th Ann. Conf. Political Studies Assoc. of the UK (1997)Google Scholar
  10. 10.
    Hatcliff, J., Wayssyng, A., Kelly, T., Comar, C., Jones, P.: Certifiably safe software-dependent systems: challenges and directions. In: Proc. Future Softw. Eng., pp. 182–200 (2014)Google Scholar
  11. 11.
    Boehm, B.: Verifying and Validating Software Requirements and Design Specifications. IEEE Softw. 1, 75–88 (1984)CrossRefGoogle Scholar
  12. 12.
    Glinz, M.: Improving the quality of requirements with scenarios. In: Proc 2nd World Cong. Softw. Qual., pp. 55–60 (2000)Google Scholar
  13. 13.
    ISO/IEC 25010: Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models. International Organization for Standardization (2011)Google Scholar
  14. 14.
    Boehm, B.: Software Engineering Economics. Prentice Hall, Englewood Cliffs (1981)zbMATHGoogle Scholar
  15. 15.
    Glinz, M., Fricker, S.: On Shared Understanding in Software Enigneering. Computer Sci. Res. Dev. doi: 10.1007/s00450-014-0256-x
  16. 16.
    Gacitua, R., Ma, L., Nuseibeh, B., Piwek, P., de Roeck, A., Rouncefield, M., Sawyer, P., Willis, A., Yang, H.: Making tacit requirements explicit. In: Proc. 2nd Int. Workshop on Manag. Req. Knowl., pp. 85–88 (2009)Google Scholar
  17. 17.
    Lisagor, I., Sun, L., Kelly, T.: The illusion of method: challenges of model-based safety assessment. In: Proc. 28th Int. Syst. Safety Conf. (2010)Google Scholar
  18. 18.
    Sun, K.: Establishing Confidence in Safety Assessment Evidence. Dissertation, Univ. of York (2012)Google Scholar
  19. 19.
    Flynn, D., Warhurst, R.: An Empirical Study of the Validation Process within Requirements Determination. Inf. Syst. J. 4, 185–212 (1994)CrossRefGoogle Scholar
  20. 20.
    Davies, I., Green, P., Rosemann, M., Idulska, M., Gallo, S.: How do Practitioners use Conceptual Modeling in Practice? Data & Knowl. Eng. 58, 358–380 (2006)CrossRefGoogle Scholar
  21. 21.
    US FAA: Introduction to TCAS II, Version 7.1. (2011). http://goo.gl/EPCYzI
  22. 22.
    Glinz, M.: On non-functional requirements. In: Proc. IEEE Int. Requirements Eng. Conf., pp. 21–26 (2007)Google Scholar
  23. 23.
    Chung, L., Nixon, B., Yu, E., Mylopoulos, J.: Non-functional Requirements in Software Engineering. Kluwer, Boston (2000)CrossRefzbMATHGoogle Scholar
  24. 24.
    Sikora, E., Tenbergen, B., Pohl, K.: Industry Needs and Research Directions in Requirements Engineering for Embedded Systems. Requirements Eng. 17, 57–78 (2012)CrossRefGoogle Scholar
  25. 25.
    Störrle, H.: Semantics of UML 2.0 activities. In: Proc. IEEE Symp. Visual Lang. and Human-Centric Computing, pp.235–242 (2004)Google Scholar
  26. 26.
    Wohlin, C., Runeson, P., Höchst, M., Ohlson, M., Regnell, B., Wesslén, A.: Experimentation in Software Engineering – An Introduction. Springer, Heidelberg (2012)CrossRefGoogle Scholar
  27. 27.
    Venkatesh, V., Bala, H.: Technology Acceptance Model 3 and a Research Agenda on Interventions. Decision Sci. 39, 273–315 (2008)CrossRefGoogle Scholar
  28. 28.
    Goodhue, D.: Development and Measurement Validity of a Task-Technology Fit Instrument for User Evaluations or Information Systems. Decision Sci. 29, 105–138 (1998)CrossRefGoogle Scholar
  29. 29.
    Denger, C.: SafeSpection — A Framework for Systematization and Customization of Software Hazard Identification by Applying Inspection Concepts. Dissertation, TU Kaiserslautern (2009)Google Scholar
  30. 30.
    Fagan, M.: Design and Code Inspections to Reduce Errors in Program Development. IBM Syst. J. 3, 182–211 (1976)CrossRefGoogle Scholar
  31. 31.
    Shull, F., Rus, I., Basili, V.: How Perspective-Based Reading Can Improve Requirements Inspections. IEEE Computer 33, 73–79 (2000)CrossRefGoogle Scholar
  32. 32.
    Li Q, Boehm B, Yang Y, Wang Q: A value-based review process for prioritizing artifacts. In: Proc. Int. Conf. Softw. Syst. Process, pp. 13–23 (2011)Google Scholar
  33. 33.
    Bitsch, F.: Safety patterns - the key to formal specification of safety requirements. In: Voges, U. (ed.) SAFECOMP 2001. LNCS, vol. 2187, pp. 176–189. Springer, Heidelberg (2001)CrossRefGoogle Scholar
  34. 34.
    Heitmeyer, C., Kirby Jr., J., Labaw, B., Archer, M., Bharadwaj, R.: Using Abstraction and Model Checking to Detect Safety Violations in Requirements Specifications. IEEE TSE 24, 927–948 (1998)Google Scholar
  35. 35.
    Zafar, S., Dromey, R.: Integrating safety and security requirements into design of an embedded system. In: Proc. 12th Asia-Pacific Soft. Eng. Conf., pp. 1530–1362 (2005)Google Scholar
  36. 36.
    Sindre, G.: A look at misuse cases for safety concerns. In: Ralyté, J., Brinkkemper, J., Henderson-Sellers, B. (eds.) Situational Method Engineering: Fundamentals and Experiences. IFIP, vol. 244, pp. 252–266. Springer, Heidelberg (2007)CrossRefGoogle Scholar
  37. 37.
    Katta, V., Raspotnig, C., Karpati, P., Stålhane, T.: Requirements management in a combined process for safety and security assessments. In: Proc. Intl. Conf. on Availability, Rel., and Security, pp. 780–786 (2013)Google Scholar
  38. 38.
    Raspotnig, C., Opdahl, A.: Comparing Risk Identification Techniques for Safety and Security Requirements. J. Sys. Softw. 86, 1124–1151 (2013)CrossRefGoogle Scholar
  39. 39.
    van Lamsweerde, A.: Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley, New York (2009)Google Scholar
  40. 40.
    Letier, E., van Lamsweerde,A.: Deriving operational software specifications from system goals. In: Proc. Future of Softw. Eng., pp. 119–128 (2002)Google Scholar
  41. 41.
    Belli, F., Hollmann, A., Nissanke, N.: Modeling, analysis and testing of safety issues - an event-based approach and case study. In: Saglietti, F., Oster, N. (eds.) SAFECOMP 2007. LNCS, vol. 4680, pp. 276–282. Springer, Heidelberg (2007)CrossRefGoogle Scholar
  42. 42.
    Chen, Z., Motet, G: Formalizing safety requirements using controlling automata. In: Proc. 2nd Int. Conf. Depend., pp. 81–86 (2009)Google Scholar
  43. 43.
    Guillerm, R., Sadou, N., Demmou,H.: Combining FMECA and fault trees for declining safety requirements of complex systems. In: Proc. Ann. Europ. Safety and Rel. Conf., pp. 1287–1293 (2011)Google Scholar
  44. 44.
    Hansen, K., Ravn, A., Stavridou, V.: From Safety Analysis to Software Requirements. IEEE TSE 24, 573–584 (1998)Google Scholar

Copyright information

© Springer International Publishing Switzerland 2015

Authors and Affiliations

  1. 1.paluno – The Ruhr Institute for Software TechnologyUniversity of Duisburg-EssenEssenGermany

Personalised recommendations