# Software change request template

Copy this into your existing tracker or shared document. Replace each bracketed field.
Adapt the commercial and decision fields to the agreement and authority on your project.

## Blank record

- Request ID / revision: [reference]
- Project: [project]
- Requested by / date: [person and date]
- Decision owner / decision needed by: [authorized role and date]

### Agreed baseline

- Scope document / version / section: [stable reference]
- Existing deliverable and acceptance criteria: [current agreement]

### Proposed change

- Requested outcome: [the job the client needs to complete]
- Add or change: [bounded work]
- Remove, if proposing a scope swap: [deliverable and criteria to remove]
- Keep outside this request: [exclusions]

### Impact assessment

- Affected screens, data, permissions and interfaces: [effects]
- Implementation, testing and documentation effort: [assessment and assumptions]
- Dependencies / unknowns / assessment owner: [open questions and owners]
- Commercial impact / agreement reference: [agreed fee, credit, or other treatment]
- Current delivery commitment: [date or milestone and conditions]
- Proposed delivery commitment / assumptions: [proposed date and dependencies]

### Review criteria

- Proposed acceptance criteria and exclusions: [observable conditions]
- Expected review evidence / client reviewer: [test data, expected results and reviewer]

### Decision

- Outcome: [approve / decline / defer / approve scope swap]
- Exact request revision and selected option: [reference]
- Decision maker / date / response reference: [actual decision evidence]
- Conditions or reason: [record]
- Revisit trigger and owner, if deferred: [condition and person]

### Delivery handoff

- Revised scope and acceptance criteria version: [reference]
- Linked implementation work / delivery owner: [reference and person]
- Submitted build or commit / review evidence: [references]
- Acceptance outcome / reviewer / date: [actual review record]

## Fictional worked example: CR-014 revision 2

This project, its identifiers, estimates and scenario are illustrative. This is not a
customer result, a product screenshot or evidence of available ProjectHubs functionality.

### Request and baseline

- Project: Wholesale order portal.
- Requested by: Client operations lead.
- Decision owner: Client owner. Decision needed before implementation is scheduled.
- Baseline: Scope S3, orders-list section.
- Existing work: Orders list, date/status filters, saved filter presets. Organization-scoped access.
- Requested outcome: Prepare a weekly order report from filtered orders.

### Proposed swap

- Add: A CSV export of the current date/status-filtered result, up to 5,000 rows.
- Columns: Order ID, order date, status and total.
- Remove from this release: Saved filter presets and their acceptance criteria.
- Retain: Basic date and status filters and the organization access boundary.
- Exclude: Customer contact details, scheduled exports and accounting integrations.

### Assessment

- Estimate: 2 working days implementation + 1 testing + 0.5 documentation/review preparation.
- Interpretation: 3.5 person-days; not an automatic calendar extension.
- Dependencies: Permission model, agreed date/time-zone boundary, representative review data,
  reviewer availability and remaining effort on presets must be checked.
- Security and operations: Engineering assessment still required; this example is not a full
  technical specification.
- Commercial impact: Must be agreed and recorded for an actual project; no amount is assumed.
- Delivery date: Confirm after the swap's remaining work and dependencies are assessed.

### Proposed acceptance criteria

1. Prepared test data produces exactly the rows matching selected date and status filters.
2. An authorized operations user receives the four agreed columns. A role without export
   permission cannot download the file.
3. The cross-organization test returns none of the other organization's orders.
4. An empty result produces headers only. A result above 5,000 rows asks the user to narrow filters.
5. Review evidence names the tested build, filter settings, expected row count and sample file.

### Illustrative decision and handoff

In the article's scope-swap branch, the client owner approves revision 2 after capacity,
commercial treatment and the review date have been agreed. In a real record, attach the actual
response and date here. Revision 1 added export while retaining presets; it is not the swap.

- Scope S4 adds the export criteria and removes saved-preset criteria from this release.
- Implementation work links to CR-014 revision 2 and S4.
- Deferred presets get an owner and revisit condition outside the current commitment.
- Build B17 fails the status-filter criterion; record the failed review and request correction.
- Build B18 is submitted with revised evidence against S4; the reviewer records its outcome.

Keep original decisions and review records available when a revision replaces them.