Integrating AI Tools Into the Full SDLC

Draft a project charter for the AP automation initiative.
Context: [paste project context]

Include: problem statement, business objectives (measurable),
scope boundaries, key stakeholders, success metrics,
key assumptions and constraints.
Keep it to one page. Tone: executive audience.

Here are all the requirements gathered from stakeholder interviews
for the AP automation project: [paste list]

Categorize these requirements:
- In Scope: core functionality for initial release
- Out of Scope: confirmed not in this release
- Deferred: not in initial release but planned for Phase 2
- Needs Clarification: scope not yet agreed

Criteria: prioritize requirements that reduce manual effort
for the AP team, support compliance, and integrate with SAP.
Flag the top 5 requirements that will generate the most debate.

Review these acceptance criteria for the following user story:
[paste story and criteria]

Check whether each criterion is:
- Specific (not vague like "should perform well")
- Measurable (can be pass/failed by a tester)
- Covering the happy path
- Covering the error path
- Covering at least 2 edge cases

Rewrite any criteria that fail these checks.

Here are the functional requirements for the invoice
approval workflow: [paste]

Derive UX requirements that a designer should know:
- What information must be visible at each step
- What actions must be available at each step
- What error states must be communicated to the user
- What the user must be able to do without navigating away
- Accessibility requirements based on the user population
  (finance staff, range of technical comfort levels)

A developer has asked: "For FR-12 (auto-route invoices under
$5,000), what should happen if the invoice is for $4,999.99
and the vendor is flagged in our fraud watch list?"

The requirements don't address this. Help me draft a response that:
1. Acknowledges this is a gap in the requirements
2. Proposes a reasonable default behavior
3. Identifies which stakeholder should confirm the correct behavior
4. Adds this as a business rule to the requirements document

The following business rules have emerged through development:
[paste list of rules that emerged from developer questions]

Format these as a business rules register:
- Rule ID
- Rule description (plain language)
- Source (who confirmed this rule)
- Condition (when the rule applies)
- Action (what happens when the condition is met)
- Exception (any known exceptions to the rule)

Here is user story US-14 with acceptance criteria: [paste]

Generate test scenarios for QA, covering:
1. Happy path (standard successful workflow)
2. Boundary conditions (values at the edges of valid ranges)
3. Error conditions (invalid inputs, missing required fields)
4. Permission scenarios (different user roles attempting the action)
5. Performance scenarios (high volume, large attachments)

Format: Test ID | Scenario | Input | Expected Result | Pass/Fail

Here is our full requirements list (FR-1 through FR-24)
and here is the QA team's test plan: [paste both]

Identify:
1. Requirements with no test coverage
2. Requirements with only happy-path coverage (no error/edge cases)
3. Business rules not represented in any test scenario

Create a UAT test script for the accounts payable team to
use when validating the new invoice processing system.

The script should:
- Be written for non-technical finance staff (no system terminology)
- Cover the 8 core workflows defined in the requirements
- Include clear step-by-step instructions for each scenario
- Include a feedback section after each scenario (works/doesn't work/partially works + comments)
- Take no more than 4 hours for a tester to complete all scenarios

The AP automation system went live 90 days ago.

Original business objectives:
- Reduce invoice processing time from 8 days to 2 days
- Eliminate manual data entry errors
- Support compliance with the new $50k CFO approval rule

Generate a benefits realization review template that:
1. Measures actual vs. target for each objective
2. Identifies factors that contributed to over/under-achievement
3. Documents lessons learned for future projects
4. Recommends any Phase 2 requirements that should be prioritized