Entries Tagged as 'Security-Related Requirements'

The Need to Specify Requirements for Off-Nominal Behavior

Acquisition , Safety-Related Requirements , Security-Related Requirements No Comments »

By Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program

Don FiresmithIn our work with acquisition programs, we’ve often observed a major problem: requirements specifications that are incomplete, with many functional requirements missing. Whereas requirements specifications typically specify normal system behavior, they are often woefully incomplete when it comes to off-nominal behavior, which deals with abnormal events and situations the system must detect and how the system must react when it detects that these events have occurred or situations exist. Thus, although requirements typically specify how the system must behave under normal conditions, they often do not adequately specify how the system must behave if it cannot or should not behave as normally expected. This blog post examines requirements engineering for off-nominal behavior.

Read more...

A Summary of Key SEI R&D Accomplishments in 2011

Acquisition , Agile , Architecture Documentation , Binaries , Cyber-physical Systems , Fuzzy Hashing , Handheld Devices , Malware , Measurement & Analysis , Resilience Management Model (RMM) , Safety-Related Requirements , Security-Related Requirements , Software Cost Estimates , Team Software Process (TSP) , Technical Debt 1 Comment »

By Douglas C. Schmidt
Chief Technology Officer

Douglas C. SchmidtA key mission of the SEI is to advance the practice of software engineering and cyber security through research and technology transition to ensure the development and operation of software-reliant Department of Defense (DoD) systems with predictable and improved quality, schedule, and cost. To achieve this mission, the SEI conducts research and development (R&D) activities involving the DoD, federal agencies, industry, and academia. One of my initial blog postings summarized the new and upcoming R&D activities we had planned for 2011. Now that the year is nearly over, this blog posting presents some of the many R&D accomplishments we completed in 2011.

Read more...

A Collaborative Method for Engineering Safety- and Security-Related Requirements

Acquisition , Safety-Related Requirements , Security-Related Requirements No Comments »

By Donald Firesmith,
Senior Member of the Technical Staff
Acquisition Support Program

This blog post is the third and final installment in a series exploring the engineering of safety- and security-related requirements.

Background: In our research and acquisition work on commercial and Department of Defense (DoD) programs, we see many systems with critical safety and security ramifications. With such systems, safety and security engineering are used to managing the risks of accidents and attacks. Safety and security requirements should therefore be engineered to ensure that residual safety and security risks will be acceptable to system stakeholders. The first post in this series explored problems with quality requirements in general and safety and security requirements in particular.  The second post, took a deeper dive into key obstacles that acquisition and development organizations encounter concerning safety- and security-related requirements. This post introduces a collaborative method for engineering these requirements that overcomes the obstacles identified in earlier posts.

Read more...

Obstacles in Engineering Safety- and Security-Related Requirements, Second in a Three-Part Series

Acquisition , Safety-Related Requirements , Security-Related Requirements No Comments »

By Donald Firesmith,
Senior Member of the Technical Staff
Acquisition Support Program

Background: In our research and acquisition work on commercial and Department of Defense (DoD) programs, ranging from relatively simple two-tier data-processing applications to large-scale multi-tier weapons systems, one of the primary problems that we see repeatedly is that acquisition and development organizations encounter the following three obstacles concerning safety- and security-related requirements:

  1. Safety, security, and requirements engineers typically know little about each others’ disciplines.
  2. Safety, security and requirements engineers often reside in separate teams that rarely collaborate when engineering safety- and security-related requirements.
  3. Safety and security are viewed as specialty engineering disciplines that are not well integrated into the overall systems engineering process until after the architecture is largely finalized.

This is the second in a series exploring the engineering of safety- and security-related requirements. The first post in the series explored problems with quality requirements.  This post takes a deeper dive into key obstacles that acquisition and development organizations encounter concerning safety- and security-related requirements. In the third part of this series, we will introduce a collaborative method for engineering these requirements that overcomes the obstacles identified in this blog.

Read more...

The Importance of Safety- and Security-related Requirements, First of a Three-Part Series

Acquisition , Safety-Related Requirements , Security-Related Requirements 2 Comments »

By Donald Firesmith,
Senior Member of the Technical Staff
Acquisition Support Program

Don Firesmith In our research and acquisition work on commercial and Department of Defense (DoD) programs ranging from relatively simple two-tier data-processing applications to large-scale multi-tier weapons systems , one of the primary problems that we see repeatedly is that requirements engineers tend to focus almost exclusively on functional requirements and largely ignore the so-called nonfunctional requirements, such as data, interface, and quality requirements, as well as technical constraints. Unfortunately, this myopia means that requirements engineers overlook critically important, architecturally-significant, quality requirements that specify minimum acceptable amounts of qualities, such as availability, interoperability, performance, portability, reliability, safety, security, and usability. This blog post is the first in a series that explores the engineering of safety- and security-related requirements.

Read more...