Developing Requirements for Enhancement and Replacement Projects
Most of this book describes requirements development as though you are beginning a new software or system development project, sometimes called a green-field project. However, many organizations devote much of their effort to enhancing or replacing existing information systems or building new releases of established commercial products. Most of the practices described in this book are appropriate for enhancement and replacement projects. This chapter provides specific suggestions as to which practices are most relevant and how to use them.
An enhancement project is one in which new capabilities are added to an existing system. Enhancement projects might also involve correcting defects, adding new reports, and modifying functionality to comply with revised business rules or needs.
A replacement (or reengineering) project replaces an existing application with a new custom-built system, a commercial off-the-shelf (COTS) system, or a hybrid of those. Replacement projects are most commonly implemented to improve performance, cut costs (such as maintenance costs or license fees), take advantage of modern technologies, or meet regulatory requirements. If your replacement project will involve a COTS solution, the guidance presented in Chapter 22 will also be helpful.
Replacement and enhancement projects face some particular requirements issues. The original developers who held all the critical information in their heads might be long gone. It’s tempting to claim that a small enhancement doesn’t warrant writing any requirements. Developers might believe that they don’t need detailed requirements if they are replacing an existing system’s functionality. The approaches described in this chapter can help you to deal with the challenges of enhancing or replacing an existing system to improve its ability to meet the organization’s current business needs.
The presence of an existing system leads to common challenges that both enhancement and replacement projects will face, including the following:
The changes made could degrade the performance to which users are accustomed.
Little or no requirements documentation might be available for the existing system.
Users who are familiar with how the system works today might not like the changes they are about to encounter.
You might unknowingly break or omit functionality that is vital to some stakeholder group.
Stakeholders might take this opportunity to request new functionality that seems like a good idea but isn’t really needed to meet the business objectives.
Even if there is existing documentation, it might not prove useful. For enhancement projects, the documentation might not be up to date. If the documentation doesn’t match the existing application’s reality, it is of limited use. For replacement systems, you also need to be wary of carrying forward all of the requirements, because some of the old functionality probably should not be migrated.
One of the major issues in replacement projects is validating that the reasons for the replacement are sound. There need to be justifiable business objectives for the change. When existing systems are being completely replaced, organizational processes might also have to change, which makes it harder for people to accept a new system. The change in business processes, change in the software system, and learning curve of a new system can disrupt current operations.