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
- 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.
- 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.
- Accessible from Web servers (e.g. Cylab server, more people could use it) and can be installed on company servers
- 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.
- 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
Functional Feature by Steps
- 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.
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,...