#separator:Pipe
#html:true
#notetype:Basic
#deck:ASPICE 4.1::16 Validation
#tags:aspice::lesson-16
#guid column:3
#columns:Front|Back|GUID
What is VAL.1 Validation for?|Evidence that the end product, allowing direct end-user interaction, satisfies the intended-use expectations in its operational target environment. (PAM §4.5.1, p. 58)|aspice-16-01
What separates verification from validation, according to the Guidelines?|Whether objective measurement can settle it (verification) or it takes a judgement of what users need, made by end users or their representatives or approximated, for instance by accident simulations (validation). A simulation checked against a specification is still verification. Having a written requirement is not the criterion. (Guidelines pp. 163–164)|aspice-16-02
Gear-shift time within spec vs a good gear-shift feel: which is verification, which validation?|Shift time: verification, it “can be measured objectively”. Shift feel: validation, it “requires feedback from end users”. (Guidelines §3.14.1, p. 163)|aspice-16-03
Name three kinds of validation measure the PAM gives.|Any three of: operational use-case testing under real-life conditions, highly accelerated life testing, simulations under real-life conditions, end-user trials, panel or blind tests, expert panels. (PAM p. 10)|aspice-16-04
Which products does VAL.1 exclude, and why?|Pure embedded software, ECUs and drives: none of them “provides a direct end user interface”. (Guidelines §3.14.1, p. 163)|aspice-16-05
In the Guidelines’ automatic side-door example, which is verification and which validation?|The door-trigger angle, objectively measurable: verification. How much closing force is an intolerable harm to users: validation. (Guidelines p. 163)|aspice-16-06
A validation measure comes from a homologation requirement. Must its trace be bidirectional?|No: unidirectional traceability is sufficient for legal or homologation sources. (PAM VAL.1.BP4 note 8, p. 59)|aspice-16-07
What can validation results feed back into?|New or changed stakeholder or system requirements, e.g. from mock-ups or concept studies (VAL.1.BP3 note 5), which SYS.1 (stakeholder) or SYS.2 (system) then handles.|aspice-16-08
A limit on gear-shift noise is written as a requirement. Does that make checking the shift feel verification?|No. Being able to write a requirement “does not serve as a distinction criterion”; judging whether the limit is adequate for users is still validation. (Guidelines p. 164)|aspice-16-09
Match each left-leg work product to the process that checks it: system requirements, system architecture, software requirements, software architecture, detailed design.|System requirements → SYS.5 · system architecture → SYS.4 · software requirements → SWE.6 · software architecture → SWE.5 · detailed design and units → SWE.4.|aspice-16-10