Let's broaden this question to address the general topic of handling requirements when migrating, converting, or otherwise reengineering an existing application. You likely are not going to try to write a complete software requirements specification, although if your existing documentation is woefully obsolete or incomplete this might not be a bad idea. Instead, focus on what things you are going to keep the same and what things you're going to change during the conversion. These "things" can encompass both requirements and design issues.
One risk with reengineering is "repaving the cow paths," retaining the shortcomings and limitations of the previous system. So a migration project is a good opportunity to look for obsolete or unused functionality that should not be included in the new application. Conversely, study the backlog of change requests to see what new capabilities you should add. Perhaps some maintenance patches that were made over the years can be simplified, streamlined, more smoothly integrated, or otherwise cleaned up.
Business rules may well have changed since the application was originally built. If your business rules are not well documented, this is an opportunity to harvest and record some of that knowledge. I believe the cost of recording knowledge is small compared to the cost of acquiring knowledge, so take the time to write down what you learn. Specify requirements for the converted application to ensure that it properly enforces and complies with all pertinent business rules.
When moving into a new technology, you have an opportunity to revise the system so as to properly exploit the capabilities the new technology provides. This may result in an improved user experience and/or a more robust internal structure. From a design perspective, consider restructuring your data for more efficient queries or to eliminate data redundancies. You might choose to re-normalize some tables, for example, particularly if new data has been added over time in a way that didn't respect good normalization practices.
Nonfunctional requirements are another area to address. This is an opportunity to properly specify, and then design to satisfy, requirements for performance, security, data integrity, and so forth. Usability is, of course, a vital quality attribute. Your new target environment might provide mechanisms for improving usability. Look for ideas from the complaints users have made about the existing application and see if there are places to reduce the steps needed to accomplish a task or to improve screen layouts. Thoughtful consideration of both requirements and design issues during the conversion can lead to a more robust and user-pleasing application.
Dig Deeper on Topics Archive
Related Q&A from Karl E. Wiegers
Requirements development process models and methodologies can be helpful when applied correctly. Expert Karl E. Wiegers explains which models are ... Continue Reading
Effective requirements documentation is essential for any good software project. Expert Karl E. Wiegers explains how to structure your software ... Continue Reading
Agile development methods may have a different approach toward requirements documentation, but following agile doesn't preclude the need for good ... Continue Reading