Software Requirement Analysis

Software reguirement analysis (software reguireanalysis) is a research on user requirements. It fully understands the complete functions required by the user for the software and confirms the functional requirements of the software, establishes a verifiable basic basis.
Software Requirement analysis is the beginning of a project and the most important key point of project implementation. According to the relevant institutional analysis results, the software products we designed have problems such as integrity and correctness. More than 80% of these problems are caused by incorrect requirement analysis, in addition, the fundamental functional problems caused by incorrect demand analysis are particularly prominent. Therefore, the successful Software Requirement Analysis of a project is a key step.
I. Software Requirement Analysis Theory if we use mathematical methods to describe software requirements analysis, we can define an application software as S. It may involve a wide range of functional problems, we can use abstract theoretical analysis to divide it into various functional domains, and use D1, D2 ,... DN, so we can use an expression to describe

S = {D1, D2, D3 ,... DN}

However, functional di still has several problems: P1, P2, P3 ,... PM, and each function corresponds to a software component in the subsystem, which can be expressed as di = {P1, P2, P3 ,... Pm} Similarly, function PJ has several behaviors: F1, F2, F3 ,... FK. Each behavior corresponds to the implementation method PJ = {F1, F2, F3,… in the software component ,... FK}
A software contains a set of all functions and all methods and algorithm descriptions for implementing all functions. Requirement analysis is based on user requirements. After identifying requirements and problems, it is analyzed, digested, and integrated. Specification descriptions and reviews are formulated and divided into four stages to form a synchronization between user requirements and design, design to meet user needs. Demand analysis methods are used throughout the process of absorbing, assimilation, and implementing methods and means. commercial activities are used to solve conflicts between demands and implementations, and customer needs and commercial products can be integrated, solve the pursuit of standardization and personalization.
Ii. Software Requirement Analysis objectives the main objectives of software requirement analysis are as follows: 1) fully describe the functions of the software to help users determine the correctness, consistency, and completeness of the functions, encourage users to think carefully and comprehensively about software requirements prior to software design initiation; 2) understand and describe all information required for software implementation and provide a benchmark for software design, validation and verification; 3) provide software management personnel with a basis for calculating software costs and preparing software development plans;
The specific content of requirement analysis can be summarized into six aspects: Functional requirements of software, software and hardware or other external system interfaces, non-functional requirements of software, and reverse requirements of software, for Restrictions on software design and implementation, read the support information. The software requirement analysis should provide as much information as possible for the software to achieve functional requirements, so that software designers and Software testers do not need to contact the demand side. This requires that the software requirement analysis content 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 non-disruptive, traceable, and modifiable.
2.1 software functional requirements are the most important, critical, and complex part of the entire requirement analysis. It describes the various possible conditions of the software, all data information that may be input should be specific functions and output. To describe software functional requirements, pay attention to the following points: 1) functional requirements integrity and consistency the function description should contain functional-related information, there should be internal consistency (that is, there should be no conflicts or conflicts between various descriptions ). Pay attention to the following points: (1) various conditions for triggering the function (such as control flow, running status, and running mode); (2) define all possible inputs under various possibilities (including valid input space and invalid input space); (3) provides possible relationships between various functions (such as control flow, data flow, and information flow among various functions. Functional running relationships: sequence, repetition, selection, concurrency, and synchronization). (4) provides the main levels of functionality (for example, basic functions, functions that can be gradually implemented by the designer, and functions that can be changed and implemented by the designer). (5) try not to use words like "TBD. All requirements that contain the content to be determined are not a complete document. If a part to be determined appears, it is necessary to describe the content to be determined, implement the responsible person, and implement the implementation date.
2) non-blocking, traceability, and standardization of Functional Descriptions of functional requirements: (1) the function description must clearly describe how to input and output, and the input and output descriptions should have a data flow Description and a control flow Description diagram. These descriptions must be consistent with the descriptions elsewhere. (2) you can use languages, equations, decision tables, matrices, or graphs to describe functions. If the selected language description must use a structured language, the execution of this step (or sub-function) must be stated before the description in sequence, selection, repetition, or concurrency, and then the step logic. The entire description must be single-in-one and single-out. (3) Each function name and reference number must be unique in the description, and multiple functions should not be described together to facilitate tracking and modification of the function. (4) Pay attention to the differences between Requirement Description and program design. The requirement design is only the functional design of the software. It gives the description of the external functions of the software, and what needs to be done to implement this external function (using a data structure and defining multiple modules, interface between interfaces) is a task in the design phase. The function description should not involve those details to avoid unnecessary constraints on the software design.
2.2 software and hardware or other external system interfaces
Software and Hardware or other external system interfaces include the following: (1) Human-Computer Interface: Description of input and output content, screen arrangement, format, and other requirements; (2) hardware interface: description: port number, instruction set, content and data type of input and output signals, initialization signal source, transmission channel number, and signal processing method. (3) Software Interface: Describes the software name, mnemonic, specification, version number, and source;

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

 

