Developing Requirements for Legacy Systems: A Case Study

摘要

Many legacy systems were created without documented requirements. Over the years changes have been made, often without adequate documentation. Software quality suffers as the system becomes more and more complex. This paper describes a case study of bringing requirements management and other related process improvements to a software product, which has been successful for over twenty years.rnEight years ago, we realized that we needed drastic improvements in requirements. It became obvious that just documenting changes to the system by each development team was not adequate. We had cases where one team counteracted changes made by another team in a previous release, causing bugs to reappear.rnThe product utilizes rules based on compliance and regulation from multiple sources; federal, state, and local. The company offers a significant guarantee of compliance and meeting of the regulations. Quality problems represent a significant business liability.rnA cross functional team of management undertook a project to significantly improve processes related to requirements. These included centralizing requirements using a newly purchased requirements management tool and developing guidelines for writing requirements. Much of this paper describes the guidelines that were found useful, as well as some failures. We will show how the implemented process improvements have eliminated the quality problems that were the original impetus for undertaking the project and have improved the overall quality of the product.rnWe will discuss the following, among other things:rn1. The benefits we found from having a centralized repository and how this helped us discover problems in our processes.rn2. How we organized requirements to fit with the existing application.rn3. Prioritization of requirements work and where to focus efforts.rn4. Style. We found that the style appropriate for capturing changes in legal language is different than what worked well to capture enhancements to software behavior and workflow.rn5. How we successfully propagated change to multiple functional teams.