da conversao.No passo 1 do cenario principal (O caso de uso inicia Quando DeptVendas requer avalidacao do cliente) devemos indicar o responsavel pela execucao do mesmo.Apesar da especificacao do processo nao indicar o ator, possui comoEntidade Externa o DeptVendas, logo, ele e incluido como ator do Caso de Uso. Criar cliente Novo outros passos e realizada uma referencia a especificacao do processo, como por exemplo, em Se cliente encontrado, que foi representado pelo passo 2 O sistema verifica a existencia do cliente. Os fluxos de excecao sao tratados pelos casos de uso secundarios (include ou extend), associados ao caso de uso principal Validar Cliente. Caso de Uso Validar Cliente Objetivo Este caso de uso descreve o procedimento para que um cliente seja validado de acordo com sua situacao decorrente do credito Prioridade ( x )Essencial ( ) Secundario Pre-Condicoes Dados do cliente e Pedido do cliente incluido. Pos-Condicoes Pedido do Cliente Processado. Cenario Principal1. O caso de uso inicia Quando DeptVendas requer a validacao do cliente;2. O sistema verifica existencia do cliente (caso de uso checar cliente e incluido);3. O sistema verifica o credito do cliente (caso de uso checar credito e incluido);4. O sistema reune todos os pedidos do cliente (caso de uso reunir pedidos e incluido);5. O sistema cadastra todos os pedidos do cliente (caso de uso criar pedido cliente e incluido).Fluxos Secundarios Caso de Uso Pai Caso de Uso Subordinado Checar cliente Checar credito Reunir pedidos Criar pedido Tabela 4. Especificacao do Caso de Uso.c) Organizacao das Entradas e Saidas do Sistema esta diretriz tem por objetivo relacionar e validar as entradas e saidas do sistema. Este passo requer o auxilio da equipe ou responsavel pela manutencao do sistema, que indicara para cada entrada (em tela) e saida (relatorio existente) o usuario responsavel pela informacao.Deste modo, o engenheiro de software tera uma relacao de todos os atores (stakeholders) que sao afetados. d) Validacao dos Stakeholders esta diretriz tem por objetivo validar osstakeholders apontados. Deste modo, o engenheiro de software devecomparar com os atores ja identificados e realizar as alteracoesnecessarias nos casos de uso identificados.e) Organizar Casos de Uso esta diretriz tem por objetivo organizar os diagramas de caso de uso de acordo com as notacoes propostas pela UML. Casos de uso devem ser agrupados em pacotes ou pela especificacao de relacionamentos de generalizacao, inclusao e extensao, existentes entre os mesmos.4. Principais Dificuldades Presentes no Processo de TransicaoA experiencia ja ditava regras desde a Analise Estruturada, uma vez que apenas os analistas experientes tinham conhecimento para discernir o logico do fisico, pois os poucos que conseguiam aprender a fazer esta distincao, nao tinham sucesso em passar esta aptidao aos colegas.Na pratica, o que verificamos e que, com pouquissimas excecoes, as pessoas naoconseguem aprender uma nova metodologia de desenvolvimento com tanta facilidade.Para muitos analistas, uso do RUP envolve diversas dificuldades tecnicas e de origem pessoal. A realidade de nossas empresas, tanto privadas, quanto estatais ou do governo, como e o caso do Exercito Brasileiro, esta comecando a mudar. A experiencia de um dos autores do presente artigo no Exercito Brasileiro mostra