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?