Documento de Requisitos

Transcrição

1 UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM Ciência DA COMPUTAÇÃO CENTRO DE INFORMÁTICA Documento de Requisitos IF716 ESPECIFICAÇÃO E VALIDAÇÃO DE REQUISITOS Alunos: Felipe Duarte (fds) Gabriela Sampaio (gcs) Guilherme Cavalcanti (gjcc) Roberto Filho (rsmbf) AGOSTO 2013

2 Sumário 1. Introdução Motivação O problema Identificado Convenções Para Identificação dos Requisitos Convenções Para Identificação dos Casos de Uso Estrutura dos Casos de Uso Prioridades dos Casos de Uso Requisitos Organizacionais Requisitos Funcionais [RF01] Login [RF02] Cadastrar Administrador [RF03] Cadastrar Cliente [RF04] Relatório de Orçamentos [RF05] Cadastrar Equipamento [RF06] Gerar Contato [RF07] Controle de Vendas [RF08] Controle de Estoque [RF09] Realizar Compra [RF10] Cadastrar Funcionário [RF11] Renovação de Licença [RF12] Relatório de Área Explorada Requisitos Não-Funcionais Requisitos de Produto Usabilidade Confiabilidade Segurança Desempenho Requisitos de Processo [RNF07] Utilizar o SCRUM como Metodologia de Desenvolvimento [RNF08] Utilizar Linguagem Java (J2EE) [RNF09] Utilizar o Framework Hibernate [RNF10] Utilizar Banco de Dados MySQL [RNF11] Utilizar Padrão de Projeto com Arquitetura em Camadas

3 4.3 Requisitos Externos [RNF12] Custo do Desenvolvimento [RNF13] Tempo de Desenvolvimento Modelagem BPMN Modelagem Organizacional Modelo de Dependência Estratégica Modelo de Razão Estratégica Modelagem de Requisitos Funcionais Modelagem de Requisitos Não Funcionais Conclusões Formulário do relatório da equipe Referências Apêndices Apêndice A - Sobre a JML Apêndice B - Contatos e Coleta de Informações Apêndice C Descrição dos Casos de Uso

4 1. Introdução 1.1 Motivação As empresas dos mais diversos setores estão ficando cada dia mais dependente do uso de sistemas de informação. Quando uma empresa é composta de vários departamentos e sua extensão é acima de médio porte, o uso destes sistemas, com o intuito de facilitar e aperfeiçoar os serviços internos e externos da organização, tornase indispensável. Nessas empresas, trabalhos manuais costumam ser repetitivos, o que os torna tendenciosos a falhas. Os sistemas de TI podem automatizar essas operações tornando-as mais rápidas e menos falhas. Com o uso de um sistema adequado, e bem utilizado, é possível reduzir custos, aumentar produtividade e comunicação dos departamentos da empresa, bem como trazer conforto para clientes e funcionários. O grande desafio dessas empresas é encontrar um sistema adequado para suas necessidades. Um sistema que seja completo o suficiente para abranger as necessidades de todos os seus departamentos, que não modifique drasticamente o processo atual, apenas aperfeiçoe, e que tenha custos dentro do orçamento da organização. A nossa motivação é desenvolver uma solução que permita automatizar parte do processo atual da empresa JML Areia Empreendimentos, que realiza venda de grande quantidade de areia, e lida com clientes, fornecedores, produtos e dentre outros. Para o melhor gerenciamento deste negócio, seria ideal um sistema capaz de auxiliar na administração dos setores, geração de relatórios, vendas e armazenamento de dados relevantes para o cliente. 1.2 O problema Identificado O objeto do estudo é o areeiro localizado na fazenda de Santa Rita, sede da empresa JML Areia Empreendimentos. A empresa é relativamente recente (foi criada em 2012) e ainda não conta com um grande número de funcionários. Porém, lida com vendas de areia de grande porte. Mais detalhes sobre a empresa podem ser encontrados no Anexo A. A empresa JML Areia Empreendimentos não possui uma forma precisa de gerenciar a empresa (atualmente, o controle é feito através de planilhas). Além disso, as vendas de areia atualmente são feitas apenas por telefone e não há nenhuma forma de divulgação da empresa. 4

5 Foram realizadas entrevistas com um dos sócios da JML Areia Empreendimentos, Marcos Sampaio. Nestas entrevistas, pôde-se perceber que há certa dificuldade em gerenciar a empresa, já que ela envolve vários aspectos, como equipamentos, leis ambientais, funcionários e clientes. No Anexo B, há mais informações sobre as entrevistas. Este documento de requisitos especifica um sistema intitulado SandManager, que se trata de um sistema de gerenciamento e venda web que será alimentado pelos administradores da empresa para gerenciar a empresa JML Areia Empreendimentos. Onde, apesar de as vendas também continuarem sendo realizadas por telefone, haverá módulo de vendas web e que listará os clientes e seus telefones e fará o registro dessas vendas. 1.3 Convenções Para Identificação dos Requisitos Para facilitar posteriores rastreamentos e referências aos requisitos, foi criado um padrão a ser seguido para identificar todos os requisitos do sistema. Para os requisitos funcionais, usaremos um indicador no formato [RFxx] seguido do nome do requisito, onde xx é o número do requisito funcional. O mesmo será aplicado para os requisitos não funcionais, os quais usaremos um indicador no formato [RNFxx] seguido do nome do requisito, onde xx é o número do requisito não funcional. 1.4 Convenções Para Identificação dos Casos de Uso Com o mesmo objetivo da identificação dos requisitos e seguindo o mesmo raciocínio, temos o seguinte padrão. Usaremos um indicador no formato [UCxx] seguido do nome do caso de uso, onde xx é o número do caso de uso Estrutura dos Casos de Uso Cada caso de uso será estruturado da seguinte maneira: Atores: Os humanos ou máquinas que utilizarão os casos de uso, isto é, que irão interagir com o sistema e executar algum trabalho; Prioridade: Define a prioridade de implementação deste caso de uso; Entradas: Variáveis que serão passadas ao sistema para realização do caso de uso; Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser executado; 5

