A public hospital IT team is starting a 311 mobile app and finds stakeholder requirements ambiguous. How can AI best help in this SDLC phase?
Select an answer to reveal the explanation.
Short Explanation
Fuzzy requirements sink apps. Use AI to turn vague asks into crisp, testable statements—then put those drafts in front of stakeholders before anyone codes the wrong thing.
Full Explanation
In the requirements phase of the SDLC, AI best helps a public hospital IT team building a 311 mobile app by clarifying and rephrasing ambiguous stakeholder asks into testable statements for human review. Fuzzy requirements produce wrong builds; turning “make it easy for residents” into measurable acceptance criteria—authentication paths, ticket categories, SLA timers, accessibility targets—gives stakeholders something concrete to accept or reject before design and code harden the wrong interpretation. AI accelerates that translation work while ownership of scope remains with the project team and business sponsors.
Deploying the unfinished app to all residents immediately fails because early discovery ambiguity is not a release criterion; shipping incomplete software to the public creates support debt and trust harm. Skipping requirements to jump straight to production database design fails by concept: schema choices encode assumptions about entities and workflows that should follow clarified requirements, not precede them. Letting the model invent clinical diagnosis features outside the 311 scope fails because generative expansion can drag a civic service request app into regulated clinical territory the hospital never authorized.
Exam caveat: AI-clarified requirements can still smuggle in assumptions from generic industry patterns that do not match this hospital’s triage or privacy rules. Stakeholder review must explicitly reject out-of-scope clinical features and confirm local policy constraints.
Operational check: produce a short list of AI-rephrased, testable requirement statements; walk them with service-desk and clinical-adjacent stakeholders; mark each accepted, revised, or rejected; and only then open design and database work against the approved set.