# Bug and change request classification worksheet

Use this record to compare a reported result with the applicable approved requirements.
Keep unresolved evidence visible. Split a message that contains independently assessable requests.
Classification does not itself establish priority, fees, warranty coverage or a delivery commitment.
Keep those decisions tied to the project's actual agreement.

## Blank record

- Request ID / original message reference:
- Project / requester / date received:
- Affected feature / submitted build:
- Approved scope revision / applicable requirement:
- Observed behaviour:
- Reproduction steps / test account role / prepared data:
- Expected result and its source:
- Actual result / evidence reference:
- Missing evidence or conflicting interpretations:
- Working classification and reason:
- Parts requiring separate records:
- Question to resolve / responsible person / response target:
- Next action / owner:
- Delivery impact / assessment still needed:
- Decision reference / decision maker / date:
- Resulting baseline revision, if changed:
- Correction review / build / evidence, if applicable:

## Completed fictional examples

Every identifier and result below is illustrative. These are not customer records or test evidence.
Dates, owners and decisions must be filled from the real project before use.

### Common baseline

Wholesale orders portal, scope S4 / CR-014 revision 2, scope-swap branch.
CSV columns: order ID, order date, status and total. Export applies selected date and status
filters, enforces agreed access rules and caps results at 5,000 rows. Contact details and
scheduled exports are excluded. Saved filter presets were deferred; basic filters remain.
Check the wider applicable requirements as well as the feature acceptance criteria.

### 1. Status filter failure

- Request: Export includes pending orders when paid status is selected.
- Submitted build: B17.
- Requirement: S4 requires rows matching selected date and status filters.
- Setup: Authorized operations test account; eight paid and four pending orders in the date range.
- Expected: Eight paid rows.
- Actual: Twelve rows, including four pending rows.
- Classification: Bug against the status-filter criterion.
- Evidence: Preserve the prepared data reference, filter settings and B17 sample file in the real record.
- Next action: Delivery lead assigns correction C-01 and obtains an assessment before confirming a review date.
- Review: Repeat affected checks on the corrected build; retain the original failed result.
- Decision/date/reference: Record when made; not supplied by this fictional example.

### 2. Additional email column

- Request: Include customer email addresses in the export.
- Requirement: S4 names four columns and excludes contact details.
- Classification: Change request for an additional column and data exposure.
- Questions: Which roles need it? Which contacts may be included? What review is required?
- Next action: Delivery lead assesses access, implementation, testing and delivery impact.
- Decision: Authorized client owner reviews the proposal under the agreed process.
- Baseline: Preserve S4 until a decision changes it.
- Decision/date/reference: Pending assessment and an actual decision.

### 3. Date boundary ambiguity

- Request: An order near midnight is absent from the selected day.
- Requirement: S4 says selected date range; the relevant day boundary is unspecified in this example.
- Missing evidence: Referenced requirements, prior decisions, order timestamp and time zones used by each surface.
- Classification: Clarification needed; final defect/change classification unresolved.
- Next action: Analyst collects evidence; delivery lead and authorized client representative resolve the interpretation.
- Possible outcomes: Existing rule establishes a defect; or unresolved specification needs clarification and impact assessment.
- Record: Preserve old wording and the decision. Name any approved baseline revision.
- Response target / decision/date/reference: Agree and record in the real project.

### 4. Read-only review account

- Request: Review account receives access denied when exporting.
- Requirement: S4 permits operations users with export permission.
- Observed setup: Read-only account without that permission.
- Classification: Review setup issue on current evidence.
- Next action: QA repeats with an appropriately authorized test account and verifies read-only denial remains.
- Reclassification: Authorized account failure needs bug investigation. Broader role access needs separate assessment.
- Evidence: Record test role/permission references; keep credentials out of the worksheet.
- Review build/result/date: Record after testing; this example supplies no authorized-account test result.

### 5. Mixed correction and enhancement

- Message: Fix the paid filter and email the export every night.
- Part A: Link the reproducible filter failure to C-01, using example 1's evidence.
- Part B: Record scheduled export as a proposed change outside S4.
- Questions for B: Recipients, access, filters, delivery failures and review criteria.
- Next action: Assign correction assessment and enhancement assessment separately.
- Decision boundary: Correction approval does not authorize scheduled delivery.
- Owners / response targets / decision references: Assign and record separately in the real project.

## Before sharing

- Confirm scope and build references identify exact revisions.
- Retain the original client message and reproduction evidence.
- Include applicable requirements beyond the short acceptance checklist.
- Give each unresolved question an owner and response target.
- Check that client-facing links are accessible to the intended reviewers.
- Remove internal-only information and use approved synthetic data for examples.
- Keep classifications and proposed actions separate from approvals and completed work.

## Background

- [APM change control](https://www.apm.org.uk/resources/what-is-project-management/what-is-change-control/)
- [NASA software acceptance criteria guidance](https://swehb.nasa.gov/spaces/7150/pages/16450634/SWE-034%2B-%2BAcceptance%2BCriteria)

The worksheet is a suggested delivery practice. It does not claim compliance with either source.