6 Fluxo de eventos: A sequência de passos das ações realizadas para que o caso de uso seja concluído sem erros, podendo incluir fluxos de eventos secundários e/ou alternativos (usados normalmente quando algum erro ocorre durante a execução do caso de uso); Saídas: Dados que devem ser fornecidos pelo sistema quando o caso de uso for executado; Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser finalizado Prioridades dos Casos de Uso Os casos de uso são classificados com os seguintes níveis de prioridade: Essencial: É o caso de uso indispensável ao funcionamento do sistema. É obrigatória a implementação deste caso de uso, uma vez que, sem ele, o sistema não funcionará de forma correta; Importante: É o caso de uso necessário ao funcionamento do sistema. Sem este caso de uso, o sistema ainda é capaz de ser utilizado. Porém, a utilização ocorre de forma não satisfatória; Desejável: É o caso de uso que agrega novos valores ao sistema e o torna mais completo. Esse tipo de caso de uso poderá ser implementado em versões posteriores do sistema, visto que, mesmo sem a sua implementação, o sistema atende as suas funcionalidades básicas. 6

7 2. Requisitos Organizacionais Os requisitos organizacionais devem satisfazer os objetivos da organização e definir porque o sistema é necessário. Esses requisitos são: Fornecer módulo de venda online de areia para os clientes. Fornecer maneira simples de visualizar balanço financeiro da empresa. Informar quando houver proximidade do vencimento de acordos ambientais. Fornecer módulos para o gerenciamento da empresa como um todo. 3. Requisitos Funcionais Os requisitos funcionais representam as funcionalidades presentes no sistema. Neste capítulo, abordaremos todos os requisitos elicitados e validados até o presente momento pela equipe. 3.1 [RF01] Login [RF01] Login Caso de uso relacionado [UC 01] Descrição Permite que o usuário faça seu login no sistema. Para isso, ele deve informar seu login e sua senha. Prioridades [ x ]Essencial [ ]Importante [ ]Desejável 3.2 [RF02] Cadastrar Administrador [RF02] Cadastrar Administrador Caso de uso relacionado [UC 02] Descrição Permite o cadastro de um usuário no sistema. Todo usuário possui nome, cpf, login e senha. Prioridades [ x ]Essencial [ ]Importante [ ]Desejável 3.3 [RF03] Cadastrar Cliente [RF03] Cadastrar Cliente Caso de uso relacionado [UC 03] Descrição Permitir o cadastro de um cliente da empresa no sistema. Todo cliente possui nome, CNPJ e um ou mais telefones. Prioridades [ x ]Essencial [ ]Importante [ ]Desejável 3.4 [RF04] Relatório de Orçamentos [RF04] Relatório de Orçamentos Caso de uso relacionado [UC 04] Descrição Gera um relatório de orçamentos para determinado mês, quais foram os gastos e os gastos ficam organizados em receita/despesa por 7

8 Prioridades ordem cronológica. [ ]Essencial [ x ]Importante [ ]Desejável 3.5 [RF05] Cadastrar Equipamento [RF05] Cadastrar Equipamento Caso de uso relacionado [UC 05] Descrição O usuário poderá cadastrar um equipamento no sistema. Todo equipamento possui um nome. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 3.6 [RF06] Gerar Contato [RF06] Gerar Contrato Caso de uso relacionado [UC 06] Descrição É gerado um contrato padrão para determinado cliente, visto que muitos contratos diferem apenas em dados simples como nome do cliente, data, etc. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 3.7 [RF07] Controle de Vendas [RF07] Controle de Vendas Caso de uso relacionado [UC 07] Descrição Permite ao usuário realizar operações com vendas, e uma venda possui cliente, data, nota fiscal, preço e quantidade de estoque. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 3.8 [RF08] Controle de Estoque [RF08] Controle de Estoque Caso de uso relacionado [UC 08] Descrição O usuário pode realizar operações com o estoque, como acrescentar estoque, remover estoque. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 3.9 [RF09] Realizar Compra [RF09] Realizar Compra Caso de uso relacionado [UC 09] Descrição Permite ao cliente realizar uma compra no sistema online, sem precisar realizar uma ligação ou ir pessoalmente à sede da JML. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 8

9 3.10 [RF10] Cadastrar Funcionário [RF10] Cadastrar Funcionário Caso de uso relacionado [UC 10] Descrição O usuário poderá cadastrar um funcionário no sistema. Todo funcionário possui nome, CPF, salário, data de admissão e vários telefones. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 3.11 [RF11] Renovação de Licença [RF11] Renovação de Licença Caso de uso relacionado [UC 11] Descrição Um relógio ficará disparando e o administrador será notificado por na hora de renovar a licença de exploração da terra. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 3.12 [RF12] Relatório de Área Explorada [RF12] Relatório de Área Explorada Caso de uso relacionado [UC 12] Descrição O administrador poderá consultar um relatório sobre a área que foi explorada até o momento, e se esta quantidade está de acordo com os limites permitidos. Prioridades [ ]Essencial [ x ]Importante [ ]Desejável 9

