6.4. Requirements#

The Requirements Definition stage is where developers determine exactly what the software needs to do (functional requirements) and how it needs to perform and comply (non-functional requirements).

6.4.1. Functional Requirements#

Functional requirements detail the core tasks and behaviors the software must fulfill from an end-user perspective. They define what the system should do and how it should interact with users, external systems, or devices.

Examples

  • User Authentication: The system must allow users to create accounts and log in securely.

  • Data Input & Output: The system must let users submit posts or feedback, and must display relevant data on screen.

  • Business Logic: If it’s an e-commerce platform, it must process payments, generate invoices, and handle inventory.

6.4.2. Non-Functional Requirements#

Non-functional requirements capture the qualities and constraints of the software. This is how the software should behave beyond basic functionality. They often include performance, reliability, usability, privacy and security aspects.

User Capabilities and Secure Design#

Experience and Capabilities

Understanding the experience level of end users guides the complexity of secure features. For example, less tech-savvy audiences may need simpler authentication flows e.g. clear password guidelines or simple multi-factor authentication.

You must also be aware of making your software accessible for those with impairments or disabilities. Secure software should be available to everyone equally and it should not be compromised.

Error Handling

If your users are non-technical, error messages should be clear yet not overly detailed detailed errors can inadvertently reveal system internals to malicious actors.

Exception Management as a Requirement#

Exception management is how software responds when something unexpected happens, such as missing data, invalid input, a database error, or a failed network request.

Secure software should define how exceptions are handled before the software is released. Requirements and specifications should state that the software must:

  • show users clear, safe error messages

  • avoid exposing stack traces, database errors, file paths, secret keys, or internal configuration details

  • log enough information for developers to investigate the problem

  • fail safely, for example by denying an action if authorisation cannot be confirmed

  • keep running where possible rather than crashing the whole application

Good exception management improves the user’s experience and reduces security risk. It also helps developers find and fix problems after release.

Memory and Resource Management as a Requirement#

Memory management is part of efficient execution. If software uses too much memory, it can become slow, crash, or make the server unavailable for other users. Attackers may also try to trigger high memory use by sending very large requests or repeatedly asking for expensive operations.

Secure software should define memory and resource expectations before the software is designed and built. Requirements should consider:

  • maximum request and upload sizes

  • pagination for large results instead of loading everything at once

  • streaming large files rather than reading the whole file into memory

  • timeouts for slow operations

  • limits on how many records can be returned in one response

  • rules for closing files, database connections, and network connections

  • monitoring expectations for memory, CPU, disk, and network usage

  • avoiding storage of sensitive data in memory longer than needed

These requirements improve performance for users and reduce the chance that one request can exhaust the resources needed by the rest of the system.

Privacy as a Requirement#

Privacy Policy & Transparency

Users must be informed about how their data is collected, used, and stored. Requirements should specify the creation or update of privacy policies, with easy access and transparent language.

Obtaining User Consent

Consent must be explicitly gained for data collection whenever required by law or good practice. Requirements should clarify the opt-in and opt-out mechanisms.

Data Minimisation

Data minimisation means collecting only what is essential. The system’s requirements should limit personal data fields to what’s strictly needed to operate features.

Retention & Deletion

Requirements should define how long data is kept and under what conditions it will be deleted to uphold users’ rights.

Compliance with Regulations#

Privacy Act 1988 (Australia)

Software developed or used in Australia is subject to Australian law and must comply with the principles of the Privacy Act 1988, including rules around personal information handling, disclosure, and consent.

Global / Other Jurisdictions

Projects with international reach may need to address other frameworks like the GDPR (Europe) or CCPA (California).

User Data Rights

Regulatory requirements often include the right to access, rectify, and delete personal data. The system’s non-functional requirements should address how users can request these actions, how the system will honor them, and how quickly.

6.4.3. Glossary#

Functional requirement#

A requirement that describes what the system should do and how it should interact with users, external systems, or devices.

Non-functional requirement#

A requirement that describes qualities or constraints of the software, such as performance, reliability, usability, privacy, or security.

Exception management#

The way software detects, handles, reports, and recovers from unexpected errors.

Memory management#

Designing software so it uses memory and other system resources efficiently and safely.

Privacy policy#

A document that informs users how their data is collected, used, and stored.

Explicit user agreement for data collection, when required by law or good practice.

Opt-in#

A mechanism where users actively choose to allow something, such as data collection.

Opt-out#

A mechanism where users choose to stop or reject something, such as data collection.

Data minimisation#

Limiting personal data collection to what is strictly needed to operate features.

Privacy Act 1988#

Australian privacy law covering personal information handling, disclosure, and consent.

GDPR#

European privacy regulation that may apply to projects with international reach.

CCPA#

California privacy law that may apply to projects with international reach.

Data access#

A user’s right to request access to their personal data.

Data rectification#

A user’s right to request correction of their personal data.

Data deletion#

A user’s right to request deletion of their personal data.