2.3 non-functional requirements of software the non-functional requirements of software refer to requirements other than software performance indicators and tolerances. It generally refers to the following content: (1) time requirement: input/output frequency, input/output response time, and various function recovery time; (2) processing margin, accuracy, resolution of sampling parameters, error processing, etc.; (3) MTBF requirements for reliability, maintainability, and security requirements. (Normal response to possible Abnormal Input is an important part of reliability, which is a functional requirement .)
2.4. Reverse requirements of Software Reverse requirements description of what the software can do in those circumstances. This article depends on the actual requirements of the software. There are two types of situations that require reverse requirements. First case: Some user requirements should be described in reverse form, such as data security requirements. Case 2: For software with high reliability and security requirements, some must describe what the software cannot do. If the ignition sequence is controlled, we must make it clear that the ignition cannot be performed in those cases; otherwise, a fault may occur.
2.5 restrictions on software design and implementation the restrictions on software design and implementation mainly refer to the restrictions on software designers. Such as restrictions on the software running environment (select the computer type, use configuration, operating system restrictions, etc.), design tool restrictions (use languages, execution standards), and confidentiality requirements.
2.6. Read the support information to help us better understand user requirements and to facilitate modification and tracking. It is not a requirement description, but it affects the readability of requirement analysis and is also an important part of requirement analysis. General Contents, requirement background information, Content Indexing, cross-referenced tables, and comments all belong to this part.
3. Software Requirement analysis personnel organization
The fundamental problem of software requirement analysis is to understand the functional requirements of users. Therefore, software requirement analysis is actually the goal of communicating with customers. We are required to organize appropriate participants for communication activities. Demand analysis is the work of a comprehensive team. It is guided by the demand analysis theory to gradually deepen user needs. It forms specific constraints through constant changes; efforts should be made to implement commercial products that require functional goals to form distinctive results. Demand Analysis is a commercial action. It is completely a commercial operation. It requires teams that have business, technology, and other combinations to work together to solve the synchronization of requirements and design, and design to meet the needs.
Project Content, project size, we need to consider the number of people who participate in the Software Requirement Analysis Team to withdraw, configure reasonable participants. Generally, we must have business activities, project management personnel, and design technicians. In addition, the organization personnel must specify the scope of responsibility and work objectives to ensure the effectiveness of the implementation.
4. Software Requirement analysis methods to ensure the normal implementation of the project and the smooth completion of the project, we must strengthen the project management and pay attention to the project analysis work. We only need to start from the actual situation, grasp the user's needs, grasp the user's needs and objectives, grasp the user's future function definition, and ensure that our development work is correct.
4.1 key monitoring software demand analysis methods the importance of software demand analysis is self-evident due to the particularity of software projects, the broad coverage of the industry, and the high risk of demand analysis, at the same time, the demand analysis is indeed difficult to do. The reason is basically due to the following situations.
4.1.1. the customer cannot clarify the requirements. Some customers have a vague feeling about the requirements. Of course, the customer cannot clarify the specific requirements. For example, when many departments, institutions, and units throughout the country are building application systems and networks, most of the customer's office staff are not clear about the use of computer networks, lack of IT system construction experts and knowledge. At this point, the user will ask the software system analysts to imagine the demand for them. Project requirements are subjective, which may pose potential risks for future project construction.
4.1.2 frequent changes in requirements based on past experiences, with the customer's understanding of information construction and improvement of their business level, they will put forward new requirements and demand changes for the project at different stages and periods. In fact, there have never been any software requirement changes less than three times in history! Therefore, we must accept the fact that "requirements will change". When conducting demand analysis, we must understand how to prevent problems before they happen, and try to analyze as much as possible what are stable requirements and what are easy-to-change requirements, in order to design the system, the core architecture of the software must be stable, while leaving room for change. The consulting authority assumes an intermediate, fair, and impartial role in defining the demand analysis function. Therefore, the consulting authority must actively participate in the preparation of the demand analysis, this allows customers and administrators to define system functional boundaries of "what to do" and "nothing to do.
4.1.3 analysts or customers may understand that incorrect software system analysts cannot be full talents, but they may not be industry experts. Different analysts may have different understandings of customer requirements. If the analyst understands the error, it may lead to unnecessary development work in the future. One joke is that an alien spy lurks into the earth's spying information and writes a report to his boss: "cars dominate the earth. They drink gasoline and move on with four wheels. They have a loud voice, and their eyes can emit intense light at night ...... Interestingly, there is a kind of parasite called 'people' in the car, which completely controls the car ." Therefore, the uniqueness of the analyst's knowledge may cause misunderstanding and failure of the requirement analysis. At this time, the consulting and supervision company must follow the actual project demand survey plan to remind the Party to enhance business understanding and focus on communication skills.
4.2 Effectiveness Software Requirement Analysis Three-step method based on past engineering experience and demand analysis work methods should be positioned in the "three stages" (also known as the "three-step method ").
4.2.1 The "Interview-style visitation" phase refers to the interview-style communication with the leadership and business personnel of specific users. It aims to grasp the specific demand-side direction and trend of users from a macro perspective, measure the test taker's knowledge about the specific situation and objective information about the existing organizational structure, business processes, hardware environment, software environment, and operating systems. Establish good communication channels and methods. It is best to specify the contact person for this project for specific functional departments and committees. Implementation Means: output results of interview and survey forms: Survey Report and Business Process report
4.2.2. the "inductive inducement" phase indicates that the publisher has understood the actual situation of the organization architecture, business processes, hardware environment, software environment, and existing operating systems of specific users, based on objective information, make a simple user process page based on existing hardware and software implementation solutions, and use inductive and heuristic survey methods and methods based on previous project experience, discuss with users the rationality, accuracy, ease of use, and habit of business process design. You can use a simple demo to check the rationality and accuracy of the entire business process, and provide suggestions and methods for improvement in a timely manner. Implementation Means: Visiting (induction), prototype demonstration output results: survey and analysis report, prototype feedback report, business process report
4.2.3. The validation afrem stage is based on the results of the above two stages, and the specific process is refined and the data items are confirmed, at this stage, the publisher must provide the prototype system and clear business process reports and data item tables, and clearly describe the business flow design objectives of the system to users. The user can provide feedback by reviewing the Business Process report, data item table, and the demo system provided by the operator, and sign and confirm the accepted reports and documents. Implementation Means: visit (review and confirmation), submit Business Process report and data item table; prototype demonstration system output results: requirement Analysis Report, data items, business process report, and prototype system feedback (the latter three can be included in the requirement analysis report and submitted to the user and the supervisor for confirmation and archiving, the three stages of demand analysis are an important part of demand research. The implementation and adoption of the three stages or three-step method can be ignored, both the user and the publisher are guaranteed to succeed in the project. Of course, in the process of system construction, especially when the iterative development model is adopted, the demand analysis work should be carried out continuously, and in the later stage of demand improvement, work is basically concentrated in the next two stages.
5. Software Requirement Analysis tools: based on user requirements, through repeated discussion and analysis, we finally define a unique user requirement. This result is actually our software requirement analysis report. Generally, we use office tools such as Word, PowerPoint, Visio, prontpage, and Excel. Some development tools, such as VC or BC, may also be used, such as potoshop and palette.
Various tools are used to express Software Requirement Analysis. Specific expressions can be divided into: l description. The description of the UI interface mainly reflects the functions required by the user; l logical diagram description. Based on the user's demand functions, abstract theories and demand analysis theories are used to comprehensively analyze user demand functions, establish functional logical relationships, process logical relationships, and so on. l relational charts and descriptions. It mainly describes information relations, database tables, interface functions, etc.; L Engineering mathematical description. Analysis of user requirements, analysis of user requirements information, algorithm Derivation Using Engineering Mathematics, reasonable demand analysis and derivation; l Gan map description. It mainly refers to the software project work arrangement, development cycle estimation, and other methods description. A valid description of integrity.
6. Software Requirement Analysis and Evaluation the software requirement analysis and evaluation aims to check our software requirement analysis work, ensure the correctness, integrity, effectiveness, rationality, testability, and implementation of software requirement analysis, and fully guarantee the functions required by users.
6.1. Organizational structure and responsibility management our evaluation of organizational structure and responsibility management mainly includes the clarification of the tasks and responsibility interfaces of participants, and the completion of the plan on time; coordination between each other.
6.2. The purpose of our demand analysis is to completely and accurately describe user requirements and track changes in user requirements, accurately reflect user requirements to system analysis and design, and ensure that the system analysis, design, and user requirements are consistent. Requirement Analysis is characterized by requirement integrity, consistency, and traceability. Integrity: describes user requirements accurately and comprehensively. Consistency: analyzes and sorts out the conflicts between user needs and standardizes user needs. Traceability: There are two meanings and requirements for organization and standardization. First, we need to constantly communicate with users to keep up with the latest requirements of users. Second, it is consistent with System Analysis (design. Therefore, before requirement analysis, we must establish a basic framework at the technical level of requirement analysis to ensure the technical requirements of requirement analysis, on this basis, our demand analysis can meet the requirements of the project for demand analysis.
6.3. to ensure implementation, we must compile software demand analysis in a realistic, accurate, and complete manner based on the user's software requirements, so as to avoid the idea of a fantasy world or a castle in the air; avoid non-logical and non-core descriptions; Avoid the concept of unlimited thinking and no practical space.
6.4 The demand analysis and evaluation indicators mainly include functions, integrity, correctness, logic, performance, rationality, and feasibility.
6.5. Review personnel input and rationality of expenses during the work cycle. Correctly develop work cycles to ensure smooth completion of software projects.
6.6 uncertain demand change and verifiable assurance the verifiable demand function is the basic guarantee for implementing user requirements. Uncertain changes may impede software implementation, or the software design has integrity defects or non-implementation problems. We must distinguish between functional disorder and future problems. If it cannot be clear that it is a future issue, you must adjust the functional requirements to solve the problem of uncertain changes. Therefore, determining uncertainty changes is a very important issue.