10 4. Requisitos Não-Funcionais Os requisitos não-funcionais descrevem restrições e aspectos de qualidade relacionados ao sistema e ao seu processo de desenvolvimento. Eles serão classificados em três grupos: requisitos de produto, requisitos de processo e requisitos externos. Esta forma de classificação é apresentada por [4]. 4.1 Requisitos de Produto Os requisitos de produto se referem às características desejadas que um sistema deve fornecer. Abaixo estão os requisitos não-funcionais de produto elicitados pela equipe Usabilidade [RNF01] Interface Amigável Identificação: [RNF01] Interface amigável Casos de Uso relacionados: Descrição: Prioridade: Todos. O sistema deve possuir uma interface amigável com o usuário. Não possuindo ambiguidades e dificuldades de entendimento. Essencial Importante Desejável [RNF02] Fácil Aprendizagem Identificação: [RNF02] Fácil Aprendizagem Casos de Uso relacionados: Descrição: Prioridade: Todos. O sistema deve ser de fácil aprendizagem para o usuário, um usuário leigo deve conseguir realizar as funcionalidades mais básicas, como as de consultas de dados. Essencial Importante Desejável Confiabilidade [RNF03] Disponibilidade Identificação: [RNF03] Disponibilidade Casos de Uso relacionados: Descrição: Todos. O sistema deve estar sempre disponível. O sistema não deverá ficar indisponível por erros de utilização dos usuários. E caso isso aconteça, 10

11 sua recuperação deve ser imediata. Prioridade: Essencial Importante Desejável Segurança [RNF04] Integridade Identificação: [RNF04] Integridade Casos de Uso relacionados: Descrição: Prioridade: Todos. Todos os dados armazenados no sistema devem estar corretos e não serem corrompidos por nenhum motivo. Essencial Importante Desejável [RNF05] Privacidade Identificação: [RNF05] Privacidade Casos de Uso relacionados: Descrição: Prioridade: Todos. Apenas pessoas autorizadas pelo sistema poderão obter as informações disponíveis. Essencial Importante Desejável Desempenho [RNF06] Tempo de Resposta Identificação: [RNF06] Tempo de Resposta Casos de Uso relacionados: Todos. Descrição: As transações processadas pelo sistema não devem exceder 10 segundos. Prioridade: Essencial Importante Desejável 4.2 Requisitos de Processo Os requisitos de processo se referem às restrições relacionadas com o processo de desenvolvimento do sistema. Abaixo estão os requisitos não funcionais de processo elicitados pela equipe. 11

12 4.2.1 [RNF07] Utilizar o SCRUM como Metodologia de Desenvolvimento Identificação: [RNF07] Utilizar SCRUM como Metodologia de Desenvolvimento Casos de Uso relacionados: Todos. Descrição: O SCRUM[1] será a metodologia de desenvolvimento empregada. Todos os artefatos envolvidos no processo especificado pelo SCRUM serão produzidos e disponibilizados de acordo com o cronograma definido no Estudo de Viabilidade. Prioridade: Essencial Importante Desejável [RNF08] Utilizar Linguagem Java (J2EE) Identificação: [RNF08] Utilizar Linguagem Java (J2EE) Casos de Uso relacionados: Descrição: Prioridade: Todos. A Linguagem de Programação JAVA é uma linguagem consolidada no mercado, uma vez que ela possui uma gama de ferramentas que auxiliam no desenvolvimento, sendo portável em diversos Sistemas Operacionais. Essencial Importante Desejável [RNF09] Utilizar o Framework Hibernate Identificação: [RNF09] Utilizar do Framework Hibernate Casos de Uso relacionados: Descrição: Prioridade: Todos. Facilita o desenvolvimento de consultas ao banco de dados e permitir a independência do mesmo. Essencial Importante Desejável [RNF10] Utilizar Banco de Dados MySQL Identificação: [RNF10] Utilizar Banco de Dados MySQL Casos de Uso relacionados: Descrição: Prioridade: Todos. Esse sistema de banco de dados oferece os recursos básicos necessários à aplicação e é economicamente viável. Essencial Importante Desejável 12

13 4.2.5 [RNF11] Utilizar Padrão de Projeto com Arquitetura em Camadas Identificação: [RNF11] Utilizar padrão de projeto Model-View-Controller. Casos de Uso relacionados: Descrição: Prioridade: Todos. O padrão de projeto MVC permite desenvolver aplicativos web de forma flexível e em camadas bem definidas (Apresentação, Controle e Dados). Essencial Importante Desejável 4.3 Requisitos Externos Os requisitos externos se referem às informações sobre o domínio de aplicação, considerações organizacionais e restrições de projeto. Abaixo estão os requisitos nãofuncionais externos elicitados pela equipe [RNF12] Custo do Desenvolvimento Identificação: Casos de Uso relacionados: Descrição: Prioridade: [RNF12] Custo do desenvolvimento Todos. O custo total do desenvolvimento do sistema não poderá ser maior do que o estimado com o Estudo de Viabilidade. Essencial Importante Desejável [RNF13] Tempo de Desenvolvimento Identificação: Casos de Uso relacionados: Descrição: Prioridade: [RNF13] Tempo de desenvolvimento Todos. O tempo com o desenvolvimento do sistema não poderá superar mais de 30% do estimado no Estudo de Viabilidade. Essencial Importante Desejável 13

14 5. Modelagem BPMN Na modelagem, foi utilizado o BizAgi Process Modeler[6]. 14

15 Figura 1 - Modelagem BPMN do processo de vendas O modelo acima define o processo de vendas no sistema proposto. 15

