Guidelines for survey and analysis of management information system requirements

51cmm. com Author: Lu linsheng, Xiamen julong Software Engineering Co., Ltd [ 2003/12/01 ]

 

Abstract:
This article is a summary of some experiences in the survey and study of management information system requirements, some of which are my own experiences and some books or articles from experts. I hope to share them with you, it also plays a leading role. If you have any problems, please correct them.
Keywords: Demand, Research
Body:
I. Definition of software requirements
The requirements defined in the IEEE software engineering standard vocabulary (1997) are:
(1) Conditions or capabilities required by the user to solve the problem or achieve the goal;
(2) The conditions or capabilities required by the system or system components to meet the contract, standards, specifications or other formal provision documents;
(3) A document describing the above conditions and capabilities.
Ii. Requirements Analysis
Requirement analysis can be divided into four stages: problem identification, analysis and synthesis, preparation of requirement analysis documents, and Requirement Review, which include the following aspects: determining the desired user categories of the software and obtaining the requirements of each user; understand the actual user tasks and objectives and the business requirements supported by these tasks; the analyst and user information distinguishes the user's task requirements, functional requirements, business rules, quality attributes, recommended solutions, and additional information. The system-level requirements are divided into several subsystems, allocate part of the requirement to software components, understand the importance of relevant quality attributes, discuss implementation priorities, and compile collected user requirements into Requirement Specification descriptions and models; reviews requirement specifications to ensure consensus with users.
Shows the components of software requirements:

Iii. requirement document specifications
A. Three compiling methods
1. Make good use of structured and natural languages to compile text-based documents;
2. Create a graphical model that depicts the conversion process, system status, and changes, data relationships, logical flows, or object classes, and their relationships;
3. Write a description of the formal specifications, which can be defined by a mathematical and precise formal logic language.
Multiple writing methods can be used in the same document. They can be selected as needed or supplemented to provide a clear description of the requirements.
B. Expected results
1. manual process text instructions for various businesses;
2. flowchart of manual handling of various businesses;
3. Manual Handling of input and output forms and data sources for each link in each business;
4. functional division of the target software system (and text description );
5. Description of various business processes in the target software system;
6. Business Process Flowchart (model) in the target software system );
7. Data, data collection methods, and Internal Relationship Analysis between various business processes in the target software system.
8. Target software system user interface diagram, various system logic model diagram and description
C. Recommended document tools
1. For the survey result, see the development document template in the requirement analysis statement format;
2. Organization Structure Diagram and functional module Breakdown Diagram are drawn Using Visio or directly using the drawing tool in word;
3. The business flow chart is drawn using the flowchart template in Visio;
4. Use rose to draw the system Logical Model. Use the UML template in Visio to draw the model;
5. Use the Win95 User Interface Template in Visio to draw the software user interface;
6. The physical data model is drawn using powerdesiner;
D. Requirements document writing principles
1. The sentence is short and complete, with correct syntax, spelling, and punctuation;
2. The terms used are consistent with those defined in the vocabulary;
3. The requirement statement should have a consistent style, such as "system must..." or "user must...", and keep up with a behavior action and an observed result .;
4. Avoid using vague and subjective terms to reduce uncertainty, such as "user-friendly and easy to operate ";
5. Avoid using comparative words, such as "improve". The extent of improvement should be quantitatively stated.
Iv. Task and process of Requirement Analysis
The task of requirement analysis is to use the physical model of the current system (system elements of the system to be developed) to export the logic model of the target system (only describes the functions to be completed and the data to be processed ), to solve the "what" problem of the target system, the task is to describe the functions and performance of the software in depth, and determine the restrictions of the software design and the interface details of the software with other system elements, define other validity requirements of the software, and describe the data to be processed by the software in a step-by-step manner, it also provides a data and function representation for software development that can be converted into data design, structure design, and process design. The user's requirements must be fully understood, but not fully accepted. Only reasonable requirements must be accepted. The vague requirements should be further clarified and then determined whether to adopt them; the requirements that cannot be met must be fully explained to the user. Finally, the software requirements are accurately expressed to form the Software Requirement Specification SRS. Implementation steps

