Example of Requirement Analysis for software development

Requirement analysis example

The Requirement Analysis of the complete system is too large to be clear. We may wish to find a node to illustrate how to deal with the evolution of various management objectives in the process of demand discrimination research. Due to the length constraints, we can only discuss the problem based on the construction of the proposition framework, rather than going deep into the internal details of the application function.
We can imagine a device fault repair ticket provided by a user. It must include basic information such as the device name, service content, service personnel, time, location, and result. This is not the case in the simple management process. Without using the information system, this management method is only a kind of responsibility record, it is difficult to exert greater information application value.
After the data is incorporated into the system, a series of new application topics will be generated immediately. In turn, the collection process of raw data will bring about a series of changes and influences. We provide various management components related to the business, and then discuss their relevance and change processes.
The functions described in Figure 1-1 include three layers: simple management mode, complex application mode, and advanced application mode. We can try to analyze the differences between these modes in the implementation process.
1.3.4.1 simple mode
• Data Collection: collects data sets that meet simple requirements.
• Maintenance process: the maintenance process of each device can be traced, generally through reports.
• Maintenance Responsibility: Select Service records from the perspective of owner to form special reports.
For simple applications, this is the end. If the user's management goals are not the same, the problems will become complicated. For example, the user needs to further deepen the management objectives, which will lead to a series of problems. If you need to manage the consumption of work hours and raw materials, the requirements may be met through a relatively simple parameter table. If you really want to achieve "cost accounting", it will bring about a series of new problems.
1.3.4.2 Complex Mode
1. support from other data systems: the data referenced here may not be complex, but it is not as simple as a data item to ensure the effectiveness and completeness of the data, instead, it is possible to implement the concept of a sub-system.
• Work-hours: A simple subsystem is required to define a dedicated physical table and service programs to solve a series of problems such as the definition of the job type and the billing standard. If necessary, a table is associated with the personnel table.
• Spare Parts consumables: a complete system consisting of materials, inventory, warehouse receiving, and billing and accounting functions is required.
2. Increase data collection scope: To achieve subsequent management goals, you need to add related data items during the maintenance ticket input process to achieve a more comprehensive data description.
3. establish associations between data: In the process of generating a repair ticket, you must effectively obtain data related to work hours and spare parts consumables, and establish associations between various perspectives for subsequent accounting.
4. cost accounting: related to various parameter tables based on the data on the repair ticket, obtain valid accounting data and complete accounting, form cost accounting tickets and implement storage, support cost query reports from various perspectives if necessary.
This is just a relatively simple statement. In practical applications, it is not difficult to obtain real-time data. More complex problems are reflected in the effectiveness of data. The man-hours pricing system will change at any time, and the cost of spare parts consumables will also change at any time. The most accurate and effective data at any time is generally not as simple as imagined. Although this mode is somewhat complicated, it is easy to implement as long as the idea is clear.
The demand materials only reflect the word "cost accounting", but the resulting changes are very small. The requirement analysis personnel must accurately assess the workload and complexity of user requirements. The experience in this area comes from the experience of the project process, and is based on project abstraction and regular understanding.
1.3.4.3 Advanced Mode
The impact of equipment maintenance on production capacity is a more abstract value evaluation and evaluation. It depends largely on the raw data that can be collected in the historical process. The overall evaluation of historical processes or the prediction of future development trends are the product of the organic combination of objective results and subjective judgment in history. This knowledge system is not a proposition that can be described by structured data. At this time, we can understand the difficulty of implementation and will not continue to discuss its implementation in depth.
We can also analyze the impact of raw data on subsequent applications from Figure 1-1. When the complexity of the system increases, omissions or deviations may occur in the analysis process. Assume that we did not exhaust the data elements of subsequent applications in the process of constructing the original data collection. After discovering data defects in the subsequent design, we will overhead the original design, this rework will affect a series of related functions, which are the important impact of demand defects on the implementation cycle. If such a defect is found in the application process, it will cause more trouble and consume more time. Rework at key function nodes has a major impact on the project process. If the scope of rework is large or multiple times, the project delivery schedule will inevitably be hard to be fulfilled.
Tip: In the project process, how to emphasize the overall goal, system and integrity is not much, because frequent rework is often caused by the importance of these problems and insufficient cognitive level. Therefore, we absolutely cannot adopt a case-based attitude on a node. To avoid repeated rework, you must always have a global view on any node. So far, we will evaluate the role of the original material and find that the proportion of the raw material in the entire demand analysis process must be a relatively small part.