Requirements Engineering Checkpoint Quiz

10 questions covering all four modules — Module 1 through Module 4. Read each question carefully. Some questions are scenario-based. Instant scoring with explanations on submission.

📋 10 Questions⏱ ~20 min🎯 Pass mark: 70% (7/10)📖 Covers Modules 1–4

Q1. Why is structured requirements engineering mandated in S-CORE rather than left to individual project discretion?

A It is required because requirements management tools are already available in the platform.
B ISO 26262, ASPICE SWE.1, ISO/SAE 21434, and ISO PAS 8926 all require a documented, traceable requirements hierarchy as a precondition for certification; without it a safety and security release is not possible.
C It is only needed for ASIL_D projects; QM-only projects can skip structured RE.
D Requirements engineering is optional — projects can substitute it with comprehensive test coverage.

Correct: B. All applicable standards in S-CORE (ISO 26262, ASPICE, ISO/SAE 21434, ISO PAS 8926) require a documented, traceable requirements hierarchy. There is no standards-compliant path to certification without it, regardless of test coverage.

Q2. In S-CORE, any Contributor may write a requirement. Which of the following statements about the approval process is correct?

A Contributors may directly merge requirements without review if the safety attribute is QM.
B All requirements are approved exclusively by Safety Managers.
C Stakeholder and Feature requirements must be approved by the Project Lead; Component requirements must be approved by a Committer.
D Requirements are approved by the Feature User because they are the primary consumer.

Correct: C. The approval authority depends on the requirement level. Project Lead approval is required for Stakeholder and Feature level (visible to all platform users); Committer approval is sufficient for Component level (implementation-specific). Safety and Security Managers provide support but do not hold the approval role.

Q3. A requirement states: 'The platform shall support JSON-based configuration.' At which level does this belong, and why?

A Component Requirements — because it describes a concrete implementation detail.
B Stakeholder Requirements — because it describes a platform-level capability at high abstraction, without specifying how any component implements it.
C Feature Requirements — because JSON is a specific technical format.
D Process Requirements — because it describes a process constraint.

Correct: B. Stakeholder Requirements describe what the platform must contain from the customer's perspective at the highest abstraction level. This requirement names a platform capability without specifying which component implements it or how — that decomposition happens at Feature and Component levels.

Q4. An S-CORE component is released for integration into a vehicle OEM project. The OEM needs to know the boundary conditions their application must satisfy for the component to behave correctly under safety constraints. Which S-CORE work product delivers this information?

A wp__requirements_comp (Component Requirements)
B wp__requirements_feat (Feature Requirements)
C wp__requirements_comp_aou (Component Assumptions of Use)
D wp__requirements_proc_tool (Process/Tool Requirements)

Correct: C. Component Assumptions of Use (AoU) define the boundary conditions the user of a component must fulfil. They are exported in the Module Safety Manual so integrators can include them in their own requirements management systems, satisfying ISO 26262 and ISO/SAE 21434 requirements for SEooC integration.

Q5. Which values are currently defined for the 'safety' attribute in S-CORE requirements?

A QM and ASIL_B only, because ASIL decomposition is not used in S-CORE.
B ASIL_A, ASIL_B, ASIL_C, and ASIL_D to cover the full ISO 26262 range.
C QM, ASIL_A, and ASIL_B for the subset of ISO 26262 levels used in automotive OSS.
D Safety classification is not an attribute in S-CORE requirements.

Correct: A. S-CORE currently defines only QM and ASIL_B as valid safety attribute values. ASIL decomposition is not applied, so ASIL_A, _C, and _D are not needed. A safety-relevant requirement incorrectly marked QM is a safety defect.

Q6. A developer edits a Component Requirement by changing its description to fix a typo and rewrites one sentence for clarity — the functional meaning is identical. Must the version attribute be incremented?

A Yes — any edit to description requires a version bump.
B No — only functional content changes, or changes to the safety, security, or type attribute, are significant and require a version increment.
C Yes — otherwise child requirement links become invalid.
D No — version increments are only required for ASIL_B requirements.

Correct: B. S-CORE distinguishes significant changes (functional content changes; any change to safety, security, or type attributes) from non-significant changes (typos, layout, notes). Only significant changes require a version bump and trigger re-validation of child requirement links.

Q7. Which of the three auto-generated attributes is populated by scanning source code files for a defined tag containing the requirement ID?

A Derives
B Implemented by
C Verified by
D Status

Correct: B. 'Implemented by' is populated by scanning source code files for a defined tag containing the requirement ID. 'Verified by' comes from test files. 'Derives' is automatically inserted into parent requirements when a child uses 'derived_from'. 'Status' is a manual attribute.

Q8. A contributor wants to create Feature AoU requirements. Compared to a plain Feature Requirements workflow, which additional input is required?

A wp__requirements_stkh (Stakeholder Requirements)
B wp__requirements_proc_tool (Process/Tool Requirements)
C wp__feature_arch (Feature Architecture)
D wp__requirements_inspect (Requirements Inspection)

Correct: C. AoUs at Feature level emerge from the safety concept defined in the Feature Architecture. The architecture defines isolation boundaries and safety mechanisms; AoUs express the conditions that must hold outside those boundaries. Without the Feature Architecture there is no basis for writing Feature AoUs.

Q9. A safety auditor asks how S-CORE ensures that a requirement shown as 'verified by Test_X' in the documentation genuinely corresponds to a test that references that requirement. What is the correct answer?

A The Safety Manager manually cross-checks the traceability matrix against the test repository each sprint.
B The Docs-as-Code build scans all test files for requirement ID markers on every build and regenerates the 'verified_by' links automatically, so the documentation can never show a test link that does not exist in the codebase.
C An external ALM tool is synchronised monthly to keep the traceability matrix current.
D Developers are required to update the traceability spreadsheet whenever a new test is added.

Correct: B. The 'verified_by' attribute is auto-populated on every docs build by scanning actual test files. The traceability matrix is therefore always regenerated from real artefacts — it cannot be manually falsified, forgotten, or allowed to drift. This is a key argument in the S-CORE safety case for requirements coverage.

Q10. A new feature is being specified. The correct end-to-end flow in S-CORE is:

A Write Component Requirements first to anchor implementation, then derive Feature and Stakeholder Requirements bottom-up.
B Write Stakeholder Requirements first, then derive Feature Requirements, then derive Component Requirements top-down, linking each level to its parent with a versioned derived_from reference.
C Write Feature Requirements first, then both Stakeholder Requirements and Component Requirements independently.
D Only Stakeholder Requirements and Component Requirements are needed; Feature Requirements are optional in S-CORE.

Correct: B. S-CORE follows the standards' top-down derivation model. Stakeholder Requirements describe what the platform must contain; Feature Requirements break this down to integration level; Component Requirements specify individual component behaviour. Each level links to its parent using a versioned 'derived_from' reference. Process Requirements are a separate, parallel concern derived from the process description, not a step that precedes stakeholder requirements.

🏆

Requirements Engineering Certified

You have successfully passed the S-CORE Requirements Engineering Training.

S-CORE Requirements Engineering Training — Eclipse Foundation

Eclipse S-CORE Training Program ·

← Module 4: Workflows and Work Products