Demand Analysis (ii)

The specific content of the requirements analysis can be summarized into six aspects: the functional requirements of software, software and hardware or other external system interface, software non-functional requirements, software reverse requirements, software design and implementation limitations, reading support information.

The software requirement analysis should provide all the information that the software realizes the function requirement, so that the software designer and software tester no longer need the demand side contact. This requires that the software requirements analysis content should be correct, complete, consistent and verifiable.

Software functional Requirements

It describes the various possible conditions of the software, for all possible input data information, should complete those specific functions, produce what kind of output.

1) Completeness and consistency of functional requirements

The description of the function should contain information related to the function and should have intrinsic consistency (i.e., there is no contradiction or conflict between the various descriptions). The following points should be noted:

(1) give the triggering function of various conditions (such as: control flow, operating state, operation mode, etc.);

(2) define all possible inputs (including legal input space and illegal input space) under various probability conditions;

(3) give the possible interrelationships among various functions (such as control flow, data flow, flow of information, function running relationship among various functions: order, repetition, selection, concurrency, synchronization);

(4) give the main functional level (such as: basic functions, can be selected by the designer to gradually realize the function, can be changed by the designer to achieve the function, etc.);

(5) do not use the words "to be determined" as far as possible. All the requirements containing pending content is not a complete document, if there is a pending part, it is necessary to carry out a pending part of the content of the description, the implementation of responsible personnel, implementation date.

2) non-bifurcation and traceability of function description

The requirements function describes the non-bifurcation, traceability and normalization:

(1) function Description must clearly describe how to input how to output, and input, output description should be the description of the data flow, control Flow description diagram, these descriptions must be consistent with other local description;

(2) You can use language, equations, decision tables, matrices, or graphs to describe the function. If the language description must be used in a structured language, the description must indicate whether the step (or sub-function) execution is sequential, select, repeat, or concurrency, and then explain the step logic. The entire description must be single-in and out.

(3) when describing, each function name and reference number must be unique, and do not mix multiple functions to describe, so as to facilitate the tracking and modification of functions.

(4) The function description should pay attention to the difference between the requirement description and the program design. The requirement design is only the function design of the software, it gives the external function description of the software running, and what must be done in order to realize this external function (adopt and kind of data structure, define multiple modules, interface between interfaces, etc.) is the design stage thing, the function description should not involve the detail question, To avoid unnecessary constraints on software design.

2.2. software and hardware or other external system interfaces

Software and hardware or other external system interfaces include the following:

(1) Man-machine Interface: Description of input, output content, screen arrangement, format and other requirements;

(2) Hardware interface: Description port number, instruction set, input and output signal content and data type, initialize signal source, transmission channel number and signal processing mode.

(3) software Interface: Description of the software name, mnemonic, specification, version number and source;

(4) Communication interface: Specify the communication interface and communication protocol and other description.

2.3. non-functional requirements of software

Software non-functional requirements refers to software performance indicators, tolerances and other functions beyond the requirements. Generally refers to the following content:

(1) time requirement: input, output frequency, input, output response time, various function recovery time, etc.

(2) processing tolerance, accuracy, the resolution of sampling parameters, error processing, etc.

(3) reliability of MTBF requirements, maintainability, safety requirements. (The normal response to a possible abnormal input is an important part of reliability, which is a functional requirement.) )

2.4. Software Reverse Demand

Software's reverse requirements describe what the software cannot do in those cases. This is in line with the actual requirements of the software. There are two types of situations that need to take the form of reverse demand. The first scenario is that some user requirements are appropriate in reverse form, as data security requirements fall into this form. The second case: for some software that requires high reliability and security, some must describe what the software cannot do. If the ignition sequence is controlled, we must explain clearly that the ignition is not possible in those cases, otherwise it will cause malfunction.

2.5. limitations on software design and implementation

Software design and implementation limitations mainly refer to the limitations of software designers. such as restrictions on the operating environment of the software (select computer type, use configuration, operating system restrictions, etc.), limitations of the design tools (language of use, standards of execution), and confidentiality requirements.

2.6. Read support information

This part of the content is to better help us understand the needs of users, but also to make the requirements easy to modify and tracking. It is not a description of requirements in itself, but it affects the readability of demand analysis and is also an important part of demand analysis. General catalogs, requirements background information, content indexes, cross-reference tables, annotations, and so on, are part of the content.

Three-step method of validity software requirement analysis

"Interview-style visitation" stage

"Inductive inducement" stage

This stage is in the contractor has already understood the concrete user party's organization structure, the business process, the hardware environment, the software environment, the existing operating system and so on concrete actual, the objective information Foundation, unifies the existing hardware, the software realization Plan, makes the simple user process page, simultaneously unifies the former project experience to the user to adopt the inductive, Heuristic research methods and means, together with users to discuss the business process design rationality, accuracy, ease of use, habitual.

"Confirmation afirm" stage

Output: Requirements analysis report, data item, business process report, prototype system feedback (the latter three can be integrated into the requirements analysis report, submitted to the user, the supervisor to confirm and archive)

Requirements Analysis and evaluation indicators

There are a number of indicators: functional, integrity, correctness, logic, performance, rationality, implementation and so on.

Demand Analysis (ii)