#separator:Pipe
#html:true
#notetype:Basic
#deck:ASPICE 4.1::14 The V at system level
#tags:aspice::lesson-14
#guid column:3
#columns:Front|Back|GUID
Is the “system” in the SYS processes a fixed product level?|No. The SYS processes are “not tied to a particular system boundary”: a mechatronic-system or drive supplier applies them to its mechatronic system, an ECU supplier to its ECU, a chip supplier to its microcontroller. (Guidelines §2.3.2, pp. 47–48)|aspice-14-01
Name three things SYS.1 Requirements Elicitation asks for.|Obtain stakeholders' expectations, agree them as stakeholder requirements, analyse every change to them, and keep their status visible to all affected parties. (PAM pp. 33–34)|aspice-14-02
Name three things SYS.2 System Requirements Analysis asks for.|Specify system requirements with defined characteristics, structure and prioritise them, analyse correctness and feasibility, analyse the impact on the system context, trace to the stakeholder requirements, communicate. (PAM pp. 35–36)|aspice-14-03
Name three things SYS.3 System Architectural Design asks for.|Static aspects (elements, interfaces, relationships) and dynamic aspects (behaviour, interaction in system modes); analysis with rationales; special characteristics for non-software elements; traceability to the system requirements; communication. (PAM pp. 37–38)|aspice-14-04
System requirements are structured only as “functional” and “non-functional”. What happens?|SYS.2.BP2 shall be rated N (SYS.2.RL.5). SWE.1.RL.4 says the same for software requirements. (Guidelines p. 122)|aspice-14-05
Not all system requirements exist yet because development is release-driven. Downrate?|No: SYS.2.BP1 and BP2 are not downrated (SYS.2.RL.4). (Guidelines p. 121)|aspice-14-06
What is the minimum set of views a system architecture needs?|At least one static and at least one dynamic view; no particular set is prescribed. (Guidelines p. 125)|aspice-14-07
Which process owns the hardware-software interface?|SYS.3 System Architectural Design. If an HSI exists, it is an input to the software requirements. (PAM SWE.2.BP1 note 1, p. 46; SWE.1.BP1 note 4, p. 44)|aspice-14-08
Must every customer requirement trace down to design and verification?|No. Only requirements about the product itself do. Process requirements (e.g. “reach ASPICE level 2”) and work-product requirements are evidenced in other ways. (Guidelines §3.3.1, pp. 116–117)|aspice-14-09
SYS.4 vs SYS.5: what does each verify against?|SYS.4: the integrated system elements against the system architecture (interfaces, signal flow, timing). SYS.5: the integrated system against the system requirements. (PAM pp. 39–43)|aspice-14-10
Name the five steps the verification processes on the right of the V broadly share.|Specify the measures · select them (with regression criteria and sufficient coverage for the release scope) · perform and record · trace measures to what they verify and results to measures · summarise and communicate.|aspice-14-11
What must a SYS.5 verification measure's specification include?|Techniques, pass/fail criteria, entry and exit criteria, the necessary sequence, and the required infrastructure and environment setup. (PAM SYS.5.BP1, p. 42)|aspice-14-12
Why does ASPICE 4 say “verification” rather than “testing”?|Because “testing is not the only verification approach”: measurements, calculations, analyses and simulations count too. (Guidelines §2.3.6, p. 61)|aspice-14-13
An automated verification measure's definition says nothing about checking its own scripts. What happens?|BP1 shall be downrated (SYS.4.RL.2, SYS.5.RL.2; likewise SWE.4 and SWE.6, and BP1 or BP2 for SWE.5). (Guidelines pp. 129, 131, 157, 159–161)|aspice-14-14
Exploratory tests trace to no requirement. Is the traceability BP downrated?|No (SYS.5.RL.3, SYS.4.RL.3). Exploratory tests must still trace to their results.|aspice-14-15
A sound selection of verification measures is made against a poor release plan. Is BP2 downrated?|No (SYS.4.RL.4, SYS.5.RL.4): the weakness belongs to the release planning.|aspice-14-16
Name three kinds of stakeholder requirement besides the customer’s.|Any three of: the supplier’s own (product-specific or platform), legal, regulatory, statutory or industry-sector requirements, international standards, codes of practice. The PAM’s list is open: any requirement for the stakeholders in the given context. (PAM p. 10)|aspice-14-17
What can a system element be?|Logical: a structural object at architecture or design level, which may be decomposed further. Or physical, or a combination: e.g. a sensor, an actuator, a mechanical part or a software executable. (PAM p. 10)|aspice-14-18