Finalidade
  • Estabelecer um acordo sobre quais problemas precisam ser resolvidos.
  • Identificar os investidores para o sistema.
  • Definir os limites do sistema.
  • Descrever os principais recursos do sistema.
Função:  Analista de Sistemas  
Freqüência: Conforme necessário, normalmente uma vez por iteração na Iniciação e Elaboração e novamente verificada sempre que necessário em fases subseqüentes.
Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   

Detalhes de Detalhamento do Fluxo de Trabalho::   


Estabelecer Acordo sobre o Problema a Ser Resolvido Para o início da página

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?

  • Procure as causas raízes ou o "problema por trás do problemas". O verdadeiro problema costuma se esconder atrás do que é entendido como um problema.

Não aceite a primeira indicaçã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 utilizadas para localizar o problema por trás do problema são ../workguid/wg_brnst.htm -- This hyperlink in not present in this generated websitecoleta de idéias, ../workguid/wg_fish.htm -- This hyperlink in not present in this generated websitediagramas espinha de peixe e ../workguid/wg_paret.htm -- This hyperlink in not present in this generated websitediagramas de Pareto.

Identificar os Investidores Para o início da página

Dependendo do conhecimento de campo da equipe de desenvolvimento, a identificação dos investidores 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 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.  Eles serão mapeados para as funções dos atores humanos do sistema que está sendo desenvolvido. As informações iniciais sobre usuários-chave e seu ambiente devem ser registradas no documento Vision

Definir os Limites do Sistema Para o início da página

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.

Geralmente, é bastante eficaz utilizar atores para definir e descrever os limites do sistema. Consulte Atividade: Localizar Atores e Casos de Uso

Identificar as Restrições a Serem Impostas no Sistema Para o início da página

Há várias fontes de restrições que devem ser consideradas. Várias informações podem ser documentadas no artefato Especificação Suplementar . 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?

As informações reunidas aqui serão a entrada inicial para as restrições de design definidas nas Especificações Suplementares.

Formular a Indicação de Problema Para o início da página

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 <os investidores afetados pelo problema>.
O impacto causado é <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.

Exemplo:

O problema de: resolução inoportuna e incorreta de problemas de atendimento ao cliente
afeta: nossos clientes, os representantes de suporte ao cliente e os técnicos de serviços.
O impacto causado é: insatisfação do cliente, queda visível na qualidade, funcionários insatisfeitos e prejuízo na 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, oportunamente, somente para os locais que realmente precisem de assistência.

Definir Recursos do Sistema Para o início da página

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 .

Avaliar os Resultados Para o início da página

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 do documento Visão Atividade: Revisar Requisitos.



Rational Unified Process   2003.06.15