Sempre que uma solicitação de mudança é aprovada um novo item deve ser criado na lista da aba de requisitos Isso garante que o escopo do projeto estará sempre atualizado. Após este ponto a mudança aprovada passa a ser tratada como qualquer outro requisito, respeitando o ciclo de vida destes itens.

Deve-se planejar o momento em que a mudança será realizada no projeto.

Uma mudança poder ser profunda (alterando desde o requisito até o código) ou superficial (alterando só a especificação do Caso de Uso).

No caso de uma mudanças de um Caso de Uso ainda não implementado a mudança é superficial, no entanto, pode afetar outros elementos já implementados. Esta mudança possui um impacto menor em tempo de implementação, uma vez que o conjunto de níveis de elementos alterados é menor, assim como o número de papeis para tratar a mudança. A implementação da mudança aqui é apenas no nível dos requisitos do software e não de implementação do código.

Já no caso um uma mudança profunda seu impacto é maior e a mudança tende a ser crítica. Sendo assim esta mudança não pode ser adiada.

Concluindo, não é uma boa opção adiar a implementação da mudança, isto poderia gerar retrabalho, uma vez que poderia estar sendo construído uma função que será alterada como impacto de mudanças futuras, além de aumentar a complexidade de gestão do projeto (mais ítens para gerenciar). Sendo assim, adotamos no processo que as mudanças são sempre implementadas nas iterações seguintes (considerando que a implementação muitas vezes será apenas de elementos da modelagem, no caso de mudanças superficiais).