After baseline approval on a predictive park-renovation permitting system, a council rule change requires new fields. What BA responsibility often applies?
Select an answer to reveal the explanation.
Short Explanation
Baselined requirements are like sealed blueprints—when the council changes the rules, you file a controlled change, not a quiet sticky note. Predictive BA stays tied to that change process.
Full Explanation
After baseline approval on a predictive park-renovation permitting system, a council rule change that requires new fields triggers BA responsibility to own or support formal change-controlled amendments to the baselined requirements. Predictive baselines are not frozen forever; they change through controlled process so impact on design, tests, and schedule remains visible. Civic rule changes still demand auditability when they alter approved scope.
Silently editing the live BRD without change records fails conceptually because mandatory rules do not authorize silent baseline corruption; they authorize a controlled change. Telling developers to code the fields and update documents only at closeout fails because late documentation breaks traceability and verification during the project. Converting the entire project to Kanban so change control is unnecessary fails because switching life cycle to avoid governance does not erase the need for controlled requirements changes on a baselined predictive effort.
Exam caveat: Baselined predictive requirements change through change control, even when the trigger is a mandatory council rule. Operational check: open a change request for the new permitting fields, assess impacts on design, tests, and schedule, update the baseline after approval, and link new tests before treating the fields as Ready for release.