16 1. O primeiro pool representa o contratante do serviço, que após acessar o site, faz uma requisição que pode ser cancelada antes do pagamento, paga sua compra e entra em um estado de espera. Após o recebimento da encomenda, é pedido uma qualificação básica do atendimento, finalizando o processo. 2. O segundo pool representa a empresa, que por sua vez é dividida em duas partes distintas, o atendimento ou escritório, e a parte de entrega de material, ou delivery O escritório recebe uma mensagem informando que deve iniciar as tarefas assim que um pedido é pago por um contratante. Inicialmente, verifica os dados do contratante para então encaminhar o pedido que foi feito pelo mesmo entrando em um estado de espera. Quando o pedido é então qualificado, o escritório fica ciente que ele foi entregue, fazendo então a baixa no estoque. E, por fim, o escritório analisa a qualificação do contratante para poder melhorar seus atendimentos O delivery recebe o pedido do escritório e faz o trabalho manual, separando o que for necessário entregar, processando o pedido e separando a frota de entrega. Quando o pedido é entregue, o trabalho do delivery acaba. 16

17 6. Modelagem Organizacional A modelagem organizacional utilizada foi feita com base na notação i* (i estrela). Há dois tipos básicos de modelos nessa notação: Dependência Estratégica (Strategic Dependency - SD) - Descreve relacionamentos de dependência entre atores (entidades ativas que executam ações para atingir objetivos). Razão Estratégica (Strategic Rationale - SR) - Explica como atores atingem seus objetivos. 6.1 Modelo de Dependência Estratégica Figura 2 - Modelo de Dependência Estratégica Baseado na figura acima, pode-se notar que o cliente depende da JML Areia Empreendimentos para comprar areia. Já a JML Areia Empreendimentos depende de vários outros atores. Em primeiro lugar, ela depende que os orgãos ambientais regulem as leis ambientais. Em segundo lugar, ela depende que fornecedores de equipamentos e de peças forneçam equipamentos e peças respectivamente. Finalmente, ela depende do sistema SandManager para gerenciar os vários aspectos da empresa (acordos ambientais, vendas, equipamentos, funcionários e custos) e atender pedidos de clientes pela Internet. Também é desejável para a JML Areia Empreendimentos que o SandManager seja consistente, seguro e disponível. 17

18 6.2 Modelo de Razão Estratégica Figura 3 - Modelo de Razão Estratégica com o ator JML Areia Empreendimentos expandido 18

19 A Figura 3 mostra o Modelo de Razão Estratégica com o ator JML Areia Empreendimentos expandido. O objetivo principal da empresa é vender areia e para isso ser feito é necessário gerenciar a empresa. Para o gerenciamento da empresa ser feito é desejável que o SandManager seja consistente, seguro e disponível. A tarefa de gerenciar a empresa, pode ser vista como a junção de várias sub-tarefas. Cada sub-tarefa depende de um módulo do SandManager. Estas sub-tarefas são: gerenciar equipamentos, gerenciar pedidos, gerenciar legislação, gerenciar custos e gerenciar funcionários. Além delas, a empresa precisa ser lucrativa. Algumas das sub-tarefas possuem suas próprias sub-tarefas: gerenciar equipamentos, gerenciar pedidos e gerenciar legislação. A primeira, pode ser dividida em comprar equipamentos e manter equipamento. Para comprar um equipamento a empresa depende de um fornecedor de equipamento e para manter um equipamento a JML Areia Empreendimentos depende de um fornecedor de peças. A segunda, pode ser vista como os objetivos de atender e entregar os pedidos, além de ter o intuito de satisfazer os clientes. O atendimento do pedido pode ser feito por telefone ou pela Internet (através do SandManager). Já a entrega do pedido pode ser com frete ou sem frete. Finalmente, para gerenciar a legislação é necessário cumprir os acordos ambientais e renová-los quando necessário. 19

20 7. Modelagem de Requisitos Funcionais Os casos de uso de CRUD seguiram tal perspectiva: para cada entidade foi criado apenas um caso de uso, chamado de cadastro. Ex.: Cadastrar Administrador. Este caso de uso, por sua vez, engloba todas as possíveis operações de CRUD (Inserir, atualizar, remover e listar). Cada operação é tratada como um subfluxo na descrição do caso de uso de CRUD. Portanto, no caso de uso de Cadastrar Administrador, existe o fluxo principal onde o usuário irá escolher a operação que deseja realizar e algum subfluxo (Inserir Administrador, Atualizar Administrador ou Remover Administrador) será realizado dependendo da escolha. A descrição dos casos de uso podem se encontradas no Apêndice C. Figura 4 - Casos de Uso 20

21 8. Modelagem de Requisitos Não Funcionais Na modelagem de requisitos não funcionais, foi utilizado o framework NFR [5]. Figura 5 - Modelagem dos Requisitos Não-Funcionais Figura 6 - Resultado da Tomada de Decisão 21

