For more than 50 years, Auerbach Publications has been printing cutting-edge books on all topics IT.

Read archived articles or become a new subscriber to IT Today, a free newsletter.

This free newsetter offers strategies and insight to managers and hackers alike. Become a new subscriber today.



Interested in submitting an article? Want to comment about an article?

Contact John Wyzalek editor of IT Performance Improvement.


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:

  1. Agree on definitions
  2. Identify security goals
  3. Develop artifacts to support security requirements definition
  4. Assess risks
  5. Select elicitation technique(s)
  6. Elicit security requirements
  7. Categorize requirements
  8. Prioritize requirements
  9. 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:

  1. Agree on definitions
  2. Identify assets and security goals
  3. Perform risk assessment
  4. Elicit security requirements
  5. 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:

  1. 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.
  2. 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.
  3. 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.♦


1SQUARE Instructional Materials, Software Engineering Institute.

2Requirements Elicitation Case Studies Using IBIS, JAD, and ARM. Build Security In.

3Detail Misuse Cases,

Read more IT Performance Improvement

This article is an excerpt from:

Offering ground-level, already-developed software nonfunctional requirements and corresponding test cases and methods, this book will help to ensure that your software meets its nonfunctional requirements for security and resilience. The accompanying CD filled with helpful checklists and reusable documentation provides you with the tools needed to integrate security into the requirements analysis, design, and testing phases of your software development lifecycle.

Some Praise for the Book:

This book pulls together the state of the art in thinking about this important issue in a holistic way with several examples. It takes you through the entire lifecycle from conception to implementation —Doug Cavit, Chief Security Strategist, Microsoft Corporation

...provides the reader with the tools necessary to jump-start and mature security within the software development lifecycle (SDLC). —Jeff Weekes, Sr. Security Architect at Terra Verde Services

... full of useful insights and practical advice from two authors who have lived this process. What you get is a tactical application security roadmap that cuts through the noise and is immediately applicable to your projects. —Jeff Williams, Aspect Security CEO and Volunteer Chair of the OWASP Foundation

About the Authors

Mark S. Merkow, CISSP, CISM, CSSLP works at PayPal Inc. (an eBay company) in Scottsdale, Arizona, as Manager of Information Security Policies, Standards, Training, and Awareness in the Information Risk Management area. Mark has more than 35 years of experience in information technology in a variety of roles, including applications development, systems analysis and design, security engineering, and security management. Mark holds a masters degree in decision and info systems from Arizona State University (ASU), a masters of education in distance learning from ASU, and an undergraduate degree in computer info systems from ASU. In addition to his day job, Mark engages in a number of other extracurricular activities, including consulting, course development, online course delivery, and writing columns and books on information technology and information security.

Lakshmikanth Raghavan, CISM, CRISC (Laksh) works at PayPal Inc. (an eBay company) as Staff Information Security Engineer in the Information Risk Management area, specializing in application security. Laksh has more than ten years of experience in the areas of information security and information risk management, and has provided consulting services to Fortune 500 companies and financial services companies around the world. Laksh holds a bachelor’s degree in electronics and telecommunication engineering from the University of Madras, India. He enjoys writing security-related articles and has spoken on the various dimensions of software security at industry forums and security conferences. This is Laksh’s second book.