An Overview of System Quality Requirements Engineering (SQUARE)
Mark S. Merkow and Lakshmikanth Raghavan
System Quality Requirements Engineering (SQUARE) is a process model
developed1 at Carnegie Mellon University (CMU). SQUARE provides a
means for eliciting, categorizing, and prioritizing security requirements for
information technology systems and applications. The focus of the model is
to build security and quality concepts into the early stages of the development
life cycle. The model can also be used for documenting and analyzing the
security and quality aspects of a development project.
The nine different steps of SQUARE are:
- Agree on definitions
- Identify security goals
- Develop artifacts to support security requirements definition
- Assess risks
- Select elicitation technique(s)
- Elicit security requirements
- Categorize requirements
- Prioritize requirements
- Inspect requirements
SQUARE usually requires about three months of effort to complete.
CMU also developed a shorter version, called SQUARE-Lite, with these five
steps:
- Agree on definitions
- Identify assets and security goals
- Perform risk assessment
- Elicit security requirements
- Prioritize requirements
SQUARE-Lite can be used by organizations that already have a requirements
engineering process in place and want to fit security and quality
requirements into it, or by organizations that have not yet decided to implement
the full SQUARE process model but still want some of the benefits.
Let's look at these five steps in detail.
Agree on Definitions
Agreement is the initial step that the requirements engineering team and
stakeholders undergo. They must first agree on a common set of terminology
and definitions. The process is carried out through a set of interviews and
guarantees effective and clear communication throughout the requirements
engineering process. This involves using public resources, such as the Software
Engineering Body of Knowledge (SWEBOK) [IEEE 05], the IEEE 610.12 Standard Glossary of Software Engineering Terminology [IEEE 90],
and Wikipedia.
Agreement also resolves ambiguity and differences in perspective. The
exit criteria for this step are a documented set of definitions. Typical examples
are access control (ACL), antivirus software, artifacts, assets, control,
attacks, audit information, authentication, availability, back doors,
breaches, brute force, buffer overflow, cache cramming, cache poisoning,
confidentiality, nonrepudiation, denial-of-service (DoS), intrusion, malware,
and so on.
Identify Assets and Security/Quality Goals
Identifying assets that need protection in the system and their corresponding
security and quality goals is the next objective. Initially, different stakeholders
will have different security and quality goals. Development teams
need to formally agree on a set of prioritized security goals for the project.
Without overall security goals for the project, it is impossible to identify the
priority and relevance of any security and quality requirements that are generated.
The quality goals of the project must be in clear support of the
project's overall business goal, which also must be identified and enumerated
in this step.
Once the goals of the various stakeholders are identified, they must be
reviewed, prioritized, and documented. In the absence of consensus, an
executive decision may be needed to prioritize the goals.
The exit criteria for this step is to document a single business goal for the
project and several prioritized security and quality goals for the overall software
system.
Perform Risk Assessments
This step begins with identification of the vulnerabilities and threats that
face the system, the likelihood that the threats will materialize as real
attacks, and any potential consequences of an attack. Without a risk assessment,
organizations may be tempted to implement security requirements or
countermeasures without any logical rationale.
Once the threats have been identified by the risk assessment method,
they must be classified according to their likelihood. These will aid in prioritizing
the security requirements generated at a later stage. For each threat identified, a corresponding security requirement can identify a quantifiable
and verifiable response. For instance, a requirement may describe speed of
containment, cost of recovery, or limit to the damage that can be done to
the system's functionality.
The requirements engineering team should facilitate the completion of
a structured risk assessment, which is often performed by an external risk
expert. Once complete, review the results of the risk assessment and share
them with stakeholders.
The exit criteria for this step are documented threats, their likelihoods,
and their classifications.
Elicit Security Requirements
Prior to this step, the requirements engineering team must select an elicitation
technique that is suitable for the client organization and project. Multiple
techniques may work for the same project. The difficulty with selecting
a technique is choosing one that can adapt to the number and expertise of
the stakeholders, the size and scope of the client project, and the expertise of
the requirements engineering team.
CMU has done an extensive evaluation and analysis of the different
types of elicitation methods and has shown that the Accelerated Requirements
Method (ARM) has been successful for eliciting security requirements.
The evaluation criteria include:
- Adaptability: The method can be used to generate requirements in
multiple environments. For example, the elicitation method works
equally as well with a software product that is near completion as
with a project in the planning stages.
- Computer-aided software engineering (CASE) tool: The method
includes a CASE tool. (The Software Engineering Institute defines
a CASE tool as "a computer-based product aimed at supporting
one or more software engineering activities within a software
development process.")
- Stakeholder acceptance: The stakeholders are likely to agree to the
elicitation method in analyzing their requirements. For example,
the method isn't too invasive in a business environment.
- Easy implementation: The elicitation method isn't overly complex
and can be properly executed easily.
- Graphical output: The method produces readily understandable
visual artifacts.
- Quick implementation: The requirements engineers and stakeholders
can fully execute the elicitation method in a reasonable length
of time.
- Shallow learning curve: The requirements engineers and stakeholders
can fully comprehend the elicitation method within a reasonable
length of time.
- High maturity: The elicitation method has experienced considerable
exposure and analysis in the requirements engineering community.
- Scalability: The method can be used to elicit the requirements of
projects of different sizes, from enterprise-level systems to small-
scale applications.2
Though results will vary from one organization to another, CMU's
approach is worth considering as a choice for your organization.
The Security Elicitation step is the heart of the SQUARE process. This
step describes the execution of the elicitation technique that was previously
selected.
Avoiding Potential Mistakes
The biggest mistake that the requirements engineering team can make in
this step is to elicit nonverifiable, vague, or ambiguous requirements. Each
requirement must be stated in a manner that will enable relatively easy verification
once the project has been implemented. For instance, the requirement
"the system shall improve the availability of the existing customer
service center" is impossible to measure objectively. Instead, the requirements
engineering team should encourage the production of requirements
that are clearly verifiable and, where appropriate, quantifiable. A better version
of the previously stated requirement would thus be "The system shall
handle at least 300 simultaneous connections to the customer service center."
Later in this chapter, you'll learn what makes for a good write-up of
nonfunctional requirements, and throughout the book you'll see hundreds
of good examples.
A second mistake that the requirements engineering team can make in
this step is to elicit implementations or architectural constraints instead of
requirements. Requirements are concerned with what the system should do,
not how it should be done.
Face-to-Face Elicitation Works Best
A key success factor is face-to-face interaction with all stakeholders. The exit
Criteria is an initial set of documented nonfunctional requirements for the
system.
Different methodologies dictate differing documentation techniques
for requirements gathering and analysis. Fans of the Unified Modeling Language
and Rational Unified Process are very familiar with the documentation
tool called use cases to capture functional requirements, but you may
find that they are not well-suited for capturing NFRs. You might find that
misuse cases to describe the steps of performing a malicious act against a system
are useful, just as you might describe an act that the system is supposed
to perform in a use case. Here are some suggested steps to follow:
- Begin with a preexisting knowledge base of common security
problems for systems that are similar to the one under development,
and determine whether an attacker may have cause to
think such vulnerability is possible in the system being developed.
Then, try to describe how the attacker would leverage the
problem. if it exists.
- Brainstorm on the basis of a list of system resources. For each
resource, attempt to construct misuse cases in connection with
each of the basic security services: authentication, confidentiality,
access control, integrity, and availability.
-
Third, brainstorm on the basis of a set of existing use cases. This
may be useful for identifying representative risks and for ensuring
that the first two approaches did not overlook any obvious
threats. Misuse cases derived in this fashion are often written in
terms of a valid use and then annotated to have malicious steps.3
Prioritize Requirements
In most cases, the development team will be unable to implement all of the
nonfunctional requirements due to the lack of time and/or resources, or
due to changes in the goals of the project. The purpose, then, of this step in
the SQUARE process is to prioritize the nonfunctional requirements, so
that the stakeholders can choose which requirements to implement and in
which order.
During prioritization, some of the requirements may be deemed
entirely infeasible to implement. In such cases, the requirements engineering team has a choice; completely dismiss the requirement from further
consideration, or document the requirement as "future work" and remove it
from the draft set of project requirements. This decision should be made
after consulting with all stakeholders and after leadership approvals.♦
Notes
1SQUARE Instructional Materials, Software Engineering Institute.
2Requirements Elicitation Case Studies Using IBIS, JAD, and ARM. Build Security In.
3Detail Misuse Cases, OWASP.org.
Read more IT Performance Improvement
Certain names and logos on this page and others may constitute trademarks, servicemarks, or tradenames of
Taylor & Francis LLC. Copyright © 2008—2012 Taylor & Francis LLC. All rights reserved.
|
