Software Requirement Analysis method

Http://www.cnblogs.com/luluping/archive/2009/06/18/1505754.html

Software Requirements analysis (software reguirement) is to study the user needs to get things, fully understand the user to the software requirements of the complete function, to confirm the user software functional requirements, establish a verifiable, verifiable a basic basis.

Software Requirement analysis is the beginning of a project and the most important key point of project implementation. According to the analysis results of the relevant agencies, we have designed the software products are not integrity, the correctness of the problem of more than 80% is the result of demand analysis errors, and due to demand analysis errors caused by the fundamental functional problems are particularly prominent. Therefore, a successful software requirements analysis of a project is a critical step.

First, theory of software requirement analysis

If we use the mathematical method to describe the software requirements analysis, we can define an application software as s, the application software may involve a very wide range of functional problems, we use abstract theory analysis, can be divided into various functional domains, can be used D1, D2 、... The DN says, well, we can use an expression to describe

S={D1,D2,D3, ... Dn}
However, there are still several problems with the functional domain di P1, P2, P3 、... PM, and each function corresponds to a soft component in the subsystem, which we can represent as
DI={P1,P2,P3, ... PM}
Similarly, functional PJ has several behaviors F1, F2, F3 、... Fk, each behavior corresponds to the implementation method in the software component

PJ={F1,F2,F3, ... FK}

A software contains a collection of all the functions, along with all the methods and algorithm descriptions that implement all the functions. Demand analysis is based on user needs, through the demand problem identification, analysis, digestion and synthesis, the formulation of specifications, review, divided into four stages, the formation of user requirements and design synchronization, design to meet user demand goals.

The method of demand analysis always runs through absorbing, assimilating, implementing method and means, solving the contradiction in demand and realization with commercial behavior, solving the user demand and commercialization of product, solving the norm and individuation pursuit.

Second, Software Requirements Analysis Objectives

The main goal of software requirement analysis is to achieve:

1) The realization of the function of the software to do a comprehensive description, to help users to determine the correctness of the implementation of functions, consistency and integrity, prompting users in the software design before the start of a thorough and comprehensive thinking of software requirements;

2) to understand and describe all the information required for the implementation of the software, to provide a benchmark for software design, validation and verification;

3) Provide the basis for software management personnel to make software cost pricing and prepare software development plan;

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. In addition, in order to ensure the quality of software design, ease and verification of software functions, the software needs to express the non-bifurcation, traceability and modifiable.

2.1. Software Functional Requirements

The functional requirements of the software are the most important, the most critical and the most complex part of the whole requirement analysis, it describes the various possible conditions of the software, on all possible input data information, should complete those specific functions, produce what kind of output. The following points should be noted for describing software functional requirements:

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.

Third, Software Requirements Analyst Organization

The fundamental problem of software requirement analysis is to understand the requirement of user function, so software requirement analysis is actually the goal of communication process with customer. We are required to organize appropriate participants to exchange activities.

Demand analysis is the work of a comprehensive team, under the guidance of the theory of demand analysis, the gradual deepening of the user needs, through the changing way to form specific constraints, and strive to achieve the requirements of functional objectives to form a commercial product characteristic effect. Demand analysis is a business behavior, is a commercial operation, requires a combination of business, technology and other teams to work together to solve the requirements and design synchronization, design in line with the requirements.

The project involves content, and the size of the project requires us to consider the number of people who participate in the software requirements analysis mission and to configure the appropriate participants. In general, we must have business activities, project managers, design and technical personnel to participate in, but also require the organization must clear the scope of responsibility, as well as clear the objectives of the work to ensure the effectiveness of implementation.

Four, Software Requirement Analysis Method

In order to ensure the normal implementation of the project, and can be successfully completed, we must strengthen the project management and focus on the project analysis work. We only from the actual start, the real grasp of user needs, grasp the user needs goals, grasp the user's future function definition, to ensure that our development work correctness direction.

4.1 , key monitoring software requirements analysis Method

Because of the particularity of software project and the broad nature of industry coverage, as well as the high risk of demand analysis, the importance of software requirements analysis is self-evident, and the demand analysis is indeed difficult to do. The reason is basically caused by the following conditions.

4.1.1 , the customer is not clear about the demand

Some customers have only a hazy sense of demand, of course, not clear the specific needs. For example, many departments, institutions, units throughout the country in the application system and network construction, the client side of the office staff is not clear what the use of computer networks, but also lack of IT system construction experts and knowledge. At this point, the user will ask the software system analyst to envision the demand for them. There is a certain subjectivity in the requirements of the project, and the potential risks are buried for the future construction of the projects.

4.1.2 , the demand itself changes constantly

According to the historical experience of the past, with the understanding of information construction and the improvement of their business level, they will put forward new requirements and change of demand in different stages and periods. In fact, none of the software needs change less than three times in history! So we must accept the fact that "demand will change", in the analysis of needs to know how to prevent, as far as possible to analyze what is stable demand, which is the variable requirements, in order to carry out the system design, the core of the software building in a stable demand, while leaving room for change. The consulting supervisor plays an intermediate, fair and impartial role in the function definition of demand analysis, so it is necessary to actively participate in the preparation of demand analysis so as to assist clients and contractors to define the system functional boundaries of "what to do" and "What Not to do".

4 . 1. 3. The analyst or the customer understands the mistake

