Monday, August 18, 2008

Why Requirements Change?

Requirements change because this is the norm. We should never think that frequent requirements changes are sign of poor analysis capability of the team. This is one of the killing mistakes that managers used to do with the development teams!

Two reasons govern this change:

Rule #1: No Customer fully understands the requirements. At best, the customer understands the business problem; and in most cases, he cannot articulate it. What should be done is to implement part of the requirement (potentially the user interface), and let him work on it for a while to get a feeling of the solution, then start a second round of analysis.

Rule #2: the Customer is not a single person. This is always overlooked. This is why RUP says that the customer community should be dissected into groups, and each group should have at least one representative in the customer group.

The project leader/manager/master (call it whatever you like) is the responsible person to enforce these two rules. For the first rule, he should break down the vague requirements into small ones and plan for several iterations, after each of them, he goes back to the customer and get more feedback. For the second rule, he should make sure that all groups of users are represented in the customer group.

Monday, August 11, 2008

Pulling Requirements Analysis out of the project lifecycle !

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.