Use simplified primitive method for Demand Analysis

1 Preface

The demand analysis stage is the most important stage of management information system (MIS) development. The requirement stage of MIS development is to first understand and clarify the user's requirements, and then strictly define the requirement specification for the developed software system [1]. Common Software Requirement analysis methods include data flow-oriented structured analysis, data structure-oriented Jackson, object-oriented, and primitive methods. The concept of the primitive method changes the view of system analysis, design, and implementation in three sequence stages [2]. It changes the traditional top-down development mode and reduces the risk of software requirements, therefore, it has been widely used, especially in software companies dedicated to MIS development in a certain field, such as those dedicated to MIS development. However, during the long-term MIS requirement analysis, the author found that the original method has the following defects:
1) The heavy workload of designing and modifying the prototype increases the system development cost;

2) because the user does not care about or does not understand the concept and implementation of the prototype, and has great expectations, the prototype that differs greatly from the actual system increases the difficulty of communication between the demand analysts and the user; both horizontal and vertical prototypes do not reflect the overall picture of the actual system;

3) software requirements include: functional requirements, interface requirements, performance requirements, environmental requirements, reliability requirements, security and confidentiality requirements, resource usage requirements, software cost consumption, Development Progress requirements, and target requirements [3]. Prototypes in the original method are difficult to express the last seven requirements of the software;

4) The prototype method emphasizes that users and developers constantly modify and supplement the prototype until the user is satisfied. In large MIS Projects with tight time and heavy tasks, this situation is difficult to guarantee, especially when the distance between the user and the Development Unit is relatively long.

Based on the practice of management information system project implementation, this paper proposes a new requirement analysis method-Simplified primitive method. Based on the characteristics of database applications, this method divides requirement analysis into two stages and simplifies the system prototype as a requirement analysis tool.
2. simplified the first phase of Requirement Analysis of the original method

The Management Information System is a database application. Database application requirement analysis should focus on data rather than functions. Therefore, we should first solve "what" and then clarify "what to do" [4]. The first stage is to solve "what", that is, the Project Manager negotiates with the user to determine the technical agreement of the system. Therefore, it can be called the technical agreement stage. The technical agreement shall be signed and stamped by the developer's project manager and the technical director of the user's organization, and shall exist in the form of an attachment to the contract. The main content of the Technical Agreement is: system boundaries, system processing services, interfaces with other systems, project progress control, training arrangements, and technical service commitments.

2.1 system boundaries

The system boundary specifies the scope of operations covered by the system, which mainly involves geographical boundaries (specifying the departments and branches of the system), operator scope (all operator identities, distribution, and general permissions of the operating system are defined) and business scope (specifying the Services processed by the system, especially for edge businesses not processed ).

2.2 System-processed services

The Services processed by the system cover all the Services processed by the system, including descriptions of various services, data sources, and implementation requirements. However, the business requirements are not too detailed and can correspond to a module in the actual system. For example, the management of line equipment in the management subsystem of transmission facilities in power MIS does not describe all functions in line equipment management in detail.

2.3 interfaces with other systems

The interfaces with other systems clearly define the systems, functions, and implementation units of interfaces. In the implementation unit of the interface, it is clear whether it is completed by the developer or by the developer to assist a third party.

2.4 project progress control

Project Progress control specifies the project start, end date, name, completion time, location, completion mark, and division of responsibilities of a specific project. Specific projects generally include: purchase equipment to the site, purchase equipment installation and debugging, complete network wiring, development preparation stage, business demand investigation, system analysis and design, software preparation, on-site debugging, data preparation and input, function validation, trial Run and System Acceptance. The division of responsibilities specifies the work content and cooperation methods of the two parties for specific projects. In the cooperation mode, the personnel organization mode, personnel quality requirements, and provided equipment and places are specified. The name and requirements of the documents provided for the completion of specific projects, such as the network wiring acceptance report and hardware equipment acceptance report.

2.5 training arrangements

Training includes training for operators and system maintenance personnel. The training schedule includes the number of personnel, training content, training time, location, organization method and teaching materials for each type of training, and defines the quality requirements of instructors and trainees, and the level of trainees after the training.
3. simplified the second stage of Requirement Analysis of the original method

If the first stage solves the "what" problem, the second stage solves the "what" problem. The main tasks include requirement investigation preparation, requirement investigation and analysis by the user organization, and Requirement Review.

3.1 requirement survey preparation

