We all know requirements change, and there are classic reasons why that happens: change of environment, change of management, change of budgeting, new users may be added to the stakeholders, .... On top of all that, users and customers change their mind about the system requirements. In the early development cycles they may show interest in some features, later, as soon as they see the real system implemented, they may change their mind and express interest in some other features.
Well, the story comes from the psychology of human minds. Even if I ask you sort four available fruits in the order you like to have them, you may say: Orange, apple, banana, watermelon, and then I take out watermelon from the list of available fruits, you may change the sort and say, well, if watermelon is not available any more I'll rather have apple, banana, and then orange ! Why preferences sometimes depend on what are the available options?
It is wrong to assume stakeholders have some fixed preferences about the requirements. They have some hidden criteria for evaluating the elements and requirements that we may not know about. In the case of fruits, you may not know, but someone wants to have watermelon at the end because it is juicy, but once watermelon is not in the list, the individual rather to have the other juicy fruit (orange) at the end, so changes the sort for you ! The same thing happens when dealing with software requirements. Users show interests in some features while having some hidden goals and criteria in their mind.
Well, now the question is when asking the stakeholders to rank the requirements, features, or alternative solutions, do we need to uncover their rationale behind these preferences? And if we do, the more the criteria of comparisons and rationale of preferences are more explicit, the more accurate are the preferences we extracted?
Subscribe to:
Post Comments (Atom)
1 comment:
Personally, I prefer the approach of methods such as ATAM in which they explicitly tell the stakeholder the rationale behind prioritizing the requirements and then they try to analyze and solve any inconsistency and conflict in the existing rankings among stakeholders in brainstorming workshops. (e.g. in case of ATAM, the stakeholder prioritize the quality attributes based on ease of implementation and importance).
In my practice, I specify the existing criteria and the exact definition of each criteria. In some cases, we may define criteria and sub-criteria. Also, I utilize brainstorming workshops for reaching to conclusion about the priority of each feature and/or requirement.
I think that if we do not specify the logic, we can not reach to a useful result.
BTW, I enjoyed reading your blog. Please invite others to contribute and keep writing and share your experience with others.
Post a Comment