Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How to handle requirements when converting an application

A software migration project calls for a reexamination of an application's existing requirements. Expert Karl E. Wiegers explains how to update your requirements.

I have to do requirements gathering of an application which is currently in FoxPro 2.6 and has to be converted into .Net. I will be using a mix of top-down and bottom-up approach to study the requirements. Please advise me what all should be my key focus areas for both the approaches.

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.

Software requirements gathering resources:
Guidelines for handling changes in software requirements

How to document system, software requirements

Ambiguous software requirements lead to confusion, extra work

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

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.