How to request a software improvement without leaving scope open

"Let the system send an email when there is an order"

The sentence sounds clear. But who receives the email? For any order or only those above a certain value? What does it say? What if the order is canceled? Every unanswered question is a decision someone else will make, and likely not the way you would have.

Requesting an improvement well does not require programming knowledge. It requires describing the problem and how you will know it is solved.

The seven elements of a good requirement

Problem before solution

"I need a button to export to Excel" is a solution. The problem might be "every Friday I copy the week's orders by hand for the management report." By describing the problem, the developer can propose a better solution, such as an automated report.

Scenarios and acceptance criteria

User stories help describe who needs something and why. Acceptance criteria specify when it is done. A useful format is "Given... when... then...", which uses Gherkin syntax:

Write at least one normal scenario and one exception: what happens if the order is canceled or if a field is missing?

Constraints and out of scope

Constraints prevent surprises: "the ERP cannot be modified", "must work on mobile." The out-of-scope section is the most protective: writing what is not included prevents scope from growing uncontrolled.

Changes

If a new need appears during the work, record it as a change: describe what is added, its effect on effort and schedule, and who approves it. Do not mix it silently into the original requirement.

Procedure

1. Write the problem with a recent real example.
2. Identify users.
3. Describe two or three scenarios, including exceptions.
4. List rules and constraints.
5. Write verifiable acceptance criteria.
6. Declare what is out of scope.
7. Review the requirement sheet with the implementer before starting.

Applied example

How to use the downloadable template

1. Fill in problem, users and scenarios.
2. Complete rules and acceptance with the implementer.
3. Declare what remains out of scope.
4. Record each change with its effect and approval.

Criteria of a good requirement

Complete concise example

Concise example. A fictional company asks "that the system send an email when there is an order." When completing the sheet, the real problem appears: orders from new customers remain unreviewed because nobody is notified in time.

The sheet looks like this. Users: the account manager. Normal scenario: an order arrives from a customer with no history and the account manager receives a notification with the customer name, the amount and the link to the order. Exception: if the account manager does not review it within four business hours, the notification escalates to their backup. Acceptance criteria: the notification arrives in under five minutes for 100% of ten test orders; customers with history do not generate a notification. Out of scope: approving the order from the email and notifications via WhatsApp.

When the commercial area requests also adding orders above a certain value, it is recorded as a change, with impact on timeline and approval by the responsible party. Example invented.

How to review what was delivered

Review the improvement against the acceptance criteria, not against what you remember having requested. Test the normal and exception scenarios with realistic data, note what does not meet the criteria with a concrete example and approve in writing when everything complies.

How to know if it worked

• The supplier can estimate without basic questions.
• Delivery is approved against written criteria.
• Changes are recorded with their effect.

Plan for the first four weeks

1. Week 1: fill in problem and scenarios.
2. Week 2: review with the implementer.
3. Week 3: agree on criteria and out of scope.
4. Week 4: approve the sheet and define change control.

Diagnosis before starting

• Take the last improvement you requested and check if it had acceptance criteria.
• Count how many times it was redone.
• Check whether it was documented what was not included.

A second example, in contrast

Concise example. A fictional company requests a new report describing only the problem: "we don't know which customers stopped buying." The provider proposes an alert instead of a report, simpler and more useful. Unlike the first example, the better sheet left the solution open and closed the problem. Example invented.

What to do when something fails

• If the delivered item does not comply, point out the exact criterion that fails.
• If an unforeseen scenario appears, register it as a change.
• If there is disagreement, revert to the approved sheet.

How to measure it with your own data

• Count how many questions the supplier asked before estimating.
• Record how many times the improvement was redone.
• Note how many changes were requested after the sheet was approved.
• Measure the time between delivery and approval.

Compare these data between an improvement requested without a sheet and one requested with a sheet. If with the sheet there are fewer reworks and approval is faster, the method works. If subsequent changes remain many, the initial scenarios were incomplete: include more users in the next sheet.

Common mistakes

• Requesting a solution without describing the problem.
• Criteria like "works well."
• Forgetting exception cases.
• Not declaring what is out of scope.
• Adding changes without recording them.

Checklist

• Problem described with an example.
• Normal and exception scenarios.
• Verifiable criteria.
• Out of scope declared.
• Changes recorded.