As of 2009, if the application is first developed. More than 80% of software applications are not new. Currently, most applications are substitutes for old or outdated applications. Because these applications are outdated, their written functional specifications are often ignored, and these specifications are also outdated. However, despite the lack of current documents, old applications contain hundreds or thousands of business rules and algorithms, so these business rules and algorithms need to be transformed into new applications.
Therefore, as of 2009, requirements analysis should not only involve new requirements, but also include data mining of legacy code to extract hidden business rules and algorithms. Some tools can do this, and many maintenance workbench can display code and help extract hidden business rules. Although clear requirements are a laudable goal, for software applications with 10000 function points, this goal can only be an extravagant hope. So far, the author has only observed a small project with less than 500 function points. And the initial requirements of the application are clear and unchanged.
For large applications, business requirements are dynamic and cannot be static. Website production Many external events will change the requirements of software applications, such as changes in tax laws, changes in enterprise structure, business process reengineering, mergers and acquisitions. In addition, the development of large-scale applications usually takes several years, which makes the situation more complicated. It is obviously unrealistic for a company to freeze all its business rules just to meet the requirements of a software project. The most typical case is to process the requirements of applications with 10000 function points. It will take several months to collect and analyze the initial requirements. In the subsequent design process, the new demand and change demand will reach about 2% every month. The final total demand will reach 50% of the initial demand. After the release of the first version of the software application. These new and changed requirements should be terminated, and new and changed requirements should be added in subsequent versions after 9-12 months. For a project with 10000 function points, the monthly demand change rate is slightly less than 0.5%, and the cumulative increment does not exceed 10% of the original demand. However, the maximum increment can reach 200%. In the design and coding stages, the average rate of monthly demand changes is between 1% and 3%, and the subsequent change dramas have been added to the later versions.
At the same time, the use of JAD meetings, careful requirements analysis, requirements review and prototype can make the requirements process under the control of technology and management. Although it sometimes takes months or even years to see the results of a project, the success or failure of a large software project is already clear in the requirements phase. Successful projects are more complete and thorough in collecting and analyzing requirements than failed projects. Therefore, there are few successful project changes and few requirements spread. However, since most new applications are the renovation of legacy applications, the requirements should include data mining to extract the potential business rules and algorithms of legacy applications.
