On the selection of software demand analysis methods and tools-thesis 3: Application of the Communication Industry

【Abstract]
This article takes the Business Report System Development of a communication company as an example to discuss the selection of software requirement analysis tools and methods. In our opinion, software requirement analysis is an important step in software engineering. It is directly related to the subsequent project and whether the final product can meet the needs of users. Therefore, it plays a key role in the entire project. Using appropriate tools may significantly reduce errors in the demand phase, and greatly improve the quality and efficiency of demand analysis. Of course, the selection of tools should be combined with the actual project to give full play to the role of the tool. Based on our practical experience, this article briefly discusses the tools used for system development and their applications, the principles taken into consideration during the selection, and the problems encountered. This article also compares multiple development methods (traditional waterfall method, information engineering method, and object-oriented method) and points out the shortcomings of various methods, describe the role of the tools we use on the software requirement analysis and the corresponding results.
[Body]
I work in a communication company in a city. As a technical backbone, I was commissioned by the leaders to participate in the development of the company's business report system, I work on system requirement analysis, overall design, and partial code writing.
As a communication Operation Company, my company is divided into three levels: Headquarters, provincial companies, and municipal branches. companies at all levels have data report requirements. However, different local branches in different cities have different operating environments and different problems, as a result, a distinctive data report is formed (except that the municipal branch reports to the provincial company ). The company has multiple departments, which also need data as the basis for analysis and decision-making. Therefore, understanding the needs of various departments becomes the key to the business report system.
During the survey, I used a tool named play case, which can be downloaded for free from the Internet and has powerful functions. The following describes how to use this tool in the demand analysis phase.
Step 1: understand the business organizational structure. The company's internal data is actually flowing between departments. The business department needs to know the traffic volume of each base station in the local coverage area and the traffic volume of the day (that is, the time-space distribution of traffic volume ). The finance department needs to know the telephone bill revenue, pre-payment income, and inter-network settlement with other telecom operators this month. The Planning Department needs the analysis data of each department. The billing department needs to provide the statistical data of the current month and the distribution of phone numbers (for example, distribution by base station, time period, and user type), pre-payment statistics, the distribution of the current total amount of overdue payments, and the amount of reminders. These departments often have a lot of unnecessary disputes over data. When using the play CASE tool, you must first input these departments into the "Business Department" of play case. it forms the receiving point (or sending point) of a source of information. The play case graph shows the relationship between these departments and converts them into the corresponding software structure. In fact, this is a system modeling method, that is, to transform each organization in the business system into each structure in the software function. In this way, in the demand analysis stage, identify the departments that need data to ensure that the demand analysis is comprehensive to the entire company, rather than ignoring a certain department, resulting in incomplete demand analysis.
Step 2: understand the business processes in each business department and convert them into software running processes through play case. This is a dynamic modeling method. Based on the previous step, we track the behaviors of various departments, input them into the play case, and describe the processes in a formal language. For complex processes, the tool also provides further refinement methods and forms a business flow chart and business status chart. The comparison between these flowcharts and status charts and the actual business department's business is quite consistent. In the implementation process of this step, dynamic modeling technology is used to reflect the business processes of each department in the software operation process, this ensures that the description of the running process in the demand analysis phase can reflect the actual situation and prevent the following situations that may occur frequently during subsequent programming: programmers are "Behind Closed Doors" because they do not understand the business process. This ensures the correctness of the software from the perspective of its functionality.
Step 3: transform business data into software data. This step is actually to collect the data required by each department. Analyze what data is required by each department and how the data is converted. This can be classified into "function modeling. Enter the corresponding data into the play case and select the department. In this case, the DFD diagram (data flow chart) is automatically created, and the data dictionary saves the trouble of manual creation.
Step 4: Convert business data relationships into data relationships in software. The object-oriented method is used here to regard the data required by the business department as an entity. The data relationship between departments is the relationship between entities. For example, the user information and user charges required by the business department are actually the relationship between the user and the bill. Play case provides components (but I think the components are more appropriate) to represent the corresponding data, and provides three types of component representation relationships: Assembly, classification, and connection. These three relationships reflect the relationships between business data in the real world. For example, in the real world, user data and user phone fees can be expressed in a link between user components and billing components in play case. In fact, this method draws on the concepts of classes, aggregation, inheritance, and encapsulation in OOA object-oriented analysis methods to better reflect real-world businesses. At the same time, this step also laid a good foundation for the conceptual schema design of the database in the overall design.
After the above four steps, the play CASE tool is used to automatically generate the Software Requirement Specification, initial DFD diagram and business flow chart, laying the foundation for the next overall design.
Using the play CASE tool, demand analysis can inherit the traditional structured analysis methods and absorb the advantages of object-oriented design methods. For example, it can transform a business process into a running process and a business organization into a software structure. During the running process, the subdivision and tracing of complex processes reflect the analysis ideas from top to bottom decomposition in traditional methods, which is very helpful for the analysis of complex systems.
I think this tool is quite good. Because it actually integrates the following four aspects: software, business, developers and users. For users, the play case displays the Business Process in a graphical manner, so that users can understand the operation process of the business in the software and provide the basis for future acceptance of the software. For developers, developers can have a clearer understanding of business processes and no longer encounter "closed doors because they do not understand users' needs, as a result, the developed product does not meet the user's needs. Therefore, the demand statement automatically provided by play case can communicate the understanding between users and developers, so that they can have a common understanding of the needs.
After using the play CASE tool, our demand analysis has achieved good results, not only can automatically provide many results, such as the demand statement; the quality of requirements has also been greatly improved and praised by leaders (leaders are not computer-related, but very familiar with the company's business ); in the subsequent design and maintenance work, we felt that the work seemed much easier.
Of course, this software tool also has some shortcomings. One prominent problem is that it is not flexible enough. When the departments or organizations of a county company change, the whole design should be re-designed. Therefore, in the process of improvement, we have reserved many virtual departments in the first step for further expansion or change.
Comments: (1) there are some experiences in a specific project, and the progress seems to be good. (2) A clear and systematic description of the process and experience of using play case. (3) focusing on the discussion of tools, it is not enough to analyze the demand analysis methods. (4) The project is relatively small and only involves the report system. Examples and analyses of more complex business processes can fully reflect the functions of methods and tools. (This article mainly references the papers of Guangdong Wei Fujian and others)