Requirements allocation
Requirements allocation assigns system or stakeholder requirements to appropriate engineering elements so that responsibility, expected behavior, and verification scope are explicit.
Systems engineering guide
ASPICE Analysis Guide
A practical engineering model for examining requirements, interfaces, traceability, verification evidence, and development process completeness with Automotive SPICE.
Engineering model
How ASPICE fits together
ASPICE analysis examines whether engineering work is defined, connected, reviewable, and supported by objective evidence. The analysis depends on clear requirements, allocated responsibilities, defined interfaces, verification criteria, and traceability between engineering artifacts. ISO 26262 and SysML can provide related safety and modeling context, but ASPICE analysis remains focused on the completeness and consistency of the development process and its work products.
Core concepts
The parts of a practical ASPICE setup
Traceability
Traceability connects requirements, design elements, implementation evidence, and verification results, making gaps and unsupported claims visible during analysis.
Verification criteria
Verification criteria define what must be checked and what result is acceptable; without them, a test result may not demonstrate that a requirement was satisfied.
Interface definition
Interface definition describes the relationships and exchanged behavior between system elements, reducing ambiguity when requirements are allocated across boundaries.
Process evidence
Process evidence is the set of reviewed engineering artifacts that shows how work was performed and whether the expected relationships between artifacts are present.
What ASPICE analysis is actually assessing
The useful question is not whether documents exist, but whether the engineering chain is coherent and can be reviewed from intent to evidence.
Automotive SPICE analysis examines the relationship between requirements, engineering activities, resulting artifacts, and verification evidence. A requirement should have a clear meaning, an allocation or design relationship, defined verification criteria, and evidence that the intended behavior was checked. Analysis therefore looks for both missing artifacts and contradictions between artifacts.
- A requirement is understandable and sufficiently specific for engineering work.
- Allocated requirements remain consistent with the originating system or stakeholder need.
- Interfaces and dependencies are defined where responsibility crosses an engineering boundary.
- Verification criteria can distinguish an acceptable result from an unacceptable result.
- Traceability is complete enough to identify unverified or weakly supported requirements.
The analysis chain from requirement to evidence
A repeatable analysis follows relationships rather than reading each artifact in isolation.
- 01
Establish the requirement baseline
Identify the available system, software, or stakeholder requirements and check whether each has a stable meaning, an owner, and a verification expectation.
- 02
Follow allocation and interfaces
Determine where each requirement is realized and inspect interface definitions where responsibility or behavior crosses between engineering elements.
- 03
Inspect verification criteria
Check that each requirement has an observable acceptance condition and that the associated test specification can produce relevant evidence.
- 04
Evaluate traceability
Follow links in both directions: from requirements to design and verification evidence, and from tests or evidence back to the requirements they are intended to support.
- 05
Record findings by relationship
Describe the missing, inconsistent, or ambiguous relationship and separate an absence of evidence from evidence that contradicts the requirement.
This sequence helps prevent a common analytical error: treating a test specification as proof of coverage before confirming that the test actually exercises the behavior and acceptance condition defined by the requirement.
Requirements, allocation, and interfaces
Requirements analysis becomes meaningful when each statement can be placed in the system structure and interpreted at its boundary.
Requirements allocation should make responsibility visible without changing the intent of the originating requirement. The allocated requirement may add implementation detail, but it should remain possible to determine why it exists and how it contributes to the higher-level need. Interface definition is especially important when behavior depends on another element, because an apparently complete requirement can still be unverifiable if its exchanged conditions are unspecified.
| Analysis area | Evidence to inspect | Typical finding |
|---|---|---|
| Requirement meaning | Requirement wording and acceptance condition | The expected behavior cannot be distinguished from implementation preference |
| Allocation | Relationship from higher-level requirement to allocated element | Responsibility is implied but not assigned explicitly |
| Interface definition | Declared interaction and boundary conditions | The requirement depends on an interface detail that is absent or ambiguous |
| Consistency | Related requirements and allocated statements | Allocated behavior narrows, expands, or conflicts with the originating requirement |
Traceability and verification coverage
Traceability is useful only when links carry engineering meaning and lead to evidence that addresses the requirement.
A traceability matrix should allow an engineer to start with a requirement, identify its allocated design element, locate the relevant test specification, and judge the resulting evidence. The reverse direction is equally important: an apparently valid test should have a clear reason for existing and should not be counted as coverage for an unrelated requirement.
- Distinguish a link to a planned test from evidence that the test was executed and assessed.
- Check that expected results correspond to the requirement's verification criteria.
- Identify requirements with no linked verification activity or with links that stop at a test description.
- Identify tests linked to many requirements when their result cannot independently demonstrate each requirement.
- Record unresolved links separately from failed verification results; they represent different engineering conditions.
| Traceability condition | Interpretation | Analysis response |
|---|---|---|
| Requirement linked to a test with matching criteria | Potentially demonstrable coverage | Inspect execution evidence and result assessment |
| Requirement linked to a test with weak or absent criteria | Coverage cannot be judged reliably | Clarify the acceptance condition before relying on the result |
| Test has no requirement relationship | Purpose and scope are unclear | Determine whether the test is exploratory, supporting evidence, or an orphaned artifact |
| Requirement has no verification relationship | Verification coverage is incomplete | Record the gap and assess its effect on validation planning |
Building an actionable analysis result
The output should help an engineer decide what is missing, inconsistent, or ready for further review.
- 01
Classify the observation
State whether the issue concerns requirement clarity, allocation, interface definition, verification criteria, traceability, or evidence completeness.
- 02
Identify the affected relationship
Name the connection that cannot be followed, such as a requirement-to-test or allocation-to-interface relationship.
- 03
State the engineering consequence
Explain whether the issue prevents coverage assessment, creates conflicting interpretations, or limits confidence in the verification result.
- 04
Reference available evidence
Point to the relevant requirement, test specification, model relationship, or engineering document without asserting more than the artifact supports.
- 05
Define the review condition
Describe what must become clear or consistent before the finding can be reconsidered.
A strong finding is bounded and reproducible. It does not claim a root cause when the available artifacts show only a missing link or ambiguous criterion. This distinction keeps analysis useful during review and follow-up.
Deliverables that support continued review
A useful analysis leaves behind structured evidence that another engineer can inspect without repeating the entire investigation.
| Deliverable | Purpose | Minimum useful content |
|---|---|---|
| Requirements specification | Defines the requirements being analyzed | Requirement intent, allocation context, and verification criteria |
| Traceability matrix | Shows relationships across engineering artifacts | Requirement links to allocation, design context, test specification, and verification evidence |
| Engineering documentation | Records analysis reasoning and review context | Finding description, affected relationship, evidence considered, and review condition |
The deliverables should preserve both positive and negative findings. A confirmed relationship can show where coverage is credible, while an unresolved relationship shows where further engineering work or review is required.
Engineering pitfalls
Common mistakes
Counting every linked test as coverage
A link alone does not show that the test exercises the requirement or uses matching verification criteria. Inspect the expected result and the evidence produced.
Analyzing artifacts independently
Requirements, allocation, interfaces, and tests can each look reasonable while disagreeing as a set. Follow relationships across artifacts.
Treating missing evidence as a failed result
An absent test result, an unclear criterion, and a failed verification result are different conditions and should be reported separately.
Using a model as proof of implementation or verification
SysML can clarify structure and behavior, but a model relationship does not by itself prove that a requirement was implemented or verified.
Assuming ISO 26262 references establish completeness
Safety context may change the analysis scope, but references to ISO 26262 do not replace clear requirements, allocation, criteria, and evidence.
Reporting vague findings
A statement such as 'traceability is weak' is difficult to act on. Identify the missing relationship, affected artifact, and condition needed for review.
FAQ
ASPICE questions
- What is the primary object of ASPICE analysis?
- The primary object is the coherence of engineering work: requirements, allocation, interfaces, verification criteria, traceability, and supporting evidence should form a reviewable chain.
- Why can test coverage remain unclear when tests exist?
- Tests may exist without matching verification criteria, meaningful requirement links, relevant expected results, or evidence that the intended behavior was exercised and assessed.
- Should every requirement have a direct test link?
- Each requirement should have an appropriate verification relationship, but the relationship may depend on the engineering structure. The important point is that the chosen evidence can demonstrate the stated requirement.
- How does SysML help an ASPICE analysis?
- SysML can make structure, behavior, allocation, and interfaces easier to inspect. The analysis must still check consistency between the model and the requirements, test specification, and verification evidence.
- How should ISO 26262 be handled during analysis?
- Treat ISO 26262 as functional-safety context that may add expectations to requirements, allocation, and verification. Do not use its presence as a substitute for complete and consistent ASPICE evidence.
Engineering support
Discuss an ASPICE Project
Need a focused review of requirements, traceability, or verification evidence? An independent automotive software engineer can help analyze the available engineering artifacts and document actionable findings.