Give software work a clear route back to its requirements.

Begin with the approved system context.

Select the feature, component and baseline for the software task. Collect the relevant system requirements, architecture decisions, interface definitions and constraints. Mark unresolved inputs before drafting code or tests so an uncertain assumption does not silently become an implementation decision.

In Automotive SPICE 4.0, SWE.1 is Software Requirements Analysis and SWE.6 is Software Verification. Refer to the official model for process definitions and agree the applicable scope with your team. This guide offers a practical work sequence.

Translate the allocated behaviour into software criteria.

Describe what the software must do at its own boundary. Include relevant inputs, outputs, states and error behaviour. Keep the source requirement and allocation decision attached so reviewers can check whether the software interpretation preserves the intended system behaviour.

A system response target does not automatically become the same software execution deadline. Communication, sensing and actuation may use part of the available time. Ask the system and software owners to agree the allocation, record its assumptions and identify how the software contribution will be measured.

Make the design decision usable for implementation.

Identify the software components and interactions that realise the requirement. Explain the selected behaviour at interfaces, including invalid inputs, timeouts and state transitions where relevant. Record the reasoning for the chosen design so a future reviewer can distinguish an intentional constraint from an accidental implementation detail.

For each coding task, prepare the subset of context the implementer needs: the approved requirement, relevant design, interface contract and expected checks. Engineers review generated code against that context and the project's coding rules. A plausible implementation still needs evidence that it behaves as intended.

Choose checks that answer distinct questions.

Use unit checks to examine local behaviour and appropriate boundaries. Review component and integration checks for assumptions that cross interfaces. At the software level, select verification that can demonstrate the required behaviour in the intended configuration. Explain what each check establishes and what remains outside its scope.

Prepare expected results from the agreed criteria before inspecting the outcome. Keep test inputs, preconditions, environment and configuration identifiable. When a check fails, connect the finding to the relevant requirement and implementation context so the engineer investigating it has a useful starting point.

• Does the check exercise the behaviour and relevant operating conditions?
• Are the expected results precise enough for another engineer to evaluate?
• Can the result be traced to the tested configuration and the requirement version?
• Have failures, limitations and follow-up actions stayed visible?

Revisit evidence when the baseline changes.

Follow a proposed change through the software requirements, design, interfaces and verification records. Inspect the content of the linked items to decide which need revision. A complete set of links helps find the work; engineers still need to establish that the records agree.

For the 80 ms proposal, review whether earlier measurements used suitable conditions and captured enough detail to evaluate the tighter target. Existing evidence supports the version it was produced for. Record any decision to reuse results and identify the tests or analysis needed to support the revised baseline.

Close with a decision the next engineer can use.

Before approving the work, check that the requirement, design and verification describe the same behaviour and configuration. Record accepted changes, unresolved findings and responsible owners. Carry the approved information into later tasks so each handoff starts with the current decision rather than an outdated draft.

• Confirm the software requirement reflects the approved system allocation.
• Review the implementation against its interfaces and agreed design constraints.
• Keep the selected verification results and any limitations with the tested version.
• Record the approval and the actions still needed before the next project milestone.

Prepare requirements and verification from shared context.

KlugSpice helps draft software requirements, prepare tests, identify coverage gaps and review potential change impact. Engineers inspect the proposed work and decide what to approve. Existing development and test tools remain part of the workflow, with connections and permissions agreed for the project.