22 Há quatro requisitos não funcionais básicos no topo da modelagem, são eles a Usabilidade, o Desempenho, a Confiabilidade e a Segurança. A Segurança é composta por Integridade e Privacidade. Para a Privacidade, serão operacionalizadas a identificação e autorização de acesso do usuário, por meio de controle de acesso, pode ser feito via login e senha, ou certificado digital, no entanto, o uso deste último impacta diretamente na viabilidade econômica do projeto. A integridade é baseada na validação de dados do sistema. Logo em seguida, vem a Confiabilidade do sistema, composta pela Disponibilidade, que será operacionalizado com a utilização de um servidor dedicado sempre disponível. O Desempenho é constituído por Tempo de Resposta, que será executado através da indexação dos dados presentes no sistema. Por fim, a Usabilidade é composta por Interface Amigável e Fácil Aprendizagem. Interface Amigável é alcançada ao serem fornecidas informações intuitivas e a disposição em menu das funcionalidades do sistema. Por sua vez, a Fácil Aprendizagem é conquistada com a disponibilização de menus e dicas de contexto pelo sistema, ambas operações também influenciam a amigabilidade da interface do sistema. 9. Conclusões O objetivo deste documento foi o de elicitar os requisitos e definir o escopo do sistema SandManager. Em um primeiro momento, definiu-se o problema a ser resolvido. Depois disso, foram apresentados os requisitos organizacionais, isto é, os requisitos essenciais para a empresa. Em seguida, foram apresentados todos os requisitos funcionais do sistema. Isto é, todas as funcionalidades que a empresa JML Areia Empreendimentos espera do sistema. Na seção 4, foram detalhados os requisitos não funcionais que irão definir as restrições do funcionamento do sistema. Estes requisitos foram divididos em requisitos de produto, de processo e externos. Após as definições dos requisitos, foram feitas as modelagens BPMN, Organizacional e dos requisitos funcionais e não-funcionais. A modelagem organizacional foi feita com a notação i* e incluiu os modelos de Dependência Estratégica (SD) e de Razão Estratégica (SR). Já os requisitos funcionais, foram modelados utilizando uma técnica bem conhecida e difundida chamada Casos de Uso. Finalmente, foi feita a modelagem dos requisitos não funcionais utilizando a plataforma NFR. 22

23 10. Formulário do relatório da equipe Nome Esforço(25%) Assinatura Felipe Duarte 25 Gabriela Sampaio 25 Guilherme Cavalcanti 25 Roberto Filho Referências [1] SCRUM online - acessado em julho/2013. [2] Disciplina de Especificação de Requisitos e Validação de Sistemas online - acessado em julho/2013. [3] G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, [4] MySQL online - acesso em julho/2013. [5] THE NFR FRAMEWORK IN ACTION online ftp://ftp.cs.utoronto.ca/pub/eric/nfrch2.pdf - acesso em agosto/2013. [6] Bizagi online - acesso em agosto/2013. [7] i* Wiki online - acesso em agosto/

24 Apêndices Apêndice A - Sobre a JML A empresa JML Areia Empreendimentos contempla o Areeiro da fazenda de Santa Rita, ocalizada em Igarassu. Na figura1 pode-se ver o areeiro. Nesta área é realizada uma grande escavação, de cerca de 20 metros de profundidade, e a areia que se encontra nessa profundidade é jogada para a superfície. Figura1 Imagem do areeiro da fazenda Santa Rita. Existem três tipos de areia: 1. A areia que se localiza na superfície, que é a areia de aterro 2. A areia que está abaixo da areia de aterro, a areia argila 3. A areia que é mais valiosa e mais comercializada, que é uma areia preta que fica abaixo da areia argila. Esta areia serve para construção civil. As vendas são realizadas para clientes grandes (geralmente construtoras) e a venda pode ser de dois tipos: com frete e sem frete. No caso da venda com frete, a venda sai 24

25 mais caro (o preço aumenta dependendo do destino) e o caminhão leva a areia até o cliente. Caso contrário, o cliente vai até a fazenda e ele mesmo leva a areia. Para que as vendas sejam realizadas, há um processo para extração da areia. 1. Um equipamento chamado Draga realiza a escavação até o subsolo para que a areia seja retirada até a superfície. 2. A areia fica espalhada na superfície, e então outro equipamento, a pá carregadeira, retira a areia da superfície e coloca em caminhões. 3. Quando a areia é colocada em caminhões, os caminhões levam diretamente ao cliente (no caso da venda com frete) ou o cliente vai até a fazenda buscar a areia (no caso da venda sem frete). Abaixo está ilustrado de como ocorre o transporte da pá carregadeira para o caminhão na figura2. Figura 2 a areia sendo transportada da pá carregadeira para o caminhão Ao total, portanto, são dois equipamentos e os caminhões que são mantidos pela JML para caso a areia necessite ser entregue fora da fazenda. 25

26 Cada máquina exige um funcionário manuseando-a. Há também alguns funcionários que são motoristas dos caminhões e funcionários envolvidos no administrativo da empresa. Ao total, são aproximadamente dez funcionários. Além dessas informações, seria necessário ter um setor de leis ambientais. Há uma lei quanto à exploração, pois ao ser realizada a escavação da areia se trata de uma exploração da terra. Há uma quantidade máxima que deve ser respeitada anualmente, e a empresa necessita também ter uma licença. Essa licença necessita ser renovada anualmente, e o sistema irá ajuda a empresa a cumprir estes requisitos. Apêndice B - Contatos e Coleta de Informações Para melhor entendimento do problema e do que a solução deveria conter, foram realizadas algumas entrevistas com o sócio da empresa JML Areia Empreendimentos, Marcos Sampaio. Seguem algumas das perguntas/respostas: Pergunta: Qual o maior problema do areeiro? Resposta: Armazeno todas as informações de gerenciamento em planilhas Excel e gostaria de ter uma forma mais eficiente de armazená-las. Pergunta: O que o senhor costuma armazenar nas planilhas Excel? Resposta: Minhas despesas, combustível gasto com a pá carregadeira, informações sobre os funcionários, manutenção dos equipamentos(limpeza, etc). Pergunta: O senhor vende quantos tipos de areia? Resposta: Vendemos areia de três tipos, mas a mais vendida é a areia preta, pois ela é mais cara que as outras. As outras são areia de aterro e areia de argila. Pergunta: Como funcionam as vendas de areia? Resposta: As vendas são realizadas todas pessoalmente ou por telefone. Temos 2 tipos de venda, com frete e sem frete. No caso de com frete cobramos um valor e um caminhão nosso transporta a areia para o local de entrega. No caso de venda sem frete, o cliente deve buscar a areia na nossa fazenda. Pergunta: Quanto está sendo extraído de areia por dia? Resposta: Atualmente 100m³, mas queremos aumentar para 360m³. Pergunta: Como funcionam as licenças ambientais em relação a extração da areia? 26

