AI-assisted requirements & scope
A simple request.
Several decisions.
A dashboard request sounds ready to estimate. The notes reveal different expectations. Compare the original with three authored suggestions.
- Surface unclear definitions before implementation.
- Give stakeholders a concrete scope proposal.
- Connect it to observable acceptance examples.
Fictional Harbor & Pine example · Authored draft awaiting review · No live AI or recorded AI output. The sponsor and process owner decide scope and policy; the proposal below is not approved.
Context comes from the sponsor request, two interviews, access constraints, available data and the delivery discussion. View scenario sources.
Feature request
Feature request with AI assistance
A proposal people can discuss
The read-only view could help managers prepare for the weekly meeting while the overdue and escalation policies are worked out. Earlier agreement on definitions and testable scope could reduce avoidable rework; these are potential benefits to evaluate, not measured savings. The sponsor and process owner still need to agree the increment, with access and data owners confirming its boundaries. No delivery date is promised.
Putting this into practice
AI could compare stakeholder notes, expose ambiguity and draft alternatives. People own definitions and priorities. Ordinary software must enforce permissions, filtering and any eventual escalation rules; a generated proposal cannot authorize them.
01 Name the decision owners
Business & operationsIdentify the sponsor, process owner and affected teams. Agree who decides scope and policy.
Technical implementationLink requests, notes and decisions in existing delivery tools. Preserve authors and versions.
02 Compare expectations
Business & operationsReview different meanings of open, waiting and late. Keep unanswered questions distinct from disagreement.
Technical implementationProvide relevant, permitted source notes. Ask for cited gaps and alternatives, treating source text as data.
03 Check data and access
Business & operationsConfirm team visibility, status definitions and what missing dates mean with their owners.
Technical implementationMap available fields and null values. Enforce authorization in trusted code before returning records.
04 Agree the increment
Business & operationsDiscuss the read-only proposal and exclusions. Record what is accepted and what remains unresolved.
Technical implementationVersion proposed and accepted scope separately. Keep unapproved notifications and timers out of delivery.
05 Make behavior testable
Business & operationsReview access, waiting and missing-date examples. Confirm that they describe the intended behavior.
Technical implementationTrace each example to a requirement and decision. Test permissions and filtering with representative records.
06 Review and learn
Business & operationsCheck whether the proposed view helps meeting preparation. Revisit deferred rules through their owners.
Technical implementationRetain change history and regression checks. Evaluate draft quality separately from software correctness.