If you want to eat nuts, you must break their shells first. It is difficult to control the scope of demand in the demand stage. If it is not handled well, it will lead to disputes between the owner and the contractor, and even the project will be endless and cannot be accepted. Because when the project is accepted, it is often based on the tender documents, bidding documents, development contracts and demand achievement documents to determine whether the project meets the scope requirements. Often the bidding documents do not specify the scope of users' needs, and the contract is not clear. If the requirement achievement document is poorly written, the owner will think that the required functions have not been realized during the trial operation of the project, and the contractor will think that the user did not put forward the requirements at first, and then constantly revised and supplemented the requirements, and the project will never be accepted. In order to solve this problem, supervisors should play an important role. Suggestions are as follows: 1. Controlling the development mode of software is conducive to the acquisition of requirements: according to the complexity of the project and the basic situation of the owner's informatization, choose the development mode. If the complexity is high and the owner's information foundation is weak, the prototype method can be chosen. If time is tight and the contractor has experience, he can choose agile method. Second, skillfully guide the use of user demand specifications, coordinate and suggest owners and contractors. When conducting a demand survey, summarize the "demand questionnaire" to form a user demand specification to define the development scope and performance target requirements, and suggest the business department of the owner to sign and confirm its business requirements, and agree that the change scope is reasonable, such as 10%- 15%. If it is within this scope, a meeting minutes or memorandum will be formed for all parties to abide by. Third, based on the user's demand specification, check and review the development scope of the demand specification. This section mainly expounds the completeness of form and content. Only when the form and content meet the requirements can it be considered as a qualified requirement specification. First, the form is perfect, including perfect cover, clear version control information, reasonable, concise, accurate, professional, non-redundant, illustrated and so on. Second, the content is complete, including introduction (including purpose, scope, reading object, reference materials, abbreviations, abbreviations, relevant laws and regulations, etc.). ); Functional requirements; Non-functional requirements (including reliability, security, availability, ease of use, expansibility, maintainability, portability, etc.). ); Interface requirements, constraints and other documents have a reasonable structure, including operating environment, operating mode, fault handling, backup requirements, response speed, traffic, frequency and so on. One principle to grasp is: do not miss items. Pay attention to a higher level: grasping the three elements of the requirement specification is the first key to the audit. First of all, we must understand the influence of adopting structured method, object-oriented method and SOA architecture in software development on requirements specification. In addition to communicating with users, the requirement specification is the basis for the supervisor to control the project, the tester to test and the designer's basis and work guide. If the development method is structured, then "business flow", "data flow" and "data dictionary" in the requirements specification become its three indispensable elements, which are interlocking and mutually external. 1. Business flow chart: It should be consistent with the actual business of users and clearly expressed in standard graphics that users can easily understand. If it is complicated, it should be expressed by sub-graph layering, with simple principle and easy business understanding. The second is the data flow chart: first, it corresponds to the business flow chart one by one, and then the input or output tables involved should be clearly drawn, with reasonable table division and no redundancy. Pay attention to handling expressions when layering. Third, the data dictionary: actually, it is the corresponding data item in the input and output table in the data flow chart. What needs to be explained is to indicate the type or word length required by the data item. If it is an object-oriented method, there is no obvious boundary between requirements and design because of its iterative and seamless characteristics. Therefore, when reviewing the requirements specification, there should be at least use case diagrams, sequence diagrams, class diagrams, etc. And the information to be expressed should grasp the equivalence between the three elements of basic and structured methods. If the situation is complicated, there should be a state diagram, which is briefly described as follows: Use case diagram: It can clearly reflect the roles and use cases, and can correspond to the main functional items in the business process, usually. Sequence diagram: check the granularity of sequence diagram, which basically corresponds to business process and data process. It describes the process in chronological order, and can also be replaced by spatial order's collaboration diagram. Class diagram: Class diagram mainly describes data items, which can correspond to a structured data dictionary, but it is closer to nature and more adaptable to changes. Focus 2: It is particularly important to grasp the interface and security. Interface and security are the key and difficult points in software development. If it is not handled properly, it will plant a time bomb for the project. Even if we avoid it temporarily, the contradiction will soon be exposed. Grasping these two directions according to the actual situation of the project is also the focus of supervision and audit. Having written so much, I finally suggest completing the supervision report of Requirements Specification Review, and throwing a brick below, hoping to attract golden phoenix. About the requirement specification audit report Project name XXXX information management system construction project owner full name supervision full name contractor full name XX supervision company reviewed the requirement specification submitted by the contractor (including OA system requirement specification, website requirement specification and business system requirement specification) on XXXXX. Comments or suggestions are as follows: (If one of the three systems is not indicated, it means that the evaluation results of the three systems are the same. ) 1. demand goal: the "demand goal" part of the OA system demand specification fully describes the performance of the system, but the function description of the system is less, and the specific "what to do" is not clearly described in the goal. The "requirement goal" in the website requirement specification describes the function and performance. The "requirement target" in the business system requirement specification is relatively clear. 2. Content integrity: (1) Requirements analysis structure content: including compilation purpose, scope of application, terminology description, reference materials, system objectives, operating environment, requirements description, detailed requirements of functional modules, database performance requirements and application platform performance requirements. (2) Demand business content: subject to the owner's opinion (user demand specification). III. Functional requirements of the system: (1) Each business module has a business process description, but there are no business process details and optional processes and treatments; (2) The description of data flow is not clear; (3) The page requirement description is clear and in place; (4) The description of data items is more detailed; Meet the requirements; (5) The description of authority is relatively simple, and some are not clear; (6) Some function descriptions are too simple, such as the description in 8. 1.2 function overview in OA System Requirements Specification: "It includes functions such as browsing, publishing, modifying and deleting information." There is no explanation of what "information" refers to. (7) In the combined query, "query conditions" are not described. Fourth, the performance requirements of the system: the performance requirements are clearly described, including "operating environment", "hardware requirements" and "software requirements", but the requirements for security and internal and external networks are less described. V. Data requirements of the system: The functional aspects of OA system requirements specification are clearly described in the requirements of each sub-item, and the performance requirements are also described in special chapters, but there are few descriptions of data confidentiality and backup. The functional data in the website requirements specification are not described, and the performance requirements are also described in a special chapter. In the Business System Requirements Specification, the functional aspects are clearly described in each sub-item, and the performance requirements are also described in a special chapter, but the data confidentiality and backup are less described. Interface requirements of intransitive verb system: OA system requirements specification includes the description of interface, but the description of interface relationship between modules is weak. Interface is described in the website requirement specification, but the interface relationship between modules is weak. There is an interface description in the business system requirements specification, but the interface relationship between modules is weak. Eight. System design constraints: the design constraints in OA system requirements specification are weak. This aspect is described in the website requirements specification, but the performance is weak. This aspect is described in the business system requirements specification, but its performance is weak. Conclusion: The document structure of requirement specification basically conforms to the specification, but some elements need to be further refined and improved. XXXX supervision company