27 Resposta: Há três licenças e a mais importante é a do CPRH, que só dura um ano. Esta licença serve para que nós tenhamos direito de vender areia. Seria legal se o sistema me lembrasse três meses antes que a licença está para vencer. Com estas respostas, a equipe visa entender o problema com mais detalhes e propor soluções adequadas. Apêndice C Descrição dos Casos de Uso [UC01] Entradas Atores Pré-condições Fluxo Principal Fluxo alternativo Pós-condições Login Login Senha Administrador Nenhuma 1. É apresentado ao usuário um formulário com os campos login e senha 2. O usuário informa o seu login e senha e clica no botão entrar. 3. Se o login estiver cadastrado no sistema e a senha correta, o usuário é autenticado no sistema. 1. Autenticação inválida, login incorreto. No passo 3, se o login que o usuário informou está inválido ou não preenchido, o sistema informa que o login do usuário está incorreto e retorna para o passo Autenticação inválida, senha incorreta. No passo 3, se a senha que o usuário informou está inválida ou não preenchida, o sistema informa que a senha do usuário está incorreta e retorna para o passo 1. Usuário autenticado no sistema através do seu login e senha. [UC02] Entradas Atores Pré-condições Cadastrar Administrador Login Senha Nome CPF Administrador O usuário deve estar logado no sistema 27

28 Fluxo Principal Subfluxo Inserir Administrador Subfluxo Atualizar Administrador Subfluxo Remover Administrador Fluxo alternativo Pós-condições O usuário deve ser do tipo administrador 1. O usuário escolhe a opção de Cadastro 2. O usuário é solicitado a escolher qual opção de cadastro será realizada: inclusão, atualização ou remoção. 3. De acordo com a opção escolhida, um dos subfluxos abaixo é executado. 4. É apresentado ao usuário na tela de Inserir Usuário um formulário com os campos login, senha, nome e CPF. 5. O usuário preenche estes dados e clica no botão inserir. 6. Se os dados forem válidos, a inserção é realizada. 4. É apresentado ao usuário na tela de Atualizar Usuário um formulário com os campos senha, login e nome. 5. O usuário preenche estes dados e clica no botão atualizar 6. Se os dados forem consistentes, a atualização será feita com sucesso. 4. É apresentada ao usuário a tela de Remover Usuário. 5. O administrador identifica o usuário a ser removido do sistema 6.O sistema mostra informações gerais sobre o administrador. 7. O sistema solicitará uma confirmação de exclusão do administrador no sistema. 8. O administrador decide se excluirá o administrador ou não, do sistema 9. Caso a decisão feita seja excluir o administrador, o sistema removerá o mesmo. 1. Erro ao preencher o formulário de inserção ou atualização. No passo 5, o sistema identifica campo inválido e solicita que o usuário preencha corretamente, indicando onde ocorreu o erro. 2. Erro ao inserir o administrador, administrador já inserido. Neste caso, o sistema retorna para o usuário uma mensagem de erro informando que já existe usuário inserido com aquele login. O cadastro do administrador é realizado. 28

29 [UC03] Entradas Atores Pré-condições Fluxo Principal Subfluxo Inserir Cliente Subfluxo Atualizar Cliente Subfluxo Remover Cliente Subfluxo Listar Clientes Subfluxo Relatório Clientes Cadastrar Cliente Nome CNPJ Telefones Endereço Administrador O usuário deve estar logado no sistema O usuário deve ser do tipo administrador 1. O usuário escolhe a opção de Cadastro 2. O usuário é solicitado a escolher qual opção de cadastro será realizada: inclusão, atualização, remoção, listagem ou relatório. 3. De acordo com a opção escolhida, um dos subfluxos abaixo é executado. 4.É apresentado ao usuário na tela de InserirCliente um formulário com os campos nome, CNPJ, Telefones e Endereço 5. O usuário preenche estes dados e clica no botão atualizar. 6. Se os dados forem consistentes, a atualização será feita com sucesso. 4.É apresentado ao usuário na tela de AtualizarCliente um formulário com os campos nome, CNPJ, Telefones e Endereço com as informações preexistentes no banco. 5. O usuário preenche estes dados a serem alterados e clica no botão atualizar 6. Se os dados forem consistentes, a atualização será feita com sucesso. 4. O administrador identificará o cliente a ser removido do sistema. 5. O mesmo informará se excluirá o cliente do sistema. 6. O sistema solicitará ao administrador uma confirmação de exclusão do cliente. 7. O sistema removerá o cliente. 4. O administrador solicita informações gerais sobre os clientes que estão no banco. 5. O sistema envia uma listagem com as informações resumidas dos clientes. 6. O administrador escolhe o cliente para obter informações mais detalhadas e completar a consulta. 4. O administrador solicita relatórios de um determinado mês. 5. O servidor envia o relatório requisitado à aplicação cliente. 6. O relatório sobre os orçamentos do referido mês é mostrado ao usuário. 29

