SISTEMA ALVORADA MOTOS Processo de Engenharia de Requisitos Empresa: Arco Verde Veículos Ltda

Transcrição

1 Unioeste Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática SISTEMA ALVORADA MOTOS Processo de Engenharia de Requisitos Empresa: Arco Verde Veículos Ltda Projeto e Engenharia de Software I (PESI) 3º Ano do Curso de Bacharelado em Informática CASCAVEL 2006

2 Douglas Antoniazi Jonny C. Model Kleberson H. Angelossi Rodrigo A. Gonzato ESPECIFICAÇÃO DE REQUISITOS E MODELAGEM ORIENTADA A OBJETO Professor: Victor Francisco Araya Santander CASCAVEL

3 ÍNDICE Motivação...01 Introdução Requisitos Funcionais...03 Modelagem Organizacional(I*)...05 Modelo de Dependências Estratégicas...05 Modelo de Razões Estratégicas...07 Requisitos Não Funcionais (NFR) Diagrama De Caso De Uso Diagrama De Classe Conclusão Apêndice A...30 Formulário Relatório da Equipe

4 MOTIVAÇÃO Atualmente o modo de operação utilizado na empresa faz uso de métodos de atendimento e gerenciamento administrativo um tanto quanto arcaicos. A ausência de métodos eficientes, ou a utilização de métodos ineficientes implica em maiores despesas operacionais, desperdício de tempo, baixa qualidade nos serviços oferecidos aos clientes e insatisfação dos funcionários que dependem da disponibilidade e do bom funcionamento dos recursos de informática da empresa para realizar seu trabalho. Tudo isso se traduz em ineficiência e alto custo operacional, que precisam ser evitados pelas organizações. A empresa Arco Verde Veículos Ltda., observando a constante modernização, melhora nos serviços prestados e otimização das empresas concorrentes se viu na necessidades de implantar um sistema de informação que possibilite à empresa uma melhora nos seus serviços e operações de modo a equipara-la a suas concorrentes. O foco deste trabalho esta na tentativa de melhorar o atendimento e possivelmente com isso aumentar o volume de vendas, controle de entrada e saída dos produtos da empresa visando evitar possíveis falhas. Para isso propõem-se estudar a viabilidade de desenvolvimento do sistema, processo engenharia de requisitos e outras etapas de projeto para a futura implantação de tal sistema de informação. 4

5 INTRODUÇÃO A empresa escolhida para desenvolver o projeto de prática de processo de engenharia de software I(parte II-Especificação de Requisitos e Modelagem Orientada a Objeto) foi a Alvorada Motos. Ela possui duas lojas em Cascavel-Paraná, uma central na avenida Brasil número 4646, centro, CEP , e outra filial na avenida Piquiri número 222, centro, CEP Atua com razão social Arco Verde Veículos Ltda. e CNPJ número / A Alvorada Motos trabalha na área de comércio de motocicletas novas e usadas de marcas e modelos diversos, realizando compra, venda e consignação. Além disso, atua como representante do consórcio Araucária. A empresa não possui nenhum sistema de informação implantado, todas as atividades de operação como venda, controle de estoque, arquivo dos produtos, informação de funcionários, e entre outras, são realizadas manualmente. Sendo assim, propõe-se a implantação de sistema que otimize todas as operações realizadas dentro da empresa e ainda facilite a comunicação entre a matriz e filial, que atualmente é feita apenas por telefone. O sistema proposto será implementada na plataforma Windows com as seguintes características: cada vendedor utilizará de um computador para preenchimento de pedidos, verificação da disponibilidade de produtos e encaminhamento de pedido de confirmação de compra e venda junto aos gerentes; o meio de comunicação entre a matriz e sua filial será via internet, possibilitando uma consulta única a produtos em estoque, assim como um cálculo único de lucros; os gerentes também usarão um computador, mas com privilégios fornecidos pelo sistema em relação aos funcionários através de uma política de login/senha. Este documento será apresentado um estudo detalhado dos Requisitos Funcionais, NãoFuncionais e modelagem organizacional (i*) do Sistema Alvorada Motos. Além dos diagramas de Casos de Uso e de Classe usando o padrão UML, que facilitam a visualização no processo de Engenharia de Requisitos e auxiliar em um melhor projeto de sistema orientado a objetos. O processo de coleta de informações sobre a empresa está detalhado no apêndice A. 5

6 REQUISITOS FUNCIONAIS Como citado anteriormente os requisitos funcionais de um sistema são a descrição das diversas funções que a empresa e usuários do sistema queiram ou precisam que o software faça. Nesta primeira parte são exibidos os requisitos funcionais do sistema da empresa Alvorada Motos, assim como uma breve descrição dos mesmos. Esses requisitos foram eliciados, avaliados e validados junto ao Stakeholders envolvidos no projeto. [RF-01] Cadastrar Cliente O sistema poderá cadastrar um novo cliente com todos os dados a seguir: nome; endereço; telefone; CPF; RG; habilitação; e título de eleitor. Caso o cliente já esteja cadastrado, o sistema deverá mostrar uma mensagem informando sua existência. [RF-02] Remover Cliente A remoção de um cliente poderá ser realizada a partir de seu nome ou CPF. Caso o cliente não exista, o sistema deverá imprimir uma mensagem relatando o fato. [RF-03] Alterar Dados do Cliente O sistema oferecerá a opção do usuário realizar alterações cadastrais de clientes, como endereço, telefone, entre outros. Esta poderá ser realizada a partir de uma busca por nome ou CPF. [RF-04] Consultar Cliente A consulta a um cliente se realizará através de seu nome ou CPF. O resultado da será exibido na tela. [RF-05] Logar no Sistema Todas as funcionalidades do sistema são acessíveis aos usuários de acordo com seu nível de privilégio no sistema. Isto é realizado através de um sistema de Login/Senha. [RF-06] Cadastrar Produto Todo produto adquirido pela empresa deve ser cadastrado no seu banco de dados. Motocicletas não cadastradas não estarão disponíveis para a venda. O cadastro de cada motocicleta nova deve conter as seguintes informações: preço, fabricante, ano de fabricação; placa; modelo; RENAVAN; IPVA; Licenciamento; Seguro Obrigatório. Para motocicletas usadas serão acrescidos as seguintes informações: último proprietário; quilometragem; avaliação. [RF-07] Remover Produto A remoção de uma motocicleta poderá ser realizada a partir de sua placa. Caso o produto não exista, o sistema deverá imprimir uma mensagem relatando o fato. 6

