Uma das formas mais simples de estabelecer um acordo sobre a definição do problema é registrá-lo por escrito e verificar se todos estão de acordo.

Pergunte ao grupo: Qual é o problema?

• É bastante comum as pessoas partirem logo para a definição da solução, em vez de levarem algum tempo para entender o problema primeiro. Registre o problema por escrito e veja se todos concordam com a definição.

Pergunte novamente ao grupo: Qual é realmente o problema?

• Procurar causas raiz ou o "problema atrás do problema". O verdadeiro problema costuma se esconder atrás do que é entendido como um problema.

Não aceite a primeira indicação de um problema. Continuar a perguntar "porque?" Explore a natureza do problema.

Às vezes, o grupo pode estar tão focado em uma solução imaginada que é difícil fazer com que formule o verdadeiro problema subjacente. Nesses casos, convém explorar os benefícios da solução e tentar encontrar os problemas que estão sendo solucionados por eles. Então, você poderá explorar se esses problemas são ou não "reais" na organização. As técnicas comuns utilizadas para localizar o problema atrás do problema são brainstorming, Diagramas de Espinha de Peixe e Diagramas de Pareto.

Dependendo do conhecimento de campo da equipe de desenvolvimento, a identificação das partes interessadas pode ser um passo comum ou incomum. Em geral, esta etapa abrange entrevistas com tomadores de decisão, possíveis usuários e outros grupos interessados. As seguintes perguntas são úteis:

• Quem são os usuários do sistema?
• Quem é o comprador ou demandante do sistema?
• Quem mais será afetado pelas saídas produzidas pelo sistema?
• Quem avaliará e aprovará o sistema quando for liberado e implantado?
• Será que existem outros usuários internos ou externos do sistema cujas necessidades precisam ser abordadas?
• Quem manterá o novo sistema?
• Existe mais alguém?
• Existe ainda mais alguém?

Inicie o desenvolvimento de perfis de usuários possíveis (ou reais) do sistema. As informações iniciais sobre usuários-chave e seu ambiente devem ser registradas no documento Visão.

Use a Cadeia de Resultados para entrevistar as partes interessadas críticas para o sucesso do seu projeto -- aquelas que você identificou no passo anterior -- de maneira a validá-la e identificar suas premissas, iniciativas e resultados adicionais de alta prioridade. Este passo é importante para o dimensionamento apropriado do sistema e para um posicionamento correto do projeto no portfólio de projetos da organização como um todo.

O limite do sistema define o limite entre a solução e o mundo real que a cerca. Em outras palavras, esse limite descreve um envelope que contém o sistema de soluções. As informações, na forma de entradas e saídas, são trocadas entre o sistema e os usuários que se encontram fora dele. Todas as interações com o sistema ocorrem por meio de interfaces entre o sistema e o mundo externo.

Em muitos casos, os limites do sistema são óbvios. Por exemplo, os limites de um único usuário, gerenciador de contatos pessoais compacto executado no Microsoft Windows® são relativamente bem definidos. Há somente um usuário e uma plataforma. As interfaces entre o usuário e o aplicativo são formadas por caixas de diálogo da interface de usuário que ele acessa para inserir informações no sistema, bem como por relatórios de saída e caminhos de comunicação que o sistema utiliza para documentar ou transmitir as informações resultantes.

Há várias fontes de restrições que devem ser consideradas. A seguir, é fornecida uma lista das possíveis fontes e perguntas feitas:

• Política: Existem problemas de política interna ou externa que afetam possíveis soluções? Entre departamentos?
• Econômica: Quais são as restrições financeiras ou orçamentárias aplicáveis? Existem custos de mercadorias vendidas ou considerações sobre a fixação de preços de produtos? Existem problemas de licenciamento?
• Ambiental: Existem restrições ambientais ou reguladoras? Legais? Existem outros padrões aos quais estamos restritos?
• Técnica: Há restrições nas opções de tecnologias? Estamos restritos a trabalhar dentro das plataformas ou tecnologias existentes? Somos proibidos de utilizar qualquer tecnologia nova?
• Viabilidade: O planejamento está definido? Estamos restritos aos recursos existentes? Podemos utilizar mão-de-obra externa? Podemos expandir os recursos? Temporariamente? Definitivamente?
• Sistema: A solução será construída nos sistemas existentes? Devemos manter a compatibilidade com as soluções existentes? Que sistemas operacionais e ambientes devem ser suportados?

A esta altura da tarefa você já realizou uma identificação abrangente das fronteiras do sistema, bem como das restrições impostas a ele. Esta informação foi fornecida pelos interessados críticos para o sucesso do projeto; provavelmente há incompatibilidades entre esses itens de informação.

Agora você precisa de uma fonte para identificar conflitos de modelos ("model clashes") que precisam ser conciliados entre as partes interessados em um conjunto de acordos ganha-ganha mutuamente satisfatórios. Você pode usar a Teia de Conflitos de Modelo como um checklist de alto nível representando esses conflitos.

Sumarize os resultados obtidos e coordene-os com as partes interessadas no documento de Visão.

Com todo o grupo, trabalhe com flip charts e preencha o gabarito a seguir para cada problema identificado:

O problema de <descrever o problema>
afeta <as partes interessadas afetados pelo problema>.
O impacto causado é <qual é o impacto do problema>.
Uma solução bem-sucedida <listaria lguns benefícios-chave de uma solução bem-sucedida.>.

O objetivo desse modelo é ajudar a distinguir soluções/respostas a partir de problemas/perguntas.

Exemplo:

O problema de: resolução fora de hora e imprópria de problemas de serviço ao cliente
afeta: nossos clientes, os representantes de suporte ao cliente e os técnicos de serviços.
o impacto disso é: insatisfação do cliente, queda visível na qualidade, funcionários insatisfeitos e perda de receita.
Uma solução bem-sucedida seria: fornecer acesso em tempo real a um banco de dados de resolução de problemas, através de representantes de suporte e facilitar o dispatch de técnicos de serviço, na hora certa, somente para os locais que realmente precisem de sua assistência.

Com base nos benefícios listados nas indicações de problemas, desenvolva uma lista de recursos que deseja no sistema. Descreva-os resumidamente e forneça atributos a eles para ajudar a definir o seu estado geral e a sua prioridade no projeto.

Nesta etapa, consulte o documento Visão para verificar se o trabalho está na direção certa, mas não efetue uma revisão detalhada. Considere a lista de verificação para o documento Visão (Lista de Verificação: Visão).