#6 Defining the System Functions and Requirements

Once we have understood our context and defined the system boundary, the next step is to define what the system must do. This is where we shift from exploration to specification, from understanding the world around the system to stating the system’s intended behaviour.

This step marks the transition from Concept Definition to the System Requirements phase in the V-Model. It creates the foundation for architecture, design, and verification by producing traceable, testable, and stable requirements.

We focus on two levels of definition:

• Functional Requirements (FRs): What the system must do, from an operational point of view

• System Requirements (SRs): How those functions are technically realised

We also carry forward:

• Contextual insights (from #4 Establishing the System Context)

• Boundary decisions and interface expectations (from #5 Defining the System Boundary and Interfaces)

What’s a Function?

A system function is a discrete, observable behaviour the system performs to fulfil a purpose. It should be agnostic to specific implementation choices. In system engineering, we use functions to organise behaviour into logical units that:

• Address stakeholder needs

• Reflect system interactions

• Decompose cleanly into subsystems or components

For example:

• Validate user OTP

• Securely unlock locker door

• Notify admin of failed access attempts

These become Functional Requirements.

 Functional Requirements Example – OTP Locker System:

• FR-01: The system shall validate the user’s OTP before granting access.

• FR-02: The system shall notify the user of access approval or denial.

• FR-03: The system shall unlock the locker upon successful validation.

From Functions to System Requirements

Functional Requirements are translated into System Requirements — the testable, often more technical, specifications that describe how each function will be implemented.

We trace each FR into one or more SRs. Here’s a mini translation example:

FR-01 (Validate OTP) SR-01-1: The system shall accept OTP input via a 5-inch touchscreen. SR-01-2: The system shall validate OTPs against a server-side database within 3 seconds. SR-01-3: The system shall deny access after 3 consecutive incorrect attempts.

This method supports traceability, ownership assignment, and test planning.

We also ensure non-functional requirements are captured, often derived from context:

Context: Semi-sheltered locationSR-NF-01: The enclosure shall meet IP54 ingress protection rating.

Traceability Structure

Each requirement is tagged for stability and source:

Requirements marked TBD are escalated during stakeholder review sessions.

Clarifying Ownership

Each SR is allocated to an engineering discipline for delivery.

Example:

• SR-01-2 (Database validation) → Owned by Software

• SR-01-3 (Mechanical actuator) → Owned by Mechanical Engineering

• SR-NF-01 (IP Rating) → Owned by Hardware/Enclosure Design

This clarifies interfaces within the team and supports accurate effort estimation.

 Watch Out For

Over-Specifying FRs:

• Bad: "System shall have a 5-inch touchscreen"

• Good: "System shall accept user OTP input" (The screen is an implementation choice)

Vague SRs:

• Bad: "System shall be reliable"

• Good: "System shall have MTBF > 10,000 hours"

System Functions vs. Requirements

Closing Reflection

This is the point where intent becomes specification. We’ve moved from describing what’s needed, to defining how we will meet those needs within the boundaries and context established earlier.

Strong FR/SR definition is the bridge between engineering scope and verifiable delivery.

In the next post, we move into system architecture, defining how the system’s functions are partitioned into components, subsystems, and interfaces.

#7 – Architecting the System We'll examine logical decomposition, physical mapping, and early design choices that balance technical feasibility with stakeholder needs.