SQUARE's Nine Steps

SQUARE’S security requirements elicitation and analysis process consists of the following nine steps:

Step 1: Agree on Definitions

  • Input: Candidate definitions from IEEE and other standards
  • Techniques: Structured interviews, focus group
  • Participants: Stakeholders, requirements engineer
  • Output: Agreed-to definitions

Step 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

Step 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

Step 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

Step 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

Step 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

Step 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

Step 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

Step 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