Requirement Analysis of Software writing

Requirement Analysis of write software

Demand always answers the question of "what is needed", and implementation always solves the question of how to achieve it. The requirement is to achieve the goal, that is, to determine the path and method to reach the destination in advance. To avoid going astray, we must avoid misleading requirements analysis errors.
First, make it clear that "analysis" is an active thinking process, rather than a summary process. Many demand researchers believe that simply summarizing the original requirements put forward by users is a misunderstanding.
For different purposes, the requirement document may be written in different ways.
1. pre-sales proposal: describes the key functions provided to users before project signing.
2. Demand Analysis Report: defines the boundaries of design tasks for the basic content of design tasks agreed by both parties.
3. Requirement Specification: provides a complete description of the system's design objectives and functional systems, and adds support and constraints for the design process based on the requirement report.
The first two schemes have little impact on the implementation of the project. The Requirement Specification Description is often an important document to be referenced in the system architecture design. This is the topic to be elaborated on.
During the analysis process, the following problems are frequently noted.
1.3.1 grasp the overall situation
Both the origin and purpose of demand are based on the specific application of their respective jobs. In the demand research phase, the staff in each position and their related management personnel can reflect the situation in the traditional work mode. Each job is only a node in the overall process. The roles of the data generated on the node in subsequent applications may not be clear. The internal relationship between such existence and the job process is an important element that we need to truly understand.
The limitations of this requirement description are obvious, especially in enterprises with relatively low management level. If we rely only on these materials with inherent limitations to construct the design objectives of the system, it would be a natural outcome to eventually fall into the misunderstanding guided by users, this is certainly not the expected outcome.
The process of requirement analysis is to associate the requirements of various positions through systematic conception, which is the key to system construction. From the very beginning, we have to look down on the specific needs of each specific position at the overall height, we need to track and analyze the environment and objectives of each specific requirement in the entire system. If we can always find breakpoints or blind spots in the management process during system analysis through surface phenomena, we may block the inherent defects in the raw materials.
The management process is a complete system, and the demand materials are only a specific reflection of the management in various business positions. By stacking materials, we can only reflect the surface of transactions, and cannot fully and accurately reflect the overall management objectives. Therefore, we need to use materials to understand the specific connotation of the Project. materials are only a way to understand the management objectives, and the requirements described by users cannot be regarded as the true goals of design implementation.
After fully understanding and understanding the management objectives, we should form an overall goal and implementation framework of the system structure, and then look back at the rationality and necessity of each specific implementation, this makes it easy to discover the defects and blind spots of raw materials, which will help us to quickly and accurately approach the real goals we want to achieve, thus reducing the impact of rough materials.
Tip: the holistic view and overall situation view advocated here are the most basic methodologies. seeking truth from facts often leads to a blind ending for demand analysis. All the requirements need to be aggregated to a system framework that can carry the user's business, and then the location and role of various functions in this framework should be studied. Only under the sound mechanism of the overall framework, it is possible to provide specific feasible solutions for the implementation of specific functions.
1.3.2 grasp rules
From the general concept, the purpose of the management information system is to collect, describe, and map the implementation process and implementation strategy of the management objectives through data. This basic concept does not vary with industries or projects. This is a saying that seems to have no practical significance, but it is indeed a saying that has universal significance and should be noticed at any time during the demand analysis process.
We can analyze the specific connotation of regularity from several specific perspectives:
1. Industry: The same industry has the same management mode and operation mode.
2. Major: the same major has the same business content in different industries.
3. process: the business management process and model may be the same in different industries and specialties.
4. Operation: different application systems have the same or similar operation logic.
5. Transactions: regardless of the system's goals, they are always composed of transactions. The same transactions have basically the same implementation methods and implementation methods in various enterprise behaviors.
In the process of demand analysis, it is the simplest and most effective shortcut to learn from or follow these general rules in a broad sense, and then the personalization problem. If you are simply thinking about the materials you need, it's just an analysis method.
When mapped to an information management system, many rules represent a universal existence. The ratio of compatibility and repeatability is much higher than that of individual services, understanding and applying these rules is the basic quality for Quickly Constructing demand solutions. This is a problem at the ideological and method level.
1.3.2.1 internal law
It is an important methodology to quickly find the essential management goals. For example, in the project process, goods management and fund management are usually distributed in different positions, but the essence of the matter is: any increase or decrease of goods, it will inevitably affect a series of data changes such as inventory capital and current accounts, because in essence, goods and capital are completely different from the appearance of the same thing, they cannot be considered as two business forms that can be independent.
This is why the nature and inner relationship of transactions are not different because of different enterprises and different management concepts. They share the same performance and logic in any enterprise. Although the management process of production enterprises and circulation enterprises is very different, the methods for solving such problems are the same. In this case, we should first take the internal regularity of the transaction as the basis of the design, and study the user's personalized part on this basis. Although user requirements may have one or another defect, as long as we grasp the inherent regularity of transactions, we are still sure to design an application system with complete performance. If you follow the specific requirements given by the user and deviate from the inherent nature of the transaction, problems will inevitably occur in the application.
1.3.2.2 Data rules
The vast majority of management information systems are just the implementation process of data collection and data performance. Although the concept of data mining and decision-making support is widely advocated, the enterprises that can truly achieve it are only rare. Therefore, the Management Information System is a relatively simple data collection and display system.
Based on such data considerations, we can find the most essential internal laws and the most basic commonalities in the design process of various management information systems. In the implementation process of various management requirements, data processing can basically be divided into five basic forms:
1. Collection: including addition, deletion, modification, and other basic maintenance.
2. Derivation: A new record is derived from a record and a new record is obtained after processing.
3. Fill: Fill in some data on a certain record according to the business process needs.
4. Query: obtain the data set of a specific condition, including simple aggregation and statistics.
5. Analysis: make statistics and Comparison on data based on a specific management target.
At the data level, only by processing the data in the above mode through a relatively standard solution can we basically cover all the application processes of the management information system.
The following are three key steps:
1. Data Law: the basic proposition is solved through standard data disposal.
2. requirement rules: the interface between data and business is integrated through standard control methods.
3. Implementation Rules: the implementation means to fulfill the standard design into specific requirements.
This design is always centered on these basic issues on the data layer.
1.3.2.3 physical table rules
Data also has some rules that can be followed in specific applications. For example, for any physical table, data input and data display are generally reusable. For example, original input, data card, data maintenance, data import, and other reusable modes. These models are not sensitive to project content. As long as you change the direction of the data source, you can adapt to the design and implementation of many projects.
The specific usage of physical tables also has some rules, such:
• Parameter table: A physical table designed to achieve functional adaptability. The data is generally managed by the system administrator or an important business owner, which affects the specific performance of related functions.
• Vocabulary: it is also called a dictionary table. It mainly solves data standardization, standardization, and support for quick entry. The feature is that there are few fields and frequent references.
• Archive table: A Basic data table that must be used by system applications. It features a complete system covering the concepts of a specific topic (such as legal entities, materials, and warehouses, frequent calls and frequent maintenance are required.
• Business table: A physical table used to record business and management processes. The number of physical tables increases based on the complexity of the business, the records in each table will increase with the history process. The input process reflects the user's management objectives and operation logic.
Physical tables of the same type have similar design patterns in terms of functions, input, and display. From this perspective, we can easily classify design tasks.
1.3.2.4 permission rules
Permission management in the application system can be summarized into three methods:
• Data permissions: authorization management and permission implementation for data fields.
• Function authorization: enables function authorization management and permission implementation on menus, hotkeys, shortcut keys, toolbar menus, and other methods that enable the function interface.
• Control authorization: In the functional interface, some controls (such as buttons and text boxes) perform authorization management and permission implementation.
Where,
Authorization management: the process of defining a scheme for permission management rules.
Permission implementation: the specific implementation of each authorized role according to the permission management rules.
1.3.2.5 operation rules
In terms of operation logic, the implementation solution for each function is different from that for the operator. Its general regularity can be summarized:
• Data Entry (Collection): generally focuses on applications of keyboard operations or automated data collection devices, especially application systems with heavy input workload. This part of the function is often used by a large number of business positions. The degree of interest in entry speed and simplicity is the primary goal. Although the support for the mouse cannot be ignored, the focus is generally not here, this is mainly because mouse operations have a huge negative impact on the input efficiency.
• Query statistics: Generally, the focus is on the operation logic with the mouse, because most of these functions are operated by managers, who care much less about the keyboard operation logic than the input personnel, however, you still need to use the keyboard to solve the problem of inputting complex conditions. This is the business mode that is equally important to the keyboard and the mouse.
• Comprehensive analysis: the design of comprehensive analysis functions should basically Block keyboard operations, because these functions are generally important managers or decision makers who need to obtain results in the simplest way.
User requirements are generally not detailed in such a detailed operation logic, but it also determines that the implementation design is difficult to be detailed and accurate in the operation logic. If we can grasp this from the general rules, we will undoubtedly implement user needs more realistically and appropriately.
For programmers who have experience inputting massive data, these design concepts and implementation methods are naturally formed design habits. For those programmers who have no data entry experience, generally, it will experience multiple interactions with the user to be close to the user's actual requirements.
1.3.2.6 interface rules
The interface design also has some classic styles that can be reused. For a physical table or dataset, there are two main input or display modes: For a dataset, we basically use a data table, we prefer cards for a single record. A card is a data control that uses a single field as the basis to completely input or display a physical table and related data in a region (or page.
Although there are various changes in the interface design, we can abstract and generalize the basic mode, and then classify and customize it to form a relatively standard design style or application template. At this time, many similar design patterns can be described by style reference, which is simple and accurate.
For example, we can specify some common page styles:
• Single table data card: data card for a single table, which is the most basic design method.
• Single table tables + cards: combines datasets with cards to facilitate comprehensive management of table data.
• Master-slave tables + cards: combines the data of related tables to provide the full state of an application.
• Single-Table query: dynamic or static query based on a physical table, which is the basis for data presentation.
• Master-slave data query: queries data associated with multiple tables.
• Master-slave induction of query results: grouping and summarizing data query results to form a master-slave relationship.
These are just examples of images. In reality, they may be more and more complex forms. The rule of the interface is based on a specific angle. Changes in the perspective will affect changes in the interface category. If we can associate many application functions with the specified interface mode, the page description design will be effectively simplified.
1.3.2.7 rules and granularity
The existence of regularity is often closely related to the granularity of the study object. In general, the larger the granularity, the worse the regularity. The smaller the granularity, the more likely the regularity exists. In the process of requirement analysis, we should pay special attention to the dialectical relationship between regularity and granularity, especially in the process of analyzing complex problems, if we can obtain the regularity we seek from a reasonable level of granularity, we will find a door to success.
From the perspective of system composition, system logon, menu management, administrative organization management, and operator identity management can all be regarded as regular functions; if the granularity is degraded to the method level, we will find that there are still some regularity in the data storage and operation logic level, if you continue to degrade to the control level, you will find more regularity at a lower level.
In fact, "object" itself is a specific manifestation of regularity.