The airport operations digital ART treats performance, security, and availability as production-only surprises. What built-in quality concern should the RTE raise?
Select an answer to reveal the explanation.
Short Explanation
A runway that looks painted but cannot take a loaded jet is not done. Performance, security, and uptime are part of the product, not a gift you add after go-live. Built-in quality puts those constraints on the work from the start.
Full Explanation
Nonfunctional requirements—performance, security, availability—are built-in quality constraints throughout the PI, not production-only surprises. When an airport operations digital ART treats those concerns as afterthoughts, the RTE should raise them as continuous quality constraints. Claiming NFRs belong only in the annual capital plan removes them from ART design. Claiming they can wait until Release on Demand because they never constrain iteration design is false for airport-facing systems. Capturing NFRs only as optional stretch stories pulled if teams finish early guarantees they lose. Library digital-services reliability depends on refactoring capacity; feature-only plans grow debt that patrons eventually feel as outages and broken search. Exam caveat: some NFRs are validated in specialized environments, but acceptance criteria and tests should still be planned in-PI. Operational check: add explicit NFR acceptance criteria to airport feature definitions and include NFR evidence in System Demos. Require each team to show reserved enabler or refactoring capacity during PI Planning and protect it from last-minute feature stuffing. Hold the civic standard in facilitation notes so the next RTE inherits the same expectation for resident-facing outcomes.