1.Introduction#
1.1.Purpose and Context#
A Product Requirements Specification (PRS) is a comprehensive document whose objective is to clearly define what a product must do and how it should behave from an end-user and stakeholder perspective. It captures the product's intended functions, features, and constraints without prescribing a specific technical solution, ensuring the focus remains on what the product needs to achieve rather than how it will be implemented. This means that design decisions are deliberately excluded.
The PRS plays a critical role in product development as the contractual baseline of requirements: it is the agreement on "what the product must do". Decisions on design and implementation (the how) are addressed in later phases.
In a high-tech electronics context (hardware and embedded software), a well-crafted PRS provides a clear target for engineers and stakeholders, aligning everyone on the product goals and serving as the reference point for design, implementation, and verification.
The PRS is the primary output of the Product Requirements Analysis phase – the first pre-development phase of a structured product development process.
For context, the pre-development phases are:
-
Product Requirements Analysis
Defines what the product shall do and how it shall behave from an end-user and stakeholder perspective, without prescribing technical solutions unless strictly necessary.
-
System Requirements Analysis
Performs the technical translation of the product requirements and, where required, implements proof-of-principle (PoP) prototypes for the whole product or for specific functional components. This phase also evaluates the feasibility of each product requirement and feeds adjustments back to the PRS where needed.
-
Industrialisation Analysis
An optional phase required only when a product is intended for volume production with a required level of quality. In that case, additional requirements related to manufacturability, quality, and supply chain are addressed early to avoid costly redesigns.
-
Product Development Planning
Using the outputs of all previous phases, a detailed plan is constructed to develop and produce the product, estimating the required budget and timeframe, including resource allocations and supply chain.
The main objective of the pre-development phases is to arrive at a solid product development plan that steers the subsequent activities for hardware, software, and (where required) mechanical development.
1.2.Deliverables#
The PRA phase produces a single, consolidated deliverable:
- Product Requirements Specification (PRS)
A comprehensive, solution-neutral document that defines what the product must do and how it must behave from an end-user and stakeholder perspective. It is the contractual baseline of requirements and the reference against which design proposals are evaluated and verification is planned.
Unlike the later phases, which emit several distinct artifacts, the PRA consolidates all of its work products into the chapters of this one document. The PRS contains:
- Business Case Background
The product intent, market context, and commercial assumptions that motivate and bound the requirements.
- System Identification
The main product objective, product context, system actors, product elements in scope, external interfaces, artifacts, and a context diagram.
- Use Cases
The use cases with their actors and interactions, the use case dependencies, and a use case dependency diagram.
- System State Model
The state table, choice-point and transition tables, and state diagram describing the product's modes of operation.
- Use Case Scenarios
Normal, alternative, and failure flows per use case, including preconditions and postconditions, which serve as high-level acceptance criteria.
- Functional Requirements
The functional requirements extracted from the scenarios, traceable to their originating steps.
- Non-Functional Requirements
Requirements not tied to a specific use case, such as regulatory, performance, reliability, environmental, and business or branding constraints.
- Prioritisation
Priority levels assigned to requirements and use cases, with a dependency-consistency check, supporting MVP definition and release planning.
- Acceptance Criteria and Verifiability
Clear, verifiable acceptance criteria integrated with the requirements.
- Requirements Listing and Traceability
A consolidated requirements list with traceability back to its sources.
2.Overview#
The Product Requirements Analysis phase is dedicated to defining the product's requirements in detail, laying the groundwork for all design and development efforts.
The primary purpose of this phase is to determine what the product shall do and how it shall behave from the perspective of end-users and other stakeholders. This involves gathering and analysing inputs such as user needs, business objectives, and high-level use scenarios, and systematically formulating requirements without diving into technical implementation. The culmination of this phase is the Product Requirements Specification (PRS), which formally captures all identified requirements.
During the phase, the system engineering (SE) team performs a structured series of steps to ensure no aspect of the product's required behaviour is overlooked:
- The business case background is captured to frame the product's market context.
- The product is positioned within its intended system context and environment.
- Use cases are identified by specifying the key objectives and interactions the product must support.
- The system's operational behaviour is modelled through states and transitions.
- For each use case, scenarios are authored illustrating how the system behaves in normal conditions as well as in alternative and failure conditions.
- Functional requirements are extracted from the scenarios as explicit "shall" statements.
- Non-functional requirements are captured (performance, reliability, compliance, environmental, and so on).
- Requirements are prioritized based on stakeholder value, risk, and dependencies.
- Acceptance criteria are defined to ensure each requirement is verifiable.
- All requirements are compiled and traced in the PRS, and supporting information (glossary, references, appendices) is included for completeness.
It is crucial to distinguish Product Requirements Analysis from subsequent pre-development phases. In this phase, the focus is purely on what the product needs to do, i.e. product-level requirements that reflect user needs and business goals, independent of any particular technical solution. The subsequent System Requirements Analysis phase takes the PRS as input and determines how to implement those requirements in terms of architecture, components, and technologies. By keeping the PRS solution-neutral, the SE team avoids prematurely constraining the design and preserves the flexibility to explore multiple implementation options. The PRS thus becomes a stable reference that is used to validate the final product: a clear contract of what the product must do, against which design proposals can be evaluated and testing can be planned.
A direct consequence of this separation is that the PRS is feasibility-unconstrained by design. It states what the product must do; whether each requirement is achievable – and at what cost – is evaluated during System Requirements Analysis (SRA), not asserted in the PRS. The results of that evaluation (often expressed through an initial bill-of-materials cost) are reviewed with the customer and may feed back into an adjusted PRS. This feedback loop is intended and may occur several times. The implications for how values are stated and flagged are developed below in section 2.2.
2.1.Solution Neutrality#
Solution neutrality is central to everything that follows.
The PRS defines what the product must do and how it must behave from an end-user and stakeholder perspective. It must never prescribe internal implementation details. This applies to every part of the document: use cases, scenarios, states, requirements, and acceptance criteria.
Keeping the PRS solution-neutral preserves design freedom, enables innovation, and allows the engineering team to explore multiple implementation options during the later System Requirements Analysis phase. Premature implementation choices in the PRS risk constraining the design unnecessarily or hiding the actual functional need behind a specific technology.
Not all technical terms are implementation details, however. Some technologies are chosen at the product level because they define the user experience, market positioning, or ecosystem compatibility. These are legitimate product requirements. The distinction is:
- Product-level technology choices are visible to the user or driven by business or market needs. They describe what capability the product offers. Examples: "The system shall support Wi-Fi connectivity"; "The system shall provide a capacitive touchscreen interface"; "The system shall support Bluetooth audio streaming". These belong in the PRS.
- Implementation details describe how the product achieves specific capabilities internally. Examples: "using an SPI bus", "with an STM32 microcontroller", "firmware shall use a state machine", "data stored in flash memory". These do not belong in the PRS.
A useful rule of thumb: if the user or customer can see, interact with, or would care about the technology choice, it is a product-level decision and belongs in the PRS. If it is only relevant to the engineering team building the product, it is an implementation detail and belongs in later phases.
Customer input often mixes functional intent with implementation preferences. When this occurs, extract the underlying functional need as a requirement. If the implementation choice is a product-level technology decision, include it as stated. If it is an internal implementation detail, omit it from the requirement and – only if the customer explicitly insists on it – note it as a constraint with documented rationale. For example:
- Customer input: "Use Wi-Fi for service connection." → Product-level choice. Requirement: "The system shall provide a Wi-Fi-based wireless connection for service access."
- Customer input: "Use an STM32 microcontroller." → Implementation detail. Do not include it as a requirement. If explicitly mandated, note it as a constraint: "The customer has specified the use of an STM32 microcontroller [TBC]."
2.2.Handling Unknown Values#
A PRS inevitably contains values that are not yet pinned down: target volumes, response-time limits, environmental ranges, certification scopes, power budgets. The temptation is to mark every such value with a flag and move on. That is a mistake, and it produces documents cluttered with dozens of pending items, most of which are not genuinely open. Before flagging any value, the systems engineer must ask one question: who is the authority for this value? The answer determines whether the value is flagged, stated with a citation, or simply expressed as a need and left to a later phase.
Two markers are used throughout the PRS:
- [TBD] (To Be Determined) – a required value that is genuinely not yet determined and must be resolved before the PRS is baselined. Used only where the authority for the value is the customer/stakeholder or established knowledge, and the value is simply missing.
- [TBC] (To Be Confirmed) – a value that is present but requires confirmation from stakeholders. Used only where a stakeholder is the authority for the value.
Before attaching either marker, apply the authority test:
- A stakeholder is the authority. Target volume, certification regions, expected service life, a customer-owned behavioural choice – only the customer or another stakeholder can supply these. Flag with [TBC] if a value is stated and needs confirmation, or [TBD] if it is genuinely missing. These are the proper subject of the Pre-Draft Triage in section 3.2.
- Published standards, established science, or domain knowledge is the authority. Some values are not unknown at all, but are fixed by a cited standard or by well-established knowledge. A common example is the human-perception ceiling for "instantaneous" feedback (around 100 ms), established in the human–computer-interaction literature. Such a value is not flagged; it is stated firmly, and the rationale names the source. A reviewer checks the citation, not their own preference.
- The engineering team is the authority. Many quantitative values – achievable power consumption, a concrete mounting specification, an internal timing budget – are design or feasibility outputs. Their concrete value is not knowable at the PRS stage and is not a stakeholder decision. Do not flag these as pending items. Instead, state the functional need (e.g., "the unit shall be mountable by one person without specialist tooling") and let the System Requirements Analysis phase determine the concrete figure.
A reflex worth unlearning is attaching [TBC] to a number simply because it is a number, or because its achievability has not been confirmed. If the number is settled by established knowledge, cite it and leave it unflagged. If its achievability is the open question, that is a feasibility matter – and feasibility, as the following note explains, is out of scope for the PRS.
Feasibility is out of PRS scope. The PRS states what the product must do and is feasibility-unconstrained by design. The feasibility of every requirement – and its cost – is evaluated during System Requirements Analysis (SRA), whose results (often expressed through an initial bill-of-materials cost) are reviewed with the customer and may feed back into an adjusted PRS. This feedback loop is intended and may occur several times. Consequently, no requirement in the PRS carries a feasibility caveat or annotation, and no value is flagged [TBD]/[TBC] merely because its achievability is unconfirmed. Achievability is not a PRS question.
3.Customer Requirements Elicitation Methods#
Developing a strong PRS requires effective gathering of input from all relevant stakeholders. The initial input for the PRS is the Customer Requirements Specification (CRS), and during the Product Requirements Analysis, systems engineers collaborate closely with the customer's product managers, end-users (where available), and business stakeholders to extract a complete and validated set of requirements.
3.1.Practical Methods#
Practical methods to obtain customer requirements can be one or more of the following:
- Stakeholder interviews
Structured interviews with product managers, end-users, clients, and domain experts to capture their needs, expectations, and pain points. Open-ended questions help uncover implicit requirements and clarify the desired product behaviour in various scenarios.
- Workshops and brainstorming sessions
Cross-functional discussions (marketing, engineering, customer representatives, and so on) that enable real-time clarification, prioritize conflicting needs, and build consensus. Visual aids such as mind maps or whiteboarding help define the product context and features.
- Scenario-based design and use case development
Scenario planning to envision how the product will be used in real-world situations. Writing narratives or storyboards that walk through typical user interactions – as well as edge cases – ensures requirements are rooted in actual user workflows and helps identify missing interactions or abnormal situations.
- Early mockups or prototypes
Simple mockups, sketches, or low-fidelity prototypes reviewed with stakeholders to validate understanding. Seeing a model or simulation often elicits additional requirements or corrections, particularly for user-interface-intensive products. For hardware products, this may involve concept drawings or basic lab experiments to confirm feasibility of performance targets.
- Surveys and questionnaires
Where direct access to many end-users is possible, surveys can gather quantifiable data on user needs and preferences. Useful for capturing user-centred requirements at scale or for prioritizing features.
Key discussions and confirmations from these workshops and interviews are documented, whether as meeting minutes or a requirements backlog. These notes ensure nothing is lost and provide justification for requirements in the PRS.
3.2.Pre-Draft Triage of Customer-Authority Gaps#
Some facts can only come from the customer – no amount of engineering judgement, published standard, or domain knowledge can recover them. These are predominantly the Business Case Background facts (target volume, rollout profile, expected service life, cost positioning, certification regions, customer identity) and any genuinely customer-owned behavioural choices the input leaves open.
It is good practice to surface these as a short, focused triage round before drafting the body of the PRS, rather than discovering them as scattered flags afterwards. Stakeholders answer such questions far better when asked directly and early, against a concrete list, than when confronted with a draft full of markers. For each question, the customer can:
- Answer – the value is used directly, with no flag.
- Skip for now – the question is left open; the engineer proceeds with a best-inferred value, marks it [TBC] (inferred) or [TBD] (genuinely missing), and the item is consolidated for later resolution.
- Skip the remainder – the round ends; all remaining gaps are handled by drafting with judgement and flagging.
The triage round is an aid, never a gate: if the customer declines to engage or simply asks for a draft, the PRS is still produced, with judgement applied and gaps flagged. There is no fixed limit on the number of triage questions; if the input genuinely leaves many customer-authority facts open, asking all of them is appropriate.
Crucially, triage is only for facts whose authority is the customer or another stakeholder (see section 2.2). It must not be used to ask the customer for values the engineering team or published knowledge is the authority for. Latency budgets, power consumption, reliability figures, environmental ranges, mounting specifications, and similar engineering values are resolved later by the authority test and by System Requirements Analysis – not by the customer. Asking the customer to sign off on such a number routes the decision to the party least equipped to make it.
3.3.Output#
The elicitation methods help ensure the PRS is user- and business-centred. They turn the often vague initial input – which may be a solid Customer Requirements Specification or just a concept description – into concrete, structured requirements.
During elicitation, the focus must be on uncovering the why behind each requirement: what value or outcome it is tied to. This context is critical later when prioritizing requirements and making design trade-offs. It is equally important to document assumptions or implicit needs that surface. Throughout, close collaboration with the client and end-users is maintained; the PRS should ultimately reflect a shared understanding of the product goals.
4.Business Case Background#
4.1.Purpose#
The purpose of including a "Business Case Background" chapter in the PRS is to provide high-level business context for the product. While the PRS formally defines what the product shall do and how it shall behave, the Business Case Background describes the market problem the product addresses and explains the commercial and strategic setting in which the product is developed.
This context ensures that the product requirements – and especially the Main Product Objective defined in the System Identification chapter – are interpreted correctly and remain aligned with the intended market positioning. This chapter does not contain requirements and does not replace the customer's business case documentation; it provides only sufficient background to frame the remainder of the PRS.
4.2.Product Intent and Market Context#
The first section in the "Business Case Background" chapter briefly describes:
- The market problem the product addresses.
- The intended customer or user segment.
- The high-level positioning of the product (performance-focused, cost-optimized, specialized niche solution, and so on).
The description should be concise and factual, providing only the information necessary to understand the product's intended purpose and differentiation.
Commercial Assumptions#
To properly interpret requirements and prioritization decisions, a limited number of business assumptions should be documented where available:
- Target production volume (order of magnitude).
- Expected product lifetime in the market.
- Cost positioning strategy (aggressive unit-cost target versus premium solution).
- Planned certification regions or regulatory scope.
These assumptions influence architectural decisions, prioritization, and feasibility assessments in later phases. Documenting them here provides transparency and supports consistent decision-making. Where information is unavailable or uncertain, apply the authority test (section 2.2): these facts are almost all customer/stakeholder-authority, so a stated-but-unconfirmed value is marked [TBC] and a genuinely missing value is marked [TBD]. Because they are customer-owned, these are exactly the facts the Pre-Draft Triage (section 3.2) should surface as questions; where the customer has answered, the value is used with no flag.
4.3.Role in the PRS#
The Business Case Background provides context, not constraints. It enables:
- A more precise definition of the Main Product Objective.
- Clearer prioritization of use cases and scenarios.
- Better alignment between product requirements and business intent.
- More informed trade-off discussions during System Requirements Analysis.
All detailed product behaviour and constraints are defined in the subsequent chapters of the PRS.
5.System Identification#
After the business case is formulated to serve as background and context, the first step in building the body of the PRS is System Identification, where the product is defined in the context of its intended environment and usage. The goal is to position the product within its operational context and clarify its boundaries and interactions before detailed requirements are written. This step helps manage complexity by grounding the requirements in real-world context and ensuring a common understanding of the system's scope.
5.1.Main Product Objective#
The first step in the system identification is clearly stating the primary purpose of the product and its core value proposition in one or two sentences. This is done by describing the fundamental need or problem the product addresses. This high-level objective anchors all further requirements. For example: "to continuously monitor and report environmental conditions in an industrial plant".
5.2.Product Context#
The next step is to describe the environment in which the product will operate and the external entities it will interact with. This includes the typical users or operators, external systems, devices, or networks, as well as any physical or regulatory environment constraints. In short, outline the product ecosystem. Defining context ensures that requirements align with real operational conditions.
5.3.System Actors#
It is important to list all actors that interact with the product. Actors may be human users (end-users, administrators, maintenance personnel) or external systems and devices (sensors, external software services, hardware modules). The system itself is always part of every use case and is not listed as an actor.
Actors are organised into separate subsections by type: Human Actors and External Systems. Each list contains the columns Actor, Description, and Primary Objectives.
Generalized Actors#
When multiple specific actors perform the same interaction with the system – for example, when an Engineer, a Technician, and a Manager all establish a wireless service connection – a generalized actor is defined that represents the shared role (e.g., "Service User"). The generalized actor is listed in the appropriate table and it is documented which specific actors can fulfil that role. Use cases and scenarios can then reference the generalized actor, avoiding duplication of identical interactions. Differences between the specific actors (such as access level, available functionality, or operational context) are captured through specific requirements where relevant, not through separate use cases or scenarios for each actor.
5.4.Product Elements in Scope#
When developing a new product, it is essential to determine which parts of the overall context are within the project's scope to develop or deliver. In other words, it is important to distinguish between the product itself and external systems. Some actors or subsystems may be outside the development scope, whereas others are product elements to be developed. Clarifying this boundary ensures the PRS focuses only on requirements for the product under development and references external interfaces or assumptions for everything outside it.
5.5.External Interfaces#
No product operates in isolation and therefore it is beneficial to explicitly enumerate all interfaces the product has with the outside world. Interfaces are described in terms of their functional purpose and externally observable characteristics – what the interface connects to and what it is used for. These descriptions do not enumerate individual pin assignments, signal lists, register maps, or protocol field definitions. Detailed interface specifications belong in later phases.
To distinguish interfaces from regular text practically, all interfaces are named using Title Case (e.g., "Touch Display", "Charging Port", "Service Web Interface").
Interfaces are then organized into subsections by type, each using a table with columns: Interface, Direction (In/Out/Bidirectional), and Description. Typical types include, but are not limited to:
- Physical Interfaces
Tangible connections such as connectors, buttons, and network ports.
- Logical Interfaces
Communication protocols, data formats, and software-level connections.
Depending on the product, additional types may be added (e.g., "Wireless Interfaces", "Mechanical Interfaces", "Optical Interfaces").
5.6.System Artifacts#
Explicitly identifying all artifacts that cross the system boundary during operation make it possible to create a clear domain model. Artifacts are discrete data objects or physical items exchanged between the system and external actors. Unlike actors, artifacts do not initiate behaviour; they are non-behavioural objects involved in interactions. They may be inputs to the system, outputs generated by the system, or exchanged bidirectionally.
Artifacts are described in terms of their functional role and externally observable characteristics – what kind of thing the artifact is and what purpose it serves. These descriptions do not enumerate the concrete contents, parameter lists, field names, or internal structure. For example, for a "Operational Parameters" artifact, describe it as "Configurable values controlling the operational behaviour of the system, such as session timing, operating mode, and feature toggles" – not as a full list of every parameter. Concrete details belong elsewhere: individual parameters become functional requirements, and any consolidated reference list can go in an appendix.
To distinguish artifacts from regular text practically, all artifacts are named using Title Case (e.g., "Configuration Parameters", "Firmware Package", "Access Token").
Artifacts are then organized into subsections by type, each using a table with columns: Artifact, Direction (In/Out/Bidirectional), and Description. Typical types include, but are not limited to:
- Data Artifacts
Data objects such as configuration files, log exports, communication payloads, and user-interface artifacts such as screens, windows, pages, or dialogs that the system generates and presents to users. UI artifacts are distinct from the interface on which they are presented: the Touch Display is an interface, but each window shown on it (e.g., "Standby Window", "Session Preparation Window", "Authentication Page") is an artifact – a discrete object that the system generates and the user perceives through the interface. List each window, screen, or page by name with a brief functional description; detailed layouts and contents belong in functional requirements or an appendix.
- Physical Artifacts
Physical items such as keys, cards, tokens, and coins.
Depending on the product and technology, additional types may be added (e.g., "Electrical Artifacts", "Optical Artifacts").
5.7.Context Diagram#
The final step is to include a context diagram showing the product, its actors, its interfaces, and the artifacts that cross the system boundary. The context diagram is a visual summary of the information captured in the preceding subsections and gives readers an at-a-glance understanding of the product's operational setting.
5.8.Result#
By thoroughly documenting the system identification, the PRS sets the stage for all subsequent requirements. It provides a shared understanding of the context in which the product will function. All functional and non-functional requirements in the PRS should be consistent with this identified context. If a requirement cannot be traced back to the defined objectives, actors, or context, it may indicate that the requirement is out of scope or that the context needs refinement. System Identification acts as the foundation of the PRS: it scopes the problem and aligns the team on what the product is and where and how it will be used before specifying detailed behaviours.
6.Use Cases#
After establishing the context and scope, the next step is to identify use cases for the product. Use cases capture the high-level functions or interactions that the system must support. Each use case represents a distinct goal or task that an actor (user or external system) needs to accomplish with the help of the product. Defining use cases is a crucial part of deriving functional requirements because it keeps the focus on the intended outcomes and user goals rather than on individual features in isolation.
6.1.Identifying Use Cases#
To ensure comprehensive coverage, use cases are systematically identified by considering the following sources:
- Actor goals
For each actor identified in System Identification, it is determined what they need to accomplish with the system. Each distinct goal is a candidate use case.
- Product lifecycle phases
All phases the product goes through are considered: factory setup and configuration, installation and commissioning, normal operation, maintenance and servicing, firmware updates, and decommissioning or disposal. Each phase typically yields one or more use cases.
- Operational modes
If the system has different modes of operation (e.g., standard mode, external control mode, payment mode), each mode that involves materially different interactions is a candidate use case.
- External triggers
All external systems and interfaces from System Identification are identified. For each, consider what events or signals require a system response (e.g., incoming data, start or stop signals, payment pulses).
- Regulatory or safety obligations
Mandated functions such as emergency shutdown, self-test, safety interlocks, or compliance-related operations often become use cases in their own right.
- Shared functionality
As use cases are identified, functionality that appears across multiple use cases (see the shared-functionality rule below) is extracted into its own use case.
After identification, completeness is verified by checking that every actor has at least one use case, every external interface is exercised by at least one use case, and every operational mode is covered.
6.2.Use Case Overview#
For reference and overview, use cases are listed in an overview table with the following fields:
- Identifier
Unique ID to reference the use case, using a sequential numbering scheme (e.g., UC-01, UC-02).
- Name
A short, verb-oriented title, unique within the PRS. The name should clearly hint at the objective (e.g., "Configure Network Settings", "Perform System Self-Test").
- Objective
The goal the use case aims to accomplish, formulated as an intention (e.g., "Configure the system to access the wireless network", not "The system is configured to access the wireless network"). Think of it as completing the sentence "I want to be able to..." – though this prefix is not included in the actual text.
- Actors
The actors involved in the use case. Identify who initiates the use case and any other participants. The system itself is always implicit and doesn't have to be listed.
- Priority
The priority level of the use case, indicating its importance, where the five defined levels are: Essential, Secondary, Nice-to-have, Emerging, and Future (see chapter 11 on prioritisation).
6.3.Shared-Functionality Rule#
When multiple use cases require the same functionality – for example, establishing a service connection, authenticating a user, or performing a self-test – that functionality can be extracted into a separate use case rather than duplicating it. The original use cases then become dependent on the shared use case, and this relationship is reflected in the dependency diagram. This keeps each use case focused on a single objective and avoids scattered duplication of scenarios and requirements.
6.4.Use Case Dependencies#
Once the list of use cases is compiled, it is examined whether dependencies exist between them. Sometimes one use case must be completed before another can be performed, or certain use cases share common steps or data. These relationships are represented in a use case dependency diagram. Understanding dependencies is valuable for planning and prioritization: it highlights which functionalities build on others and ensures that prerequisites are addressed first. In addition to the diagram, an optional dependency table can describe the rationale for each dependency.
6.5.Use Case Descriptions#
After identifying all use cases and their interdependencies, the PRS devotes a section to each use case. Each section documents the details needed to understand and later implement that use case. For every use case, the following is included:
- Description
A narrative explaining how the actors interact and what the system does. This elaborates on the context and sequence of actions in general terms, before the specific scenarios are written.
- Objective
An elaboration of the brief objective from the overview table, providing additional detail on what it means for the use case to be considered successfully completed. Use the same intention-based formulation.
- Scenario overview
A table listing all scenarios that will be authored for the use case, with columns: ID, Scenario (short descriptive name), and Result (brief statement of the outcome). If a use case has no failure scenarios, a brief justification follows the table explaining why no realistic failure mode exists.
By structuring the PRS around use cases, functional requirements are organized according to real-world usage. This user-centred approach validates that the product's functions will collectively allow users and systems to achieve their goals. It also makes the PRS easier to understand for stakeholders, as each section focuses on a meaningful capability or interaction.
Use cases also serve as a bridge between high-level stakeholder needs and detailed requirements: every requirement should ideally trace back to enabling a use case.
7.System State Modeling#
Before diving into the specifics of each scenario, a high-level system state model for the product must be defined. The state model describes the various operational states the system can be in and how it transitions between them in response to events or conditions. Its purpose is to provide a shared behavioural context for all scenarios and requirements, ensuring consistency in how the system's modes of operation are understood across the team.
The state model remains abstract: it is not a detailed design of software threads or hardware conditions, but an externally observable view of system behaviour. For example, states might include "Idle", "Active / Running", "Error", "Maintenance Mode", "Shutdown", depending on the nature of the product.
7.1.Modelling Principles#
To create the state model, the following modelling principles apply:
- Behavioural focus
States are defined in terms of externally observable behaviour or high-level operation, not in terms of internal software threads, tasks, or hardware specifics. For example, a state named "Data Logging Complete" is better than one named "Buffer XYZ Empty".
- Meaningful and stable states
Each state should represent a meaningful mode of operation that persists for some duration or recurs, rather than a momentary internal condition. The state model should be simple enough to remain stable as the design evolves.
- Complete but minimal
The set of states should be sufficient to cover all scenarios (so that any scenario step can refer to a state in this model), but should minimize overlap or redundancy. If a new scenario requires a state that is not in the model, update the model. Conversely, do not include states that never appear in any scenario.
- Explicit decision points
Decisions in the state flow are explicitly modelled as a two-way branch. In the state modelling these are called "Choice-points".
7.2.Naming Conventions#
The following practical conventions are used:
- State names use Title Case (each word capitalized) and are phrased either as an ongoing action (e.g., "Awaiting Connection", "Performing Self-Test") or as the conclusion of an action (e.g., "Connected", "Error Detected", "Session Complete"). The name should convey what the system is doing or what condition it has reached, without referencing internal implementation details.
- Choice-point names use Title Case and are phrased as a binary question ending with a question mark (e.g., "Connection Lost?", "Maximum Reached?", "Payment Sufficient?"). The question must yield a clear yes or no answer that determines which transition path the system follows.
7.3.Elements of the State Model#
The state model is represented with four elements:
State Table#
A table listing each named state and a brief description. Descriptions clarify the system's capabilities or behaviour in that state and avoid implementation language.
Choice-Point Table#
Choice-points represent explicit decision points where the system evaluates a condition and follows one of two paths. They model behavioural branching without embedding logic inside scenarios. The table lists each choice-point by name and its binary evaluation condition. Typical examples include credential verification ("Correct Credentials?"), validation checks ("Self-Test Passed?"), and routing decisions ("Correct Server?").
A choice-point in the state model always has exactly two outgoing transitions: one for "Yes" and one for "No".
Same Condition Evaluated at Multiple Sites#
A frequently encountered modelling pattern is one where the same logical condition is evaluated at two or more different points in the state flow, with different downstream destinations on each outcome. For example:
- "Is the user authenticated?" asked after a login attempt (Yes → Home, No → Login Error) versus the same question asked before a protected action (Yes → Execute Action, No → Request Re-authentication).
- "Are sensors nominal?" asked at system startup (Yes → Enter Operating, No → Enter Initialization Error) versus the same question asked mid-operation (Yes → continue, No → Enter Degraded Mode).
In each case, the condition is identical but the evaluation site in the flow is different, and the destinations on Yes and No differ per site. This cannot be modelled with a single choice-point without violating the "exactly two outgoing transitions" rule or introducing ambiguous path qualifiers.
The correct model is to define a separate choice-point for each evaluation site, with each choice-point having its own unique name, its own pair of outgoing transitions, and its own entry in the choice-point table. These are named to make the shared condition and the distinct site explicit – for example, "Credentials Valid?" and "Credentials Valid for Re-authentication?". Once a naming form is picked, it must be used consistently across the document.
A single choice-point reached from multiple sources does not require splitting if all sources route through the choice-point to the same downstream destinations. The choice-point is only split when the downstream destinations differ between callers.
State Transition Table#
A table that enumerates the allowed transitions between states and choice-points. It has the columns: "From" (current state or choice-point), "Event" (the event that triggers the transition), "Description" (a short description of what happens), and "To" (the next state or choice-point).
In this table, choice-points are treated as regular states. Each row captures one transition, and each choice-point contributes exactly two rows – one for its Yes branch and one for its No branch.
Wildcard Source#
A wildcard in the "From" column denotes any state. This is used to express global transitions that apply uniformly regardless of the current state – for example, a critical fault transition, a permission revocation, or a suspension trigger. Practically the wildcard is used sparingly: only when the transition genuinely applies from every state (or almost every state, with documented exceptions).
History Pseudostate#
When a transition must return to whichever real state was most recently active other than the current one, the destination is written as a history reference (often denoted H). History is a pseudostate, not a real state. It is a general-purpose destination that can appear on the Yes or No branch of a choice-point, on a transition out of a simple state, or on any other transition where a fixed destination would require duplicating the source across multiple callers.
Typical uses of History include:
- Choice-point no-op branch
A choice-point's "No" outcome returns to the state that triggered the evaluation, rather than a hard-coded state, avoiding duplication of the choice-point per caller.
- Resumption after a transient condition
A state entered to handle a transient condition (e.g., a pop-up dialog, a blocking check, a short pause) exits back to whatever was active before.
- Return from a globally invokable state
A state reachable from many sources (e.g., a paused or suspended state) returns to its caller via History when the triggering condition clears.
- Shared exit paths
Any situation where multiple sources converge on a common state and the common state must route back to each source individually.
History resolves to the most recently visited real state other than the current one. A choice-point is never a History destination. In practice, whenever control reaches a new real state, that state is remembered, and any subsequent transition to History resolves to it.
State Diagram#
A graphical state diagram that visualizes states and transitions. It mirrors the information in the tables – states as nodes and transitions as labelled arrows – and provides an at-a-glance understanding of the system's modes and how one leads to another. The state transition table remains the authoritative enumeration; the diagram is a visual summary.
7.4.Tie-In with Scenarios#
Scenarios reference states from this model as preconditions or postconditions, and may reference states at intermediate points (e.g., "System enters Error state"). By defining the state model up front, all scenarios share a consistent vocabulary for system modes. If a new mode appears necessary during scenario development, update the state model rather than inventing ad-hoc states in the scenario narrative.
8.Use Case Scenarios#
With use cases identified and the state model in place, the PRS next describes scenarios for each use case. Scenario authoring is the process of writing detailed step-by-step flows that show how the system and actors interact to achieve the use case objective – or to handle failures. Scenarios bridge high-level use case descriptions and concrete requirements and serve as a form of high-level acceptance criteria for each use case.
8.1.Scenario Categories#
Each use case typically has multiple scenarios covering different flows:
- Success Scenario
The single primary path where the use case objective is fully achieved under normal conditions. Every use case should have exactly one success scenario. This represents the standard, expected flow – the path you would demonstrate to explain "this is how it works." If there appears to be more than one equally valid primary path, the most common or straightforward one can be chosen as the success scenario and the other can be modeled as an alternative success scenario. In rare cases, a second success scenario may be justified; when this happens, document the reason in the scenario overview.
- Alternative Success Scenarios
Different paths that still achieve the use case objective but under different conditions or through different means. For example, achieving the same goal via a different interface, with different input data, under different operational modes, or through an uncontrolled variant of the same action (e.g., a graceful session close versus a forced disconnection). Alternative success scenarios are only authored when the alternative path involves materially different system behaviour – not just minor variations in user input.
- Failure Scenarios
Situations where the use case objective is not achieved due to an error, fault, or exceptional condition. Each distinct way the use case can fail should be captured in a separate failure scenario. Most use cases have at least one failure scenario; if a use case genuinely has no realistic failure mode, the absence must be explicitly justified in the use case's scenario overview.
To ensure thorough coverage, systematically the following failure categories are considered for each use case:
- Invalid or rejected input
Wrong credentials, out-of-range values, malformed data, unauthorized access attempts.
- Communication and connectivity failures
Connection timeouts, dropped connections, unreachable external systems or services.
- Hardware and component failures
Sensor malfunctions, actuator failures, power supply issues, peripheral device errors.
- Timeout and expiration
Operations that exceed allowed time limits, sessions that expire, watchdog triggers.
- Precondition violations
Attempting an operation when the system is in the wrong state, missing prerequisites, or required resources are unavailable.
- Concurrent or conflicting operations
Multiple actors attempting conflicting actions, race conditions observable at system level.
- External system failures
Dependent use cases or external systems returning errors or unexpected responses.
Each failure scenario must define how the system detects the failure, what feedback it provides to the actor, and what safe or recovery state it transitions to.
- Partial Scenarios
Reusable scenario fragments that do not independently fulfil a use case objective but capture common sequences of interactions (e.g., establishing a connection, authenticating a user, performing a self-test) that multiple scenarios within the same use case share. Partial scenarios are strictly scoped to their parent use case and must not be referenced from scenarios in other use cases. See the section on partial scenarios below.
Each scenario is contained in its own subsection and documents the following fields, in this order:
- Result
The outcome upon completion of the scenario. For a success scenario, this describes the achieved goal (e.g., "Session started, UV lamps active"). For a failure scenario, this describes the resulting safe or error state (e.g., "Connection rejected, system remains in Standby"). For a partial scenario, this describes the intermediate result achieved.
- Actors (optional)
By default, a scenario inherits actors from its parent use case. Actors are only specified explicitly when the scenario involves a different subset (e.g., a failure scenario triggered by an external system without human involvement).
- Preconditions
Conditions that must be true before the scenario begins. Preconditions reference states from the state model where applicable. The list covers only the conditions required at the start of that scenario; it does not include preconditions that are internal to referenced partial scenarios. However, the successful execution of a partial scenario (or of a dependent use case) may itself be listed as a precondition.
- Sequence
Numbered steps describing the interaction between actors and the system. The steps are written in clear behavioural language with no implementation detail.
- Postconditions
Conditions that are true after the scenario completes, referencing states from the state model where applicable. Postconditions describe what changed as a result of the scenario – the new state and conditions that are now true because the scenario executed. They do not restate preconditions that were not affected, as this adds clutter without providing information.
8.3.Writing the Sequence#
Each step in the sequence is one of the following:
- Actor action
An actor (human or external system) does something that the system must respond to.
- System response
The system reacts to an actor action, an external event, or a detected condition.
- Contextual actor action
An action performed by an actor entirely outside the system boundary, where the system under development has no role in enabling, receiving, or responding to it (e.g., a user enabling Wi-Fi on their own device, a user plugging in a cable). Contextual actor actions do not generate requirements, but they are included in the sequence to make the interaction flow understandable.
An important distinction: when an actor performs an action through a system-generated artifact or interface (e.g., pressing an acknowledge button on a page served by the system), and the system responds to that action, it is a regular actor action – not a contextual one – even if the action is physically performed on another device. The test is: did the system create the interface that enables the action, and does the system receive and respond to it? If yes, it is a regular actor action and generates requirements.
Example:
- The Service User selects the system's wireless network on the Service Device. (contextual – the system has no role in enabling this action)
- The system receives the connection request and transitions to Service Mode.
- The Service User navigates to the service interface URL using a web browser on the Service Device. (contextual)
- The system receives the request and sends the Authentication Page to the Service Device.
- The Service User enters credentials in the Authentication Page. (regular actor action – the page is system-generated and the system receives the credentials)
- The system validates the credentials.
Steps 1 and 3 are contextual. Step 5 is a regular actor action because the Authentication Page is a system-generated artifact and the system responds to the input.
Triggers and Responses#
Steps follow a trigger-response pattern. A system response is always a reaction to a trigger. The trigger may be:
- An actor action (e.g., "The Service User presses Start.").
- An external event (e.g., "The External Timer sends a start signal.").
- A detected condition (e.g., "The system detects that the temperature exceeds the configured threshold.").
External events and detected conditions do not appear as separate step types – they are embedded in the system response step that reacts to them.
Every trigger must have at least one system response. A single trigger may produce multiple consecutive system responses when the system performs a sequence of actions in reaction (e.g., actor presses Start → system activates lamps → system starts timer → system displays countdown). These are written as separate numbered steps; there is no need to repeat the trigger – the first system response implies the trigger for the subsequent ones.
Conversely, every system response must be traceable to a trigger. If a system step appears to have no trigger, make the triggering condition explicit (e.g., "When the cool-down timer expires, the system deactivates ventilation.").
Referencing Partial Scenarios and Dependent Use Cases#
A step may reference a partial scenario within the same use case, for example:
"3. Partial Scenario UC-01-PS-01 is executed and a wireless connection is established between the Service Device and the system."
A step may also reference a dependent use case by ID with a description of the expected outcome:
"4. Use case UC-04 (Configure Wi-Fi Connection) is performed and the Wi-Fi connection is established."
Referencing specific scenarios or specific steps belonging to another use case is not permitted – see the cross-referencing restriction in the partial-scenarios section below.
8.4.Contextual Preconditions and Postconditions#
Preconditions may include contextual preconditions – conditions about actor readiness or external circumstances that are outside the system boundary but necessary to understand the scenario (e.g., "The Service User knows the correct access credentials", "The Service User has enabled wireless networking on the Service Device"). Contextual preconditions do not generate requirements – they are not verifiable from the system's perspective – but they provide essential context for the scenario to make sense.
Postconditions may similarly include contextual postconditions – conditions about actors or external entities that result from the scenario but are outside the system boundary (e.g., "The Service Device displays the Navigation Page", "The Service User has received the confirmation email"). Contextual postconditions do not generate requirements either, but describe the expected end state from the broader perspective of the interaction.
As an exception, when a scenario could plausibly change something but deliberately does not (e.g., "The existing service session remains unaffected" in a connection-refusal scenario), state this explicitly. Documenting a deliberate non-effect is different from restating an unchanged precondition – it confirms the absence of an expected side-effect.
8.5.Partial Scenario Construction#
In practical PRA projects, after authoring all success, alternative success, and failure scenarios for a use case, the full set for repeated step sequences are reviewed that appear across multiple scenarios. These are then extracted into partial scenarios.
Construction Rules#
The following construction rules apply:
- A partial scenario is a reusable scenario fragment that does not independently fulfil a use case objective. It captures a common sequence of interactions that multiple scenarios within the same use case share.
- Partial scenarios are strictly scoped to their parent use case. They must not be referenced from scenarios in other use cases. Cross-use-case reuse is handled through use case dependencies, not through partial scenario references.
- Partial scenarios may reference other partial scenarios within the same use case in their sequence steps. This allows layered composition of common behaviours (e.g., a "Start Measurement" partial scenario may reference an "Establish Connection" partial scenario). Deep nesting must be avoided – if a chain goes beyond two levels deep, flattening for readability should be considered.
- Each partial scenario uses the same format as a full scenario (Result, Actors, Preconditions, Sequence, Postconditions). Its result describes an intermediate outcome, not a use case goal. Actors are inherited from the parent use case and specified only when they differ.
- Partial scenario IDs use the same numbering scheme as other scenarios, with the partial-scenario type marker (e.g., UC-01-PS-01). The use case number always matches the parent use case.
Cross-Referencing Restriction#
A scenario step may reference:
- A partial scenario within the same use case, by ID with a brief description of what it achieves.
- A dependent use case, by use case ID with a brief description of the outcome.
A scenario step must never reference:
- Specific steps within another scenario (e.g., "Steps 1–7 of UC-03-SS-01").
- A specific scenario belonging to another use case (e.g., "The system executes the flow described in UC-04-SS-01"). The internal scenario structure of a use case is not visible to other use cases.
- A partial scenario belonging to another use case.
If the same functionality is needed across use cases, it is modeled as a separate use case with a dependency relationship. The dependency diagram captures the relationship, and the referencing step states only what outcome is expected – not how the dependent use case achieves it internally.
Precondition Rules for Referenced Scenarios and Use Cases#
For creating preconditions, the following referencing rules are used:
- A scenario's precondition list covers only the conditions required at the start of that scenario. It does not include preconditions that are internal to referenced partial scenarios – those are handled within the partial scenario itself.
- The successful execution of a partial scenario may be listed as a precondition. For example: "Precondition: Partial Scenario UC-01-PS-01 (Wireless Connection Established) has completed successfully."
- The successful completion of a dependent use case may also be listed as a precondition. For example: "Precondition: Use case UC-02 (Install and Configure System) has been successfully completed." This means the use case objective was achieved, not merely that the use case was attempted.
- This separation keeps preconditions clean and avoids duplication while making dependencies between scenarios and use cases explicit.
Practical Workflow#
When constructing a PRS, the following practical workflow can be used:
- Author all scenarios for a use case first, without worrying about duplication.
- Review the scenario set within that use case and identify step sequences that appear two or more times with identical or near-identical wording.
- Extract each repeated sequence into a partial scenario within that use case.
- Replace the original steps in the parent scenarios with a partial scenario reference.
- Verify that the partial scenario's postconditions match what the parent scenario assumes after the reference point.
- Check whether any newly created partial scenarios themselves contain repeated sequences that should be extracted into lower-level partial scenarios.
- Update the use case's scenario overview to include the new partial scenarios.
- If repeated functionality is found across different use cases, model it as a separate use case with appropriate dependencies – never reference specific scenarios or partial scenarios from another use case.
8.6.General Scenario Writing Guidelines#
For writing scenarios, the following general guidelines can be given:
- Identify triggers and conditions
Clearly highlight the triggering events that start a scenario or cause a branch. Tying each system response to a trigger or condition ensures requirements derived from the scenario include the context (no requirement stands alone without a condition).
- Capture system responses for each action
For every input or trigger in the sequence, explicitly state how the system reacts or what output it produces. This discipline guarantees that no functionality remains implicit.
- Use clear narrative and avoid implementation jargon
Write scenarios in terms of user interactions and observable system behaviours. Do not include low-level implementation details; those belong in design. For example, say "System checks that the battery level is sufficient" rather than "System reads register X for battery voltage."
- Cover alternatives and exceptions
Author not only the ideal flow but also any alternative flows and failure conditions as separate scenarios. A single use case may have one success scenario, one or more alternative success scenarios (where applicable), and one or more failure scenarios. Each should be written with the same thoroughness.
By the end of scenario authoring, every use case has a collection of scenario narratives that together illustrate all intended behaviours and responses of the system for that use case.
Scenarios are essentially high-level test cases written in prose. Stakeholders can read them to confirm that the product will handle situations as expected, and engineers can use them to derive formal requirements and test cases.
Scenarios provide rich narratives of system behaviour, but to formally specify the product, the PRS must contain explicit, testable requirements derived from those scenarios. Functional requirements extraction is the process of converting scenario descriptions into individual "shall" statements that specify what the system must do. The goal is to ensure that no intended behaviour remains only in narrative form – every action or reaction expected of the system is captured as a clear requirement that can be implemented and verified.
9.1.Methodology#
Not every scenario step becomes a requirement. Only steps where the system has a responsibility, performs an action, makes a decision, produces an output, or changes state become candidates for requirements. Steps describing actor actions alone (without a corresponding system response) do not generate requirements. Contextual actor actions, contextual preconditions, and contextual postconditions – all of which describe interactions or conditions outside the system boundary – do not generate requirements either. The relationship between steps and requirements is flexible:
- One step may yield one requirement when it describes a single, atomic system behaviour.
- One step may yield multiple requirements when it describes compound behaviour that should be verified separately.
- Multiple steps may merge into one requirement when they describe a single coherent operation from a verification perspective.
The functional requirements are listed in a table with the following columns:
- ID
A unique identifier following the project's ID scheme. Functional requirements use a format that distinguishes them as product-level and functional (e.g., REQ-PRS-FR-001).
- Requirement
A declarative statement using "shall" (the standard wording for a binding requirement), atomic (focused on a single specific behaviour or condition), and including any relevant trigger or condition.
- Source
The scenario or partial scenario ID from which the requirement was derived. This reference serves as rationale; no separate rationale field is needed for functional requirements.
- Acceptance Criteria
How the team will verify the requirement, typically a brief test description or measurement method.
- Priority
Inherited from the parent use case or scenario, or overridden with justification.
9.2.Relationship Between Scenario Steps and Requirements#
Steps in a scenario fall into three categories from the requirements extraction perspective:
- Actor actions
Describe what a user or external system does (e.g., "User presses the Start button"). These do not become requirements themselves but serve as trigger conditions for subsequent system behaviour.
- System actions
Describe what the system does in response (e.g., "System validates sensor calibration"). These are the primary source of functional requirements.
- Implied behaviours
Actions not explicitly stated as steps but implied by preconditions, postconditions, or the scenario context (e.g., logging, state transitions, error handling). These must also be captured as requirements.
The following systematic process ensures complete and consistent extraction.
- Step 1 – Identify system responsibilities
Review each scenario step and determine whether the system is performing an action, making a decision, producing output, or changing state. Mark all such steps.
- Step 2 – Identify trigger conditions
For each system action, identify the preceding actor action, external event, or detected condition that triggers it. Requirements should not describe system behaviour in isolation; they must specify when that behaviour occurs.
- Step 3 – Formulate "shall" statements
Convert each system responsibility into a declarative requirement using the standard "shall" wording. Each requirement should be atomic (addressing a single behaviour), unambiguous (having only one interpretation), and verifiable (testable by inspection, analysis, demonstration, or measurement). Use the pattern: "When [trigger / condition], the system shall [action / behaviour]."
- Step 4 – Capture implied behaviours
Review the scenario's preconditions, postconditions, and overall context for behaviours that are assumed but not explicitly stated as steps. Common examples include logging and audit-trail generation, state transitions, data persistence, timeout handling, and resource cleanup.
- Step 5 – Add verifiable criteria
Where the scenario describes behaviour qualitatively (e.g., "quickly", "reliably"), refine the requirement to include measurable criteria. Before flagging any value, apply the authority test (Chapter 2): flag with [TBD] only when the authority is the customer/stakeholder or established knowledge and the value is genuinely missing. If the value is fixed by a cited standard or by established knowledge, state it with the citation and do not flag it. If the concrete value is a design or feasibility output, state the functional need and leave the value to System Requirements Analysis – do not flag it as pending, and do not add a feasibility caveat.
- Step 6 – Verify bidirectional traceability
Confirm that every system behaviour described in the scenario maps to at least one requirement and that every extracted requirement traces back to a scenario or partial scenario. Requirements extracted from a partial scenario are written once – they are not duplicated for each parent scenario that references the partial scenario. When a scenario step references a dependent use case, do not extract requirements for that use case's functionality; those belong to the dependent use case and are extracted from its own scenarios. The referencing step is a delegation, not a system action, and generates no requirement.
9.4.Common Pitfalls#
Some common pitfalls when extracting the functional requirements are listed below:
- Missing triggers
Writing requirements without specifying when the behaviour occurs (e.g., "The system shall validate data" instead of "When data is received, the system shall validate...").
- Compound requirements
Combining multiple behaviours into one requirement, making verification ambiguous. Split these into atomic statements.
- Vague criteria
Using subjective terms like "fast", "user-friendly", or "reliable" without measurable definitions.
- Omitting failure behaviour
Focusing only on success scenarios and neglecting to specify how the system handles errors and exceptions.
- Implementation bias
Describing how the system should work internally rather than what externally observable behaviour is required.
- Extracting requirements from contextual items
Generating a requirement from a contextual actor action, a contextual precondition, or a contextual postcondition. These are outside the system boundary and do not generate requirements.
- Mis-flagging values
Marking a value [TBC]/[TBD] when the authority test (section 2.2) shows it should instead be stated with a citation (established knowledge) or expressed as a functional need and left to System Requirements Analysis (a design or feasibility output). Equally, never attach a feasibility caveat to a requirement; feasibility is evaluated later, not asserted in the PRS.
9.5.Output#
After extraction, the PRS contains a comprehensive list of functional requirements. Each requirement is:
- Uniquely identified (e.g., REQ-PRS-FR-001).
- Traceable to its source scenario or partial scenario.
- Written as a verifiable "shall" statement.
- Accompanied by acceptance criteria.
- Assigned a priority.
This systematic extraction ensures that all intended system behaviours are captured as formal requirements, providing a complete and testable specification for design and implementation.
10.Non-Functional Requirements#
In addition to functional requirements (the behaviours and features of the product), a complete PRS includes all the non-functional requirements (NFRs) – the constraints, qualities, and conditions under which the product must operate.
NFRs specify how well the system must perform, how reliable or secure it must be, what standards it must comply with, and other attributes not tied to specific use case behaviours. In high-tech electronic systems, NFRs are often as critical as functional requirements: failure to meet a performance target, regulatory standard, or safety criterion can be just as unacceptable as a missing feature.
10.1.Distinction from Functional Requirements#
Unlike functional requirements, which are extracted from use case scenarios, non-functional requirements typically originate from sources outside the scenario analysis process:
- Stakeholder constraints and business decisions.
- Regulatory and certification obligations.
- Industry standards and best practices.
- Environmental and operational conditions.
- Customer specifications and contractual agreements.
- Lessons learned from previous projects or products.
Because NFRs do not emerge from scenarios, their justification is not inherently documented through traceability. Therefore, each NFR must include an explicit rationale explaining why it exists and what drives its specific value or threshold. This rationale ensures that:
- Future engineers understand the origin and importance of each constraint.
- Trade-off decisions can be made with full knowledge of consequences.
- Requirements are not inadvertently relaxed or removed without proper justification.
- Auditors and reviewers can verify that all external obligations are addressed.
The rationale field also carries a second responsibility under the authority test (section 2.2): where a quantitative threshold is fixed by a cited standard or by established knowledge rather than by a stakeholder, the rationale names that source. This is what makes the value defensible without a pending flag – a reviewer checks the citation rather than asking the customer to confirm a figure they are not the authority for.
10.2.Structure of the NFR Chapter#
The NFR chapter opens with an Overview section containing a table that lists each NFR category used in this PRS with a short description of what it covers and why it is relevant for this product. The table has columns: Category and Description. This gives readers a quick orientation before the detailed requirements.
After the Overview, each NFR category has its own section that groups all requirements belonging to it. Within each section, every NFR is documented with:
- ID
A unique identifier distinguishing it as product-level and non-functional (e.g., REQ-PRS-NFR-001).
- Requirement
A "shall" statement with a measurable threshold.
- Rationale
Why this requirement exists and why this specific value (naming the source where the value is fixed by a standard or established knowledge).
- Acceptance Criteria
How compliance will be verified.
- Priority
See chapter 11.
Organizing NFRs by category makes ownership, review, and cross-referencing straightforward.
10.3.Categories of Non-Functional Requirements#
The exact categories vary depending on the product domain. Common categories include, but are not limited to:
- Performance
Quantitative targets for performance characteristics such as speed, throughput, capacity, response time, and efficiency. Examples include maximum latency for a critical operation, data processing rates, throughput or bandwidth, and power-consumption limits. In high-speed or real-time electronics, performance may also involve metrics like jitter, bit error rate, or timing accuracy. All such requirements are stated with concrete, measurable values and conditions. Some performance limits are fixed by established human-factors or physical knowledge rather than by a stakeholder – for example, a perceptual-response ceiling for feedback that is to feel instantaneous – and these are stated firmly with the source cited in the rationale, not flagged for confirmation.
- Reliability and Availability
Ensuring dependable operation over time. Reliability can include metrics such as Mean Time Between Failures (MTBF), error rates, and fault tolerance. Availability may be specified as a percentage uptime. For mission-critical systems, this category also covers safety requirements and fail-safe behaviour – for example, compliance with a Safety Integrity Level standard, or requirements for redundancy and graceful degradation.
- Regulatory and Compliance
Applicable regulations, standards, and certifications. Examples include electromagnetic interference standards, environmental ruggedness standards, safety standards for functional safety, medical-device regulations, communication standards, and security standards. Each compliance requirement is phrased as "The product shall comply with [Standard X]".
- Environmental Conditions
Conditions under which the product must operate reliably, such as operating temperature, humidity, altitude, shock, vibration, and ingress protection. Requirements should be testable (e.g., an implied environmental chamber test or shock/vibration test). Standard environmental envelopes (for instance, a recognised climatic class for a given installation type) are an established-knowledge source: state the range and cite the class in the rationale rather than flagging it.
- Power and Electrical Constraints
Input voltage range, current consumption limits, battery life expectations, and power-transient or quality requirements. Also efficiency requirements or limits on power consumption for battery-powered devices. Note that an achievable consumption figure is typically a design output: state the functional need (low enough that fleet energy cost stays minor, long enough battery life for the use case) and let System Requirements Analysis determine the concrete figure, rather than flagging a placeholder number.
- Maintainability and Serviceability
Requirements ensuring the product can be maintained, serviced, or updated effectively. Examples include modularity, self-diagnostic features, firmware update mechanisms, and Mean Time To Repair targets.
- Branding and User Experience Constraints
Adherence to branding guidelines, style guides, or user-experience standards. Industrial design constraints (dimensions, weight, aesthetics) may also be captured here when they impact engineering.
Other categories may be added when relevant (e.g., Security, Data Integrity, Physical Dimensions and Weight), and categories that do not apply to the product may be omitted. Choose categories that reflect the actual constraints and qualities of the product rather than forcing requirements into a fixed template.
10.4.Verifiability of Non-Functional Requirements#
As with functional requirements, each NFR must be stated in a verifiable way: clear metrics, units, and thresholds must be used and subjective or ambiguous phrasing must be avoided.
Quantitative NFRs are where the authority test (Chapter 2) earns its keep, because the temptation to flag every threshold is strongest here. This is applied before flagging:
- If the value is fixed by a cited standard or by established knowledge, it is stated by naming the source in the rationale – not by flagged it. For instance, a requirement that touch feedback be emitted within roughly 100 ms need not be marked [TBC]: the threshold is set by the human-perception literature on instantaneous response, and the rationale simply cites it. The value is as firm as any other in the document.
- If the concrete value is a design or feasibility output (achievable power consumption, a physical dimension, an internal timing budget), the functional need is stated and the figure is left to System Requirements Analysis – it is not flagged as pending.
- An NFR is flagged with [TBC] (stated, needs confirmation) or [TBD] (genuinely missing) only when a stakeholder is the authority – for example, a customer-mandated service life, certification region, or brand constraint. Where possible, such values should already have been raised in the Pre-Draft Triage (Chapter 3).
Any NFR with a feasibility caveat is not annotated. Whether a stated threshold is achievable, and at what cost, is evaluated during System Requirements Analysis and fed back through the loop described in Chapter 2; it is neither asserted nor hedged in the PRS.
10.5.Cross-Referencing with Context#
NFRs are always to be cross-checked against the context and use cases established in earlier chapters. For every environmental condition, regulatory scenario, or operational constraint mentioned in System Identification or the Business Case Background, it is verified that a corresponding NFR exists. For example:
- If the context states the device will be used in vehicles, it is ensured that there are automotive electrical and environmental requirements.
- If the target market includes a specific region, it is ensured that certification prerequisites for that region are captured.
- If the business case mentions a 10-year product lifetime, it is ensured that reliability and component availability requirements reflect this.
This alignment guarantees the PRS comprehensively reflects all external demands on the product.
10.6.Summary#
Non-functional requirements define the quality attributes and constraints that the product must satisfy. Unlike functional requirements extracted from scenarios, NFRs require explicit rationale documentation to preserve the knowledge of why each constraint exists and what value or threshold is mandated. A thorough PRS lists all such requirements with their rationale and acceptance criteria, giving equal weight to NFRs and functional requirements. Both are essential for a successful product.
11.Prioritization#
Not all requirements are of equal importance or urgency. In the PRS, it is valuable to indicate the priority of use cases, scenarios, and individual requirements. Prioritization helps the development team and stakeholders understand which functionality is critical from the start and which can be scheduled for later releases. It directly supports planning activities such as defining a Minimum Viable Product (MVP), scheduling iterative development, and making trade-off decisions when resources are limited.
11.1.Priority Levels#
The PRS uses exactly five priority levels:
- Essential
Required to implement the minimal viable functionality of the product. Core capabilities without which the product would not be viable or meet its primary objectives. Essential items typically form the MVP and are implemented first.
- Secondary
Required to extend functionality beyond the core. Important for the full product vision but implemented after essentials are in place. Significantly enhances value or usability.
- Nice-to-have
Addresses situations that are rarely encountered or apply to a small subset of users, or features that are desirable but not critical. These may be implemented if time and resources permit, or deferred to later versions. Not all nice-to-have scenarios are fully elaborated in early PRS versions.
- Emerging
Does not have to be implemented. Typically emerges out of combinations of implemented use cases. Added for completeness.
- Future
Speculative or future-expansion ideas recognized but out of current scope. Acknowledged as placeholders for future stakeholder requests, not planned for current development.
Assigning priorities is typically based on business value, user impact, implementation risk, dependencies, and technical complexity. High business value and low risk tend to be essential; low value or high effort tend to be nice-to-have or deferred.
11.2.Prioritization Summary#
The PRS includes a Prioritization Summary chapter that organizes all requirements – functional and non-functional – into separate sections by priority level: Essential, Secondary, Nice-to-have, Emerging, and Future. Each section lists the individual requirement IDs (not counts or group summaries) with a short description and a brief justification for each classification.
Dependency Consistency Check#
Before finalizing the grouping, a dependency consistency check is performed using the following guidelines:
- For every requirement in a given priority level, verify whether it depends on any requirement assigned to a lower priority level.
- If such a cross-priority dependency exists, resolve it by either:
- Promoting the lower-priority requirement to match the higher-priority one (preferred when the dependency is hard and unavoidable), or
- Demoting the higher-priority requirement to match the lower-priority one (only when re-evaluation shows the requirement is not as critical as initially assumed).
- Flag every promotion or demotion with a brief justification so the rationale is transparent to stakeholders.
Where a priority was adjusted during the dependency check, the original priority is noted and the reason for the change alongside the requirement.
11.3.Use of Prioritization in the Project#
Using these categories helps structure the project plan. Essential and Secondary use cases typically form the basis of the first complete PRS draft and the initial development iteration (the MVP or first release). Nice-to-have items are slated for subsequent releases or left for re-evaluation. Emerging and Future items may not be implemented at all, but documenting them ensures the team is aware and can accommodate them architecturally where sensible.
The benefit of including prioritization is that it aligns expectations: stakeholders know which features will be delivered first, and developers know where to focus if trade-offs are needed. It also aids in making decisions during development – if unforeseen challenges arise, lower-priority items can be dropped or postponed to protect the schedule or budget for higher-priority ones.
12.Acceptance Criteria and Verifiability#
One of the hallmarks of a good requirement is that it is verifiable – there is a clear, objective way to determine if the final product meets it. In the PRS, acceptance criteria are defined alongside requirements to describe the conditions or tests that will be used to verify compliance. This ensures that every requirement is not only clear in intent but also paired with a plan for how to test or measure it.
12.1.Defining Clear Acceptance Criteria#
For each requirement, the PRS lists how the team will verify it. Acceptance criteria often take the form of a brief test description or measurement method. For example:
- Requirement: "The power supply shall support input from 100–240 VAC." – Acceptance criterion: "Test the device across the full 100 VAC to 240 VAC range; it must function normally without errors or damage."
- Requirement: "The data interface shall sustain a throughput of 1 Gbps." – Acceptance criterion: "Measure data transfer using standard tool X under conditions Y; at least 1 Gbps is maintained 90% of the time."
Essentially, acceptance criteria answer the question: "How will we know this requirement is fulfilled?"
12.2.Verifiability Early in the Lifecycle#
Defining acceptance criteria during requirements analysis has two major benefits. First, it forces clarification of the requirement – if the team struggles to describe how to test a requirement, that is a signal that the requirement is too vague or subjective. Defining acceptance criteria often leads to refining the requirement wording for clarity. Second, it uncovers special testing needs or resources early. High-tech products may need specialized test equipment or environments (altitude chambers, EMC chambers, penetration-testing services). By identifying these needs in the PRS, the project can plan for them in budget and timeline well in advance.
Note that defining how a requirement will be verified is distinct from establishing whether it can be met affordably. Acceptance criteria describe the test that confirms the requirement is satisfied by a built product; they do not assert that the requirement is achievable. Achievability is a feasibility question addressed in System Requirements Analysis, not in the PRS – consistent with the feasibility-out-of-scope principle in Chapter 2.
12.3.Examples of Verifiable vs. Non-Verifiable Requirements#
The PRS strives to contain only verifiable requirements. Vague requirements should be avoided or rephrased.
- Not verifiable: "The system shall be easy to use." – What does "easy" mean and how is it tested?
- Verifiable: "A first-time user shall be able to perform [a specific key task] within 5 minutes without referring to a manual." – Measurable through observation or usability study.
- Not verifiable: "The device shall not overheat." – No conditions defined.
- Verifiable: "The device shall operate within specifications (no thermal shutdown or data errors) at ambient temperatures up to 50 °C for at least 24 hours." – Clear conditions and pass/fail criteria.
Each requirement should be unambiguous and tied to an acceptance method, whether functional testing, measurement, inspection, or analysis. If a requirement cannot be tested or verified somehow, it is reconsidered whether it is a valid requirement or reword it until it is verifiable.
12.4.Compliance and Certification Acceptance#
For requirements involving compliance with standards or regulations, the acceptance criteria often involve completing official tests or obtaining certifications. The PRS should state these explicitly. For example:
- Requirement: "The product shall comply with EMI standard EN 55032 Class B." – Acceptance: "Pass EMI compliance testing per EN 55032 Class B in an accredited lab."
- Requirement: "The system shall meet Safety Integrity Level 2 (SIL-2)." – Acceptance: "Independent assessment or unit testing to SIL-2 requirements by a certified body."
Stating these criteria makes clear that the definition of done for such a requirement includes the certification or test report, not just internal verification.
12.5.Integrating Acceptance Criteria with Requirements#
By incorporating acceptance criteria in the PRS, the document becomes more than just a list of requirements – it doubles as a high-level validation plan. It gives stakeholders confidence that for each requirement there is a way to prove it has been met. This alignment with testability from the start of the project greatly reduces the risk that, late in the project, someone asks "How do we test this?" and finds it problematic. The key is that for every "The system shall..." statement, you can answer "How will we test that?" immediately.
13.Requirements Listing and Traceability#
Once all functional and non-functional requirements have been identified, the PRS can organise them for easy reference and establish traceability mechanisms. This final step ensures that requirements are accessible throughout the development lifecycle.
Note that this may also be handled by external tooling which extracts the requirements from the PRS as described in section 13.3.
13.1.Requirements Listing#
The PRS presents all functional requirements as a table organized per use case and scenario, and all non-functional requirements as tables organized per category. Each requirement has a unique identifier and the metadata specified in earlier chapters:
- Functional requirements
ID, Requirement, Source, Acceptance Criteria, Priority.
- Non-functional requirements
ID, Requirement, Rationale, Acceptance Criteria, Priority.
The identification scheme distinguishes functional and non-functional requirements explicitly (e.g., REQ-PRS-FR-nnn for functional, REQ-PRS-NFR-nnn for non-functional). IDs remain stable throughout the product lifecycle and are used for traceability to system requirements, design elements, and test cases.
13.2.Traceability#
As development progresses into design, implementation, and testing, maintaining traceability is crucial – the ability to trace each high-level requirement to lower-level requirements, design elements, and test cases, and vice versa. The PRS is the top level of this trace. Therefore, any requirements in later documents (for example, the System Requirements Specification or test plans) link back to one or more PRS requirements. If a lower-level requirement or design component is introduced, it cites the PRS requirement it satisfies. This hierarchical linkage ensures that:
- Nothing is built that does not tie to a product requirement (preventing scope creep).
- All product requirements are being addressed (completeness check).
A common tool for managing this is a Requirements Traceability Matrix (RTM), typically maintained in a spreadsheet or requirements management tool. An RTM lists PRS requirements in one column and references to corresponding system requirements, design modules, and test cases in other columns. The PRS itself can note that an RTM is maintained, or include a simple form of it to demonstrate coverage.
All lower-level requirements (and even design specifications) should trace back to one or more PRS requirements. If a design requirement is found with no parent in the PRS, question why it exists (was it an unapproved feature, or does the PRS need an update?). Conversely, if a PRS requirement is not mapped to any implementation or test, it risks being forgotten – traceability flags that as well.
Maintaining traceability is particularly important in complex, high-reliability projects (aerospace, medical, automotive safety systems) where formal proof of meeting all requirements is needed. Regulatory standards often demand a trace matrix in deliverables. Even outside regulated industries, it is a best practice because it structures the verification effort and change management: if a PRS requirement changes, traceability lets you quickly find what design documents and tests need updating.
The PRS document may be authored in Markdown or a word processor for human readability, but the requirements list and traceability are often managed in a database or dedicated requirements management tool. The PRS remains consistent with that database. Some teams include an export or snapshot from the database as the requirements list in the PRS. The approach may vary, but the key is that identifiers are consistent and the source of truth is maintained.
14.Reference Materials#
A comprehensive PRS ends with a Reference Materials chapter that provides supporting information helping readers interpret and use the requirements. This chapter typically includes:
- Glossary of Terms and Acronyms
Defines every acronym, abbreviation, and domain-specific term used in the document. High-tech projects often involve jargon (e.g., SIL – Safety Integrity Level, MTBF – Mean Time Between Failures, FFT – Fast Fourier Transform). Listing these ensures consistent interpretation across stakeholders. For each term, provide a brief definition. Even common terms can be included if there is any chance of ambiguity.
- Referenced Standards and Documents
Lists all external standards, specifications, regulatory documents, and corporate documents cited in the PRS, with full title and edition or year where applicable. This includes any standards or published sources cited in NFR rationale to substantiate a value under the authority test (Chapter 2) – for example, a human-factors reference behind a perceptual-response threshold or a climatic-class standard behind an environmental range.
- Source Documents
Lists the customer-provided input documents (the Customer Requirements Specification and any background material such as market research, competitor analyses, technical white papers, or standards excerpts) that were used as the basis for this PRS. This creates a clear trail from high-level sources to the PRS content. Where a Pre-Draft Triage (Chapter 3) was conducted, the recorded triage responses are also listed here as a source.
- Preliminary Data or Diagrams
Conceptual diagrams, context or use case diagrams, or any preliminary interface illustrations that help in understanding the requirements.
14.1.Appendices#
Background information from supporting documents that is important for interpreting or substantiating the PRS but does not fit within the numbered chapters is placed in appendices following the Reference Materials chapter. Appendices are suitable for:
- Extended background material (market data, technical white papers, standards excerpts).
- Detailed reference lists (e.g., a full enumeration of configuration parameters whose individual values are expressed as requirements in the main body).
- An Open Items Summary consolidating the genuine stakeholder-authority [TBD] and [TBC] markers for review. Per the authority test (Chapter 2), this summary lists only items whose authority is the customer or another stakeholder; it does not list values resolved by citation, nor values deferred to System Requirements Analysis as design or feasibility outputs.
- Preliminary mechanical drawings, mockups, or other visual reference material.
The Reference Materials chapter and its appendices ensure the PRS is relatively self-contained: a new team member or external stakeholder reading the document can find the meaning of any term, identify referenced documents, and access supplementary context without hunting through other files.
15.Document Template#
Following from the guidelines above, the PRS is structured as follows:
| # |
Chapter |
Content |
| 1 |
Introduction |
Purpose, scope, intended audience, document structure. |
| 2 |
Document Conventions |
Numbering schemes for use cases, scenarios, and requirements; "shall" / "should" / "may" conventions; [TBD] and [TBC] markers and the authority test that governs their use; the principle that the PRS is feasibility-unconstrained (feasibility is evaluated in System Requirements Analysis, not asserted in the PRS); heading and numbering convention. |
| 3 |
Business Case Background |
Product intent and market context; target customer segment; competitive landscape; commercial assumptions (volume, lifetime, cost strategy, certification scope), informed where possible by a pre-draft triage of customer-authority facts. |
| 4 |
System Identification |
Main product objective; product context; system actors (human and external-system subsections, including generalized actors); product elements in scope; external interfaces (by type, such as physical and logical); system artifacts (by type, such as data and physical, including UI artifacts); context diagram. |
| 5 |
Use Cases |
Use case overview listing ID, name, objective, actors, and priority; use case dependency diagram (with optional dependency table); narrative description, objective, and scenario overview for each use case. |
| 6 |
System State Model |
State table; choice-point table (including distinct entries for shared-condition choice-points at different sites where applicable); state transition table (supporting wildcard sources and History destinations where needed); state diagram. |
| 7 |
Use Case Scenarios |
Per use case, one success scenario, zero or more alternative success scenarios, zero or more failure scenarios (or explicit justification for their absence), and any partial scenarios identified during deduplication. Each scenario has Result, Actors (where differing from the use case), Preconditions, Sequence, and Postconditions. |
| 8 |
Functional Requirements |
"Shall" statements extracted from scenarios and partial scenarios. Each requirement: ID (REQ-PRS-FR-nnn), Requirement, Source, Acceptance Criteria, Priority. |
| 9 |
Non-Functional Requirements |
Overview section listing NFR categories used, followed by sections per category. Each requirement: ID (REQ-PRS-NFR-nnn), Requirement, Rationale, Acceptance Criteria, Priority. Quantitative values follow the authority test: cited where fixed by a standard or established knowledge, expressed as a need and deferred to System Requirements Analysis where they are design or feasibility outputs, and flagged only where a stakeholder is the authority. |
| 10 |
Prioritization Summary |
All requirements are organized into separate sections by priority level (Essential, Secondary, Nice-to-have, Emerging, Future) with individual IDs, short descriptions, and justifications, including notes where priorities were adjusted through the dependency consistency check. |
| 11 |
Reference Materials |
Glossary; referenced standards and documents (including sources cited under the authority test); source documents (including any recorded pre-draft triage responses); preliminary diagrams or conceptual models. |
| A…Z |
Appendices |
Additional background information relevant to the PRS but not part of the numbered chapters, including an Open Items Summary of genuine stakeholder-authority [TBD]/[TBC] items where used. |
This structure moves logically from context through behaviour to formal requirements, keeping everything solution-neutral, feasibility-unconstrained, and verifiable.