Atividade:
| ||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Papel: Analista de Sistemas | |
| Mentores de Ferramentas: | |
| Diretrizes: | |
| Detalhamentos do Fluxo de Trabalho: |
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?
Depois, pergunte ao grupo mais uma vez: Qual é realmente o problema?
Não aceite a primeira descrição de um problema. Continue a perguntar "por quê?" para descobrir qual é "realmente" o 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. Depois, você poderá explorar se esses problemas são ou não "reais" na organização. As técnicas comuns usadas para encontrar o problema subjacente são brainstorming, diagramas espinha de peixe e diagramas de Pareto.
Dependendo do conhecimento de campo da equipe de desenvolvimento, a identificação dos envolvidos 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:
Comece a desenvolver perfis de usuários possíveis (ou reais) do sistema. Eles serão mapeados para os papéis dos atores humanos do sistema que está sendo desenvolvido. As informações iniciais sobre usuários-chave e o ambiente correspondente deverão ser registradas no documento Visão. Se a Modelagem de Negócios estiver sendo realizada como parte do projeto ou como um precursor dele, o Modelo de Casos de Uso de Negócios e o Modelo de Objetos de Negócios fornecerão informações valiosas nessa área.
A fronteira do sistema define o limite entre a solução e o mundo real que a cerca. Em outras palavras, essa fronteira 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, as fronteiras do sistema são óbvias. Por exemplo, as fronteiras de um único usuário, reduzir-ajustar o gerenciador de contatos pessoais executado no Microsoft Windows®, são relativamente bem definidas. 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 usa para documentar ou transmitir as informações resultantes.
Geralmente, é bastante eficaz usar atores para definir e descrever as fronteiras do sistema. Consulte Atividade: Localizar Atores e Casos de Uso. Vale mencionar novamente que o Modelo de Casos de Uso de Negócios e o Modelo de Objetos de Negócios poderão fornecer informações valiosas nessa área se a Modelagem de Negócios tiver sido realizada.
Existem diversas fontes de restrições a serem consideradas. Grande parte dessas informações pode ser documentada no artefato Regras de Negócios . A seguir, é fornecida uma lista das possíveis fontes e perguntas feitas:
As informações obtidas aqui serão a entrada inicial para as restrições de design definidas nas Especificações Suplementares.
Com todo o grupo, trabalhe com flip charts e preencha o template a seguir para cada problema identificado:
O problema de <descreva o problema>
afeta <os envolvidos afetados pelo problema>
e o impacto correspondente é <qual é o impacto do problema>.
Uma solução bem-sucedida seria <liste alguns benefícios-chave de uma solução bem-sucedida>.
O objetivo desse template é ajudar a distinguir soluções/respostas a partir de problemas/perguntas.
O problema de: resolução inoportuna e incorreta de problemas de atendimento ao cliente
afeta: nosso clientes, a equipe de suporte e os técnicos.
O impacto correspondente é: insatisfação do cliente, percepção de falta de qualidade, funcionários insatisfeitos e perda de receita.
Uma solução bem-sucedida seria: conceder à equipe de suporte técnico acesso em tempo real a um banco de dados de resolução de problemas e facilitar a designação de técnicos de serviço, de forma oportuna, somente para os locais que realmente precisem de assistência.
Com base nos benefícios listados nas descrições de problemas, desenvolva uma lista de recursos a serem incluídos no sistema. Descreva-os resumidamente e designe atributos a eles para ajudar a definir o seu estado geral e a sua prioridade no projeto (para obter mais informações sobre atributos, consulte Atividade: Gerenciar Dependências).
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 os pontos de verificação para esse documento em Atividade: Revisar Requisitos.
|
Rational Unified Process
|
