IT:AD:SQuaRE
* See also:
<callout type="Navigation" class="small">
</callout>
Summary
The acronym SQuaRE is used in the following cases:
* System Quality Requirements Engineering
* Security Quality Requirements Engineering
They both follow the same 9 steps, more or less.
Notes
System
System Quality Requirements Engineering (SQUARE) is a process model developed 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 analysing, development, development stages of the development life cycle.
- 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
Security
0. Agree on Definitions
- Input: Candidate definitions from IEEE and other standards
- Techniques: Structured interviews, focus group
- Participants: Stakeholders, requirements engineer
- Output: Agreed-to definitions
2. Identify Assets and Security Goals
- Input: Definitions, candidate goals, business drivers, policies and procedures, examples
- Techniques: Facilitated work session, surveys, interviews
- Participants: Stakeholders, requirements engineer
- Output: Assets and goals
3. Develop artifacts to support security requirements definition
- Input: Potential artifacts (e.g., scenarios, misuse cases, templates, forms)
- Techniques: Work session
- Participants: Requirements engineer
- Output: Needed artifacts: scenarios, misuse cases, models, templates, forms
4. Perform Risk Assessment
Input: Misuse cases, scenarios, security goals Techniques: Risk assessment method, analysis of anticipated risk against organizational risk tolerance, including threat analysis Participants: Requirements engineer, risk expert, stakeholders Output: Risk assessment results
5. Select elicitation Techniques
- Input: Goals, definitions, candidate techniques, expertise of stakeholders, organizational style, culture, level of security needed, cost benefit analysis, etc.
- Techniques: Work session
- Participants: Requirements engineer
- Output: Selected elicitation techniques
6. Elicit Security Requirements
- Input: Artifacts, risk assessment results, selected techniques
- Techniques: Joint Application Development (JAD), interviews, surveys, model-based analysis, checklists, lists of reusable requirements types, document reviews
- Participants: Stakeholders facilitated by requirements engineer
- Output: Initial cut at security requirements
7. Categorize Requirements as to Level (System, Software, etc.) and Whether They Are Requirements or Other Kinds of Constraints
- Input: Initial requirements, architecture
- Techniques: Work session using a standard set of categories
- Participants: Requirements engineer, other specialists as needed
- Output: Categorized requirements
8. Prioritize Requirements
- Input: Categorized requirements and risk assessment results
- Techniques: Prioritization methods such as Triage, Win-Win
- Participants: Stakeholders facilitated by requirements engineer
- Output: Prioritized requirements
9. Inspect Requirements
- Input: Prioritized requirements, candidate formal inspection technique
- Techniques: Inspection methods such as Fagan, peer reviews
- Participants: Inspection team
- Output: Initial selected requirements, documentation of decision-making process and rationale