Software Engineering Institute | Carnegie Mellon University
Software Engineering Institute | Carnegie Mellon University

Digital Library

Javascript is currently disabled for your browser. For an optimal search experience, please enable javascript.

Advanced Search

Basic Search

Content Type

Topics

Publication Date

Collection - Related Assets

Resources for Assurance Cases

  • The concept of an assurance case has been derived from the safety case. This library collection provides a list of SEI resources about assurance cases.
  • Software Architecture
  • Publisher: Software Engineering Institute
  • Software Assurance

    It is difficult to assure the safety, security, reliability or other nonfunctional properties of software-based systems because of their size, complexity, and continuing evolution. Traditional software and systems engineering techniques, including conventional test and evaluation approaches, cannot provide the justified confidence needed. The SEI is exploring the use of the assurance case is a means of providing such confidence, starting as early as when the system is designed and continuing through deployment. We are also creating a theory of assurance case confidence that will help acquirers, developers, and evaluators understand how much confidence they should have in the resulting system.

     

    Assurance Case

    The concept of an assurance case has been derived from the safety case, a construct that has been used successfully in Europe for over a decade to document safety for nuclear power plants, transportation systems, automotive systems, and avionics systems.

    The assurance case provides a means to structure the reasoning that engineers use implicitly to gain confidence that systems will work as expected. It also becomes a key element in the documentation of the system and provides a map to more detailed information.

    The following figure is a fragment of an assurance case for a keypad. It makes the claim (C1.1) that entry errors caused by the design of the keypad are mitigated. It bases this claim on an argument (only partially developed) showing how several possible hazards to proper data are mitigated (C3.1, C3.2, and C.3). C3.2 makes the claim that keypad markings are unambiguous, and this claim is supported by evidence Ev4.1 and Ev4.2 (design review and log of observed errors).

    Learn more about assurance cases and their use with the resources in this collection.

  • Dependability Cases May 2004 Author(s): Charles B. Weinstock, John B. Goodenough, John J. Hudak In this 2004 report, the authors explain how to create a dependability case for a system that helps identify and keep track of details of large systems.
  • Arguing Security - Creating Security Assurance Cases July 2013 Author(s): Charles B. Weinstock, Howard F. Lipson, John B. Goodenough In this paper, the authors explain an approach to documenting an assurance case for system security.
  • Towards an Assurance Case Practice for Medical Devices October 2009 Author(s): Charles B. Weinstock, John B. Goodenough In this report, the authors explore how to enable manufacturers and federal regulators gain confidence in software-dominated medical devices.
  • Evaluating Hazard Mitigations with Dependability Cases April 2009 Author(s): Matthew R. Barry (Software Intensive Systems, Inc.), John B. Goodenough In this 2009 paper, the authors present an example to show the value a dependability case adds to a traditional hazard analysis.
  • Assurance Cases for Design Analysis of Complex System of Systems Software April 2009 Author(s): Stephen Blanchette, Jr. In this presentation, Stephen Blanchette describes how the assurance case technique is can help analyze large and complex system of systems software design.
  • Assurance Cases for Design Analysis of Complex System of Systems Software April 2009 Author(s): Stephen Blanchette, Jr. This paper discusses the application of assurance cases as a means of building confidence that the software design of a complex system of systems will actually meet the operational objectives set forth in the project's top-level requirements.