View
213
Download
0
Category
Preview:
Citation preview
Unioeste – Universidade Estadual do Oeste do ParanáCENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICASColegiado de InformáticaCurso de Bacharelado em Informática
SISTEMA ALVORADA MOTOSProcesso de Engenharia de RequisitosEmpresa: Arco Verde Veículos Ltda
Projeto e Engenharia de Software I (PESI)3º Ano do Curso de Bacharelado em Informática
CASCAVEL2006
Douglas AntoniaziJonny C. Model
Kleberson H. AngelossiRodrigo A. Gonzato
ESPECIFICAÇÃO DE REQUISITOS E MODELAGEMORIENTADA A OBJETO
Professor: Victor Francisco Araya Santander
CASCAVEL2006
2
ÍNDICE
Motivação ................................................................................................................01
Introdução............... ................................................................................................ 02
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)........................................................................... 09
Diagrama De Caso De Uso ..................................................................................... 11
Diagrama De Classe ................................................................................................ 24
Conclusão ................................................................................................................ 28
Apêndice A...............................................................................................................30
Formulário Relatório da Equipe .............................................................................. 31
3
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 des-pesas 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
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 85.812-000, e outra filial na avenida Piquiri número 222, centro, CEP 85.812-810. Atua com razão social “Arco Verde Veículos Ltda.” e CNPJ número 03.339.345/0001-62.
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ão-Funcionais 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
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
[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 FornecedorTodos os fornecedores da empresa devem ser cadastrados. O cadastro de cada fornecedor deve
conter as seguintes informações: razão social, CNPJ, e-mail, 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
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
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
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
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
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
Caso de uso 1: CADASTRAR FUNCIONÁRIOObjetivo no Contexto: Realizar a inserção de um funcionário.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Gerente logado ao sistema.Condição Final de Sucesso: Funcionário cadastrado com sucessoCondição Final de Falha: Funcionário não cadastrado e gerente notificado da impossibilidade de cadastro.Ator Primário: Gerente
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: baixa.
Caso de uso 2: REMOVER FUNCIONÁRIOObjetivo no Contexto: Realizar a remoção de um funcionário.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Gerente logado ao sistema.Condição Final de Sucesso: Funcionário removido com sucessoCondição Final de Falha: Funcionário não removido e gerente notificado da impossibilidade de remoção.Ator Primário: Gerente
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: baixa.
15
Caso de uso 3: ALTERAR FUNCIONÁRIOObjetivo no Contexto: Alterar dados cadastrais do funcionário.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: baixa.
Caso de uso 4: CONSULTAR FUNCIONÁRIOObjetivo no Contexto: Consultar dados cadastrais do funcionário.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.
16
Freqüência: baixa.Caso de uso 5: RELATÓRIOS ESPECÍFICOSObjetivo no Contexto: Realizar a exibição ou impressão de relatórios restritos ao gerente.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: média.
Caso de uso 6: CADASTRAR FORNECEDORObjetivo no Contexto: Realizar a inserção de um fornecedor.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Gerente logado ao sistema.Condição Final de Sucesso: Fornecedor cadastrado com sucessoCondição Final de Falha: Fornecedor não cadastrado e gerente notificado da impossibilidade de cadastro.Ator Primário: Gerente
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: média.
17
Caso de uso 7: REMOVER FORNECEDORObjetivo no Contexto: Realizar a remoção de um fornecedor.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Gerente logado ao sistema.Condição Final de Sucesso: Fornecedor removido com sucessoCondição Final de Falha: Fornecedor não removido e gerente notificado da impossibilidade de remoção.Ator Primário: Gerente
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: baixa.
Caso de uso 8: ALTERAR FORNECEDORObjetivo no Contexto: Alterar dados cadastrais do fornecedor.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.Informação Relacionada
18
Prioridade: média.Freqüência: baixa
Caso de uso 9: CONSULTAR FORNECEDORObjetivo no Contexto: Consultar dados cadastrais do fornecedor.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: baixa.
Caso de uso 10: CADASTRAR PRODUTOObjetivo no Contexto: Realizar a inserção de uma motocicleta.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Gerente logado ao sistema.Condição Final de Sucesso: Motocicleta cadastrada com sucessoCondição Final de Falha: Motocicleta não cadastrada e gerente notificado da impossibilidade de cadastro.Ator Primário: Gerente
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: alta.
19
Caso de uso 11: ALTERAR PRODUTOObjetivo no Contexto: Alterar dados da motocicleta.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: baixa.
Caso de uso 12: REMOVER PRODUTOObjetivo no Contexto: Realizar a remoção de uma motocicleta.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Gerente logado ao sistema.Condição Final de Sucesso: Motocicleta removida com sucessoCondição Final de Falha: Motocicleta não removida e gerente notificado da impossibilidade de remoção.Ator Primário: Gerente
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 1: Motocicleta não localizada: O sistema cancela a operação e notifica a inexistência da motocicleta ao gerente.
20
Passo 2: Falha no acesso ao banco de dados: O sistema cancela a remoção e notifica o erro ao gerente.Informação RelacionadaPrioridade: alta.Freqüência: alta
Caso de uso 13: CONSULTAR PRODUTOObjetivo no Contexto: Consultar dados cadastrais do produto.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: alta.
Caso de uso 14: AUTORIZAR VENDAObjetivo no Contexto: Emitir autorização de venda ao funcionário.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação Relacionada
21
Prioridade: alta.Freqüência: alta.
Caso de uso 15: CADASTRAR CLIENTEObjetivo no Contexto: Realizar a inserção de um cliente.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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.
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: alta.
Caso de uso 16: REMOVER CLIENTEObjetivo no Contexto: Realizar a remoção de um cliente.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Estar logado ao sistema.Condição Final de Sucesso: Cliente removido com sucessoCondição Final de Falha: Cliente não removido e notificação da impossibilidade de remoção.Ator Primário: Gerente ou funcionário
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: média.Freqüência: baixa.
22
Caso de uso 17: ALTERAR CLIENTEObjetivo no Contexto: Alterar dados do cliente.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: baixa.
Caso de uso 18: CONSULTAR CLIENTEObjetivo no Contexto: Realizar consulta de um clienteEscopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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
Informação RelacionadaPrioridade: alta.Freqüência: alta.
Caso de uso 19: CONSULTAR CRÉDITOObjetivo no Contexto: Realizar a consulta do crédito de um cliente.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-condições: Estar logado ao sistema.Condição Final de Sucesso: Consulta verificada com sucessoCondição Final de Falha: Consulta não realizada e notificação da impossibilidade da consulta.Ator Primário: Gerente ou funcionário
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: média.
Caso de uso 20: CREDITAR PAGAMENTOObjetivo no Contexto: Realizar pagamento de prestação e atualizar crédito/débito do cliente.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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>>).
ExtensõesPasso 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
Informação RelacionadaPrioridade: alta.Freqüência: média.
Caso de uso 21: IMPRESSÃO NOTA FISCALObjetivo no Contexto: Realizar a impressão da nota fiscal.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 1: Dados de venda.Passo 2: O sistema acessa os dados no Banco de Dados.Passo 3: Enviar dados para impressão.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: alta.
Caso de uso 22: REQUER MERCADORIAObjetivo no Contexto: realizar pedido de compra de motocicleta.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação Relacionada
25
Prioridade: alta.Freqüência: alta.
Caso de uso 23: CONSULTAR ESTOQUEObjetivo no Contexto: Realizar uma consulta ao estoque.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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.
ExtensõesPasso 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.
Informação RelacionadaPrioridade: alta.Freqüência: alta.
26
Caso de uso 24: VENDAObjetivo no Contexto: Realizar a venda de uma motocicleta.Escopo: Sistema Computacional de Apoio à Alvorada Motos.Nível de UsuárioPré-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
Cenário Principal de SucessoPasso 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>>)
ExtensõesPasso 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.
Informação RelacionadaPrioridade: 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
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
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
CONCLUSÃO
A partir do estudo de viabilidades já realizado e definição da alternativa mais viável para a empre-sa, 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 orienta-da 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 infor-mação em questão.
32
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
Recommended