Requirement investigation preparation: After the system technical agreement is signed, the system will be carried out in strict accordance with the Technical Agreement. This mainly involves distributing business surveys to user organizations, establishing requirement analysis document prototypes, and establishing system simplified prototypes. After the technical agreement of the system is signed, the business questionnaire form is sent to the user's organization by fax immediately, requiring the user to complete the questionnaire before the requirement investigator arrives at the site. The business questionnaire includes the specific business name, superior business, subordinate business, occurrence conditions, processed data, and detailed processes (processing positions, processing methods, and review details ). The requirement analysis document prototype is a requirement analysis manual written according to the Technical Agreement. Its format is the same as that of the standard requirement analysis manual. The status migration diagram and various table certificates and other unclear content are designed by system analysts of similar systems or based on technical agreements and past experience.
The simplified model of the system is designed in accordance with the requirements of the technical protocol. Simplified models are designed using a Visual Database Programming Language. Generally, database application developers are familiar with PowerBuilder (PB) or Delphi. The main design requirements for simplified models include: 1) fully consider the design and implementation of the system, and do not be out of touch with the actual system; 2) simulate the operating interface of the actual system as much as possible, the operation process is the same as that of the actual system. 3) It can be installed and run on a single machine without being connected to the actual database. 4) the demo data can be stored through text files, standalone databases, or Pb external data source data windows; 5) operations on the interface that are easy to misunderstand or hard to understand, provide instructions in the function help button; 6) detailed descriptions of functions that are difficult to implement or have a large workload on the interface; 7) stable operation, it has lower hardware requirements than the actual system.

3.2 requirement Investigation and Analysis

After confirming the three preparations for the requirement survey, the requirement survey analysis is conducted by the system analysts of the Development Unit to the user unit. The system analysts discuss the business survey form and system simplified prototype with the business supervisor arranged by the user organization, and constantly modify and improve the system simplified prototype and document prototype to form a consensus, the business supervisor is required to sign the requirement analysis statement. The simplified prototype and source code of the final system are kept on the site of the user, so that the operator of the system can further understand and analyze the system until it is finally mastered. It is also helpful to put forward further improvement suggestions. Improvement suggestions can be sent to the Development Organization by email or fax at any time, or the system maintenance personnel of the user organization can modify and simplify the prototype, and then sent to the development organization at any time, this allows developers to modify the system design and coding in a timely manner.

3.3 conduct demand Review

A Requirement Review is generally organized by a user organization and is composed of peer experts, system analysis, design, and testing personnel. The review is based not only on the requirement analysis specification, but also on the simplified prototype of the system. During the review, the simplified prototype of the system is continuously optimized. The purpose of the review is to require the requirement analysis statement to be correct, feasible, necessary, priority attribute, verifiable, and unambiguous [5]. The demand review report, as a supplement and Amendment to the demand analysis, is signed by the owner of both parties and exists in the form of an attachment to the demand analysis manual. It also guides the next system design.

4. Notes

1. This method is suitable for the demand analysis of various MIS Projects and especially suitable for software companies dedicated to MIS development in a certain field. With this method, the more similar projects are developed, the higher the efficiency of requirement analysis.

2. In the demand analysis process, because the design of the system simplifies the prototype and the document prototype, and fully takes into account the design and implementation of the system, it is in line with other requirements analysis methods, the requirements for demand analysts are improved. In actual work, it is generally conducted by senior software analysis and design personnel.

3. This method is not only suitable for MIS software engineering, but also suitable for other large software engineering.

4. Due to the difficulty and importance of the demand analysis work, this method also requires the user unit and the demand analysis personnel to analyze all work content and pay enough attention to it. scientifically arrange the work steps of the demand analysis, some steps can be performed at the same time; all work steps shall not be neglected or neglected.

5 conclusion

At present, the simplified prototyping method has been applied in multiple power MIS Projects, greatly improving the efficiency of demand analysis. Practice has proved that the simplified prototype method has the following features: 1) the simplified system prototype development workload is greatly reduced, and the modification and supplement are convenient; 2) the simplified prototype greatly shortens the distance between the demand analysts and business managers, facilitates communication, and greatly enhances the understanding of the system between the demand analysts and business managers, facilitating the discovery and resolution of problems; 3) simplified prototype design the system design and implementation are taken into account in advance, which greatly reduces the risk of software engineering; 4) simplified prototype increases the awareness of system operators on the actual system, this greatly simplifies the system operation training after the project is implemented. 5) the simplified prototype can directly guide the design and coding of the project and facilitate the organization of system development. This method can also be used in other software engineering, and it is also instructive for the reform of other demand analysis methods.

This article from: http://www.21tx.com/dev/2003/10/18/10080_3.html