(1) obtain the physical model of the current system: first, analyze and understand how the current system runs, and understand the organization, input and output, resource utilization, and daily data processing process of the current system, use a specific model to reflect your understanding of the current system. This step can also be called "Business modeling". Its main task is to evaluate the user's organization or enterprise and understand their needs and the problems to be solved by the system in the future, create a business usecase model and a business object model. Of course, if the system is relatively simple, there is no need to conduct business modeling in the dango area, as long as you do some simple business analysis.
(2) abstract the logic model of the current system: on the basis of understanding the current system's "How to do", extract non-essential factors and extract the essence of "what to do.
(3) Establish the logic model of the target system: clarify what the target system should "do"
(4) supplement the logic model, such as the user interface, start and end, error handling, system input and output, system performance, and other restrictions.
Each requirement analysis process is as follows:
(1) problem identification: What the target system does and how far it does. Requirements include: functions, performance, environment, reliability, security, confidentiality, user interface, resource usage, cost, and progress. At the same time, establish the communication channels required for requirement investigation and analysis.
(2) analysis and synthesis: Starting from the data stream and data structure, we will gradually refine all software functions and find out the connections between various elements, interface features, and design restrictions, analyze whether they meet the functional requirements and remove unreasonable parts, integrate them into a system solution, and provide a detailed logical model of the target system. Common analysis methods include data flow-oriented structural analysis method SA (data flow diagram DFD, data dictionary DD, and processing logic description) the Entity Relation Diagram ERD that depicts the system data relationship, the Jackson method JSD for data structure, and the Object-Oriented Analysis Method OOA (mainly using UML) for software with Dynamic Time Series Problems, formal technology can be used, including the status transition (conversion) graph STD, Time Sequence Graph, Petri net or Z of the finite state machine FSM. Each Analytical modeling method has its own advantages and limitations. It can be analyzed from different perspectives, so we should avoid having to fall into the mindset and factional struggle in the software demand side method and model, in general, structured methods are used for small and medium-sized software and object-oriented methods for large software.
(3) Prepare the requirement analysis document
(4) Demand Review
(The suggestions and questions for netizens will be answered in the "Lu linsheng" column as soon as possible)

 

5. Requirements for Demand Analysis
1. Data domains and functional domains that must be able to express and understand the problem: the purpose of the system is to solve the data processing problem, that is, to convert a form of data (input, processing, and output) is another form of data. Data domains should include data streams, data content, and data structures. Data streaming data changes through the system. Data conversion is the function or sub-function of the program. The data transmission between two conversions determines the interface between functions. Data content is a data item. For example, a person's data item includes name, gender, and date of birth. The data structure is the logical organization of various data items, such as the table structure, tree structure, and the relationship between data items.
2. The problem must be decomposed and constantly refined by top-down and layer-by-layer decomposition: the functional domain and information of the software can be further decomposed, it can be horizontal decomposition at the same level or vertical decomposition at multiple levels.
3. Give the logical model and physical model of the system: the logical model gives the relationship between the functions to be achieved by the software and the data to be processed. The physical model provides the actual representation of the processing function and data structure.
Vi. Demand Survey Methods
1. Talks and inquiries: raise specific questions around the software objectives;
2. Questionnaire: the written answers carefully considered may be more accurate than the answers in the talks;
3. Collect and analyze the various forms used by the customer, various texts related to work responsibilities, work processes, work specifications, relevant data standards, and business standards;
4. Collect promotional materials, technical materials, demonstration programs or software programs for similar products;
5. Scenario Analysis: use situation analysis to induce users to inform analysts of their needs (this can describe how a current business is done, or how this business is done in the envisaged system );
6. visualization method: knot and scenario analysis, and discuss with customers by drawing User Interface diagrams, business flowcharts, function charts, and time sequence diagrams;
VII. Basic Survey strategies
1. First, determine the user's software development goals, determine the basic scope of the system, and then determine the departments and personnel to be accessed and the businesses to be understood, conduct research within the basic scope;
2. Based on the responsibilities of the Department, find out various existing businesses and the forms/books/documents and reports to be filled in, and find out their data sources and destinations;
3. Take the business as the main line to figure out the process relationship, department involved, and input and output items for each link of each business;
4. Take data as the main line to find out the internal relationships between data collection methods, data flows, and data;
5. Find out which services or data have been built into the system, and whether the relationship between them and the new system is connected or replaced;
6. Consider whether new technologies can improve existing work and whether users' demands can be fulfilled using existing technologies.
8. Structured Method Analysis Steps
1. Draw a data flow diagram. Data Flow Diagrams must be designed to improve gradually;
2. Determine which parts require computer-based and how computer-based (depending on user investment restrictions and technical restrictions );
3. Describes Data Flow details. Large software can use data dictionaries to describe all data elements;
4. Define the processing logic (processing logic: what each processing task does );
5. Define data storage, that is, define the exact content of each storage and its representation (format );
6. Define physical resources: if a file needs to be specified: file name, organizational structure (sorting, index, etc.), storage medium and record; if a database needs to specify relevant information for each table;
7. Determine the input and output specifications, such as the input content, input screen, print output format, and output length;
8. Determine the values required for the hardware, such as input, printing frequency, CPU, record size, data size, and file size;
9. Determine the software and hardware interfaces and environment requirements.
IX,UMLMethod Analysis Steps
The general application system consists of the problem universe, man-machine interface, data management, and task management. In the OOA stage, the problem universe is analyzed, OOA has few or no analysis on problems such as man-machine interfaces, data management, and task management, but remains to be solved in the OOD stage.
1. Investigate and identify system requirements;
2. Problem analysis: the main task is to fully understand the problems in the field and the needs of project investors and users, abstract the needs, and propose high-level solutions );
(1) determine the system scope and system boundaries;
(2) determine system constraints (environment and conditions );
(3) define the operator;
(4) determine the overall requirements of the system (functions, performance, and operation );
(5) determine the system data requirements (name, range, type, quantity, and characteristics );
(6) create a use case model and draw a use case diagram;
(7) Draw the main interaction diagram;
3. Create a static structure model (object class diagram, database model, and package diagram );
4. Create a dynamic behavior model (sequence diagram, collaboration diagram, state diagram, and activity diagram );
5. Establish the system physical model (Component diagram and configuration diagram );
10. enterprise-level Information System Survey and Analysis Steps
An enterprise-level information system focuses on the information system of the entire enterprise. It is a comprehensive information system covering all business areas of the enterprise and adapting to the continuous development of the enterprise. It is a unified and consistent overall data, this improves the overall utilization efficiency of the system.
A. Planning Stage
1. Build a high-level Enterprise Model
(1) investigate the organizational structure and establish an organizational relationship hierarchy chart;
(2) Investigate and classify the tasks, objectives, strategic priorities, and key success factors of an enterprise;
(3) identify the information required for each target and key success factor;
(4) provides the measurement standards for each target;
(5) analyze the potential impact of information technology on enterprise business;
(6) establish a high-level enterprise model (describe the subject domain of Business Processing and Its Relationship, and establish an enterprise initial function level map );
(7) Discuss with the enterprise's top management personnel to supplement and confirm the obtained information and analysis;
2. Break down functions (output: functional hierarchy diagram, functional relationship diagram, and functional/organizational matrix );
3. Perform object analysis (output: High-level object relationship diagram, entity class/information requirement matrix, business function/entity class Matrix );
4. Evaluate the current environment of the enterprise (list of existing systems and data storage, scope of information structure, list of information requirements, organization, and technical environment );
5. Identify and determine the expected data storage and business systems, establish a structure diagram of the business system, and determine and record the business fields;
B. Business analysis stage
1. Determine the business scope, establish an organization, and formulate plans;
2. perform data analysis and create a detailed data model (detailed object relationship diagram );
3. Business Activity Analysis (analyzes business process details, breaks down business processes, analyzes dependencies between processes, analyzes business interactions, and establishes business activity models );
4. Existing System Analysis (operating program decomposition table, data flow diagram, and user view: field set of interest to users );
5. Validation of Business Domain Models (integrity, correctness, and long-term effectiveness)

 

 

 11. survey description and basic problems
