I have recently encountered a project. In the project, a new development team will be developed by the previous development group.
Enter an application. This new development team saw a software demand specifications made from 3 inch belt paper.
Since it is very fear, then write code immediately. In the process of constructing software, they have no reference software requirements specification,
Instead, according to their incomplete and incorrect understanding of the expected system, the design is based on their own imagination. therefore,
The project encountered many problems. Trying to understand this huge demand specification will definitely be fearful,
Moreover, requirements Specifications may not be perfect, but ignore the demand specifications will definitely lead to failure.
I know a very successful project. During the development of the project, developers listed the same as specific code versions.
Corresponding demand. The quality assurance group of the project performs test cases by controlling the requirements to evaluate their corresponding code versions.
According to the test standard, if it is not satisfied, it is an error. If the number of demands that do not satisfy exceeds pre-given
A number, or a specific significant problem is not satisfied, then this code block is rejected. This one
The success of the project is to use the demand document as the basis for the release of the product.
A software development project will eventually be issued to meet customer needs and expectations. The demand is the most essential step from the product concept to the road of satisfaction with the user. If you don't use high quality requirements as the basis for project planning, software design and system testing, then you will waste a lot of human and material in trying to develop outstanding products. However, do not become a slave of the demand process. Avoid falling into the trap of malformation analysis, at this time, the development team will spend a lot of time to create unnecessary documents and hold a variety of conferences and reviews, and do not write any software code, which will cause the project to be canceled. Strive to make a wise choice between exact specification and minus the risk of product failure to an acceptable degree of encoding.
