NivaarExam PrepOfficial exam papers ↗

19-Soft-A5 Requirements and Specifications · Undated paper

Question 8 of 8: Requirements Management and Evolution

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

National Exams, May 2019 — 04-Soft-A5, Requirements and Specifications (open book, no calculator, 3 hours, 75 points total across 8 questions).

Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 4 (Requirements Engineering) and Ch. 5 (System Modeling – use cases); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 8–9 (Requirements Engineering, Requirements Modeling); SWEBOK v4, Requirements Engineering KA; ISO/IEC 25010 (SQuaRE) for the non-functional quality model used in Question 4; RTCA DO-178C for the avionics certification context in Question 4(iii).

Question 8: Requirements Management and Evolution (5 points)

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.

Generally, no — once a request enters formal requirements management (logged, assessed for impact, prioritized, and tracked to resolution), it should be attributed to a named requester, not submitted anonymously. Requirements management depends on being able to evaluate a change request against the requester's role and authority (is this a decision-maker whose request carries weight, or an unaffiliated party with no standing to ask for it), to follow up with clarifying questions when the request is ambiguous or incomplete, and to weigh it against other, competing stakeholders' requests when resources force a trade-off — none of which is possible if the requester cannot be identified or contacted. A formal change-control process (e.g. a change control board assessing cost, risk, and schedule impact) also needs an accountable requester of record so the rationale behind an accepted or rejected change remains traceable months or years later, which matters directly for audit and for future maintainers trying to understand why a requirement exists in its current form. The one legitimate case for anonymity is an informal idea/suggestion channel used purely to surface ideas without fear of political reprisal (for instance, a junior team member reluctant to publicly criticize a senior stakeholder's original requirement) — but such a suggestion should be re-attributed to a sponsor, or explicitly adopted by the analyst as their own recommendation, before it is allowed to enter the governed, traceable change-request backlog. There is also a practical, non-governance reason to prefer attribution: a named requester can be brought back into the loop when the impact analysis raises a question the original request did not anticipate (a proposed change conflicts with another accepted requirement, or its cost/schedule impact is disproportionate to the value described) — an anonymous request has nowhere for that follow-up conversation to go, so it either stalls the change-control process entirely or forces the analyst to guess at intent on the requester's behalf, both of which are worse outcomes than simply asking the requester to sign their name to a change they are asking the whole project to absorb.

Back to the paper →