How should you handle changing requirements?
During software development, users may discover a missing step or find that the original approach does not suit their work. Before adding work, however, both sides should agree what will change, whether it will cost more and how it will affect the schedule.
This article follows a hypothetical delivery-address change from the initial request through to checking the update. It shows how business and development teams can agree what to do, who decides and when the request can be considered complete.
1. Understand what needs to change and why
When a software change is requested, both sides need to understand the problem users face and what they want to change.
For example, staff create an order, a manager approves it and the warehouse prepares the goods. During testing, sales asks for a “reapprove” button because customers sometimes change their delivery address after approval. The questions to resolve are when an address can still be changed and how the warehouse will receive the new address. Adding a button will not resolve the problem until that process is agreed.
Next, compare the request with what was previously agreed. If the software was meant to handle this situation but cannot, investigate and correct the unmet requirement. If it is a new need, agree what additional work is involved. If the documents are unclear, settle the interpretation before discussing time and cost.
Once the requirement is clear, developers can identify the updates needed and check whether they affect other functions or data.
2. Identify what needs updating when requirements change
For the address change, agree how each situation will be handled. Before the goods are handed to the carrier, for example, sales submits a change request and the warehouse waits for address confirmation before continuing. After handover, the transport contact handles the request. The business needs to confirm whether this approach fits its actual operations.
Using the agreed process, developers check the on-screen address, dispatch note, warehouse notification and data sent to the delivery service to identify what needs updating. If the screen shows the new address but a printed note still shows the old one, the goods may be sent to the wrong place. The review must cover the related information and processing steps, as well as the “reapprove” button.
Also clarify whether the new rule applies only to orders created after the update or includes those awaiting dispatch. If existing orders are included, developers must examine the stored data and how those orders will move into the new process. Staff also need instructions before using it. All of this work belongs in the time and cost estimate.
A clear requirement gives developers a stronger basis for identifying the necessary changes. For guidance on preparing that information, see What Is Requirements Analysis? A First Step Toward Clearer Development.
3. Agree the approach, cost and approval authority
With the necessary changes identified, compare the options. One approach is to build the full address-change request and reapproval workflow. Another is to allow changes only before the warehouse starts preparing the goods. The business could also keep the launch date and temporarily assign someone to receive and handle address-change requests.
Each option has trade-offs. A full workflow needs more design and testing. Restricting when changes are allowed may reduce development effort, but some cases will still need separate handling. A manual workaround avoids an immediate software change, but adds staff work and can lead to missed requests without careful tracking. Weigh the frequency of requests, the consequences of mistakes and the responsible team’s capacity.
Before choosing, ask the partner how long each option would take, whether the cost would change and whether it would affect planned work. If more information is needed for an estimate, agree what must be investigated and when an answer can be given. An early estimate helps compare options; it is not yet a committed completion date.
If scope or cost changes, the revised quote should clearly show what has been adjusted.
What should you clarify in a software quote?
The requester explains why the change is needed, the technical team assesses the work and risks, and an authorized approver signs off the approach, budget and timing. If several departments submit requests, one person should coordinate them and confirm which are approved before passing them to developers. This prevents a suggestion still under discussion from being mistaken for an instruction to start work.
4. Record the decision and check the result
After approval, add the change request to the shared tracking list. Record what will be done, what is excluded, who approved it and the agreed time and cost. Keep the reasons for deferral or rejection too, so everyone can refer back to the decision.
Update the affected requirements, acceptance criteria and user instructions at the same time. Developers, testers and support staff should use the same current version. Agreeing a change in a chat without updating the documents can leave people working to the old requirement.
Agree the checks before developers start making the change. For the address example, test an order that still permits a change, one already handed to the carrier and a request submitted twice. Confirm that the warehouse receives the approved address, the old address is retained while the request awaits approval and repeat submissions do not create duplicate requests. Adapt these scenarios to the approach actually chosen.
When receiving the update, test the agreed scenarios rather than checking only that the new feature is visible.
Software acceptance: What should your business test?
During delivery, track approval, implementation and successful verification separately. For urgent work, record who authorized it, what must be changed immediately and what needs further checking. Once the immediate problem is resolved, someone should still follow the remaining steps through to completion.
After the update goes into use, ask users whether the original problem has been resolved and whether they still need a manual workaround. Record further needs as new requests, noting which earlier change they relate to. This helps the team track completed and outstanding work and explain changes to the schedule or scope.
If requests are coming from several departments, start with a shared list and one coordinating contact. Bring a specific request to Fenix so we can work through the changes needed, their effects on the project and a suitable way to proceed.