Software system analysts can not be all-rounder, more unlikely to be industry experts. The needs expressed by the customer, different analysts may have different understandings. If the analyst is wrong, it may lead to future development work vain. Remember a joke, an alien spy lurking in the earth spying on intelligence, it to the boss wrote a report: "Dominate the earth is a car." They drank petrol, rolled forward on four wheels, had a loud voice, and their eyes could shoot a strong light in the night ... Interestingly, there is a parasite called ' human ' in the car that completely controls the car. "So the specificity of the analysts ' knowledge also leads to misunderstandings and failures in demand analysis. At this time, consulting supervision company must according to the actual project demand research plan, remind the contractor to strengthen business understanding and focus on communication skills.

4.2 , the three-step method of validity software requirement Analysis

According to the previous engineering experience, the requirement analysis work method should be located in "three stages" (also called "Three Steps").

4.2.1 , "interview-type Visitation" Stage

This phase is and the specific user side of the leadership, the business level of the interview-type communication, the main purpose is to grasp the user's specific needs of the direction and trend, to understand the existing organizational structure, business processes, hardware environment, software environment, the existing operating system and other specific circumstances, objective information. Establish a good communication channels and methods. For specific functional departments as well as the various offices, it is advisable to designate the interface person for this project.

Means of implementation: interviews, survey forms

Output results: Survey report, Business process report

4.2.2 , "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. Users can operate a simple demonstration of the demo, to feel the whole business process design rationality, accuracy and so on, and timely suggestions and methods to improve.

Means of realization: visit (inducement), prototype demonstration

Output results: Research and analysis reports, prototype feedback reports, business process reports

4.2.3 , "Confirmation afirm" stage

This phase is based on the results of the above two stages, the specific process refinement, the validation phase of the data item, the contractor must provide a prototype system and a clear business process report, data item table, and can clearly describe the system's business flow design objectives to the user. The user can provide feedback by reviewing the business process report, data item table and the demo system provided by the contractor, and confirming the accepted report and document signature.

Means of realization: Visit (review, confirm), submit business process report, data item table; Prototype Demo system

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)

On the whole, the three stages of demand analysis is an important part of the demand investigation, and the implementation and adoption of three phases or three steps are also the guarantee for the success of the project for both the user and the contractor. Of course, in the process of system construction, especially in the use of iterative approach to the development model, the need for analysis of the work needs to continue, and in the latter part of the demand improvement, the work is basically concentrated in the latter two stages.

Five, Software Requirements Analysis tool

We based on user needs, through repeated discussion, analysis, and finally clear a unique user needs, this result is our software needs Analysis report. In general, we use Office tools such as Word, PowerPoint, Visio, Prontpage, Excel, and possibly some development tools such as VC or BC, as well as drawing tools such as potoshop, color palettes, and so on.

Using a variety of tools to express software requirements analysis, its specific expression means can be divided into:

L description. The main user UI interface description reflects the user needs function;

L Logical diagram description. According to the user demand function, using the abstract theory, as well as the demand analysis theory, the user needs function of the comprehensive analysis, the establishment of functional logic diagram, process logic diagram, etc.

L Relationship Diagram description. Mainly is the information relation, the database table, the interface function and so on description;

L Engineering Mathematical Description. Analyze user requirements, analyze user requirements, use engineering mathematics to derive the algorithm, and deduce the rationalization requirement analysis;

L Gandhitu description. Mainly is the software project work arrangement, the development cycle estimate;

L Other method description. A valid description of the reasonableness of the integrity.

Six, Software Requirements analysis and evaluation

Software Requirements analysis and evaluation is to check our software requirements analysis work, to ensure that the software needs analysis work correctness, integrity, validity, rationality, validation, and implementation, fully guarantee the user needs of the function.

6.1. Organizational structure and responsibility management

Our assessment of organizational structure and responsibility management mainly includes: The task of the participants and the responsibility of the interface of the clear, scheduled to complete the situation on time, the coordination between the situation.

6.2, to meet the needs of users of the function

The purpose of our requirements analysis is to fully and accurately describe the needs of users, tracking changes in user needs, the user's needs accurately reflected in the analysis and design of the system, and make the system analysis, design and user needs consistent.

Requirements analysis is characterized by the completeness, consistency and traceability of requirements. Completeness: An accurate and comprehensive description of the user's needs. Consistency: It is through analysis and collation, eliminate the contradiction of user demand, standardize user needs. Traceability: There are two aspects of the meaning, collation and normative requirements, one, the need for continuous and user further communication, to maintain and the user's latest demand consistent. Secondly, it is consistent with the system analysis (design).

Therefore, before the demand analysis, we must establish the basic framework of the technical level of demand analysis, from the technical requirements to ensure the demand analysis, on the basis of our needs analysis to meet the requirements of the project requirements analysis.

6.3, to ensure that the implementation of

We must take the user software requirements as the basis, in a realistic manner detailed, accurate, complete software requirements analysis, to avoid the fantasy world, the idea of castles in the sky, avoid illogical, no core description, avoid the non-quantitative thinking, no real space concept.

6.4. Requirements analysis and evaluation indicators

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

6.5. Work Cycle

Evaluation of staff input, as well as the reasonableness of cost expenditure. Set up the work cycle correctly and ensure the smooth completion of the software project.

6.6. Change of requirement uncertainty and confirmation guarantee

Can confirm the requirement function is the basic guarantee that realizes the user demand, if the unconfirmed, the uncertainty change exists, will hinder the software realization, or the software design has the incomplete flaw, or exists the question which is not implemented, we must distinguish whether is the functional obstacle question, or the future sex question. If it is not clear that it is a future problem, you must adjust the functional requirements to resolve the problem of indeterminate changes. Therefore, it is a very important question to judge the uncertainty change.

Software Requirement Analysis method