Do not think that you will be able to identify, analyze, specify and verify product requirements consistently and simultaneously, in one sitting. In practice, these actions are performed alternately, step-by-step and repeatedly. Working with clients as an analyst, you will ask questions, listen to the answers and observe the actions of clients (it is a requirements elicitation procedure). Next, you process the information received, classify it in different categories and correlate the needs of customers with possible software requirements (thus, conducting their analysis). Then you will receive information from clients and the requirements developed as written documents and diagrams (specification), ask the representatives of users to confirm that the text you wrote is accurate and complete, and ask them to correct possible errors (this refers to verification). So as you can see, the requirements development is an iterative process.
Due to the variety of software development projects and organizational cultures, there is no single, template approach to creating requirements. However, you can use a scheme for creating requirements, which thanks to reasonable corrections is suitable for most projects. As a rule, the actions are performed basically in sequence, but the process itself is not strictly consistent. The first seven actions are usually performed once in the early stages of the project (nevertheless, the development team will have to periodically change priorities). The rest are necessary for each next release or stage of work on the project. Automation testing company is almost always takes part in project development process so that to make it faster and more effective.
After evaluating the ways you can communicate with user representatives, select the appropriate methods for identifying requirements (roundtables, surveys, etc.) and plan the time and resources necessary to collect information. Many systems are created in stages, and therefore any team working on the project needs to determine the priorities for use cases and other user requirements. By setting priorities, you decide at which stage you should implement particular use cases. In the case of new systems or significant improvements, you can define and not specify the architecture in step 11, and in step 15, distribute the functional requirements for specific subsystems. Steps 12 and 17 are quality control operations, as a result of which you may have to return to correct errors, improve analysis models, or identify missing requirements. The prototypes created in step 13 often reveal the need to improve and modify previously defined requirements. After completing step 17 for any part of the requirements, it is possible to start implementing the corresponding part of the system. Repeat steps 8 –17 for the following sets of use cases that may be included in a later version of the product.
Add Comment