Requirements for Enhancement and Replacement Projects
In short Many projects start from an existing system, not a blank page. In an enhancement project you add features, fix defects or adapt to changed business rules within that system; in a replacement project you swap it for a new custom system, a package, or both. Either way, you must recover what the current system does and decide what to keep.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), ch. 21.
On this page
Key ideas#
What is different about this kind of project#
Wiegers and Beatty list typical challenges: - the change may lower the performance users are used to; - documentation of the current system is thin, missing or out of date; - users who are comfortable with the current system resist change; - you may break or drop a function someone relies on without knowing it; - stakeholders use the occasion to push unrelated wish-list items.
In one case they describe, each version’s specification said, in effect, “same as the previous version, plus these new features”, so the original functionality was never described anywhere.
Familiar techniques, specific aims#
Most requirements techniques still apply, with a twist: - feature tree: what is added and what disappears; - user classes: who is affected, and whether there are new ones; - process models: how the system is woven into current work; - business rules: capture rules that today live only in code; - context diagram or ecosystem map: which interfaces change; - data models: what to migrate, archive or delete; - quality attributes: at least as good as today; - existing specifications: look for broken trace links and obsolete requirements.
Enhancements are also a low-risk place to try a new technique, such as user stories, before using it on a bigger project.
Prioritize against business objectives#
In enhancements, watch for gold-plating (extras nobody asked for) disguised as improvement; in replacements, for scope creep (“since we’re rebuilding anyway…”). Do not carry functions over by default. Ask users whether they actually use a function, and check usage data.
Gap analysis#
Compare the existing and the desired system. For a replacement, the authors sort requirements into four groups: carried over unchanged, carried over with changes, new, and dropped. Then prioritize closing the gaps with the usual techniques.
Protect performance levels#
Beatty and Chen’s key performance indicator model (KPIM) ties business process steps to the measures stakeholders expect to keep or improve. A warning case from the authors: a synchronization job that originally ran in about an hour, comfortably before an early-morning deadline, grew to some 20 hours after a series of “improvements”. Everyone had assumed the time limit, but nobody had ever written it down as a requirement.
Software archaeology#
This is the authors’ term for recovering requirements from the screens, code and database contents of an undocumented system. Always write down what you dig up, or the next team will dig it up again. Weigh the cost of documenting now against the cost of rediscovery later: document the area you are changing in detail, and neighboring areas as you discover their connections. Over time, the system’s documentation improves piece by piece.
Iterate with care#
Enhancements are incremental by nature. A replacement often needs a critical mass of functionality before users can switch, yet replacing a mature system all at once is unrealistic. The authors’ compromise: find a loosely coupled part (in their case, inventory management, about a tenth of the functionality), move it first, and build an interface between the old and new systems.
Adoption and transition#
The bigger the change, the stronger the resistance. Users often insist the new system must do everything the old one did, even things they never use. In one of the authors’ cases, an upgraded document system turned a two-click routine task into three or four clicks; prototype demos could have revealed the problem before release. Plan transition requirements, a category defined by the IIBA: data conversion, training, process changes and parallel running of old and new systems.
Example#
The Workshop, a fictional bike-repair chain, replaces its desktop job-card program with a cloud booking and repair-tracking system.
| Group | Examples |
|---|---|
| Carried over unchanged | Job card with bike details and work done |
| Carried over with changes | Customer lookup by phone number, now also by email |
| New | Online booking; SMS status updates |
| Dropped | Printed daily schedule (managers confirm nobody uses it) |
A measure to protect: the front desk can check a bike in at least as quickly as with the old program. The business analyst times check-ins now to set the baseline. Spare-parts ordering is only loosely coupled to the rest, so it moves first.
Checklist#
- Business objectives filter every proposed addition.
- Existing functions are kept only if someone actually uses them.
- Requirements are sorted into unchanged, changed, new and dropped.
- Today’s performance levels are measured and written down as requirements.
- Rules and requirements recovered from the old system are documented.
- A loosely coupled first release is identified.
- Transition requirements cover data, training, process changes and parallel running.
- Users see prototypes before release.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 21 (including the authors’ references to Beatty and Chen and to the IIBA).