Requirements and Architecture
Requirements and Architecture tests the translation chain from stakeholder needs to a verifiable requirement set and an architecture that satisfies it. The exam draws on ISO/IEC/IEEE 29148 for requirement quality and on 15288 architecture definition processes. Expect questions on requirement characteristics, traceability, functional versus nonfunctional allocation, interface definition, and architecture views.
From needs to requirements
Stakeholder requirements express what users and acquirers need in their language. System requirements restate them as verifiable system-level obligations, including functions, performance, interfaces, and constraints. Each requirement should be necessary, singular, unambiguous, feasible, verifiable, and free of design prescription unless a constraint is genuinely imposed. 'The operator shall be able to...' is testable; 'the system shall be user-friendly' is not.
Architecture
Architecture is the set of concepts and properties of a system in its environment embodied in its elements, relationships, and design principles. Logical architecture describes what functions and data flows must exist; physical architecture describes allocated elements and interfaces. Allocation links requirements to architecture elements and is the basis for traceability. Views serve stakeholders: functional, product, interface, and life-cycle views answer different questions; no single view is the architecture.
Worked example
Requirement: 'System shall be easy to use.' Rewrite for verification: 'A trained operator shall complete a standard incident entry in 90 seconds or less, with two or fewer errors per 20 entries, measured in a usability test with 12 representative operators after 30 minutes of training.' Reasoning: the original is subjective and not verifiable; the rewrite names the user, task, measures, conditions, and threshold. If the customer insists on 'intuitive,' it belongs in a validation criterion or quality-attribute scenario, not a system requirement.
Traps that cost marks
Treating a design description as a requirement; writing compound and/or requirements; allocating a performance requirement to a component without a budget or interface assumption; using architecture diagrams as a substitute for interface definitions; accepting traceability as a one-way link rather than bidirectional evidence.