7 [RF-08] Alterar Dados do Produto O sistema oferecerá a opção do usuário realizar alterações cadastrais de produtos, como preço, avaliação e cor. Esta poderá ser realizada a partir de uma busca pela placa. [RF-09] Consultar Produto A consulta a um produto se realizará através de sua placa. O resultado será exibido na tela. [RF-10] Cadastrar Funcionário Todo funcionário contratado pela empresa deve ser cadastrado. O cadastro de cada funcionário deve conter as seguintes informações: nome, RG, CPF, título de eleitor, habilitação, endereço, telefone e dados trabalhistas. Após sua contratação, ele receberá um login e uma senha para usar o sistema. [RF-11] Remover Funcionário A remoção de um funcionário poderá ser realizada a partir de seu nome. Caso o funcionário não exista, o sistema deverá imprimir uma mensagem relatando o fato. [RF-12] Alterar Dados do Funcionário O sistema oferecerá a opção do gerente realizar alterações cadastrais dos funcionários, como telefone, endereço, entre outros. Esta poderá ser realizada a partir de uma busca por nome. [RF-13] Consultar Funcionário A consulta a um funcionário se realizará através de seu nome. O resultado será exibido na tela. [RF-14] Cadastrar Fornecedor Todos os fornecedores da empresa devem ser cadastrados. O cadastro de cada fornecedor deve conter as seguintes informações: razão social, CNPJ, , telefone e endereço. [RF-15] Remover Fornecedor A remoção de um fornecedor poderá ser realizada a partir de sua razão social ou CNPJ. Caso o fornecedor não exista, o sistema deverá imprimir uma mensagem relatando o fato. [RF-16] Alterar Dados do Fornecedor O sistema oferecerá a opção do gerente realizar alterações cadastrais dos fornecedores, como telefone, endereço, entre outros. Esta poderá ser realizada a partir de uma busca por razão social ou CNPJ. [RF-17] Consultar Fornecedor A consulta a um fornecedor se realizará através de sua razão social ou CNPJ. O resultado será exibido na tela. [RF-18] Verificação de Estoque 7

8 O sistema possibilitará a consulta ao estoque para verificar a disponibilidade de cada produto. Tanto na matriz, quanto na filial. [RF-19] Imprimir Nota Fiscal Caso seja necessário imprimir novamente uma nota fiscal, o sistema oferece a opção de somente reimprimir a nota de um venda já realizada. [RF-20] Venda Para efetuar uma venda o sistema oferece os seguintes passos: definir tipo de venda (à prazo ou à vista); definir o produto; verificar estoque; consultar crédito do cliente; solicitar autorização do gerente; e por fim, imprimir nota fiscal. Após efetuada a venda, o produto será removido do estoque. Caso não haja mercadoria no estoque, é feita uma notificação ao gerente, e o mesmo faz compra da motocicleta direto do fornecedor. [RF-21] Gerar relatório Poder-se-á imprimir ou visualizar (na tela) relatórios específicos (vendas, compras, estoque, clientes, fornecedores, funcionários). Estes somente poderão ser solicitados pelo gerente. [RF-22] Pagamento de Prestação Quando o cliente pagar uma prestação de uma venda à prazo, o sistema irá requerer seus dados, e após o pagamento imprimir-se-á um recibo. [RF-23] Solicitar Autorização O gerente deverá emitir uma autorização ao funcionário para que a venda seja concretizada. MODELAGEM ORGANIZACIONAL i* Apresentaremos nesta sessão uma modelagem organizacional a partir da técnica i*, utilizando os modelos: SD (Modelo de Dependências Estratégicas) figura 1 e SR (Modelo de Razões Estratégicas) figura 2. Modelo de Dependências Estratégicas A partir de uma visão macro do modelo note-se que é composto de seis atores, sendo que a utilização direta do sistema é feita apenas pelos autores gerente e vendedor, essa interação é especificada pelas dependências destes com o ator sistema. 8

9 Figura 1: Modelo de Dependências Estratégicas (SD) 9

10 O ator vendedor interage com o ator sistema, para isso ele necessita logar no sistema, sendo necessária entrada de usuário e senha. Após logado no sistema ele tem permissão de realizar algumas tarefas: operações com clientes, efetuar pagamentos, verificar estoque, e realizar venda, sendo a mesma só concretizará após obter autorização do gerente. Todas estas operações para não impor dificuldade ao usuário na utilização do sistema é necessário que ele tenha uma boa usabilidade. Por haver grande fluxo de dados entre os atores, sendo que o sistema tem uma dependência de obter dados junto ao vendedor, é necessário que esta comunicação seja feita de forma segura e ágil.. O ator gerente pode ser considerado um funcionário especializado, sendo assim ele poderá executar todas as operações de um funcionário comum, para isto ele faz uso de um login/senha diferenciado. Esta especialização é denotada com a ligação ISA entro os atores. Além das operações herdadas do ator vendedor, ele se relaciona com o ator sistema ao fazer uso das funções: operações com produtos, relatórios, operações com fornecedores, estas sendo essenciais ao funcionamento da organização. Uma dependência do sistema junto ao gerente é a obtenção de autorização de venda, visto que este é um requisito essencial do sistema ele requer um alto nível de segurança, integridade dos dados transmitidos, e um boa performance. O ator fornecedor atende as dependências do ator gerente quanto a aquisição de produtos e a disponibilidade dos dados para efetuar o cadastro do mesmo. O ator cliente depende do ator vendedor para ser bem atendido, caso este seja um novo cliente o vendedor necessita de seus dados cadastrais para assim efetuar uma possível compra de produto. Caso o cliente adquire um produto a prazo ele dependera do ator vendedor para pagamento de prestações. Ao comprar um produto o vendedor deverá fornecer ao cliente a nota fiscal do mesmo. Para que o sistema seja rápido, com dados íntegros e confiáveis ele dependera da qualidade do sistema gerenciador de banco de dados. Modelo de Razões Estratégicas O modelo SR (figura 2), complementa o modelo SD de forma a compreender e modelar de maneira mais detalhada as razões associadas com cada ator e suas dependências. Percebem-se pela expansão do ator sistema, a tarefa logar é necessário que usuário forneça um login e senha. Já as operações com fornecedores, clientes, produtos e funcionários têm as mesmas subdivisões, que são: cadastrar, modificar, remover e consultar. Para se concretizar uma venda alguns passos são necessários: selecionar o tipo venda, buscar o produto no estoque (caso não encontre repassar pedido ao gerente), solicitar pedido de autorização de venda, emitir nota fiscal e retirar produto do estoque. Ao efetuar o pagamento de uma prestação, deve-se definir o cliente, verificar parcela e logo após, imprimir comprovante. Outra seria a geração de Relatórios e Históricos de Vendas e saída de produtos para determinado cliente, que serão verificadas posteriormente pelo gerente da empresa. 10

11 Figura 2: Modelo de Razões Estratégicas (SR) 11

12 REQUISITOS NÃO-FUNCIONAIS (NFR) Os requisitos não funcionais (NFRs), que objetiva explanar como os requisitos funcionais serão implementados e ainda relacionar com seus aspectos de qualidade, do sistema Alvorada Motos divide-se em: requisitos do processo(referente ao modo de desenvolvimento), requisitos do produto(relacionado com as características e qualidades) e requisitos externos(derivados do ambiente externo:aspectos legais e econômicos). Requisitos do processo [RNF-01] O sistema será implementado na linguagem Java (orientada a objetos) com suporte para a plataforma Windows. [RNF-02] A implementação seguirá todas as restrições e passos descritos na documentação do sistema. Requisitos do produto Quanto a segurança: [RNF-01] A confidencialidade dos dados será implementada por um sistema de login e senha, em que cada funcionário terá acesso as funcionalidades e aos dados conforme seu cargo. [RNF-02] A integridade dos dados será mantida pela utilização do banco de dados SQL SERVER. [RNF-03] A disponibilidade será mantida por um servidor 24 horas, sendo que o acesso ao SQL SERVER será feito por login e senha. Quanto à usabilidade: [RNF-01] O sistema possuirá uma interface padronizada, com informações e funcionalidades objetivas. [RNF-02] Haverá teclas de atalho para acesso mais rápido aos dados e as funcionalidades mais utilizadas. [RNF-03] Um manual de ajuda auxiliará os usuários com informações detalhadas de como operar os sistema e seus dados. Quanto a performance: [RNF-01] O espaço a ser utilizado será de acordo com o banco de dados SQL SERVER. [RNF-02] O tempo de uma operação dependerá dos recursos dos computadores (processadores, memória, etc.), do tipo de rede, da conexão ADSL, da linguagem (Java) e da autorização do gerente (para algumas operações). Entretanto, o tempo deve ser mínimo para melhor atender o cliente. Requisitos externos [RNF-01] O custo de toda a implementação do sistema deve ser de no máximo R$27080, 00, valor previsto no Estudo de Viabilidades. [RNF-02] Todas as compras e vendas realizadas pela empresa deverão estar de acordo com as regulamentações do estado. 12

13 Grafo SIG O grafo SIG (Softgoal Interdependency Graph) abaixo fornece uma representação sistemática e global dos requisitos não funcionais, apresentando suas decomposições e operacionalizações. Além disso, mostra o inter-relacionamento entre os requisitos, bem como as contribuições positivas e negativas das operacionalizações. Figura 3: Grafo SIG(Softgoal Interdependency Graph) 13

14 CASOS DE USO Este diagrama mostra como os atores vão interagir com o sistema a ser desenvolvido. Ele é importante porque será a base do processo de desenvolvimento do sistema. O diagrama de classes especifica a estrutura do domínio e do sistema, os casos de usos vão ser a entrada para formalizar as funcionalidades que o sistema deve cumprir. Um caso de uso descreve as operações que o sistema deve cumprir para cada usuário. Ele vai ajudar a formalizar as funções que o sistema precisa fazer. Nesta sessão descreveremos os Casos de Uso do Sistema através de descrições textuais detalhadas e de um diagrama de Casos de Uso. Figura 4: Diagrama de Casos de Uso 14

15 Caso de uso 1: CADASTRAR FUNCIONÁRIO Objetivo no Contexto: Realizar a inserção de um funcionário. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Funcionário cadastrado com sucesso Condição Final de Falha: Funcionário não cadastrado e gerente notificado da impossibilidade de cadastro. Ator Primário: Gerente Passo 1: Obter os dados cadastrais do funcionário. Passo 2: O sistema insere os dados no Banco de Dados. Passo 3: O sistema emiti mensagem de cadastro efetuado. Passo 2.1: Falha no acesso ao banco de dados: o sistema cancela o cadastro e notifica o erro ao gerente. Passo 2.2: Funcionário já cadastrado: o sistema cancela o cadastro e notifica o erro ao gerente. Prioridade: média. Freqüência: baixa. Caso de uso 2: REMOVER FUNCIONÁRIO Objetivo no Contexto: Realizar a remoção de um funcionário. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Funcionário removido com sucesso Condição Final de Falha: Funcionário não removido e gerente notificado da impossibilidade de remoção. Ator Primário: Gerente Passo 1: Dados do funcionário a ser excluído. Passo 2: O sistema busca o funcionário a ser excluído. Passo 3: O sistema remove o cadastro do Banco de Dados. Passo 4: O sistema emite mensagem de funcionário removido. Passo 2: Funcionário não localizado: o sistema cancela a operação e notifica a inexistência do funcionário ao gerente. Passo 3: Falha no acesso ao banco de dados: o sistema cancela a remoção e notifica o erro ao gerente. Prioridade: média. Freqüência: baixa. 15

16 Caso de uso 3: ALTERAR FUNCIONÁRIO Objetivo no Contexto: Alterar dados cadastrais do funcionário. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Dados alterados com sucesso. Condição Final de Falha: Dados não alterados e erro notificado. Ator Primário: Gerente Passo 1: Dados do funcionário a ser alterado. Passo 2: O sistema busca o funcionário a ser alterado. Passo 3: O sistema acessa os dados no Banco de Dados. Passo 4: Alterar os dados. Passo 5: O sistema atualiza o Banco de Dados. Passo 6: O sistema emite mensagem de dados cadastrais atualizados. Passo 2: Funcionário não localizado: o sistema cancela a operação e notifica a inexistência do funcionário ao gerente. Passo 3 : Falha no acesso ao banco de dados: o sistema cancela a exibição e notifica o erro ao gerente. Passo 5: Falha no acesso ao banco de dados: o sistema cancela a exibição e notifica o erro ao gerente. Prioridade: média. Freqüência: baixa. Caso de uso 4: CONSULTAR FUNCIONÁRIO Objetivo no Contexto: Consultar dados cadastrais do funcionário. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Funcionário consultado com sucesso. Condição Final de Falha: Funcionário não consultado e erro notificado. Ator Primário: Gerente Passo 1: Dados do funcionário a ser consultado. Passo 2: O sistema busca o funcionário a ser consultado. Passo 3: O sistema acessa os dados no Banco de Dados. Passo 4: O sistema exibe a consulta. Passo 2: Funcionário não localizado: o sistema cancela a operação e notifica a inexistência do funcionário ao gerente. Passo 3 : Falha no acesso ao banco de dados: o sistema cancela a exibição e notifica o erro ao gerente. Prioridade: média. 16

17 Freqüência: baixa. Caso de uso 5: RELATÓRIOS ESPECÍFICOS Objetivo no Contexto: Realizar a exibição ou impressão de relatórios restritos ao gerente. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Relatório exibido ou impresso com sucesso. Condição Final de Falha: Relatório não exibido ou não impresso e erro notificado. Ator Primário: Gerente Passo 1: O gerente seleciona o tipo de relatório de: vendas, compras, estoque, clientes, fornecedores, funcionários. Passo 2: O sistema acessa o Banco de Dados. Passo 3: Selecionar modo de exibição. Passo 4: O sistema exibe o relatório. Passo 2: Falha no acesso ao banco de dados: o sistema cancela exibição e notifica o erro ao gerente. Passo 4: Falha de hardware de impressão: o sistema cancela exibição do relatório e erro é notificado. Prioridade: alta. Freqüência: média. Caso de uso 6: CADASTRAR FORNECEDOR Objetivo no Contexto: Realizar a inserção de um fornecedor. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Fornecedor cadastrado com sucesso Condição Final de Falha: Fornecedor não cadastrado e gerente notificado da impossibilidade de cadastro. Ator Primário: Gerente Passo 1: Obter os dados cadastrais do fornecedor. Passo 2: O sistema insere os dados no Banco de Dados. Passo 3: O sistema emite mensagem de cadastro efetuado. Passo 2.1: Falha no acesso ao banco de dados: o sistema cancela o cadastro e notifica o erro ao gerente. Passo 2.2: Fornecedor já cadastrado: o sistema cancela o cadastro e notifica o erro ao gerente. Prioridade: média. Freqüência: média. 17

18 Caso de uso 7: REMOVER FORNECEDOR Objetivo no Contexto: Realizar a remoção de um fornecedor. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Fornecedor removido com sucesso Condição Final de Falha: Fornecedor não removido e gerente notificado da impossibilidade de remoção. Ator Primário: Gerente Passo 1: Dados do fornecedor a ser excluído. Passo 2: O sistema busca o fornecedor a ser excluído. Passo 3: O sistema remove o cadastro do Banco de Dados. Passo 4: O sistema emite mensagem de fornecedor removido. Passo 2: Fornecedor não localizado: O sistema cancela a operação e notifica a inexistência do funcionário ao gerente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a remoção e notifica o erro ao gerente. Prioridade: média. Freqüência: baixa. Caso de uso 8: ALTERAR FORNECEDOR Objetivo no Contexto: Alterar dados cadastrais do fornecedor. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Dados alterados com sucesso. Condição Final de Falha: Dados não alterados e erro notificado. Ator Primário: Gerente Passo 1: Dados do fornecedor a ser alterado. Passo 2: O sistema busca o fornecedor a ser alterado. Passo 3: O sistema acessa os dados no Banco de Dados. Passo 4: Alterar os dados. Passo 5: O sistema atualiza o Banco de Dados. Passo 6: O sistema emite mensagem de dados cadastrais atualizados. Passo 2: Fornecedor não localizado: O sistema cancela a operação e notifica a inexistência do fornecedor ao gerente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a exibição e notifica o erro ao gerente. Passo 5: Falha no acesso ao banco de dados: O sistema cancela a exibição e notifica o erro ao gerente. 18

19 Prioridade: média. Freqüência: baixa Caso de uso 9: CONSULTAR FORNECEDOR Objetivo no Contexto: Consultar dados cadastrais do fornecedor. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Fornecedor consultado com sucesso. Condição Final de Falha: Fornecedor não consultado e erro notificado. Ator Primário: Gerente Passo 1: Dados do fornecedor a ser consultado. Passo 2: O sistema busca o fornecedor a ser consultado. Passo 3: O sistema acessa os dados no Banco de Dados. Passo 4: O sistema exibe a consulta. Passo 2: Fornecedor não localizado: o sistema cancela a operação e notifica a inexistência do fornecedor ao gerente. Passo 3 : Falha no acesso ao banco de dados: o sistema cancela a exibição e notifica o erro ao gerente. Prioridade: média. Freqüência: baixa. Caso de uso 10: CADASTRAR PRODUTO Objetivo no Contexto: Realizar a inserção de uma motocicleta. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Motocicleta cadastrada com sucesso Condição Final de Falha: Motocicleta não cadastrada e gerente notificado da impossibilidade de cadastro. Ator Primário: Gerente Passo 1: Obter os dados da motocicleta. Passo 2: O sistema insere os dados no Banco de Dados. Passo 3: O sistema emite mensagem de cadastro efetuado. Passo 2.1: Falha no acesso ao banco de dados: O sistema cancela cadastro e notifica o erro ao gerente. Passo 2.2: Produto já cadastrado: o sistema cancela o cadastro e notifica o erro ao gerente. Prioridade: alta. Freqüência: alta. 19

20 Caso de uso 11: ALTERAR PRODUTO Objetivo no Contexto: Alterar dados da motocicleta. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Dados alterados com sucesso. Condição Final de Falha: Dados não alterados e erro notificado. Ator Primário: Gerente Passo 1: Dados da motocicleta a ser alterada. Passo 2: O sistema busca motocicleta a ser alterada. Passo 3: O sistema acessa dados no Banco de Dados. Passo 4: Alterar os dados. Passo 5: O sistema atualiza o Banco de Dados. Passo 6: O sistema emite mensagem de dados atualizados. Passo 2: Motocicleta não localizada: O sistema cancela a operação e notifica a inexistência do funcionário ao gerente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a exibição e notifica o erro ao gerente. Passo 5: Falha no acesso ao banco de dados: O sistema cancela a exibição e notifica o erro ao gerente. Prioridade: alta. Freqüência: baixa. Caso de uso 12: REMOVER PRODUTO Objetivo no Contexto: Realizar a remoção de uma motocicleta. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Motocicleta removida com sucesso Condição Final de Falha: Motocicleta não removida e gerente notificado da impossibilidade de remoção. Ator Primário: Gerente Passo 1: Dados da motocicleta a ser excluída. Passo 2: O sistema busca a motocicleta a ser excluída. Passo 2: O sistema remove o cadastro do Banco de Dados. Passo 3: O sistema emite mensagem de motocicleta removida. Passo 1: Motocicleta não localizada: O sistema cancela a operação e notifica a inexistência da motocicleta ao gerente. 20

21 Passo 2: Falha no acesso ao banco de dados: O sistema cancela a remoção e notifica o erro ao gerente. Prioridade: alta. Freqüência: alta Caso de uso 13: CONSULTAR PRODUTO Objetivo no Contexto: Consultar dados cadastrais do produto. Pré-condições: Logado ao sistema. Condição Final de Sucesso: Produto consultado com sucesso. Condição Final de Falha: Produto não consultado e erro notificado. Ator Primário: Gerente ou funcionário Passo 1: Dados do Produto a ser consultado. Passo 2: O sistema busca o produto a ser consultado. Passo 3: O sistema acessa os dados no Banco de Dados. Passo 4: O sistema exibe a consulta. Passo 2: Produto não localizado: o sistema cancela a operação e notifica a inexistência do produto. Passo 3 : Falha no acesso ao banco de dados: o sistema cancela a exibição e notifica o erro. Prioridade: média. Freqüência: alta. Caso de uso 14: AUTORIZAR VENDA Objetivo no Contexto: Emitir autorização de venda ao funcionário. Pré-condições: Gerente logado ao sistema. Condição Final de Sucesso: Autorização enviada. Condição Final de Falha: Autorização não enviada e gerente notificado da impossibilidade de envio. Ator Primário: Gerente Passo 1: Funcionário solicita pedido de autorização. Passo 2: O sistema emite pedido de autorização. Passo 3: Gerente analisa e emite a resposta. Passo 4: O sistema emite resposta do pedido de autorização. Passo 2: Falha de comunicação(rede inoperante, etc.): O sistema cancela o pedido de autorização e notifica o erro. Passo 4: Falha de comunicação(rede inoperante, etc.): O sistema cancela o pedido de autorização e notifica de erro. 21

22 Prioridade: alta. Freqüência: alta. Caso de uso 15: CADASTRAR CLIENTE Objetivo no Contexto: Realizar a inserção de um cliente. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Cliente cadastrado com sucesso. Condição Final de Falha: Cliente não cadastrado e usuário notificado da impossibilidade de cadastro. Ator Primário: Gerente ou Funcionário. Passo 1: Obter os dados cadastrais do cliente. Passo 2: O sistema insere os dados no Banco de Dados. Passo 3: O sistema emite mensagem de cadastro efetuado. Passo 2.1: Falha no acesso ao banco de dados: O sistema cancela cadastro e notifica o erro. Passo 2.2: Cliente já cadastrado: o sistema cancela o cadastro e notifica o erro ao gerente. Prioridade: alta. Freqüência: alta. Caso de uso 16: REMOVER CLIENTE Objetivo no Contexto: Realizar a remoção de um cliente. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Cliente removido com sucesso Condição Final de Falha: Cliente não removido e notificação da impossibilidade de remoção. Ator Primário: Gerente ou funcionário Passo 1: Dados do cliente a ser excluído. Passo 2: O sistema busca o cliente a ser excluído. Passo 3: O sistema remove o cadastro do Banco de Dados. Passo 4: O sistema emite mensagem de cliente removido. Passo 2: Cliente não localizado: O sistema cancela a operação e notifica a inexistência do cliente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a remoção e notifica o erro. Prioridade: média. Freqüência: baixa. 22

23 Caso de uso 17: ALTERAR CLIENTE Objetivo no Contexto: Alterar dados do cliente. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Dados alterados com sucesso. Condição Final de Falha: Dados não alterados e erro notificado. Ator Primário: Gerente ou funcionário Passo 1: Dados do cliente a ser alterado. Passo 2: O sistema busca cliente a ser alterado. Passo 3: O sistema acessa dados no Banco de Dados. Passo 4: Alterar os dados. Passo 5: O sistema atualiza o Banco de Dados. Passo 6: O sistema emite mensagem de dados atualizados. Passo 2: Cliente não localizado: O sistema cancela a operação e notifica a inexistência do cliente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a exibição e notifica o erro. Passo 5: Falha no acesso ao banco de dados: O sistema cancela a exibição e notifica o erro. Prioridade: alta. Freqüência: baixa. Caso de uso 18: CONSULTAR CLIENTE Objetivo no Contexto: Realizar consulta de um cliente Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Cliente consultado com sucesso. Condição Final de Falha: Consulta não realizada e notificação da impossibilidade de consulta. Ator Primário: Gerente ou funcionário Passo 1: Dados do cliente. Passo 2: O sistema busca o cliente. Passo 3: O sistema acessa o Banco de Dados. Passo 4: O sistema exibe a consulta. Passo 2.1: Cliente não localizado: o caso de uso Cadastrar Cliente é estendido <<extends>> Passo 2.2: O sistema cancela a operação e notifica a inexistência do cliente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a consulta e notifica o erro. 23

24 Prioridade: alta. Freqüência: alta. Caso de uso 19: CONSULTAR CRÉDITO Objetivo no Contexto: Realizar a consulta do crédito de um cliente. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Consulta verificada com sucesso Condição Final de Falha: Consulta não realizada e notificação da impossibilidade da consulta. Ator Primário: Gerente ou funcionário Passo 1: Dados do cliente a ser consultado. Passo 2: O sistema busca o cliente a ser consultado. Passo 3: O sistema acessa o Banco de Dados. Passo 4: Selecionar modo de exibição. Passo 5: O sistema exibe crédito. Passo 2: Cliente não localizado: O sistema cancela a operação e notifica a inexistência do cliente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a remoção e notifica o erro. Passo 5: Falha de hardware de impressão: O sistema cancela a exibição do relatório e erro é notificado. Prioridade: alta. Freqüência: média. Caso de uso 20: CREDITAR PAGAMENTO Objetivo no Contexto: Realizar pagamento de prestação e atualizar crédito/débito do cliente. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Pagamento realizado com sucesso. Condição Final de Falha: Pagamento não realizado e notificação da impossibilidade de pagamento. Ator Primário: Gerente ou funcionário Passo 1: Dados do cliente. Passo 2: O sistema busca o cliente. Passo 3: O sistema acessa o Banco de Dados. Passo 4: O sistema imprime o recibo(o caso de uso Impressão de Recibo é incluído <<include>>). Passo 2: Cliente não localizado: O sistema cancela a operação e notifica a inexistência do cliente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a remoção e notifica o erro. Passo 4: Falha de hardware de impressão: O sistema cancela a impressão e erro é notificado. 24

25 Prioridade: alta. Freqüência: média. Caso de uso 21: IMPRESSÃO NOTA FISCAL Objetivo no Contexto: Realizar a impressão da nota fiscal. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Nota fiscal impressa com sucesso. Condição Final de Falha: Nota fiscal não impressa e notificação da impossibilidade de impressão. Ator Primário: Gerente ou funcionário Passo 1: Dados de venda. Passo 2: O sistema acessa os dados no Banco de Dados. Passo 3: Enviar dados para impressão. Passo 2: Falha no acesso ao banco de dados: O sistema cancela a impressão e notifica o erro. Passo 3: Falha de hardware de impressão: O sistema cancela impressão e erro é notificado. Prioridade: alta. Freqüência: alta. Caso de uso 22: REQUER MERCADORIA Objetivo no Contexto: realizar pedido de compra de motocicleta. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Motocicleta adquirida. Condição Final de Falha: Motocicleta não adquirida e notificação da impossibilidade de pedido. Ator Primário: Gerente ou funcionário Passo 1: Funcionário solicita a compra da motocicleta ao sistema. Passo 2: O sistema envia pedido de compra ao gerente. Passo 3: Gerente entra em contato com fornecedor. Passo 4: Motocicleta adquirida. Passo 1: Gerente irá realizar pedido ao fornecedor.. Passo 2.1: Não há necessidade de envio: gerente já esta ciente da necessidade. Passo 2.2: Falha no acesso ao banco de dados: O sistema cancela a consulta e notifica o erro. 25

26 Prioridade: alta. Freqüência: alta. Caso de uso 23: CONSULTAR ESTOQUE Objetivo no Contexto: Realizar uma consulta ao estoque. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Estoque consultado com sucesso. Condição Final de Falha: Consulta não realizada e notificação da impossibilidade de consulta. Ator Primário: Gerente ou funcionário Passo 1: Dados da motocicleta. Passo 2: O sistema busca a motocicleta. Passo 3: O sistema acessa o Banco de Dados. Passo 4: Selecionar modo de exibição. Passo 5: Exibir a consulta. Passo 2.1: Motocicleta não localizado: o caso de uso Requerer Mercadoria é estendido <<extends>> Passo 2.2: O sistema cancela a operação e notifica a inexistência do cliente. Passo 3: Falha no acesso ao banco de dados: O sistema cancela a consulta e notifica o erro. Passo 5: Falha de hardware de impressão: O sistema cancela impressão e erro é notificado. Prioridade: alta. Freqüência: alta. 26

27 Caso de uso 24: VENDA Objetivo no Contexto: Realizar a venda de uma motocicleta. Pré-condições: Estar logado ao sistema. Condição Final de Sucesso: Venda realizada com sucesso. Condição Final de Falha: Venda não realizada e notificação da impossibilidade de venda. Ator Primário: Gerente ou funcionário Passo 1: O funcionário seleciona o tipo de venda à prazo. Passo 2: Buscar motocicleta ao estoque (o caso de uso Consulta estoque é incluído <<include>>). Passo 3: Realizar uma consulta ao cliente (o caso de uso Consultar cliente é incluído <<include>>). Passo 4: Consultar crédito do cliente (o caso de uso Consultar crédito é incluído <<include>>). Passo 5: Solicitar autorização do gerente ( o caso de uso Autorizar venda é incluído <<include>>). Passo 6: Impressão de nota fiscal ao cliente ( o caso de uso Imprimir nota fiscal é incluído <<include>>) Passo 7: Remover motocicleta do estoque (o caso de uso Remover produto é incluído <<include>>) Passo 1: Venda à vista: Funcionário seleciona o tipo de venda à vista. Passo 2: Falha no acesso ao banco de dados: o sistema cancela a venda e notifica o erro. Passo 3: Falha no acesso ao banco de dados: o sistema cancela a venda e notifica o erro. Passo 4: Venda à vista: não é consultado o crédito. Passo 5: Falha na comunicação: o sistema cancela a venda e notifica o erro. Passo 6: Falha de hardware de impressão: o sistema cancela a impressão e erro é notificado. Passo 7: Falha no acesso ao banco de dados: o sistema cancela a venda e notifica o erro. Prioridade: alta. Freqüência: alta. DIAGRAMA DE CLASSE Um diagrama de classes é uma representação da estrutura e relações das classes. É uma modelagem muito útil para o sistema pois define todas as classes que o sistema necessita, juntamente com seus métodos e atributos bem como o relacionamento estático entre elas. Na página seguinte é apresentado o diagrama de classes do sistema. Uma breve descrição textual das classes apresentadas no diagrama abaixo: 27

28 28

29 Figura 5: Diagrama de Classes 29

