Requirements analysis and methods in application software development Software engineering generally has the following basic activities: software description: definition of software functions and constraints in software operation; Software design and implementation: the software should be designed according to the description; Software validity verification: it should be determined that the software is effective and can complete the expected application; Software evolution: software evolves according to the change of application requirements. Among them, the goal of software description is to determine what services the software system needs and what constraints it is subject to during development and operation. The activities of discovering, analyzing, recording and verifying services and constraints are now commonly called requirements engineering. To this end, the author talks about how to conduct demand analysis and methods. 1. requirements process requirements engineering is a particularly critical stage for software process, and errors in this stage will inevitably be brought to the subsequent system design and implementation stage. The uniqueness of requirements engineering stage lies in that there are few ready-made models or special documents for reference. Subsequent stages can be based on previous work (at least to some extent, various related models can be derived), and the results of requirements engineering stage are created. Requirements engineering itself is a process, which will produce requirements documents to describe the system. Usually requirements are divided into two levels in this document: end users need high-level requirements description; And system developers need more detailed system description. (A) the four main stages of the demand process. Feasibility study: explain whether the existing software and hardware technology can meet the requirements of users for the new system. Determine whether the system development is cost-effective and can be developed within the budget from a business perspective. The feasibility study is preliminary, and the result is the conclusion whether the system is worthy of more detailed analysis. 2. Requirements export and analysis: This is a process of exporting system requirements by analyzing existing systems, discussing with potential users and analyzing tasks. It may also be necessary to develop one or more different system models and prototypes. All these will help analysts understand the system to be described. 3. Requirements description: Requirements description is to determine the information collected in the analysis activities in the form of documents. There are two types of requirements in this document. User requirements are abstract descriptions of system requirements from end users; System requirements are detailed descriptions of the functions provided by the system. 4. Requirements verification: This activity checks the realization, consistency and completeness of requirements. In this process, errors in the requirements document can be found and corrected. Of course, the activities in the demand process are not carried out in strict order. During the period of definition and description, requirements analysis continues, so new requirements appear constantly in the whole process of requirements engineering. Therefore, analysis, definition and description alternate. (2) Further understand the requirements 1. Software system requirements are usually divided into functional requirements, non-functional requirements and domain requirements. Functional requirements: including the description of the services that the system should provide, how to respond to input and the behavior of the system under specific conditions. In some cases, functional requirements may also need to clearly state what the system should not do. Theoretically, the description of system functional requirements should be comprehensive and consistent. Comprehensive means that all services required by users should be described. Consistency means that requirements descriptions cannot be inconsistent. In fact, it is almost impossible to describe the requirements comprehensively and consistently for large complex systems. On the one hand, because of the inherent complexity of the system, on the other hand, because of different viewpoints, the requirements will also conflict. Non-functional requirements: constraints on services or functions provided by the system. Including time constraints, development process constraints, standards, etc. Non-functional requirements stem from user restrictions, including budget restrictions, institutional policies, interoperability with other software and hardware systems, and external factors such as security regulations and privacy rights protection. Domain requirements: This is the requirement from the system application field and reflects the characteristics of this field. They may also be functional requirements or non-functional requirements. 2. Software requirements document, also called software requirements description (SRS), is a formal statement of the requirements of system developers. IEEE standard puts forward the following structure for requirements documents: Introduction (purpose, scope, abbreviation, etc. ), general description (product perspective, function, user characteristics, constraints, etc. ), special requirements (function, non-function, interface), appendix and index. Second, the method (a) the problem domain (application domain) refers to the part where the problem exists in the real world. Problem domain is the main object of demand analyst's research. For example, for the elevator control system, it will include any existing hardware (elevators, indicators, sensors, buttons, etc. ), architectural features (number of floors, number of elevator shafts), expected use mode, user characteristics, use constraints (such as restricting short-distance rides) and so on. In this problem domain, the problem can be defined as "the control system that makes the elevator use more effectively in the building". In order to solve the problem, it is obviously necessary to produce some effects in the problem domain, and it is these desired effects that constitute the software requirements, that is, the reasons and purposes of doing software requirements. So far, we have a preliminary argument. Before building a new software system, it is best to decide what it should be able to do and what it should not do; Starting with the study of the problem domain, the description of the problem and the statement that the new solution system will produce the effect (that is, the demand) are obtained; Determine the required behavior of the new system so that it can produce the required effect in the problem domain. (II) Demand Analysis Through the study of the problem domain, a thorough understanding of the characteristics of this domain and the characteristics of the problems that exist (need to be solved) is obtained and recorded. Requirements analysis aims to reveal the structure of the existing system (problem domain), while internal design aims to create the structure of the software system (solution system) that does not yet exist. For this important task, its characteristics are: (1) analyzing the problem domain and establishing its model, instead of solving the system; The main goal is to understand the problem domain and the nature of the problems in it; Analysis essentially precedes the specification of system behavior (although there are overlapping and iterative processes). (3) Methodology is not only a technology, but also a method to solve tasks, usually consisting of a group of technologies. In order to make good use of any analysis method, the following aspects should be required and easily described: (1) the structure of the problem domain, according to its subdomains and their relationships; The inherent attributes and behaviors of the problem subdomain in terms of data, grammar and semantics; Important events and phenomena in the problem domain; Demand-solving system should play a role in the problem field. Specifically, there are three methods: 1 and structural analysis (SA). Structural analysis (SA) is an analysis method with a long history, and its evolution is subtle and important. Like structured programming, it is devoted to system-wide transaction processing, data flow and storage data structure modeling. Modeling mainly includes data flow model (DFD), data dictionary (DD) and entity relationship diagram (ERD). Prototypes used in structured analysis are intuitive and easy to understand for both developers and customers. If the initial focus is on the modeling of the original system, it will be a strong support to realize the basic analysis goal of understanding the problem domain. Structured method is very similar to people's way of thinking, focusing on the process and aspects of things. It is easy to understand a new problem domain by using structured analysis, which is suitable for making software requirements in unfamiliar fields. 2. Object-oriented analysis (OOA) Object-oriented method is only a method to model the system structure at first, and then it is extended to internal design, and now it has been widely used in the analysis stage. The basic idea of object-oriented analysis is that if the modeling of object classes is limited to the field of requirements, then the basic principles, models and representations of object-oriented can be used for analysis. OOA (Object-Oriented Analysis) is not a real requirement method. The starting point of OOA is an original requirements document, even a code of conduct. The analysis of the hypothetical problem domain implied by OOA has been completed, that is, the analyst has understood what to study. The real essence of OOA is the design of the high-level architecture of the solution system, which is conducive to the next development and design of the system (if it is OOD development). The general method of OOA is: identify the object class in the problem domain; Define the properties and methods of these classes; Define the behavior of these classes; Modeling the relationship between these classes. 3. Problem-Oriented Domain Analysis (PDOA) is a new technology. PDOA emphasizes more description and less modeling. The description is roughly divided into two parts: one focuses on the problem domain, and the other focuses on the behavior of the solution system. It is generally recommended to have two independent documents at the same time: the first document contains a description of the relevant parts of the problem domain and a list of problems that need to be solved in this domain (that is, requirements); The second document (specification) contains a description of the pending behavior of the solution system that addresses the requirements. Among them, the first document is generated by doing analysis; The second document was postponed to the subsequent specification task. The basic steps of the whole PDOA method process: collecting basic information, developing problem framework (model) and establishing the type of problem domain. Under the guidance of the problem frame type, the detailed information is further collected and the feature description related to the problem domain is given. Based on the above two points, the framework for collecting and recording new system requirements. The problem framework is to model the problem domain into a series of interrelated subdomains. A subdomain can be any part of those problem domains that may be selected. The goal of the problem framework is to get more information about the problem domain. Based on the nature of different problem subdomains and their relationships, the problem framework can be divided into: workpiece system-the system must complete the direct operation of these objects that only exist in the system. Control system-the system controls the behavior of some problem domains, including the behavior framework to be sought and the behavior framework to be controlled. Information system-The system will provide information about the problem domain, including that the information is provided automatically and only in response to specific requests. Conversion system-The system must convert the input data in a specific format into the corresponding output in another specific format. Connected systems-Systems must maintain communication between subdomains that are not directly connected to each other. In the application of the problem framework method, it is suggested to adopt straightforward strategies: abstract the problem domain, determine the subdomain; Identify the interaction between subdomains; Characterize the characteristics of each subdomain; Generate a context diagram to determine the relevant standard framework; Adjust the framework to make it applicable to the problem as much as possible; Use the content technical table about the relevant framework to guide further analysis and recording tasks. There is a clear difference between the description of the problem domain and the requirements that must be met. The behavior creation and definition of the new solution system should be handled separately and postponed to the next specification stage. 4. The comparative structural analysis (SA) of methods and its corresponding derivation methods have been popular for many years. Its original version mainly focuses on modeling the data flow and data structure of the problem domain, while modern SA directly focuses on developing the model of the solution system. SA describing the problem domain is also a good one, and the effect can be seen. However, its support for other aspects is not perfect, and it seems a bit clumsy when dealing with some other types of problems. Object-oriented analysis (OOA) is the mainstream method today. OOA requires that all systems can be modeled according to the characteristics of objects. It also inherits many ideological systems of structured analysis. OOA can't have a clear understanding of the problem domain. If there is an original requirement document as a starting point, it can greatly simplify the analysis of the problem domain. OOA does not distinguish between problem domain description and solution system description, but directly delivers the high-level design of new solution system. SA and OOA also have several common characteristics: the main model is a structural model; Usually, the emphasis is on the modeling of solution system; These two methods are rarely used in the field of requirements acquisition; There is no obvious difference between analysis and internal design. Problem-oriented domain analysis (PDOA) is considered as an ideal method. The characteristic of PDOA is to re-focus on problem domains and requirements, and provide analysts with relevant guidance on specific problems through the classification of problem domains. Moreover, it regards specification as another task, and its result is only a comprehensive description of the problem domain and a list of requirements. PDOA enriches and perfects the current "analysis" method, but people still have a certain distance to understand and master it. Applying the three methods according to local conditions can not only truly understand the problem domain and create a perfect solution system, but also provide users and designers with satisfactory requirements documents. Third, summary When making software requirements, there is absolutely no need for us to limit what methods we want to use or what methods we will use. Our purpose is to analyze the requirements of software, and usually all three methods are used. First of all, we use the method of problem-oriented domain to divide the problem into several parts. Next, use the structure-oriented or object-oriented method to analyze and refine each part step by step. In the process of step-by-step analysis, various modeling techniques are used to build appropriate models for all parts of the problem to refine the requirements. With the further development of requirements, we have a clearer understanding of the requirements of software systems. Although the application method enables us to clearly understand the software requirements, most of the requirements documents and specifications are recorded in the form of text, so how to express what we know is also very noteworthy.