This is part 3 of the following series:
The document refines the high-level requirements into system-level specifications. To contribute more contents, analyze and elaborate further the constraints, performances, and behaviors by the domain-specific knowledge (Mechanical / Electrical / Optical / Software). More importantly, suggest verification plans to test each one.
The document refines and analyzes the system-level requirements. Since good system-level requirements aren’t complete unless they are testable, verification is also planned. The goal of this phase is to provide the engineering team with the inputs they need to architect the product.
This is communicated via a Product Requirements Specification (PRS). For ease of review, the PRS has been divided into three separate parts – the Constraint Specification, the Functional Specification, and the Verification Plan. A note on nomenclature – ‘system-level requirements’ are captured in the constraints specification items and in the Behavior Diagrams/functions of the Functional Specifications.
The Constraint Specification contains constraints on the system such as physical characteristics and the environment. The Functional Specification includes the behavior and performance requirements. The Verification Plan contains high level test planning, and traceability back to the system level requirements.
The main items used in this Constraint/Functional specification phase trace from the use cases developed in the previous phase. Walking through the use cases step by step is a systematic method to decompose the relevant requirements.
The verification item is used to plan verification activities at a high level. This allows the stakeholders and engineers to agree on the depth and complexity of testing required. Knowing this, testing schedules, cost, and equipment can be planned, and detailed test procedures written.
Rationale: Planning and control depend on a usable vehicle pose estimate. This requirement captures the stakeholder intent that downstream autonomy functions must not operate without localization output that the system considers valid.
Satisfies:
Designs directly impacted by this:
Verification plans:
Rationale: Downstream consumers need timely localization data rather than stale state information. This requirement reflects the intent that planning and control receive fresh pose updates at a defined interface rate.
Satisfies:
Designs directly impacted by this:
Verification plans:
Rationale: The stakeholder intent is that the controller produce commands accurate enough for safe and effective vehicle motion. This captures the expected outcome behind the requirement even though the imported source does not yet define measurable acceptance limits.
Satisfies:
Designs directly impacted by this:
Verification plans:
Linked requirements:
Linked requirements:
Linked requirements:
Linked requirements:
Linked requirements:
Linked requirements: