1. As consequências de não fazer a mudança.
- Ao avaliar uma solicitação de mudança, você deve considerar o que acontecerá se a mudança não for implementada.
- Se a mudança for associada a uma falha de sistema relatada, a gravidade da falha precisa ser levada em consideração.
- Se a falha de sistema causar a interrupção do sistema, isso é muito grave, e uma falha em fazer a mudança pode interromper a operação do sistema.
- Por outro lado, se a falha tem um efeito secundário, como cores incorretas em um display, então não é importante corrigir o problema rapidamente, de modo que a mudança deve ter uma prioridade baixa.
2. Os benefícios da mudança.
A mudança é algo que beneficiará muitos usuários do sistema ou é uma proposta que beneficiará principalmente o proponente da mudança?
3. O número de usuários afetados pela mudança.
Se apenas alguns usuários forem afetados, a mudança pode receber prioridade baixa. Na verdade, a mudança pode ser desaconselhada caso ela possa ter efeitos adversos sobre a maioria dos usuários de sistema.
4. Os custos de se fazer a mudança.
Se fazer a mudança afetar muitos componentes de sistema (aumentando, portanto, as chances de introdução de novos bugs) e/ou levar muito tempo para ser implementada, então ela pode ser rejeitada, dados os elevados custos envolvidos.
5. O ciclo de release de produto.
Se acaba de ser liberada uma nova versão do software para os clientes, pode fazer sentido atrasar a implementação da mudança até o próximo release planejado (veja a Seção 25.3).
O gerenciamento de mudanças para produtos de software (por exemplo, um produto de sistema CAD), ao invés de sistemas que são desenvolvidos especificamente para um determinado cliente, precisa ser tratado de forma ligeiramente diferente. Em produtos de software, o cliente não está diretamente envolvido nas decisões sobre a evolução de sistema, portanto, a relevância da mudança para o negócio do cliente não é um problema. As solicitações de mudança para esses