Current location - Education and Training Encyclopedia - Graduation thesis - What methods can verify the effectiveness of writing a paper on target tracking?
What methods can verify the effectiveness of writing a paper on target tracking?
From what aspects to verify the correctness of the requirements, the results of the work in the requirements analysis stage are an important basis for developing the system. A large number of statistics show that 15% of the errors in the system come from the wrong requirements. In order to improve the quality, ensure the success of development and reduce the development cost, once a set of requirements are put forward for the target system, the correctness of these requirements must be strictly verified. Generally speaking, it should be verified from the following four aspects: (1) Consistency All requirements must be consistent, and no requirement can contradict other requirements. (2) Integrity requirements must be complete, and specifications should include every function or performance required by users. (3) The requirements specified in reality should be basically achievable with the existing hardware technology and technology. We can predict the progress of hardware technology, but it is difficult to predict the progress of technology. We can only judge the reality of demand from the existing technical level. (4) Validity must prove that the requirements are correct and effective and can really solve the problems faced by users. Method of verifying requirements 1. Verifying the consistency of requirements When the results of requirements analysis are written in natural language, there is no better "testing" method except manual technical review to verify the correctness of system specifications. However, this informal specification is difficult to verify, especially when the target system is large in scale and the specification is long, the effect of manual review can not be guaranteed, and problems such as redundancy, omission and inconsistency may not be found and kept, which makes the development work unable to proceed smoothly on the correct basis. In order to overcome the above difficulties, people put forward a formal method to describe requirements. When the requirement specification is written in formal requirement statement language, tools can be used to verify the consistency of requirements, thus effectively ensuring the consistency of requirements. 2. Verifying the authenticity of requirements In order to verify the authenticity of requirements, analysts should refer to the previous experience of developing similar systems and analyze the possibility of realizing the target system with existing software and hardware technologies. When necessary, simulation or performance simulation technology should be used to help analyze the reality of the requirement specification. 3. Verify the completeness and validity of requirements Only the users of the target system really know whether the requirements specification describes their requirements completely and accurately. Therefore, testing the integrity of requirements, especially proving that the system really meets the actual needs of users (that is, the effectiveness of requirements), can only be completed with the close cooperation of users. However, many users can't clearly understand their own needs (especially when the system to be developed is brand-new and has no previous experience in using similar systems), and they can't effectively compare the sentences they need with the functions they actually need. Only when they have a working system that can be actually used and evaluated can they put forward their needs completely and accurately. The ideal way is to develop a system according to the results of demand analysis, let users try it for a period of time, let them realize what their actual needs are, and then write a formal "correct" specification. But this method will double the cost, so it is almost impossible to adopt this method in practice. Using the prototype system is a more realistic alternative, and the cost and time required to develop the prototype system can be much less than that required to develop the actual system. Users can also gain a lot of valuable experience by trying out the prototype system, thus putting forward more practical requirements.