High-level Requirement List

From Square Root

User Classes and Characteristics

• Stakeholders of the project (executives, end users, software developers, security specialists)
• Requirement engineers with security expertise

Constraint

User Interfaces

• A slick user interface, that is user friendly and helps the user with the process.

Design and Implementation Constraints

• The preferred environment for development and execution is Java and Windows.
• Use of open source software is preferred.

Software Interfaces

• Provides integration options for other requirements tools such as Requisite Pro (prefer)
• Parts of the prototype tool may be reused but this is not a requirement.

Hardware Interfaces

• Accessible from Web servers (e.g. Cylab server, more people could use it) and can be installed on company servers

Quality Attribute

• Usability – Square tool should be easy to use by requirements engineers and stakeholders.
• Maintainability - The tool should be maintainable. Therefore it should use standard technology(open source). There should be clear and adequate documentation that would help maintenance.
• Modifiability - It should be easy to add new capabilities or to modify steps as the method evolves.
• Reliability - A combination of security and availability.
  • For availability - the tool should be available and the user should not be able to cause the tool to crash, no matter what kind of unforeseen error they make.
  • For security - The tool should not be able to be hacked into. The tool should support security measures such as role-management(information hiding) and password-protection.

System Feature

• The tool should support an iterative requirements engineering process.
• The tool will provide appropriate security, privacy, and access control for the functionality and underlying database.
• Enforces all nine steps of SQUARE

– if users want to skip steps, the system will show a warning message (privacy step will mostly parallel )

• Supports multiple projects and users
• Users fill specific roles on a project basis, roles enforce access.
• Analysis and traceability of requirements to business

Image:Traceability 02.JPG

Functional Feature by Steps

The known dependencies among SQUARE steps that must be supported in the tool.

• Step 1 – Agree on Definitions
  • Create security definition list based on provided standard definition.
  • Privacy: Create privacy definitions list
• Step 2 – Identify Security(and Privacy) goals and assets
  • One business goal maps to multiple security goals.
  • Security goals linked to asset
  • Resolve conflict
  • Privacy: Identify privacy goals and assets(example asset SSN database)
• Step 3 – Artifact Collection
  • Prompt stakeholders and engineers with lists of the different artifacts and scenarios involved.
  • Privacy: Include legal documents as privacy artifacts. These may come from company/government.
• Step 4 – Risk Assessment
  • Provide techniques and examples determine risks. (e.g. NIST)
  • Support use cases and misuse cases
  • Risk link to security goal
  • Import/Export abilities
  • Privacy: Privacy risk assessment technique(currently under research)
• Step 5 – Select Elicitation Technique
  • Questions to help build a weighted matrix so organizations can make a better decision on which elicitation techniques to use
  • Descriptions of techniques are included and can be modified by the users
  • Displayed techniques can be modified by the company using the tool
  • Privacy: Select privacy requirements elicitation techniques (select privacy questionnaire or some other technique)
• Step 6 – Elicit Security Requirements
  • Holds a list of security requirements
  • Supports/guides users through elicitation techniques
  • Requirements link to goals
  • A project may only use a single technique
  • Privacy: Elicit privacy requirements.
• Step 7 – Categorize
  • Tool was decided to allow users to set categorization of security requirements. (open topic)
  • Privacy: Follow the same technique for privacy and security. Merge security and privacy requirements and categorize together if both modules exists.
• Step 8 – Prioritization
  • Analytical Hierarchical Process (AHP)
  • Privacy: Similar to step 7--merge together if both modules exist.
• Step 9 – Review Requirements
  • Fagan inspection process
  • Traceability – should be able to show based on data collected in DB
  • Privacy: Inspect both security and privacy together.

Documentation

The tool should be developed using good software engineering practices and documentation.

• Developer’s, user’s and installation guides are needed.
• Formal review of major documents/decisions - requirements, architecture, design, test, user's guide, developer's guide,...