Product Requirements Analysis

The first stage of the pre-development process. It transforms the customer's CRS into a structured, user-centric specification that everyone (customer and engineering team) can agree on before any technical decisions are made.

Purpose

The purpose of the Product Requirements Analysis phase is to clearly define what the product shall do and how it shall behave from an end-user and stakeholder perspective, without prescribing technical solutions unless strictly necessary.

This phase is typically executed as a joint effort between the customer's product management and our system engineering team. Methods such as workshops, interviews, scenario-based design, and early mock-ups or prototypes may be used to validate understanding and gather feedback.

System Identification

To manage complexity, the product is first positioned within its operational context. This step produces the structural backbone that everything downstream references.

Define the main product objective

Clearly state the primary purpose and value proposition of the product. This is the one-sentence answer to "what is this thing for?" that everyone can agree on.

Define the product context

Describe the operational environment, integration constraints, ambient conditions, and assumptions about how the product will be installed and used. The product never exists in isolation; its context shapes nearly every requirement that follows.

Identify system actors

Identify each entity that interacts with the product across its system boundary with a defined objective: human roles, external systems, and devices. Passive subsystems controlled by the product (lamps, fans, pumps) are not actors; they are reached through the external interfaces. The distinction matters: actors initiate interactions; controlled subsystems respond to them.

Where several roles produce the same interaction with the system, a generalised actor (e.g. "Service User" covering Manager, Technician, and Engineer) avoids the need to write near-identical scenarios for each role.

Identify product elements in scope

State which elements are within the project scope and which are external. The distinction between actor outside the scope, controlled subsystem outside the scope, and element inside the scope is often where late-stage misunderstandings hide. Listing the out-of-scope items explicitly closes that gap.

Identify external interfaces

Define the key interfaces, physical and logical, that the product has with the outside world (user interfaces, control interfaces, network interfaces, power). These are the technology-agnostic touch points that the System Requirements Analysis will later map to concrete protocols and components.

Identify all artifacts

Identify all artifacts (non-behavioural data objects or physical items such as configuration data, session records, audio streams, access credentials, and UI pages) that cross the system boundary as inputs, outputs, or bidirectional exchanges. Artifacts are how value, information, and obligation flow in and out of the product.

Context diagram

A single context diagram brings the above together visually: the product as one block, the actors around it, the external interfaces between them, and the artifacts that flow across each interface. This is the orientation page that every reader returns to.

Use Cases

Use cases describe what the product is used for, from the perspective of the actors that initiate the interactions. Each use case represents an actor objective and identifies the involved actors and external interfaces.

A use case answers: who is trying to achieve what, which actors and interfaces are involved, and what is the end result? It does not yet describe step-by-step behaviour; that comes later in the scenarios.

Use case overview

All use cases are listed in a single overview table, each with its UC-nn identifier, name, primary actor(s), and short description. This overview is the index that the rest of the document hangs off.

Use case dependencies

Use cases are not all independent. Some use cases require another to have been completed first (a service session must be started before configuration can be changed); others are mutually exclusive (the system cannot be in factory configuration and live operation simultaneously). Dependencies are captured in a dedicated table and shown in a dependency diagram, both because they directly affect prioritisation and phased delivery, and because they expose ordering constraints that the development plan needs to honour.

System State Model

Before scenarios are written in detail, the product's overall behaviour is captured as a state model. Many embedded products are inherently stateful; their response to the same input depends on which mode they are currently in (Standby, Service Mode, Session Active, Cool-Down, etc.), and scenarios become much easier to write, read, and verify when the state space is defined explicitly first.

The state model consists of:

• State table: every state the product can be in, with its meaning, entry conditions, and constraints
• Choice-point table: decision points where the product's next state depends on conditions (input value, configuration, prior history)
• State transition table: every legal transition, with its trigger and any associated effect on artifacts or external interfaces
• State diagram: the visual overview, derived from the above tables

Once the state model is defined, scenario preconditions and postconditions can refer to it directly ("the system is in Standby state") instead of describing the state from scratch each time. The model also surfaces gaps (a state with no documented exit, a transition with no defined trigger) that would otherwise only become visible when the implementation behaves unexpectedly.

Use Case Scenarios

For each use case, one or more scenarios describe how the use case unfolds in concrete terms: what the actor does, how the product responds, what state changes occur, and what artifacts move across the boundary. Together, the scenarios under a use case cover its success path, its valid alternatives, and the failure modes the product must handle gracefully.

Scenario structure

Every scenario uses the same four sections so it can be read and tested consistently:

• Result: the one-sentence outcome the scenario delivers (or fails to deliver, for failure scenarios)
• Preconditions: what must already be true for the scenario to apply (system state, prior scenarios completed, contextual assumptions)
• Sequence: the ordered exchange between actors and the system. Steps the actor performs outside the system's control are marked as such. For example, an operator selecting a network on their device before the system even sees the connection request
• Postconditions: what is true once the scenario has run, including system state, artifact persistence, and any external side effects

Success, alternative, and failure scenarios

A use case typically has one nominal success scenario, zero or more alternatives (different valid paths to the same goal), and one or more failure scenarios (the product responds correctly when something goes wrong, such as invalid credentials, lost connection, or timeout). Common fragments shared across scenarios are written once and referenced from each scenario that needs them, so a change in shared behaviour propagates automatically rather than drifting out of sync.

Functional Requirements

Functional requirements are derived from the scenarios. Each scenario step that requires a defined product behaviour is captured as one or more atomic requirements. This makes the requirements directly testable: every requirement traces back to a specific scenario, and the scenario itself already describes how the behaviour should be exercised.

What every requirement carries

Each requirement is more than a single sentence. To be useful for downstream design, verification, and traceability, it carries:

• A clear, atomic "when … the system shall …" statement
• A link back to the scenario(s) it is derived from
• A verification approach (how the requirement will be tested and what counts as pass)
• A priority that reflects business value, regulatory necessity, and dependencies

Atomicity

A common temptation is to write compound requirements that bundle several behaviours together ("the system shall accept the connection, transition to service mode, and display the service window"). Such a requirement cannot be partially verified: if one of the three behaviours is wrong, the requirement as a whole fails, and the test report is less informative than it should be. Each requirement is therefore broken into atomic statements, even when this produces a longer list. The list length is not the cost; the absence of traceability would be.

Cross-cutting requirements

A small set of functional requirements do not belong to a single use case but apply across the product, such as logging, audit trails, time-keeping, and default state on power-up. These are captured separately, to avoid duplicating them under every use case they touch.

Non-functional Requirements

Non-functional requirements describe qualities the product must exhibit rather than functions it must perform. They are typically organised into categories such as:

• Performance: response times, throughput, latency budgets
• Reliability and availability: MTBF targets, uptime requirements, fault tolerance
• Regulatory and compliance: EMC, safety standards (e.g. EN 60335-1), RoHS, REACH, regional approvals
• Environmental conditions: operating and storage temperature ranges, humidity, altitude, ingress protection
• Power and electrical: supply voltage, current draw, behaviour during interruptions
• Physical and mechanical: dimensions, weight, mounting, backward compatibility
• Maintainability and serviceability: diagnostics, firmware updates, spare parts strategy
• Security: authentication, authorisation, data protection at rest and in transit
• Branding and user experience: visual identity, language support, accessibility

Each non-functional requirement is written in the same atomic, verifiable style as the functional requirements: a concrete "shall" statement, a verification approach, and a priority. "The system shall be reliable" is not a requirement, but "the system shall achieve a mean time between failures of at least 30 000 hours under the operating conditions defined in §9.5, verified by accelerated life testing" is.

Prioritisation

With all requirements captured, each is assigned a priority that reflects business value, regulatory necessity, dependencies, and technical complexity. The priority drives phased delivery, scoping conversations, and the eventual development plan.

Priority framework

Five priority tiers are used:

• Essential: required for the product to be shippable. Includes regulatory obligations, core use cases, and behaviours without which the product is not viable.
• Secondary: strongly desired and planned for the initial release, but the product would still be saleable without them. Often the first candidates for descope under schedule pressure.
• Nice-to-Have: adds value but is not committed to the initial release. May be added later if scope permits.
• Emerging: under active discussion or refinement; the requirement is present but its exact form, scope, or feasibility is not yet fixed.
• Future: explicitly out of scope for this release, captured to inform architectural decisions that should not foreclose later inclusion.

Dependency consistency

Priorities cannot be assigned in isolation. If an Essential requirement depends on another that is marked Secondary, the priorities are inconsistent, so one of them must change. A dependency-consistency check is performed once priorities are assigned, and inconsistencies are resolved before the PRS is baselined.

What prioritisation supports

• Phased development: which capabilities arrive first, which can wait
• MVP definition: the smallest deliverable that satisfies all Essential requirements
• Release planning: how subsequent releases extend the product through Secondary and Nice-to-Have items
• Architectural foresight: Future requirements inform which decisions to make reversible

Prioritisation is also the moment when competing stakeholder views become visible. A use case that product management considers Essential but sales considers Nice-to-Have is a conversation that is much better had now than during the first integration test.

Deliverable: The PRS

The Product Requirements Specification consolidates all of the above into a single, reviewed, and approved document. Once baselined, it becomes the input to Phase 2: System Requirements Analysis, and the reference against which the eventual product is validated.