Sep 26
2011
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...
Jul 18
2011
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:
- Safety, security, and requirements engineers typically know little about each others’ disciplines.
- Safety, security and requirements engineers often reside in separate
teams that rarely collaborate when engineering safety- and
security-related requirements.
- 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...
Jun 27
2011
By Donald Firesmith,
Senior Member of the Technical Staff
Acquisition Support Program
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...
Recent Comments