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.
No comments:
Post a Comment