30 Pessoa: Os atributos os quais estão aqui contidos dizem respeito aos dados comuns a todos os indivíduos, estes são comuns às classes Cliente, Funcionário, Gerente. Ela esta relaciona associativamente com a classe Endereço. Endereço: Engloba todos os atributos referentes à localização, como: estado, cidade, rua, entre outros. Ela possui relação de associação com as classes Pessoa e Fornecedor. Dados Trabalhistas: Reúne informações trabalhistas comuns a todos os funcionários da empresa. Estando associada com as classes Gerente e Funcionário. Funcionário: É uma especialização da classe Pessoa, contendo os atributos referentes a sua identificação no sistema, ou seja, Loguin e Senha. Também estão disponíveis métodos para possibilitar a emissão de relatórios de funcionários, consulta de funcionários e realização de pagamentos. Para possibilitar operações de venda ela esta classe esta associada à classe Venda, sendo assim ela possui acesso indireto às classes Nota Fiscal, Produtos Novos, Produtos Usados e Cliente, assim possibilitando operações de venda, consulta à cliente e ou cadastro de clientes, consulta a produto e ou requerimento de produtos, entre outros. Gerente: Esta classe herda todos os atributos e métodos da classe Funcionário e conseqüentemente todos atributos e métodos da classe Pessoa. Não possui atributos específicos, em contrapartida agrega os métodos com funções administrativas, tais como: Autorizar Venda, Criar usuários, Remover Usuários, Alterar Senha, Emissão de Relatórios de vendas, compras, funcionários, clientes, entre outros, a única classe associada a esta é a classe Pedido. Pedido: Foram inclusos nesta classe os atributos e métodos, para possibilitar uma ponte entre as classes Gerente e Fornecedor, seus atributos correspondem aos dados existentes em pedido e os atributos às operações necessárias para sua execução (pedido). Esta classe esta associado com as seguintes classes: Gerente, Produto e Fornecedor. Venda: Classe construída para reunir atributos e métodos referentes a operação de venda de produtos, por ser uma operação um tanto quanto complexa e sendo uma das principais funções do sistema. Ela possui associação com uma série de classes, elas são: Produtos Novos e Produtos Usados, Nota fiscal, Cliente e Funcionários. Cliente: Classe derivada da classe Pessoa. Pode fazer uso de todos os métodos e atributos desta através do mecanismo de herança, como atributos específicos como a situação do individuo junto a empresa a respeito de crédito para compras à prazos e a data da efetuação de seu cadastramento na empresa. Através de seus métodos é possível obter-se relatórios de clientes, conferência, alteração e ou exclusão destes dados. Está associada com as classes: Produto Novos e Produtos Usados, Endereço, Venda e Nota Fiscal. Nota Fiscal: Classe criada única e exclusivamente para conter os atributos referentes aos dados existentes em uma nota fiscal e métodos para a sua impressão. Observa-se que não foram inclusos, até este momento, os 30

31 atributos referentes a impostos e/ou taxas as quais serão incluídos após uma consulta aos órgãos governamentais que regulamentam a confecção deste documento. Já estão inclusos os atributos número, via e valor total, que será composto do valor de venda mais as taxas e impostos. O método calc( ) foi construído para efetuar esta, mas dependem dos dados ausentes supracitados para que funcione corretamente. Possui ligação associativa com a classes:venda, Produtos Novos e Produtos Usados, Cliente e Endereço. Produtos Novos: Criada para representar os produtos da empresa adquiridos diretamente do fabricante. Seus atributos são referentes às características do produto e seus métodos possibilitam alteração nestes dados, confecção de relatórios, entre outros. Possui associação com as classes Pedido, Fornecedores, Venda, Cliente e Nota Fiscal. Produtos Usados: Por ser uma especialização da classe Produtos Novos, ela herda todos atributos e métodos desta. Seus atributos dizem respeito aos dados do antigo proprietário e condição do produto. Fornecedor: Reúne atributos referentes aos dados da empresas as quais são efetuadas a compra de produtos novos, entre eles: razão social, CNPJ e telefone. Já os dados e atributos referentes endereço são obtidos através de associação com a classe Endereço. Ela também esta associada com as classes Venda e Nota Fiscal. 31

32 CONCLUSÃO A partir do estudo de viabilidades já realizado e definição da alternativa mais viável para a empresa, iniciou-se o estudo da Engenharia de Requisitos. Para um melhor entendimento do funcionamento da organização foi utilizada a técnica i-estrela para elaborar os modelos de dependências e de razões estratégicas. A partir destes, iniciou-se a elicitação dos requisitos do sistema. Para melhor esclarecimento de como satisfazer os requisitos não funcionais, foi utilizado o grafo SIG(Softgoal Interdependency Graph). A partir disto, fizemos uso da técnica UML para a construção de um modelo de casos de uso no qual é visualizada as interações entre os usuários e o sistema. Isto nos deu uma noção mais completa de como vai ser satisfeito os requisitos e os passos necessários para satisfação destes. Como temos por intuito implementar o sistema utilizando a metodologia da programação orientada a objeto, utilizamos um diagrama de classes para identificar quais classes fariam parte desse sistema. Isso pode evitar erros em tempo de implementação e produzir um software de melhor qualidade dentro do cronograma. Através deste documento procuramos atender a todos os requisitos necessários para satisfação das necessidades da empresa. Esta documentação servirá de apoio para implementação do sistema de informação em questão. 32

33 Apêndice A Coleta de Informações A coleta de informações baseou-se na visita a empresa Alvorada Motos e em entrevistas com o gerente e funcionários. O primeiro contato foi com o gerente, ele explanou o funcionamento básico do ambiente organizacional. Para compreender melhor as atividades que movimentam a empresa, entrevistou-se um funcionário que pudesse explicar quais os principais problemas encontrados no ambiente de trabalho e as funcionalidades que um sistema deve possuir para qualificar todas as operações. 33

34 Formulário do Relatório da Equipe Todos os membros da equipe contribuíram de forma igualitária em todas as etapas do projeto. 34