Acceptance tests are based on user demand, and system testing is based on functional requirements, and integrated testing is based on system architectural structure. In the corresponding development phase, test activities must be planned and designated for each test design. It is impossible to truly test in the demand development phase, because there is no software that has not been executed. However, you can establish a conceptual test case basis based on the development group, and use them to discover the errors, erliness and omissions of the software requirements specifications, and model analysis. Demand verification is the fourth part of demand development (the rest three for acquisition, analysis and writing specification), the activities included in demand verification are to determine the following aspects: • Software requirements Specifications Correctly describe the expected system behavior And characteristics. • Software requirements are obtained from system requirements or other sources. • Demand is complete and high quality. • All views on demand are consistent. • Demand provides a sufficient foundation for continuing product design, constructors and testing. The best type of formal technical review is called the review (I N S P E C T I O N) (Ebenau and Strauss 1994; Gilb Andgraham 1993). Review of the demand document is the most advanced software quality technology available. Some companies have realized that it takes an hour to review the demand document or other software products, saving 10 hours of working hours (G R a D Y 1 9 4). I don't know which other software development or quality assessments can produce ten times recycling investment ratio. If you have a serious attitude towards improving the quality of the software, you will review each line of the written demand document. Although it is very bored with a detailed review of large demand documents and is also very expensive, people I know are consistent with the need to think that every minute they spend is worth it. If you think there is no time to review each aspect, then use a simple risk analysis model to distinguish between the demand documents, which parts are needed to review and those informal parts, as long as the informal review can meet the quality requirements.