Businesses in many industries are composed of a series of links. Some are simple and have only one or two links. Some are complex and have multiple links, which may be cyclical or branching, system software should not only solve the business problems of independent links, but also be able to automatically connect these links. It is hoped that the work done in one link will be automatically used in the next link, this is the most basic workflow requirement. For example, a case is handled by different departments from case taking, case filing, investigation, and prosecution to execution. These links are not independent. The subsequent links should not be earlier than the previous ones, nor should they be delayed too much, because there is a legal time limit and there is a cycle in the process, that is to say, some links may be repeated multiple times, and each department has many different types of processes. Each staff member may have to deal with tasks in multiple links. Therefore, we clarify every link of each business and mainly clarify the following basic problems:
Can every link in each process no longer be broken down?
Who is the owner (responsible) Department of each link in each process?
What are the inputs (projects, formats, methods) and outputs (projects, formats, and methods) required by each link?
What are the changes or relationships between input and output in each link?
What are the sources of input data for each link?
What is the destination of output data in each link?
Are there any national or ministerial standards or other standards for data projects in each phase?
What are the types of data items in each link?
What is the permission of the owner of each link for the purpose of data items in this link? (Can be created, can be deleted, can be modified, read-only ,)
Are there any inspection rules for the input data items in each link? (If not empty)
What are the conditions for a link to the next one?
Is there a time limit between one link and the next link? What is it?
In which business is the collected forms used?
Relationship between multiple tables in a Single Room: inherited? Association?

 12. Demand Management
The demand research and analysis process is a process from rough to fine, gradual and clear, and continuously improved. In the subsequent system design and coding stages, the requirement documents should be constantly improved. Therefore, requirement management is very important. Requirement management includes all activities that maintain the integration and accuracy of requirement conventions during project progress. It is the primary kPa (key process domain) in level 2 of the CMM model. These activities include:
(1) define a requirement baseline (subject of the requirement document );
(2) review the request change application and assess the potential impact of each change, so as to determine whether to implement the change;
(3) integrate demand changes into the project in a controllable manner;
(4) make the current project plan consistent with the requirements;
(5) analyze the impact of changes and negotiate new agreements on this basis;
(6) associate each requirement with its corresponding design, source code, and test cases for tracking;
(7) tracking the demand status and changes throughout the project.

References:
The second edition of practical software engineering, such as Zheng Renjie, Yin renkun, and Tao yonglei
By Soren lauesen, translated by Liu Xiaohui
Software Engineering: Research Methods for practitioners (5th) by Roger S. Pressman
Completed on: November 8, 2003
Author Email: luls@dragonsoft.com.cn or lulsnet@21cn.com
Thank you for your correction.
(The suggestions and questions for netizens will be answered in the "Lu linsheng" column as soon as possible)