Jan 16
2012
By Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
In 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...
Dec 19
2011
Acquisition , Acquisition Dynamics , Agile , Architecture Documentation , Architecture Driven Design (ADD) , Binaries , Cyber-physical Systems , Fuzzy Hashing , Handheld Devices , Malware , Measurement & Analysis , Resilience Management Model (RMM) , Safety-Related Requirements , Security-Related Requirements , SEI Research , Software Cost Estimates , Team Software Process (TSP) , Technical Debt
By Douglas C. Schmidt
Chief Technology Officer
A 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...
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