【Summary】
This paper is developed as an example with the development of a communications company, and the selection of software requirements analysis tools and methods are discussed. We believe that software demand analysis is an important step in software engineering, directly related to subsequent engineering, and whether the ultimate product can meet the needs of users, so it plays a key role in the entire project. With appropriate tools, it is possible to significantly reduce errors in the demand phase, or greatly improve the quality and work efficiency of demand analysis. Of course, the selection of tools should be combined with the actual items and fully utilize the role of the tool. This article combines the actual experience of our work, briefly discusses the tools and their applications used in the development system and their applications, and the problems encountered. In the text, it also combines a variety of development methods (ie the traditional waterfall law, information engineering method, object-oriented method), pointing out the deficiencies of various methods, explaining the role of the tools we use on software demand analysis. And the effects of the corresponding result.
【text】
I worked in a city communication company as a technical bone, the leadership commissioned, participated in the development of the company's business report system, I served as the system's demand analysis, overall design and partial code preparation.
As a communication operation company, my company is divided into three levels of headquarters, provincial companies and land-level branches, and all levels of companies have data statements. However, every sub-city branch is different from the place where the business environment is different, and the problems faced are different, so it has formed a distinctive data report (except for the provincial companies reported to the provincial company) . The company is divided into many departments, which also require data as the basis for analysis decisions. Therefore, understanding the needs of various departments become the key to the business report system.
In the process of investigation, I chose a tool called Play Case, you can download freely from the Internet, with a strong function. Let's introduce it to how I use this tool during the needs analysis phase.
The first step is to understand the business organization structure. The company's internal data is actually flowing between sectors. The business department needs to know the traffic volume of each base station in the area, the traffic volume (ie the time and space distribution of traffic). Finance department needs to know the income income, pre-payment income, pre-payment, and other telecom operators. The planning department needs analysis of various departments. The billing department needs to provide the account statistics of this month, and the statistics distribution of the bill (for example, according to the distribution of base station, time period distribution, and according to user category), the pre-deposit statistics, current distribution of arrears, and pay the situation and many more. These sectors often have a large number of unnecessary controversies for data. When using the Play Case tool, first enter these departments into the "Business Department" of Play Case. The receiving point (or send point) of a source of information is constituted; the Play Case represents the relationship between the sectors by illustrating, and converted into a corresponding software structure. In fact, this is a method of modeling, that is, transforming the individual organizations in the business system into various structures in software functions. In this way, in the demand analysis phase, it is clear which departments need data, thereby ensuring the need to analyze the comprehensiveness of the entire company, without ignoring a certain department, leading to incomplete demand analysis.
Step 2, understand the business processes in each business unit, making it a dynamic modeling method through the Play Case to switch into software. On the previous step, track the behavior of each department, enter the Play Case, and describe the processes in a formal language. For complex processes, the tool also provides a further refined method and forms a business flow chart and a business state diagram. According to these flow charts, the state diagram is compared with the business of the actual business unit, or is more consistent. During this step, dynamic modeling technology is used to make the situation of each department business process reflect the operation of the software, thereby ensuring that the description of the operation process in the demand analysis phase can truly reflect the actual situation and prevent it. During the subsequent programming process, a class of cases that may occur often: the programmer has a "closed door" phenomenon because there is no understanding of the business process, and the software is guaranteed from the software functionality. In the third step, transform business data into software data, this step is actually the data needed to collect various departments. Analysis of the data needed by each department; and how the data is converted, this can be classified into the "function modeling". This corresponding data is entered into the Play Case, select the department to which you belong. At this time, the DFD map (data flow chart), the data dictionary, and the province have saved the troubles of manual establishment.
In the fourth step, turn the business data relationship into the data relationship in the software. Here, an object-oriented method is used, and the data required by the business unit is used as an entity, and the data relationship between the department is the relationship between the entity. For example, the user information required by the business department, the user's call, actually the relationship between the entity of the user and the entity of the bill. Play Case provides a component (but I think it is more appropriate) to indicate the corresponding data, and provides the relationship between the three components, the assembly relationship, classification relationship and the connected relationship. These three types of relationships basically reflect the relationship between business data in the real world. For example, the user data in the real world is represented in the Play Case, the user component can be represented by a connected relationship with the billing component. This method is actually a concept of objects, gathering, inheritance, packaging, etc. in OOA-oriented analysis methods, can better reflect the real business; at the same time, this step is also the overall design database The concept pattern design lays a good foundation.
After experiencing the above four steps, the Play Case tool automatically generates a software demand specifications, a preliminary DFD diagram, and a business flow chart to make the foundation for the next overall design.
With the Play Case tool, the demand analysis can inherit the traditional structured analysis method, and can absorb the advantages of object-oriented design methods. For example, it is reflected in the structure of the business process into a running process, and the business organization is converted into software. During operation, the subdivision and tracking of the complex process reflects the analysis of the analysis of the above-bottom-up decomposition in the traditional approach, which is very helpful for solving the analysis of complex systems.
By using, I think this tool is still very nice. Because it actually combines the following four aspects: software, business, developers and users. For the user, Play Case shows the business process in a graphical manner, enabling the user to understand the operation of the business in the software, provides the basis for the future acceptance software. For developers, developers can make more clear understanding of business processes, and will not happen again. "Because the shutter-made car conditions do not understand the needs of users, the development of products do not meet the needs of users." Therefore, the demand manual provided by Play Case can communicate well between users and developers, so that they can have a common understanding of demand.
After using the Play Case tool, make our demand analysis have achieved good results, not only can automatically provide many results, such as demand instructions, etc. Learning computer, but is very familiar with the company's business); in successive design and maintenance work, we feel a lot of work. Of course, the software tool also has a deficiency, a protruding problem is not flexible, and the entire design has been renewed when the department or organization of one county company changes. Therefore, in the process of improvement, we reserve a number of virtual sectors in the first step to prepare further expansion or changes in the future.
Comment: (1) Some experiences in specific projects do appear to be good. (2) Capture is clearer, compare the process and experience of using Play Case. (3) Define from the tool discussion, the method of demand analysis is not enough. (4) The project is relatively small, and only the reporting system is involved, and the more complex business processes should be analyzed to more fully reflect the role of methods and tools. (This article mainly refers to the paper of Wei Fujian, Guangdong Province)
