Carry system intent through to the evidence.

Start with one behaviour and its source.

Pick a bounded feature rather than a whole specification. Bring its customer request, current requirement, architecture view and available test records into the discussion. Record the versions and identify who can resolve questions about the intended behaviour. This gives reviewers a shared starting point.

For orientation, Automotive SPICE 4.0 names SYS.1 Requirements Elicitation, SYS.2 System Requirements Analysis and SYS.5 System Verification. The official model defines the processes; the workflow below is an illustrative way to organise engineering work.

Make the customer request clear enough to decide.

Separate what the stakeholder requested from the team's interpretation. A request for a faster parking response leaves open the start event, end event and operating conditions. Ask which delay matters to the customer and whether the proposal applies to all operating modes.

Keep unresolved questions visible. If a meeting proposes a new target while the approved specification still shows the old one, retain both sources and record the decision needed. An AI draft can prepare wording and questions; the responsible engineer resolves the intended change.

Write a requirement the team can verify.

Describe the observable system behaviour, its conditions and the acceptance criterion. Confirm the measurement boundaries with the people who will design and verify it. A numerical target becomes useful only when everyone understands what is measured.

Check where the behaviour belongs.

Follow the requirement into the architecture. Identify the components and interfaces that contribute to the response, then review the assumptions behind their timing allocations. Record why the proposed distribution is feasible and what still needs investigation.

Use the relationships as a route into the engineering discussion. A linked controller may be affected by a timing change, but the link alone cannot determine whether its implementation needs changing. Inspect the relevant design and involve the owners of adjacent interfaces.

• Confirm the requirement and architecture describe the same operating conditions.
• Check the timing contribution and assumptions at each relevant interface.
• Record open design questions, responsible owners and the decision that closes each question.

Prepare verification that answers the current question.

Review the test conditions and expected results against the proposed requirement. Decide which interface checks and system tests are relevant, then record the selected configuration, environment and measurement method. Explain exclusions so the next reviewer understands the chosen scope.

Existing results for the approved 100 ms requirement do not yet demonstrate the proposed 80 ms target. An engineer must determine whether the recorded measurements and conditions can support a fresh evaluation or whether tests need to run again. Keep that decision with the result and its requirement version.

Bring a review pack the team can follow.

Before closing the change, ask another engineer to follow the reasoning from the customer input to the verification result. Make gaps and unresolved findings easy to see. Keep approval records alongside the work they refer to so later changes can start from the agreed baseline.

• The stakeholder request, agreed interpretation and requirement version are identifiable.
• The architecture and interface decisions explain how the behaviour is allocated.
• Verification criteria, test configuration and results refer to the intended version.
• Open findings have owners, and approval decisions state what was accepted.

Use AI to prepare the work for that review.

KlugSpice can draft requirements from project sources, flag unclear or conflicting wording, prepare verification assets and expose connected work that may need review. Its shared project context keeps the source information available for engineers to inspect. Select one feature and agree the review responsibilities and tool permissions before evaluating the workflow.