30 Fluxo alternativo Pós-condições 1. Erro ao preencher o formulário de inserção ou atualização. No passo 5, o sistema identifica campo inválido e solicita que o usuário preencha corretamente, indicando onde ocorreu o erro. 2. No subfluxo de remoção o administrador pode recusar de exluir o cliente. Neste caso, o sistema retorna para a tela inicialmente mostrada. O cadastro do cliente é realizado. [UC04] Entradas Atores Pré-condições Fluxo Principal Fluxo alternativo Pós-condições Relatório de Orçamentos Definição de tempo (como mês e ano) Administrador O usuário deve estar logado no sistema O usuário deve ser do tipo administrador 1. O administrador solicita relatórios de um determinado mês. 2. O servidor envia o relatório requisitado à aplicação cliente. 3. O relatório sobre os orçamentos do referido mês é mostrado ao usuário. (1) Caso o administrador escolha a opção de voltar a tela anterior, o sistema interrompe a execução de exibir o referido relatório. O sistema mostrará o referido relatório ao usuário através da tela. [UC05] Entradas Atores Pré-condições Fluxo Principal Cadastrar Equipamento Nome da Máquina Informação de Status (Alugada/Comprada) Custo único ou mensal Administrador O usuário deve estar logado no sistema O usuário deve ser do tipo administrador 1. O usuário escolhe a opção de Cadastro 2. O usuário é solicitado a escolher qual opção de cadastro será realizada: inclusão, atualização ou remoção. 3. De acordo com a opção escolhida, um dos subfluxos abaixos é executado. 30

31 Subfluxo Inserir Equipamento Subfluxo Atualizar Equipamento Subfluxo Remover Equipamento Fluxo alternativo Pós-condições 4. O administrador informa ao sistema a intenção de inserir um novo equipamento 5. O administrador insere as informações sobre o equipamento a ser cadastrado 6. O sistema informa ao usuário o sucesso ou o fracasso da operação. 7. Caso o cadastro tenha ocorrido normalmente, o sistema mostrará a página de cadatro novamente. 4. O usuário solicitará modificações em um equipamento específico. 5. O usuário seleciona o equipamento que deseja realizar modificações. 6. As informações sobre o equipamento são mostradas ao usuário. 7. O usuário atualiza as informações 8. O sistema mostra uma mensagem de confirmação da atualização a ser realizada 9. O usuário confirma atualizações. 10. O sistema envia uma mensagem na interface com o usuário, sobre a atualização do sistema. 4.O administrador solicita a exclusão de um equipamento. 5. O administrador informa algum atributo do equipamento e posteriormente escolhe o equipamento, a ser excluído. 6. O sistema informa ao usuário que o equipamento foi removido. (5) Campos inválidos O sistema informará ao usuário a impossibilidade de cadastro devido ao erro das informações inseridas Equipamento cadastrado no sistema. [UC06] Entradas Atores Pré-condições Fluxo Principal Geração de Contrato Administrador O usuário deve estar logado no sistema O usuário deve ser do tipo administrador 1. O administrador solicita geração de contrato relacionado a uma venda específica. 2. O administrador insere as informações necessárias à criação de tal contrato. 3. O sistema mostrará o contrato para confirmação do usuário. 4. O administrador irá validar o contrato e 31

32 Fluxo alternativo Pós-condições inserir a sua existência ao banco. 5. O sistema retorna uma mensagem ao usuário, caso a operação tenha ocorrido com sucesso ou tenha ocorrido alguma falha. (2) Campos incorretos a. O administrador ter inserido campos incorretos ao momento da validação do documento. b. O administrador corrige esses valores iniciando o processo de preenchimento dessas informações. O sistema mostrará ao administrador o contrato gerado. [UC07] Entradas Atores Pré-condições Fluxo Principal Fluxo alternativo Pós-condições Controle de Vendas Preço Quantidade Data Cliente Frete Administrador, Funcionário O usuário deve estar logado no sistema 1. O usuário deverá inserir as informações necessárias para efetuar uma venda. 2. O sistema envia uma mensagem de confirmação da venda requerida. 3. O usuário confirma a venda. 4. O sistema registra essa venda no banco de dados para posterior gerenciamento e manutenção de relatórios. 5. O sistema envia uma mensagem de confirmação da venda, através da interface do usuário. (3) O usuário do sistema cancela uma venda A venda não é inserida no banco de dados, portanto não fará parte dos relatórios. O sistema retorna a tela de vendas para que o usuário possa cadastrar outra venda. A inserção de uma venda no banco de dados, para criação dos relatórios com a finalidade de consulta pelo usuário. O sistema mostrará uma tela para cadastro de uma outra venda, caso assim, este desejar. 32

33 [UC08] Entradas Atores Pré-condições Fluxo Principal Subfluxo Adicionar Estoque Subfluxo Remover Estoque Fluxo alternativo Pós-condições Controle de Estoque Administrador Funcionário O usuário deve estar logado no sistema. 1. O usuário deverá inserir as informações necessárias para efetuar alguma operação relacionada ao estoque. 2. O sistema envia uma mensagem de confirmação da operação requerida. 5. O usuário confirma a operação. 6. O sistema registra no banco de dados para posterior gerenciamento e manutenção de relatórios. 7. O sistema envia uma mensagem de confirmação, através da interface do usuário. 3. O usuário é redirecionado para a tela de Adicionar Estoque. 4. O usuário informa a quantidade de estoque que deseja adicionar. 3. O usuário é redirecionado para a tela de Remover Estoque. 4. O usuário informa a quantidade de estoque que deseja remover. (3) O usuário do sistema cancela uma operação de modificação no controle de estoque. A operação não deverá modificar o banco de dados, portanto não fará parte dos relatórios. Uma lista de operações possíveis é mostrada na interface do usuário, com a finalidade de mais alterações nos relatórios sobre o estoque para gerenciamento dos mesmos. 33

