The full reference for the SRA phase. Each chapter describes one activity, its inputs, outputs, and its place in the overall process. For a compact view of inputs/outputs across all activities, see the SRA Task Overview.
1. Introduction
The System Requirements Analysis (SRA) phase is the second stage of the structured pre-development process, following the completion of the Product Requirements Analysis (PRA).
The PRS produced in Phase 1 defines what the product must do and how it should behave from the perspective of users and stakeholders, without yet making technical choices. The SRA takes that PRS as input and answers the question that comes next: how can each of those requirements actually be realised?
This is the phase where technical exploration is welcome. Architecture options are evaluated, technologies are assessed, and where uncertainty is high, targeted prototypes are built to validate feasibility. The phase also serves as a sanity check on the PRS itself: if a requirement turns out to be technically infeasible or economically impractical, the customer is engaged early (well before significant capital has been committed) to decide whether to revise the requirement or reconsider the business case.
By the end of the phase, the engineering team should have high confidence that the product can be built as specified, and the customer should have visibility into the architecture, the design risks, the verification approach, and an initial cost estimate.
Deliverables
The SRA produces a set of deliverables that together form the foundation for development planning and detailed design:
System Architecture
A solution-neutral decomposition of the product into functional modules, with all internal and external interactions mapped.
Implementation Concept Analysis
For each functional module, an evaluation of implementation options with feasibility, risk, and selection rationale.
Proof-of-Concepts
Targeted prototypes that validate the critical or uncertain aspects of selected concepts.
Device Architecture
Mapping of functional modules to concrete hardware, software, and where applicable, FPGA and mechanical components.
Preliminary BoM & Cost Estimate
An initial component list with indicative unit cost, supply risk, and lifecycle notes.
System Requirements Specification
The detailed, verifiable technical requirements derived from the PRS.
Initial Product Test Plan
The first version of the verification strategy: how each requirement will be tested, and with what equipment.
2. System Architecture
The first major technical activity of the SRA is defining the System Architecture: a solution-neutral decomposition of the product into functional modules. These modules collectively describe how the product will perform what the PRS says it must do, without yet committing to specific implementation technologies.
Functional modules
The product's functions, derived from the use cases and scenarios in the PRS, are grouped into logically cohesive modules. A typical product might have modules such as a user interface, sensing, control logic, power management, communication, and a mechanical frame. The grouping is driven both by functional cohesion and by anticipated architectural boundaries (natural software / hardware splits), without yet assigning implementation technology to any of them.
Interactions across the system boundary
Functional modules don't live in isolation. They interact with each other, with the actors and external interfaces identified in the PRS, and through any cooperation between actors required for the product to be used as intended. Every one of these interactions is captured (internal, external, and operational) so that the architecture is provably complete: no interaction implied by the PRS is left undocumented, and every documented interaction can be traced back to a use case or non-functional requirement that justifies it.
This completeness is what makes the architecture useful as a foundation for the rest of the phase. The design risk analysis, the system requirements specification, and the test plan all index into it; if an interaction is missing here, it's missing everywhere downstream.
The architecture diagram
The visual centrepiece of this work is the architecture diagram: a single block-level overview showing all functional modules, the external interfaces from the PRS, the connected actors, and every interaction between them. Different visual treatments distinguish modules, interfaces, and actors so the reader can identify the kind of each element at a glance. Each connection in the diagram is cross-referenced with the underlying tables so any reader (engineer or customer) can drill from the picture into the detail.
Why it matters for the project
The System Architecture is not produced as a documentation exercise. It serves several concrete purposes:
- It gives a shared technical vision of the product's structure that the customer and the engineering team can both reason about
- It defines a natural work breakdown: each module can become a work package, with clear ownership and parallel development paths
- It surfaces where the risk lives: modules with novel functions, demanding requirements, or unclear technology choices stand out and become candidates for further analysis or prototyping
- It provides early visibility for the customer on how their product requirements have been understood, supporting realistic quoting and resource planning
Because of its central role, the System Architecture is typically reviewed with the customer before concept evaluation begins, so any misunderstanding is caught while it's still cheap.
3. Concept Analysis
Once the System Architecture is defined, the question becomes how each functional module can be implemented. This is the work of concept analysis: evaluating implementation approaches (referred to as concepts) for feasibility, complexity, and suitability.
Not all functional modules carry the same level of uncertainty. Some have well-understood, standard solutions; others require a real trade-off; some present significant unknowns. Allocating equal effort to all of them is a waste. Concept analysis classifies each module so the team's attention is spent where it actually matters.
Three classifications
Trivial
A single clear and reasonable solution exists that fulfils all the relevant requirements. Established solutions, industry standards, or existing building blocks make the implementation path obvious. The decision is still documented (including confirmation that the solution meets the applicable requirements) but no trade-off study is needed.
Balanced
Multiple viable approaches exist, each with distinct trade-offs in performance, cost, power consumption, component availability, integration effort, or technology maturity. A structured trade-off study compares the options against defined criteria, and the selection is recorded with its rationale. This transparency keeps the design decision auditable for the lifetime of the product.
Exploratory
Feasibility itself is uncertain. The function may rely on novel technology in the intended application, push known technical limits, or fall outside available supplier experience. The approach is to identify the key uncertainties up front and resolve them through targeted prototyping or feasibility studies, and where the evidence warrants it, to propose revisions to the PRS rather than commit to a requirement that cannot be met.
Why classification matters
The classification has practical consequences beyond the SRA phase itself. It tells the project manager where to expect schedule risk, tells the customer where prototype effort will be spent (and why), and informs the eventual development plan: a project with six exploratory modules has a different shape than one with mostly trivial and balanced ones.
4. Prototyping & Feasibility Validation
For modules classified as exploratory, prototyping converts uncertainty into evidence. The work focuses on the specific aspects of a concept (performance, integration, manufacturability) that cannot be confirmed through analysis alone.
Minimal and focused
The goal is not to build the product. It's to answer the open feasibility question with the least possible effort: a breadboard, a software simulation, a 3D-printed mock-up, a bench test against a representative load. If the answer can be reached on a desk in two days, that's better than a four-week build.
Where a critical manufacturing process itself poses a feasibility risk, that process is validated at this stage too, well before it becomes part of a production ramp.
If a prototype turns out to require more effort than the phase allows, that is itself a finding: it gets raised with the customer and either planned as a separate feasibility track or used to revisit the underlying requirement.
Using the findings
Prototype outcomes are reviewed with stakeholders and feed directly into the rest of the phase: finalising the concept choice, refining or confirming the technical requirements, and providing concrete inputs to the SRS. The result is that selected concepts are not just theoretically valid but demonstrably achievable within the project's constraints.
5. Device Architecture
With the System Architecture defining what functions exist and the selected concepts defining how each one will be implemented, the Device Architecture maps those functions onto concrete components: hardware, software, and where applicable, FPGA and mechanical elements, with the physical interfaces between them.
A high-stakes decision
This is the point where the project commits to the partitioning between hardware, software, FPGA, and mechanical domains. Trade-offs made here cascade through every subsequent design choice and are expensive to revisit later. Getting it right early is part of why the SRA exists.
How it's captured
The Device Architecture is typically expressed in two complementary forms. A diagram shows the physical components and their interconnections, including where software is executed and stored, with interfaces annotated where known. A mapping ties each component back to the functional module(s) it supports, clarifying multi-use elements (one microcontroller participating in several functions) and confirming that every module from the System Architecture has a physical home.
Distinction from the System Architecture
The two architectures answer different questions. The System Architecture is about function; the Device Architecture is about realisation. A single functional module may span several components, and a single component may support several modules. That mismatch is normal and expected, and the mapping makes it visible. Establishing this physical view early supports cross-disciplinary alignment, integration planning, and the test strategy that follows.
6. Functional Module Descriptions
With the Device Architecture in place, each functional module identified in the System Architecture is described in more detail. These descriptions sit at the system engineering level: they bridge the gap between abstract function and concrete implementation without yet getting into detailed design.
What each description contains
For every functional module, the description covers four things:
- Role and scope: what the module does, and which product requirements it supports
- Involved components: the hardware, software, and where relevant FPGA and mechanical components that participate, drawn from the Device Architecture
- Interfaces: the internal and external interfaces the module uses, with any module-specific implementation notes that come from the chosen concept
- Selected concept: a short recap of the implementation approach and its rationale
Where helpful, the relevant portion of the Device Architecture is redrawn for that module (a focused sub-view rather than the full overview) to make the components and interfaces of that module immediately visible.
Why this step is worth its space
The module descriptions are what make the system design transparent and traceable. They clarify how each part of the product contributes to the whole, support clean ownership during detailed design, provide the context needed to write specific technical requirements in the SRS, and let reviewers see how architectural and concept decisions map back to actual product functionality. Without them, the architecture diagrams remain abstract; with them, the design is something a customer can review meaningfully.
7. Design Risk Analysis
The Design Risk Analysis, typically performed as a Design Failure Mode and Effects Analysis (DFMEA), is a structured evaluation of how the proposed architecture could fail. It is not a documentation exercise; it is an active design-validation tool that challenges assumptions, surfaces architectural weaknesses, and drives measurable improvements to robustness.
The DFMEA answers, for every functional module and critical interface, a small set of pointed questions: How could this fail? What would the effect be at system and user level? How severe is that effect? How likely is the failure to occur? How easily would it be detected before it does damage? The answers determine which risks need mitigation and which can be accepted with documented rationale.
When the DFMEA is performed
The analysis is positioned deliberately: after the System Architecture, concepts, Device Architecture, and module descriptions are in place, but before detailed design begins. By then, enough technical clarity exists to evaluate realistic failure modes, while the design is still flexible enough that architectural changes are feasible and cheap.
Scope
The analysis is performed at architecture and module level, considering functional modules and their responsibilities, the interfaces between them (data, control, power, mechanical), the partitioning of functionality across hardware, software, and mechanical domains, the operating environment, and external dependencies such as power, communications, and user interaction. Manufacturing and process-related risks are not in scope here; those are addressed in Phase 3 (Industrialisation), if applicable.
Not just documentation
The DFMEA earns its place by driving change. A risk identified here typically results in one of four concrete outcomes: a revised architecture, a new or refined system requirement, an added verification activity, or (for risks that turn out to be acceptable) an explicit acceptance with documented rationale. Identified risks that produce no outcome are a sign the analysis isn't working.
How the findings flow
Mitigation actions that affect product behaviour or constraints are reflected back into the SRS, with traceability between the DFMEA item and the resulting requirement maintained so the connection isn't lost. The Test Plan is updated where additional detection, monitoring, or validation activities are required. Where a structured rating system (severity, occurrence, detection) is appropriate for the project's regulatory or contractual context, that's applied; the DFMEA adapts to the standard the product needs to meet.
Why it matters for the project
The Design Risk Analysis directly supports realistic, transparent estimation. It makes architectural complexity visible, identifies where prototyping or extra validation is needed, highlights reliability- and safety-critical elements, and gives the customer a clear, evidence-based view of technical risk. The cost is real time spent during the SRA; the payoff is a sharply reduced chance of late-stage redesign, reliability surprises, or underestimated effort.
8. System Requirements Specification
The System Requirements Specification (SRS) is the formal output of the SRA phase. It captures the complete set of technical requirements that define how the product requirements from the PRS will be fulfilled, and becomes the foundation for detailed design, implementation, and verification.
What every system requirement carries
Each system requirement is written as a clear, atomic statement that is:
- Unambiguous: precise enough that two engineers reading it independently would build the same thing
- Verifiable: testable by inspection, analysis, measurement, or demonstration
- Traceable: linked to one or more product requirements in the PRS, and indicating how it will be verified ("tested in a thermal chamber", "verified by EMC lab report", "inspection of label")
The detailed verification method and test procedure live in the Test Plan, but the SRS itself already signals whether and how each requirement is testable. A requirement without a verification path doesn't make it into the SRS; it goes back for refinement.
Structure and traceability
Requirements are organised by subsystem or functional module (matching the architectures), or grouped by type (functional, interface, environmental, regulatory). The structure aids readability, makes ownership allocation natural, and supports test planning. Whichever organisation is used, traceability from PRS to SRS, and back, is established and maintained. One product requirement often produces several system requirements; one system requirement may support several product-level needs.
Review and baseline
The SRS undergoes internal review and, where applicable, customer review, to validate technical correctness, feasibility, alignment with the original product intent, and testability. Once approved, the SRS is baselined: changes after that point follow a structured change-control process, so requirement drift cannot quietly erode the foundation of the project.
9. Initial Product Pricing
As part of evaluating technical feasibility, an initial cost estimate is developed. It's based on a preliminary Bill of Materials (BoM) derived from the system and device architectures and early component selection.
The goal is not to finalise pricing (that comes later, once the design is detailed and supplier negotiations have happened); the goal is to gain early insight into cost drivers and pricing sensitivity. This is the right moment to discover that a chosen architecture lands above the customer's target price, or that a single high-cost component is responsible for a third of the BoM total. Both findings can still influence the design.
How candidate components are chosen
The concept BoM identifies candidate components (typically commercial off-the-shelf (COTS) parts) that could fulfil the hardware portion of each functional module. Three considerations drive the selection:
- Availability and lifecycle: key components should be backed by industrial supply contracts or long-term availability commitments, to avoid end-of-life risk forcing a redesign mid-life
- Regulatory compliance: all components must comply with the relevant regulations for the target markets, such as RoHS (restriction of hazardous substances) and REACH (chemical registration)
- Technical and commercial suitability: components must be appropriate for the use case in form factor, power, performance, and integration complexity, including any manufacturer restrictions on end-use or region of deployment
What the estimate delivers
The output is a preliminary unit-cost estimate with the assumptions made explicit: indicative supplier pricing, expected volumes, sourcing and supply-risk notes, and excluded items. Where useful, a sensitivity analysis shows how total cost would shift under different design choices or volumes. The estimate is reviewed internally and, where appropriate, shared with the customer to align expectations before the project enters detailed development.
10. Initial Product Test Plan
With the Device Architecture defined and the SRS taking shape, the Initial Product Test Plan establishes how the system will be verified. It ensures that both the product requirements (from the PRS) and the system requirements (from the SRS) are demonstrably testable, and maps each one to an appropriate verification method.
This is also the document used to align with the customer on the verification approach, including any regulatory or contractual testing the customer is responsible for arranging, and any third-party test labs that need to be engaged.
What the test plan covers
- Verification strategies: the approach used for each type of requirement: inspection, functional testing, simulation, or analysis
- Test tooling and fixtures: any special hardware test setups, software emulators, or custom interface boards needed to exercise the product
- Test equipment: required lab instruments such as oscilloscopes, thermal chambers, or EMC benches
- Acceptance criteria: clear pass/fail criteria for product- and system-level requirements alike
- Traceability: initial mapping between requirements and the test activities that verify them, supporting later coverage analysis
Why "initial"
The plan is called initial deliberately. It will be refined and expanded during development as the design matures and more is known about test fixtures, lab availability, and edge cases. What this initial version delivers is just as important, though: an agreed verification approach, an early view of test infrastructure needs (which often have long lead times of their own), and proof, for every requirement in the SRS, that there is a credible way to confirm it has been met. Testability stops being something retrofitted at the end of the project and becomes something the design is built to support.