Develop a requirements management plan, define requirements baselines, obtain understanding and commitment to requirements, manage requirements changes, maintain two-way tracking of requirements, and identify inconsistencies between project work and requirements

Two-way tracking of requirements: In forward tracking, in which use case the original requirement is realized, whether all the original requirements are realized. In reverse tracing, if a use case does not realize any original requirement, it is an exciting need.

Information related to the problem domain, information related to the problem to be solved, user expectations and constraints

Stakeholders, legacy systems, competitors, domain experts

Joint discussion requirements meeting (multi-party discussion), user interviews (key users prepare questions), written surveys (when there are many people), on-site observations, reading historical documents, and participating in business practices

Graphical tools: hierarchical block diagram, use case diagram, IPO diagram, Warnier diagram

Requirements development is a non-waterfall, iterative evolutionary process that decomposes the problem from top to bottom, layer by layer, and provides a logical view and a physical view of the system.

Draw a scope diagram of the relationship between the system and external entities, create a user interface prototype, analyze the feasibility of requirements, determine the priority of requirements, establish an analysis model for requirements (use case model, ER diagram, data flow diagram), create a data dictionary, and use quality functions allocate

structured analysis methods

Object-oriented analysis method

Area problem domain analysis method

Logical view (meeting functional requirements), process view (concurrency issues), component view (implementation issues), deployment view (distribution issues)

Convert software requirements into data structures and software system structures, mainly completing the overall design, including dividing functions into modules, determining module functions and the calling and composition relationships between modules

Top-down, gradual refinement, information hiding (operation interface), independent modules (high cohesion, low coupling)

Design data structure and algorithm for each module, performance, turnaround time, response time, throughput, accuracy, etc.

Incoming module, outgoing module, transformation module, coordination module

Transformation, Transaction, Mixed

Design test cases according to the functional specifications and check whether the functions meet the requirements, regardless of the structure and processing of the program.

Equivalence class division

boundary value analysis

error guessing

cause and effect diagram

Test content

Test Methods

Combine black box and white box testing

Conducted during the coding phase, general white-box testing, such as module interface function testing, local data structure testing, path testing, error handling testing, and boundary condition testing

Errors in the design stage are discovered. After the modules are assembled, the interface and communication between the modules are tested, usually black box testing.

Check whether the functions and performance of the software are consistent with the user's needs, based on the demand specifications, validity testing, software configuration review, and acceptance testing (analysis report, user manual, development summary report) in a simulated environment

Production environment testing, black box testing based on requirements specifications, covering all joint components, and evaluating the quality of software products

Including software, hardware, peripherals, data, support software, etc., specifically recovery testing, security testing, strength testing, performance testing, reliability testing, and installation testing

For product-type software, the @ developer is present and the customer implements the test, and the b developer is not present.

Purpose (evaluate system capabilities, identify weaknesses, system tuning, verify stability and reliability), type (load testing, strength testing, capacity testing)

Software requirements analysis, preparation of acceptance test plan and project acceptance criteria, test design and test case design, test environment construction, test implementation, result analysis, test report

Intermediary--Beijing Software Evaluation Center

Requirements analysis--Possible improvements and modifications are explained

Design phase - easy to expand, portable, reusable solution, object-oriented

Coding phase - annotation, quality, object-oriented

Testing phase--if the test is good, then the maintenance is good; all test-related documents are available

Maintenance phase - good configuration management and synchronized documents

Number of loops (source code complexity), software size, other factors