34 [UC09] Entradas Atores Pré-condições Fluxo Principal Fluxo alternativo Pós-condições Realizar Compra CPF Cliente O usuário deve estar logado no sistema O usuário deve ser do tipo Cliente 1. O cliente solicita uma compra. 2. O cliente informa a quantidade que deseja comprar 3. O cliente decide se a compra será com ou sem frete e informa dados de pagamento. 4. O cliente confirma a compra e o sistema envia um para a gerência da JML informando que aquela compra foi feita. 5. A JML envia o estoque para o cliente (no caso do frete) ou notifica o cliente que ele pode ir buscar o material (no caso de não haver frete). (3) O cliente informa dados de pagamento inválidos (número de cartão de crédito, etc). O sistema retorna uma mensagem ao cliente sobre a invalidez dos dados e retorna para a tela de compra. (4) O servidor cai e o sistema não consegue finalizar a compra e enviar um para os administradores. O sistema retorna para a tela de compra e informa ao cliente sobre a perda de conexão. O sistema atualizado com a venda realizada. [UC10] Entradas Atores Pré-condições Fluxo Principal Cadastrar Funcionário Nome CPF Salário Data de admissão e Um ou mais telefones. Administrador O usuário deve estar logado no sistema. O usuário deve ser um administrador. 1. O usuário escolhe a opção de Cadastro 2. O usuário é solicitado a escolher qual opção de cadastro será realizada: inclusão, atualização, remoção, listagem ou relatório. 34

35 Subfluxo Inserir Funcionário Subfluxo Atualizar Funcionário Subfluxo Remover Funcionário Subfluxo Listar Funcionários Subfluxo Relatório Funcionários Fluxo alternativo Pós-condições 3. De acordo com a opção escolhida, um dos subfluxos abaixos é executado. 4. O administrador informa ao sistema a intenção de inserir um novo funcionário 5. O administrador insere as informações sobre o funcionário a ser cadastrado 6. O sistema informa ao usuário o sucesso ou o fracasso da operação. 7. Caso o cadastro tenha ocorrido normalmente, o sistema mostrará a página de cadatro novamente. 4. O usuário solicitará modificações em um funcionário específico. 5. O usuário seleciona o funcionário que deseja realizar modificações. 6. As informações sobre o funcionário são mostradas ao usuário. 7. O usuário atualiza as informações 8. O sistema mostra uma mensagem de confirmação da atualização a ser realizada 9. O usuário confirma atualizações. 10. O sistema envia uma mensagem na interface com o usuário, sobre a atualização do sistema. 4. O administrador solicita a exclusão de um funcionário. 5. O administrador informa algum atributo do funcionário e posteriormente escolhe o funcionário a ser excluído. 6. O sistema informa ao usuário que o funcionário foi removido. 4. O administrador solicita informações gerais sobre os funcionários que estão no banco 5. O sistema envia uma listagem com as informações resumidas dos funcionários. 6. O administrador escolhe o 4. O administrador solicita relatórios com as informações dos funcionários cadastrados, relacionado a um determinado mês. 5. O servidor envia o relatório requisitado à aplicação cliente. 6. O relatório sobre os orçamentos do referido mês é mostrado ao usuário. (3) Campos inválidos O sistema informará ao usuário a impossibilidade de cadastro devido ao erro das informações inseridas Funcionário cadastrado no sistema 35

36 [UC11] Entradas Atores Pré-condições Fluxo Principal Fluxo alternativo Pós-condições Renovação de Licença Relógio, Sistema de 1. O relógio fica disparando. 2. Haverá algum momento em que a licença de exploração da terra deverá ser renovada, pois a mesma tem uma validade de um ano. 3. Quando este momento chegar, o relógio irá ativar um sistema de e- mail. 4. Este sistema de irá notificar o Administrador da JML que ele precisa renovar sua licença de exploração da terra, para evitar que ele descumpra as leis de exploração. (2) A licença pode não ter vencido o prazo de validade e neste caso o relógio não irá ativar o sistema de , ele apenas continuará a disparar. (4) Pode ser que ocorra alguma falha na comunicação, neste caso o sistema irá deixar o evento em standby e irá tentar executá-lo até que o usuário seja notificado sobre a renovação da licença. O usuário irá ser notificado que sua licença venceu. [UC12] Entradas Atores Pré-condições Fluxo Principal Relatório de Área Explorada Administrador O usuário deve estar logado no sistema O usuário deve ser do tipo administrador 1. O administrador irá solicitar que o sistema exiba um relatório da área explorada. 2. O sistema irá redirecionar para uma tela onde será exibido um relatório sobre a área explorada. Essa informação será obtida através dos dados das vendas realizadas. 3. O sistema fará uma checagem de se a área explorada é razoavelmente menor que a permitida por ano. Se o 36

37 Fluxo alternativo Pós-condições administrador estiver nos conformes, ele verá apenas a quantidade. Caso contrário, um alerta será exibido de que ele está próximo de chegar no limite permitido pela legislação, evitando que ele descumpra as leis. (2) Pode ser que nenhuma venda tenha sido realizada, ou seja, não foi explorado nada. Neste caso, o relatório não conterá nehuma informação. O usuário poderá consultar quanto explorou até agora de área. 37