Make it work like the old system. I have worked on three large projects where this was the stated requirements for a system. Each time I wanted more specific requirements. Each time I relented. Each time there was a huge price to pay as a result.
The biggest reason a company will want to use this methodology is because they think it will reduce the time and/or cost to build a software system. All we have to do is make a new system that works exactly the same. Given the same inputs, we should always return the same outputs. So, we have a perfect opportunity here for testing. All we have to do is make sure both systems result in the same output. If there is variance, we simply fix it, and we are golden.
Here are some of the problems that result from this methodology:
- You never know when you are done. Is there some scenario you may have missed? Should we keep on trying, or is this enough testing
- You never know when you are right. When there is variance, you may have done something correctly in the new system, and identified a bug in the old code. How do you know which system is really correct?
- You never know if your logic is correct. For example, there are a number of different values you can add to get to the number 10. If you don’t have business rules, then having the same answer as another system doesn’t mean your software is equivalent.
- You never know how much work is left. When you work from a list of requirements, you can tell how close a project is to completion, because the list of implemented requirements can be measured against the list.
- You produce a system that cannot be easily maintained. You don’t know what the rules were that your system implements. How can you modify or extend the rules, when you really don’t know what they were in the first place.
The point of all this is to emphasize the importance of business requirements. Without rules for how the software should behave you cannot prove you have created an effective solution. Comparing to previous systems may give you a warm feeling, but there is little value beyond that. If you don’t have rules for a previous system, and the company wants to re-produce it, then the best place to start is to reverse engineer the business rules.
I can say that I really enjoyed each of the projects where we modernized and existing system. What was not fun is the amount of time and energy wasted because we didn’t have clear requirements regarding how the system was to work. A word to the wise…always get requirements.
Cheers,
Ben