Question 1 of 4: Part 1: Requirements Engineering Statement/Reason Analysis

Part 1: Requirements Engineering Statement/Reason Analysis (30%)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Approach. Each item is evaluated in two independent steps — is the statement itself defensible under the requirements-engineering literature, and is the reason a factually correct claim — before asking whether the reason logically explains the statement; the combination of the three judgements picks the letter. Per the paper's own Note 1, where a term is genuinely ambiguous the assumption made is stated inline.

1. Item 1 — Answer D. The statement is false: mainstream requirements-engineering practice (Sommerville §4.4; Wiegers) treats prioritization as an ongoing, iterative activity threaded through elicitation, not a step deferred to the very end — deferring it entirely lets low-value requirements consume elicitation budget before anyone screens them out, and it removes the scope-control benefit prioritization is meant to provide during a long gathering phase. The reason, however, is a valid and well-known observation in its own right: understanding of a given requirement genuinely sharpens as stakeholders are interviewed and cross-checked against one another, which is exactly why re-prioritizing periodically (not only once, and not only at the end) is the recommended practice. A true supporting fact does not rescue a false general prescription.
2. Item 2 — Answer D. The statement has the comparison backwards: simple ordinal ranking (rank requirements 1st, 2nd, 3rd, …) is the lighter-weight technique, while ratio-scale methods such as the Analytic Hierarchy Process require pairwise comparison of every pair of requirements (an O(n²) elicitation burden versus roughly O(n log n) for a full ranking) — so ratio-scale prioritization is the one that requires more work, not less (Karlsson, Wohlin & Regnell, "An Evaluation of Methods for Prioritizing Software Requirements"). The reason, though, is a correct and directly relevant fact: a ratio scale does require eliciting "how many times more important" priority fractions between requirement pairs, which is precisely the extra elicitation load the (false) statement gets backwards. The reason is valid, in the specific situation of pairwise ratio-scale methods like AHP, even though it does not make the statement true.
3. Item 3 — Answer E. Both clauses are false. Good requirements engineering deliberately does not hold every requirement to the same level of completeness: effort is proportioned to risk, complexity and business value, so a safety-critical or highly novel requirement receives far more elaboration than a routine, well-understood one (Wiegers' "spend your scarce elicitation time where it matters"; agile "just enough" requirements). The reason compounds the error rather than rescuing it — specifying trivial and non-trivial requirements to the same accuracy does not make the best use of spent effort; it is precisely the opposite allocation (proportioning accuracy to risk/complexity) that makes best use of a fixed effort budget.
4. Item 4 — Answer E. The statement is false: a prototype that largely fulfills the requirements is evidence about the concept, not proof about the production implementation, which is normally built differently (different code, different rigour around edge cases, performance, integration and error handling) and must still be verified against the requirements — substituting a prototype demonstration for implementation verification is a recognized anti-pattern. The reason is also false: an integrator that limits its responsibility to prototypes of only a small fraction of the subsystems leaves the integration and verification of everything else with the customer, so the customer's verification risk rises rather than falls. A customer's risk is reduced when the integrator (supplier) accepts more responsibility — for the complete, integrated system and its acceptance testing — not less; narrowing the supplier's commitment shifts risk onto the buyer (Lauesen, Software Requirements: Styles and Techniques, Ch. 1 on project types and supplier responsibility). Neither clause holds, so E.
5. Item 5 — Answer C. The statement is true: precedence (a feature must ship no later than the feature it depends on) and coupling (two features must ship in the same release) are additional constraints on the release-planning combinatorial problem, and adding constraints to a constraint-satisfaction/optimization problem can only shrink or leave unchanged the set of feasible solutions, never enlarge it — so accounting for them does make the solution space of feasible release plans smaller (Ruhe, Product Release Planning). The reason states the opposite relationship ("more constraints → more feasible plans in general"), which is false by the same combinatorial argument, so it cannot be the explanation for a statement it directly contradicts.
6. Item 6 — Answer A. The statement is true: the agile preference for face-to-face communication over documentation is valuable, but wholesale replacement of written specifications does pose real risk — it removes the persistent, reviewable record that written requirements provide, and makes correctness dependent on communication actually happening at sufficient intensity every time it is needed. The reason is true and is exactly the mechanism that produces the risk: if the intensive, sustained availability that face-to-face communication demands is not actually achieved (a stakeholder is unavailable, a conversation is rushed, no one writes anything down afterward), the chance that the requirements process converges on incorrect requirements rises materially. The reason is therefore a valid explanation of the statement, not merely a coincident true fact.
7. Item 7 — Answer C. The statement is true: test-driven development ties every unit of production code to a test that was written from (and therefore traces back to) a requirement or acceptance criterion, so a requirement's satisfaction can be walked forward mechanically from requirement → failing test → passing implementation, which is exactly what "increased traceability" means in practice. The reason is false, and in fact states the opposite of what makes TDD work: test cases in TDD do not merely "capture requirements" in isolation — their entire value for traceability comes from the fact that they are explicitly linked to the design and code that must satisfy them (a red/green/refactor cycle is meaningless without that link).
8. Item 8 — Answer D. The statement is false. On the standard goal–domain–product–design scale of requirement levels (Lauesen, Software Requirements: Styles and Techniques, Ch. 1 and Ch. 3), a domain-level requirement describes the user's work and goals in the application domain without yet deciding how the product will support them, and task descriptions are the characteristic domain-level technique; screens and prototypes are design-level requirements that already commit to a concrete user interface. So when requirements are to be described at the domain level, task descriptions are the more suitable choice and screens/prototypes the less suitable one — the opposite of the statement (screens and prototypes come into their own later, for validating a chosen design and its usability). The reason is valid in some situations: a task description deliberately does not say how the actor achieves the goal with the product (which steps the user does, which the computer does, through which screens), leaving that open for the supplier's design. That omission is true, but at the domain level it is a deliberate strength — it keeps the requirement solution-independent — rather than a reason to prefer screens, so it does not make the statement true.
9. Item 9 — Answer A. The statement is true and is one of the most consistently repeated observations in the non-functional-requirements literature: quality (non-functional) requirements such as usability, security or performance are harder to pin down precisely than data requirements such as "field X stores a 10-digit account number." The reason gives the two textbook mechanisms for exactly why, and both are correct: quality requirements are cross-cutting (a security or performance property constrains many components at once rather than one field or table, per Chung et al.'s NFR Framework and ISO/IEC 25010), and they are typically expressed as a target on a continuous/sliding scale ("as fast as reasonably possible," "highly usable") rather than a fixed, checkable value, which is intrinsically harder to specify unambiguously and verify than a discrete data constraint.
10. Item 10 — Answer A. The statement is true: in requirements engineering a focus group is a structured, facilitated session in which representatives of the different stakeholder groups first describe current problems, then generate ideas for the future system, and finally prioritize the issues — with each stakeholder (or stakeholder group) selecting its own top-priority wishes (Lauesen, Software Requirements: Styles and Techniques, Ch. 8, focus groups). Carrying those per-stakeholder priorities into the requirements is precisely how the analyst makes sure every stakeholder gets something they want from the product, which in turn supports stakeholder buy-in. The reason is true and is the mechanism behind the statement: because the recorded result of the meeting includes a list of each stakeholder's top wishes, the analyst can check that every stakeholder's list is represented in the final requirement set. (A focus group is still a weaker tool than a private interview for extracting one person's detailed, tacit process knowledge, but that is not what the statement claims.)