Bug vs Change Request: Five Software Delivery Examples

A bug report says the software behaves incorrectly. A change request proposes different behaviour. To classify a client request, compare the observed result with the agreed scope and acceptance criteria. If the evidence leaves that comparison unresolved, record a clarification before committing to a fix or an addition.

This guide works through five fictional requests for an orders portal. Use the downloadable worksheet to record the basis for each classification and the next action. A request can contain both a defect and an enhancement.

Start with the agreed behaviour

Open the approved scope revision, the relevant criterion and the submitted build. Keep the client's original message alongside them. Ask what the user did, what happened and what result the agreement supports.

For this delivery review, use these working categories:

• Bug: evidence shows a failure to meet an applicable requirement. Record the expected and actual results, then investigate the correction.
• Change request: the desired behaviour would alter the approved baseline. Assess its impact and obtain the appropriate decision before adding it to the commitment.
• Clarification needed: the relevant requirement, evidence or interpretation is missing or disputed. Name the question and the person who will resolve it.

The Association for Project Management's change-control guidance describes evaluating proposed baseline changes before a decision and updating the plan after approval. That supports keeping the original agreement available throughout this assessment.

Acceptance criteria help make the comparison observable. NASA's software acceptance guidance explains why teams and customers should define the criteria used to evaluate software work products. The examples below apply that principle to an ordinary client project; they do not claim compliance with NASA requirements.

Five requests for the same CSV export

All identifiers, data and results below are fictional. The wholesale orders portal uses scope S4, approved through CR-014 revision 2. It includes a CSV export with order ID, order date, status and total. The export must apply the selected date and status filters, enforce the agreed access rules and cap results at 5,000 rows. Saved filter presets were deferred in the scope swap. Contact details and scheduled exports remain outside S4.

This is the same scope-swap branch used in our software change request template. The examples are self-contained so you can use the worksheet on another project.

1. The export ignores the status filter

The client selects paid orders. The prepared data contains eight paid and four pending orders within the selected date range. Build B17 exports all twelve.

Classification: bug. S4 requires the file to match the selected status. Record the filter settings, prepared data and sample file against B17. The discrepancy is four pending rows in a result that should contain only the eight paid rows.

Create correction C-01 against that criterion. After a corrected build is submitted, repeat the affected checks and retain the B17 failure. The client sign-off checklist carries this example into a B18 review and a recorded acceptance decision.

2. The client asks for customer email addresses

The exported rows match the filters. The client now asks for an email column so operations can contact buyers from the file.

Classification: change request. The four approved columns exclude contact details. Record the proposed fifth column separately. Assess who could download it, which contacts it would expose and what review evidence would be needed. Estimate the work after those questions are clear.

The client owner may approve, decline, defer or trade scope under the project's agreed process. Preserve S4 until a decision changes it. A useful enhancement still needs a delivery decision.

3. Orders near midnight fall on a different day

The client says an order placed late in the evening is missing from the selected day. The analyst finds that S4 says “selected date range” but does not identify the time zone or day boundary. The screen and sample file alone do not establish which interpretation was approved.

Classification: clarification needed. Check referenced requirements and earlier decisions first. Record the order timestamp and the time zones used by the screen, stored data and export. Ask the delivery lead and authorized client representative to agree which day boundary applies.

If another applicable requirement already defines it, compare B17 with that rule and classify the result. If the baseline leaves it unresolved, record the agreed interpretation and assess its impact. Clarification may reveal a specification defect or require a baseline change. Keep the original wording and the later decision visible.

4. The review account cannot download the file

The client reports that the export button fails for a review account. S4 permits operations users with export permission. The reviewer used a read-only account, and the observed response is access denied.

Classification: review setup issue on the available evidence. Repeat the check with an appropriately authorized test account and confirm that the read-only account remains denied. Record the account's role and permission state using approved test references.

If an authorized account also fails, investigate a bug. If the client wants read-only users to gain export access, assess that permission change separately. Avoid granting broader access just to make a review pass.

5. One message asks for a fix and a nightly export

The client writes, “The paid filter is still wrong. Please fix it and email the export to us every night.”

Classification: split the request. Link the filter failure to C-01 and its reproduction evidence. Create a separate proposed change for scheduled delivery. Scheduling adds questions about recipients, delivery failures, access and which filters apply to each run.

Assign each part its own owner and next action. The correction can proceed through the agreed defect process while the proposed addition is assessed. Approval of the correction does not settle the nightly-export request.

Copy the classification worksheet

Use one worksheet per issue you can assess independently. It includes a blank record and completed versions of the five examples.

Download the editable bug and change request worksheet.

REQUEST CLASSIFICATION 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:

Leave an unanswered field visibly unresolved. “Cannot reproduce yet” describes the current evidence; it does not establish that the reported behaviour is correct. Agree the next investigation step and keep the report available.

Agree the next action before discussing delivery

Reply with the requirement, the observed result and the proposed action. For the filter failure, a useful response is: “S4 requires the selected status filter. The B17 sample includes four pending rows. We have recorded C-01 for correction and will confirm the review date after assessment.”

For the email column, say: “S4 includes four columns and excludes contact details. We have recorded your proposed email column for impact assessment. Please confirm which roles need the information and how they will use the file.”

Classification helps route the work. Prioritize separately using the actual impact and the project's support arrangements. Treat suspected data exposure or other urgent incidents through the agreed incident process while the assessment continues.

Keep fees, warranty coverage and delivery commitments tied to the actual agreement. The label alone does not determine them. A change request also remains a proposal until the appropriate decision is recorded.

Try the worksheet on one disputed request

Choose a request currently described differently by the client and the development team. Put the original message beside the scope revision and the observed result. Complete the classification reason before estimating or promising a date. Your existing tracker and a linked review record may already support this process.

ProjectHubs is being developed around connected delivery records, client requests and human decisions. See the product overview for that direction and confirm available capabilities in a walkthrough.

Bring one disputed client request to a ProjectHubs walkthrough. Use the worksheet to show where the requirement, evidence or decision becomes difficult to trace.