421.1 Requirements and specifications

Clarify what the software needs to do and under what conditions it must operate securely and reliably.

Overview

The first step in secure software development is understanding what the system must do, who it is for, and what risks must be managed. This begins with gathering requirements and defining specifications. If security is not considered from the outset, later efforts to protect the system may be ineffective or incomplete.

Requirements define what a system must achieve. Specifications describe the expected behaviour in enough detail for developers to design and build the solution. Both functional and non-functional specifications should include security, privacy, and compliance expectations.

Targets

In this topic, students learn to:

• Distinguish between requirements and specifications

• Identify functional and non-functional requirements

• Define specifications that support secure software behaviour

• Incorporate user needs and security expectations into documentation

Secure software architecture

Designing software

• Interpret and apply fundamental software development steps to develop secure code, including: – requirements definition – determining specifications

Requirements gathering

Requirements describe the goals the software must meet. These include:

• Functional requirements – What the system should do (e.g. process payments, allow user registration)

• Non-functional requirements – How the system should behave (e.g. response time, uptime, security)

Security-related requirements may include:

• The system must encrypt all stored passwords

• The system must log all failed login attempts

• Only authenticated users can access user profiles

Well-written requirements are clear, testable, and user-centred.

Defining specifications

Specifications are detailed statements that explain how the system should fulfil the requirements. They may include:

• Input and output formats

• Error conditions and responses

• Behaviour under unusual or invalid input

• Access controls and validation rules

• Integration with existing systems

Specifications form the basis for technical design and must reflect both normal and edge-case scenarios, especially where security is concerned.

Embedding security early

Waiting until after development to add security features is risky. Instead, security requirements should be:

• Identified during early consultations with stakeholders

• Documented alongside functional needs

• Prioritised where vulnerabilities may have serious consequences

Standard tools to support this process include:

• User stories with acceptance criteria (e.g. “As a user, I want to receive an email confirmation so that I can verify my account.”)

• Threat modelling to anticipate risks and define controls

Secure software begins with secure thinking, and that starts with the requirements and specifications.