Software change requests
Separate defects, clarifications and additions, recording scope, cost, timing and acceptance impacts.
Author：WeTech technical team · Updated： (Hong Kong time (GMT+8))
Compare a request with the agreed baseline, then state its reason, affected features, cost, schedule and testing impact for an authorised decision. Verbal requests should not become implicit commitments. Update requirements and delivery versions after approval, keeping defect correction distinct from paid additions.
When to use this guide
For projects with frequent additions, disputed quotation scope or phased delivery.
Minimum change request fields
| Item | Required content | Decision use |
|---|---|---|
| Reason and baseline | Original need, issue, objective | Defect or addition |
| Impact | Roles, data, screens, interfaces | Dependencies and risks |
| Quote and schedule | Effort, fees, milestones | Approve, defer or exchange scope |
| Acceptance and version | Tests, handover, recovery | Definition of completion |
Classify the request
Failure to meet a clear requirement is a conformance issue; ambiguity needs joint clarification. New roles, rules or integrations may change scope. Use the original version and acceptance conditions to classify the request rather than who requested it.
Compare deferral, substitution and addition
For an addition, explain the options to decline, defer, replace existing scope or expand the release. Include data, testing and training impacts rather than only screen-editing time. A defined authority should approve changes to the delivery baseline.
Keep versions traceable
Link approved requests to requirements, work items, tests and release notes. Before launch, identify included and deferred changes. Data-structure changes need migration and recovery arrangements, and operating instructions must match the production version.
Illustrative scenario
Hypothetical change: a second approval layer affects roles, notifications, tests and documentation. Compare substitution with deferral instead of estimating it as one additional button. No company rate or project result is implied.
Frequently asked questions
Is every change chargeable?
Determine it from the contract and baseline, distinguishing defects from added scope.
Can small changes remain verbal?
Use a brief record, with the owner confirming the change and its impact.
Does agile delivery remove scope control?
Priorities, iteration goals and testable work still need transparent decisions.
Brand and public case scope
WeTech Consulting, also called WeTech or WeTech AI HK, provides AI and IT consulting in Hong Kong. WeProperty HK and WeCredit HK are self-developed products. Their cases support the observable features listed: property, estate and transaction-reference entry points for WeProperty; submission, review and public-data masking for WeCredit. WeCredit is not a TU credit-rating service or a final determination of facts.
WeProperty HK · WeCredit HK (case studies in Traditional Chinese)
Reference sources
Official documents support the technical, risk and measurement concepts. Checklists, estimation methods and illustrative scenarios are WeTech planning recommendations, not official prices or client results. Check the supplier’s current plan and terms. Sources reviewed: (GMT+8)
Related guides
Discuss your project
Share your workflow, systems and goals. We will review scope before discussing deliverables, acceptance and a quotation.
Request an initial consultationExplore this service