softwareRequirements AnalysisThe main goals of achieving:
1）A comprehensive description of the functions of implementing software will help users judge the correctness, consistency and integrity of the implementation functions, and prompt users to think carefully and comprehensively about software requirements before the software design is started;
2）Understand and describe all the information required for software implementation and provide a benchmark for software design, confirmation and verification;
3）Conduct software cost pricing and preparation for software managersSoftware Development PlanProvide basis;
The specific content of requirements analysis can be summarized into six aspects: the functional requirements of software, software andhardwareor other external system interfaces, non-functional requirements of software, reverse requirements of software, limitations on software design and implementation, and reading support information.
Software requirements analysis should provide all information on the software implementation function requirements as much as possible so that software designers andSoftware testingPeople no longer need contact from the demand side. This requires that the content of software requirements analysis should be correct, complete, consistent and verifiable. In addition, in order to ensure the quality of software design and facilitate the rest and verification of software functions, the software requirements are inconsistent and are traceable and modifiable.
1、Software functional requirements
The functional requirements of the software are the most important, critical and complex part of the entire requirement analysis. It describes the specific functions that should be completed and what kind of outputs should be generated under various possible conditions of the software. Describing software functional requirements, the following points should be paid attention to:
1）Integrity and consistency of functional requirements
The description of a function should contain information related to the function and should have inherent consistency (that is, there is no contradiction or conflict between various descriptions). The following points should be noted:
（1）Given various conditions for triggering functions (such as: control flow, operating status, operating mode, etc.);
（2）Define all possible inputs under various possibilities (including legal input space and illegal input space);
（3）Given possible relationships between various functions (such as control flow, data flow, information flow between each function, function operation relationship: sequence, repetition, selection, concurrency, synchronization);
（4）Given the main levels of functionality (such as: basic functions, functions that can be gradually implemented by the designer, functions that can be changed by the designer, etc.);
（5）Don't use words like "pending" as much as possible. All requirements containing content to be determined are not complete documents. If the part to be determined appears, the content to be determined must be explained, and the responsible persons and implementation dates must be implemented.
2）The inconsistency and traceability of functional descriptions
The non-constraint, traceability and standardization of the requirements function description:
（1）Function descriptions must clearly describe how to input and output, and the input and output descriptions should correspond to data flow descriptions and control flow description diagrams, and these descriptions must be consistent with other descriptions;
（2）Functions can be described in language, equations, decision tables, matrices or graphs. If the language description is selected, you must use a structured language, before the description, you must specify whether the execution of the step (or subfunction) is performed in sequence, selection, repetition, or concurrency, and then explain the step logic. The entire description must be single-in and single-out.
（3）When describing, each function name and reference number must be unique, and multiple functions must not be mixed together to describe it, so as to facilitate the tracking and modification of functions.
（4）Function description should pay attention to the difference between requirements description and programming. Requirements design is just the functional design of the software. It gives a description of the external function of the software running, and what must be done to achieve this external function (using a data structure, defining multiple modules, interfaces between interfaces, etc.) is a matter at the design stage. Function description should not involve those details to avoid unnecessary constraints on software design.
2、Interface software with hardware or other external systems
The software interface with hardware or other external systems includes the following:
（1）Human-computer interface: explains the input and output content, screen arrangement, format and other requirements;
（2）Hardware interface: explains the port number, instruction set, input and output signal content and data type, initialization signal source, transmission channel number and signal processing method.
（3）Software interface: Explain the software name, mnemonic, specifications, version number and source;
（4）Communication interface: specify the description of communication interface and communication protocol.
3、Non-functional requirements of software
Software non-functional requirements refer to requirements other than software performance indicators, tolerances and other functions. Generally refers to the following content:
（1）Time requirements: input, output frequency, input and output response time, various function recovery time, etc.;
（2）Processing tolerance, accuracy, resolution of sampling parameters, error processing, etc.;
（3）MTBF requirements for reliability, maintainability, safety requirements, etc. (To give a normal response to possible abnormal inputs is an important part of reliability, which is a functional requirement.)
4、Software reverse requirements
The reverse requirement of the software describes what the software cannot do in those situations. This is determined by the actual requirements of the software. There are two types of situations that require the reverse demand form. The first case: Some user needs are suitable for description in reverse form, such asData securitySexual requirements fall into this form. The second case: For some software with high reliability and security requirements, some must describe what the software cannot do. If we control the ignition timing, we must explain clearly in which situations the ignition cannot be ignited, otherwise it will cause a failure.
5、Limitations in software design and implementation
Limitations in software design and implementation mainly refer to restrictions on software designers. Such as limitations of the software operating environment (selecting computer type, using configuration, operating system restrictions, etc.), limitations of design tools (using language, execution standards), and confidentiality requirements, etc.
6、Reading support information
This part of the content is to better help us understand user needs, and to make the requirements easy to modify and track. It is not a description of requirements itself, but it affects the readability of requirements analysis and is also an important part of requirements analysis. General directories, requirements background information, content index, cross-reference tables, comments, etc. all belong to the contents of this part.