The question is: Should requirements analysis be part of the software project lifecycle?
The answer is yes and no. It is very important to distinguish two types of analysis, Business analysis and software analysis.
Business analysis should be a fast, lightweight, and continuous activity. The outcome of this activity is semi-analyzed requirements which are ready to be developed. Also, these requirements should be fully characterized in terms of customer priority, marketing impact, and technical risk, and any other requirement property that the organization sees important for planning. These requirements are backlogged till the team (customer and development) is ready to work on them.
Next, once a new project is to start, several requirements are pulled out of this backlog and they start getting developed. The strategy of selection depends largely on the business priority, and the technical risk. In other situations, it may depend on other requirement attributes, like the size, stability, et cetera.
What I have described so far is all analysis work that should not be considered part of a software project, and in the meanwhile, it constitutes about 60% of the analysis work.
On the other hand, there is still some analysis work that should be done on the project. This work is done by the developers who are going to work on design and development of the requirement. They should work face-to-face with the customer or may be a subject matter expert to dig into the details of the business, They should also make some prototyping and simulation to verify that the non-functional requirements will be met.
In all cases, they need to develop an iteration, deliver to the customer, and recieve feedback. This is all part of the analysis effort. See this post for more details.
No comments:
Post a Comment