CORRIGIDO-FlaviaFelipeRenatoIsmar-Documento de …if716/projetos/2012_3/Projeto2/Equipe07... · 2013. 7. 30. · Tabela)de)Histórico)de)Revisões:)) Revisão)Data) Descrição) Autor)

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

Sorvetech

Especificação de Requisitos

Professora: Carla Silva

Recife, 23 de novembro de 2012

Tabela de Histórico de Revisões:

Revisão Data Descrição Autor

01 05/11 Início do Documento de Requisitos. fpc

02 06/11 Descrição das técnicas de coleta de dados; início das descrições dos requisitos. rfp3

03 07/11 Descrição das técnicas de coleta de dados; continuação das descrições dos requisitos. ipbn

04 09/11 Descrição dos Casos de uso fsos

05 11/11

Término da descrição dos requisitos, modelagem do SR, modelagem do diagrama NFR, construção do modelo BPMN

fsos, fpc, ipbn, rfp3

06 14/11 Início das correções no material da primeira apresentação. Retificação do diagrama BPMN fpc, fsos

07 15/11

Retificação do diagrama NFR e i*. Fim das correções do material da primeira apresentação.

ipbn, rfp3

08 18/11

Início da elaboração da versão final do documento de requisitos. Elaboração do protótipo de telas, diagrama de atividades e sequência

fsos, fpc, ipbn, rfp3

09 19/11 Fim da elaboração do documento de requisitos fsos, fpc, ipbn, rfp3

fsos, fpc, ipbn, rfp3 23/11/2012

3

Índice1. INTRODUÇÃO …………………………………………………………………………………. 6

1.1 Motivação .................................................................... ............................................................. 6

1.2 O Problema Identificado.................................................................... ....................................... 6

1.3 Modelo BPMN do processo atual...............................................................................................7

1.4 Convenções para Identificação dos Requisitos ...................................................................... 8

1.5 Convenções para Identificação dos Casos de Uso ................................................................. 8

1.5.1 Estrutura dos casos de uso ....................................................................................... 8

1.5.2 Prioridades dos casos de uso ................................................................................... 9

1.5.3 Descrição dos Atores ................................................................................................ 9

2. REQUISITOS ORGANIZACIONAIS ........................................................................................9

3. REQUISITOS FUNCIONAIS ………………………………………………………………...... 9

3.1 AUTENTICAÇÃO ………………………………………………………………………........ 9

3.1.1 [RF01] Criar conta.............................................................. ........................................... 9

3.1.2 [RF02] Efetuar Logon........................................................ .......................................... 10

3.1.3 [RF03] Efetuar Logoff........................................................ .........................................10

3.1.4 [RF04] Mudar senha........................................................ ............................................10

3.1.5 [RF05] Receber senha........................................................ ..........................................10

3.2 ADMINISTRAÇÃO........................................................ ........................................... ................11

3.2.1 [RF06] Cadastrar pedido................................. ........................................... ................11

3.2.2 [RF07] Excluir pedido................................. ........................................... .....................11

3.2.3 [RF08] Acessar andamento de pedido................................. .....................................12

3.3 SISTEMA...................................................................................................................... ...............12

3.3.1 [RF09] Exibir notificações................................. ........................................... ...............12

3.3.2 [RF10] Fornecer respostas................................. ............................................ ........... 12

3.3.3 [RF11] Aprovar solicitações.............................. ............................................ ........... 13

3.3.4 [RF12] Reprovar solicitações.............................. ...................................................... 13

3.3.5 [RF13] Fazer planejamento financeiro.............................. ...................................... 13

3.3.6 [RF14] Visualizar histórico de transações.................... .......................................... 14

3.3.7 [RF15] Enviar solicitações ao setor de estoque.................... ................................. 14

3.3.8 [RF16] Notificar setor financeiro.................... ......................................................... 14

3.3.9 [RF17] Receber solicitações de matéria-‐‑prima....................................................... 15


4

3.3.10 [RF18] Enviar solicitação de picolé........................................................................ 15 4. REQUISITOS NÃO FUNCIONAIS.......................................................................................... 15

4.1 REQUISITOS DE PROCESSOS............................................................................................... 15

4.1.1 [RNF01] Utilizar linguagem Java................................................................................. 16

4.1.2 [RNF02] Utilizar Banco de Dados MySQL.................................................................. 16

4.1.3 [RNF03] Utilizar backup com fita................................................................................. 14

4.2 REQUISITOS DE PRODUTO................................................................................................. 16

4.2.1 [RNF04] Usabilidade.................................................................................................... 16

4.2.2 [RFN05] Disponibilidade............................................................................................. 17

4.2.3 [RFN06] Tempo de resposta......................................................................................... 17

4.2.4 [RFN07] Tempo de inserção de dados.......................................................................... 17

4.2.5 [RFN08] Robustez........................................................................................................ 17

4.2.6 [RFN09] Consistência.................................................................................................. 18

4.2.7 [RFN10] Tolerância à falhas........................................................................................ 18

4.2.8 [RFN11] Segurança..................................................................................................... 18

4.2.9 [RFN12] Backup.......................................................................................................... 18

4.2.10 [RFN13] Mensagens de erro...................................................................................... 19

4.2.11 [RFN14] Restrição no acesso..................................................................................... 19

4.2.12 [RFN15] Privacidade................................................................................................. 19

4.2.13 [RFN16] Padronização............................................................................................... 20

4.3 REQUISITOS EXTERNOS...................................................................................................... 20

4.3.1 [RNF17] Tempo de desenvolvimento........................................................................... 20

4.3.2 [RFN18] Orçamento.................................................................................................... 20

5. MODELAGEM ORGANIZACIONAL................................................................................... 20

5.1 MODELAGEM DE DEPENDÊNCIA ESTRATÉGICA..................................................... 20

5.2 MODELAGEM ESTRATÉGICO DA RAZÃO................................................................... 21

6. MODELAGEM DE REQUISITOS FUNCIONAIS (CASOS DE USO) ........................... 23

7. DIAGRAMA DE ATIVIDADE E SEQUÊNCIA ................................................................................ 23

7.1 Diagrama de Atividade ................................................................................................. 24

7.2 Diagrama de Sequência .................................................................................................. 29

8. MODELAGEM DE REQUISITOS NÃO-‐‑FUNCIONAIS (NFR FRAMEWORK) ......... 32

9. CONCLUSÃO............................................................................................................................. 36


5

REFERÊNCIAS..................................................................................................................................36

RELATÓRIO DA EQUIPE........................................................................................................... 36

ANEXO A -‐‑ Sobe a Zeca'ʹs............................................................................................................. 37

ANEXO B -‐‑ Contatos e Coleta de Informações......................................................................... 37

ANEXO C -‐‑ Deficiência no Sistema de Gerenciamento.......................................................... 38

ANEXO D -‐‑ Descrição dos Casos de Uso.................................................................................... 38

ANEXO F -‐‑ GLOSSÁRIO ................................................................................................................... 45

Índice de Figuras

Figura 1 Modelagem de Dependência Estratégica. .................................................................... 2019

Figura 2 Modelo estratégico da razão com ator Sistema expandido. ........................................ 220

Figura 3 Modelagem de Requisitos Funcionais (Casos de Uso) ................................................. 231

Figura 4 Diagrama de atividade: UC01 .......................................................................................... 332


Figura 6 Diagrama de atividade: UC03 ............................................................................................ 33



Figura 9 Diagrama de sequencia: UC01 ......................................................................................... 337

Figura 10 Diagrama de sequencia: UC02 ....................................................................................... 338




Figura 14 Modelagem de Requisitos Não Funcionais 1 ............................................................. 3330

Figura 15 Modelagem de Requisitos Não Funcionais 2 ............................................................ 3331

Figura 16 Modelagem de Requisitos Não Funcionais 3 ............................................................. 3332

Índice de Tabelas Tabela 1 Porcentagem de esforço dos membros da equipe. ........ Error! Bookmark not defined.


6

1. Introdução

O objetivo desde documento é descrever o problema que foi identificado e especificar os requisitos para a solução encontrada durante a fase de estudo de viabilidade realizada previamente. Essa solução tem como centro um sistema de gerenciamento que deve ser construído a partir das informações capturadas pela utilização de algumas técnicas descritas adiante.

O nosso objeto de estudo é a empresa Zeca’s. A empresa é atualmente organizada em vários setores que utilizam um sistema ultrapassado. Visando um aumento na produtividade e lucros da empresa, este projeto busca ajudar a empresa no seu gerenciamento de atividades a partir da construção de um sistema mais moderno e otimizado.

1.1 Motivação

O advento da computação permitiu que as atividades antes feitas pelos humanos pudessem ser automatizadas, permitindo uma maior organização e eficiência. A partir dessa premissa, temos como motivação construir um sistema de gerenciamento de uma empresa de sorvete, mais precisamente a Zeca’s.

No nosso projeto, pretendemos propor um sistema, o SorveTech, para tentar melhorar a administração da empresa, aumentando os lucros e melhorando a produtividade da empresa e de seus funcionários. Nesse sistema, faremos uma maior interação e integração entre os diversos setores da empresa, aumentando a velocidade de comunicação entre eles. Com esse sistema também podemos manter registro do que foi pedido e do que foi feito e de como foi feito, e todas as informações podem ser guardadas de forma seguras e com backup.

1.2 O Problema Identificado

No nosso projeto, nos baseamos na empresa Zeca’s de picolés e sorvetes, mas o sistema que propomos pode ser utilizado em qualquer empresa de organização semelhante (que produzem qualquer tipo de alimento). Mais detalhes sobre a empresa podem ser encontrados no Apêndice A. No Apêndice B pode ser encontrada uma entrevista realizada com o intuito de entender melhor o dia-‐‑a-‐‑dia da empresa, assim como os problemas apresentados nela. No Apêndice C estão listados os principais problemas encontrados no sistema atual da empresa.

Em geral, esse tipo de empresa é organizada em departamentos diferentes (máquinas e logística, estoque, gerência, administração e financeiro). O setor de máquinas e logística é responsável pelo recebimento dos pedidos, pela produção do pedido, e pela distribuição do produto final. O setor de estoque é responsável pelo gerenciamento da quantidade de produtos e mantimentos disponível na empresa. Caso seja detectada a falta de algum recurso, esse setor informa aos outros o que falta para poder ser feito a solicitação devida. O setor de gerência recebe as solicitações dos outros setores e as avalia, decidindo se são viáveis ou não. O setor de administração gerencia os pagamentos da empresa e é responsável pelos contratos atuais da empresa. O setor financeiro registra gastos e ganhos da empresa, também sendo responsável pela análise de redução de gastos e ampliação de investimentos.


7

1.3 Modelo BPMN do processo atual

O modelo BPMN que retrata as atividades da empresa no cenário atual é apresentado logo abaixo.


8

Neste modelo, vê-‐‑se que a empresa é representada em uma única piscina, com cada um dos setores separados em sua própria raia. Há uma raia para o departamento de transporte, uma para o departamento de produção, uma para o departamento de estoque, um para o departamento de gerência, uma para o departamento financeiro e uma para o departamento administrativo. Em cada uma das raias, podem-‐‑se ver as atividades realizadas em cada departamento, e como cada uma dessas atividades se interligam. Algumas atividades são dependentes de outras e outras podem ser realizadas em paralelo (o que é mostrado no diagrama). A dinâmica de troca de informações dentro da empresa também pode ser visualizada.

O modelo representa a situação atual do funcionamento da empresa. O setor administrativo basicamente é responsável por pagar contas, receber solicitações de pedidos de produtos manufaturados dos clientes da empresa e criar contatos com novos clientes. O setor financeiro é responsável por registrar os gastos e recebimentos da empresa, analisando o saldo no final do mês, também é responsável por liberar capital para algum setor que necessite fazer alguma compra. O setor do estoque é basicamente responsável por contabilizar as matérias-‐‑primas e produtos manufaturados, analisando a necessidade de comprar matérias-‐‑primas ou produzir novos produtos. O setor de produção é responsável pela produção dos produtos manufaturados e o setor de transporte pelo envio dos produtos aos clientes. A gerencia, nosso principal foco, consiste basicamente em receber requisições de outros setores, aprova-‐‑las ou reprova-‐‑las e repassar as solicitações aprovadas para outros setores. Essas requisições atualmente são realizadas por requisições em papel ofício, repassadas manualmente.

1.4 Convenções para Identificação dos Requisitos

Por convenção, os requisitos são indicados e referenciados por um indicador no formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os nomes dos casos de uso relacionados.

1.5 Convenções para Identificação dos Casos de Uso

Por convenção, os casos de uso são indicados e referenciados por um indicador no formato [UCxx], onde xx se refere ao número do caso de uso.

1.5.1 Estrutura dos casos de uso

Cada caso de uso terá o seguinte formato:

• Atores: Os modelos de usuário que utilizarão o caso de uso; • Prioridade: Prioridade de implementação deste caso de uso; • Pré-‐‑condições: Condições que devem ser satisfeitas antes de o caso de uso ser

executado; • Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso seja

concluído, podendo incluir fluxos de eventos secundários e/ou alternativos; • Pós-‐‑condições: Condições que devem ser satisfeitas depois de o caso de uso ser

finalizado.


9

1.5.2 Prioridades dos casos de uso

Os casos de uso são classificados como:

• Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse tipo de caso de uso deve ser implementado impreterivelmente, caso contrário, o projeto perderá sua utilidade.

• Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado. Contudo, essa utilização se dá de forma não satisfatória pelo cliente.

• Desejável: 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.

1.5.3 Descrição dos Atores

Os atores são aqueles que interagem de alguma forma com o sistema. Eles podem ser funcionário da Zeca’s, clientes da empresa ou o administrador do sistema.

2. Requisitos Organizacionais

Os requisitos organizacionais devem satisfazer os objetivos da empresa e definir porque o sistema é necessário. Esses requisitos são:

Agilizar o processo de requisições que são realizadas na empresa;

Facilitar o processo de requisições, através de uma interface computadorizada;

Reduzir custos;

3. Requisitos Funcionais

3.1 Autenticação

3.1.1 [RF01] Criar conta

Identificação: [RF01] Criar conta

Casos de Uso relacionados: [UC01]

Descrição:

Permite que um funcionário crie uma conta para um empregado da empresa, com um login e uma senha, e coloque as informações do funcionário do sistema (seu nome, endereço, telefone para contato, CPF, e-‐‑mail e o setor em que o funcionário trabalha).

Prioridade: Essencial Importante Desejável


10

3.1.2 [RF02] Efetuar logon

Identificação: [RF02] Efetuar logon

Casos de Uso relacionados: [UC03][UC04]

Descrição:

Permite que um usuário tenha acesso a informações pertencentes ao setor o qual ele faz parte. Para isso, ele deve informar na página inicial do sistema, seu login e senha e apertar no botão “Ok”.


3.1.3 [RF03] Efetuar logoff

Identificação: [RF03] Efetuar logoff

Casos de Uso relacionados: Nenhum

Descrição: Permite que o usuário saia do sistema. Ao selecionar a opção “Logoff” no canto direito superior da tela, a conta do funcionário será deslogada.


3.1.4 [RF04] Mudar senha

Identificação: [RF04] Mudar Senha


Descrição:

Permite que o usuário possa mudar a sua senha ao selecionar a opção “Mudar senha”. O funcionário deverá completar os campos: “Nova senha”, “Confirme a nova senha” e “Senha atual”. Se os dados estiverem consistentes, (Nova senha tem que ser igual à confirmação da nova senha e a senha atual deve ser igual à senha que o funcionário usou ao logar) o sistema modificará a senha do funcionário para a nova senha.


3.1.5 [RF05] Receber senha

Identificação: [RF05] Receber senha


11


Descrição: Solicitando a opção “Receber senha” a senha atual do usuário será encaminhado para o e-‐‑mail cadastrado.


3.2 Administração

3.2.1 [RF06] Cadastrar pedido

Identificação: [RF06] Cadastrar pedido


Descrição:

O setor administrativo deve ser capaz de cadastrar o pedido de um cliente no sistema. As informações acerca do cliente que devem ser armazenadas no sistema são:

1. Nome do cliente

2. Telefone/Celular

3. Endereço de e-‐‑mail

4. Endereço físico

5. CPF/CNPJ

6. Listagem dos produtos e suas respectivas quantidades

7. Preço total

8. Endereço de entrega

9. Prazo limite para entrega


3.2.2 [RF07] Excluir pedido

Identificação: [RF07] Excluir pedido


Descrição: O setor administrativo deve ser capaz de excluir o pedido de um cliente no sistema.


12


3.2.3 [RF08] Acessar andamento dos pedidos

Identificação: [RF08] Acessar andamento dos pedidos


Descrição: O setor administrativo deve ter acesso ao status de andamento de cada pedido efetuado pelo sistema, que são identificados através de um número identificador.


3.3 Sistema

3.3.1 [RF09] Exibir notificação

Identificação: [RF09] Exibir notificação

Casos de Uso relacionados: [UC02][UC03][UC04]

Descrição:

O sistema deve exibir uma notificação assim que uma solicitação de um dos departamentos for recebida. A solicitação e a pessoa que a fez devem ser claramente identificadas com o nome do funcionário que realizou a solicitação, seu departamento e o que foi solicitado.


3.3.2 [RF10] Fornecer respostas

Identificação: [RF10] Fornecer respostas


Descrição: O sistema deve apenas aprovar ou reprovar uma solicitação.



13

3.3.3 [RF11] Aprovar solicitação

3.3.4 [RF12] Reprovar solicitação

3.3.5 [RF13] Fazer planejamento financeiro

Identificação: [RF11] Aprovar solicitação


Descrição: Quando a administração aprova uma solicitação, o sistema deve repassar a informação para o departamento que mandou a solicitação.


Identificação: [RF12] Reprovar solicitação


Descrição: Quando a administração reprova uma solicitação, o sistema deve repassar a informação para o departamento que mandou a solicitação.


Identificação: [RF13] Fazer planejamento financeiro


Descrição:

O sistema deve elaborar um planejamento financeiro para o mês seguinte no último dia de cada mês a partir das solicitações aprovadas que resultem em gastos e em receita que forem armazenadas no mesmo durante o mês atual.



14

3.3.6 [RF14] Visualizar histórico de transações

3.3.7 [RF15] Enviar solicitações ao setor de estoque

3.3.8 [RF16] Notificar setor financeiro

Identificação: [RF14] Visualizar o histórico de transações


Descrição:

Pelo sistema, deve ser possível visualizar o histórico de transações da empresa com os clientes, bem como o histórico de transações durante um período de tempo determinado pelo usuário.


Identificação: [RF15] Enviar solicitações ao setor de estoque


Descrição:

O sistema deve ser capaz de, ao ser aprovada uma solicitação de venda de picolés, enviar uma solicitação ao estoque para que, se os picolés se estiverem disponíveis, sejam repassados ao setor de transporte para seu envio ao cliente.


Identificação: [RF16] Notificar setor financeiro


Descrição:

Quando uma solicitação de dinheiro for feita, o sistema deve notificar o setor financeiro sobre a solicitação com as informações de quem pediu a solicitação, qual setor ele faz parte, a quantidade de capital desejado e a justificativa para o uso desse dinheiro.



15

3.3.9 [RF17] Receber solicitações de matéria-‐‑prima

3.3.10 [RF18] Enviar solicitação de picolé

4. Requisitos Não-‐‑Funcionais

Este capítulo descreve requisitos relacionados com restrições e aspectos de qualidade. A classificação desses requisitos segue o autor [Sommerville], que agrupa os mesmos em três grupos, a saber: requisitos de processo, requisitos de produto e requisitos externos.

4.1 Requisitos de Processo

4.1.1 [RNF01] Utilizar linguagem Java

Identificação: [RNF01] Utilizar linguagem Java

Casos de Uso relacionados: Todos

Descrição: O sistema deverá ser codificado na linguagem Java, que é uma

Identificação: [RF17] Receber solicitações de matéria-‐‑prima


Descrição:

O sistema deve ser capaz de, ao ser aprovada uma solicitação de matéria-‐‑prima, enviar uma solicitação ao estoque para que a matéria-‐‑prima seja levada ao setor de produção com as informações da quantidade de matéria-‐‑prima com sua respectiva descrição.


Identificação: [RF18] Enviar solicitação de produção de picolé


Descrição: O sistema deve ser capaz de, ao ser aprovada uma solicitação de produção de picolés, repassar a solicitação ao setor de produção para que picolés sejam produzidos.



16

linguagem bastante eficiente e portável.


4.1.2 [RNF02] Utilizar Banco de Dados MySQL

Identificação: [RNF02] Utilizar Banco de Dados MySQL


Descrição: O sistema deverá utilizar banco de dados MySQL porque ela oferece os recursos necessário e é economicamente viável.


4.1.3 [RNF03] Utilizar Backup com fita

Identificação: [RNF03] Utilizar Backup com fita

Casos de Uso relacionados:

Descrição: O método de backup do sistema será com fita, porque é barato e seguro.


4.2 Requisitos de Produto

4.2.1 [RNF04] Usabilidade

Identificação: [RNF04] Usabilidade


Descrição: O sistema deve ser fácil de usar, com uma interface gráfica intuitiva, onde os usuários saibam usar as funcionalidades principais com um dia de treinamento.



17

4.2.2 [RNF05] Disponibilidade

Identificação: [RNF05] Disponibilidade


Descrição: O sistema deve estar disponível e em funcionamento 24h por dia e 7 dias por semana.


4.2.3 [RNF06] Tempo de resposta

Identificação: [RNF06] Tempo de resposta


Descrição: Nenhuma das consultas feitas ao sistema deverá ultrapassar 5 segundos.


4.2.4 [RNF07] Tempo de inserção de dados

Identificação: [RNF07] Tempo de inserção de dados

Casos de Uso relacionados: [UC01] [UC02] [UC03]

Descrição: Nenhuma inserção de dados no sistema deverá ultrapassar 5 segundos.


4.2.5 [RNF08] Robustez

Identificação: [RNF08] Robustez


Descrição: O sistema deve ser robusto, rejeitando a entrada de dados inválidos.



18

4.2.6 [RNF09] Consistência

Identificação: [RNF09] Consistência


Descrição: Os dados armazenados no sistema deverão ser corretos e atualizados, não permitindo inconsistência caso dois usuários tentem modificar a mesma informação ao mesmo tempo.


4.2.7 [RNF10] Tolerância a falhas

Identificação: [RNF10] Tolerância a falhas


Descrição: O sistema necessita ser tolerante a falhas, em que deverá gerenciar as falhas ocorridas nas operações.


4.2.8 [RNF11] Segurança

Identificação: [RNF11] Segurança


Descrição:

Os dados do sistema estarão acessíveis para manipulação apenas por pessoas autorizadas, de forma a garantir que os dados armazenados e consultados estejam corretos em relação aos dados fornecidos ao sistema.


4.2.9 [RNF12] Backup

Identificação: [RNF12] Backup


Descrição:

É fundamental que o sistema ofereça um serviço de backup dos dados que seja realizado diariamente, para que em caso de falhas as informações possam ser recuperadas de forma rápida e eficiente.


19


4.2.10 [RNF13] Mensagens de erro

Identificação: [RNF13] Mensagens de erro


Descrição: As mensagens de erro fornecidas pelo sistema deverão ser objetivas, fornecendo ao usuário informações para solucionar o problema.


4.2.11 [RNF14] Restrição no acesso

Identificação: [RNF14] Restrição no acesso


Descrição:

Cada funcionário só pode ter acesso aos dados e funções relativas ao seu setor de trabalho na empresa. Os funcionários do estoque só podem solicitar dinheiro ao sistema e receber pedidos de envio. Os funcionários da administração só devem poder pagar suas contas a partir do sistema. Os funcionários do setor financeiro só podem aprovar os pagamentos. Os funcionários do setor de máquinas só podem solicitar matéria-‐‑prima ao sistema e avisar que picolés foram fabricados.


4.2.12 [RNF15] Privacidade

Identificação: [RNF15] Privacidade


Descrição: Garantir privacidade. Os dados armazenados só poderão ser acessíveis por máquinas localizadas dentro da empresa.



20

4.2.13 [RNF16] Padronização

Identificação: [RNF16] Padronização


Descrição: As requisições só podem ser feitas a partir de formulários padronizados.


4.3 Requisitos Externos

4.3.1 [RNF17] Tempo de desenvolvimento

Identificação: [RNF17] Tempo de desenvolvimento


Descrição: O tempo com o desenvolvimento do sistema não poderá ultrapassar mais de 20% do previsto no Estudo de Viabilidade.


4.3.2 [RNF18] Orçamento

Identificação: [RNF18] Orçamento


Descrição: O custo total de desenvolvimento do sistema, não poderá ser maior do que o custo estimado com o estudo de viabilidade.


5. Modelagem Organizacional

A modelagem organizacional utilizada é feita com base na notação i* (i estrela).

5.1 Modelagem de Dependência Estratégica

Figura 1 Modelagem de Dependência Estratégica.


21

5.2 Modelo Estratégico da Razão

Figura 1 Modelagem de Dependência Estratégica.


22

Figura 2 Modelo estratégico da razão com ator Sistema expandido.


23

6. Modelagem de Requisitos Funcionais (Casos de Uso)

Neste capítulo, os requisitos descritos anteriormente são modelados através de diagramas de caso de uso. O detalhamento dos casos de uso encontra-‐‑se no Anexo E deste documento.

Figura 3 Modelagem de Requisitos Funcionais (Casos de Uso)

7. Diagramas de Atividade e de Sequência

Abaixo temos os diagramas de atividades e sequência para os 5 casos de uso descritos:


24

7.1 Diagrama de Atividades:

[UC01]:

Figura 4 Diagrama de atividade: UC01


25

[UC02]:



26

[UC03]:



27

[UC04]:



28

[UC05]:



29

7.2 Diagrama de Sequência:

[UC01]:

Figura 9 Diagrama de sequencia: UC01


30

[UC02]:


[UC03]:



31

[UC04]:


[UC05]:



32

8. Modelagem de Requisitos Não-‐‑Funcionais (NFR Framework)

Este capítulo contém os refinamentos dos requisitos não-‐‑funcionais, descreve suas interdependências e operacionalizações.


33

Figura 14 Modelagem de Requisitos Não Funcionais


34

Abaixo temos a imagem 5 dividida em duas novas figuras (Figura 6 e Figura 7) para melhor visualização.



35



36

9. Conclusão

Através deste documento de requisitos, foi possível entender o problema que o sistema Sorvetech se propõe a resolver.

Além disso, foram apresentados as funções que o sistema deve dispor, a partir das definições do cliente. A partir dessas descrições, foi possível elaborar diagramas que descrevem o comportamento do sistema (modelos de casos de uso, diagrama NFR, diagrama SD) a partir de uma notação vastamente utilizada, permitindo uma melhor visualização dos requisitos propostos.

Referências

[Disciplina] Disciplina de Especificação de Requisitos e Validação de Sistemas. Disponível em: < https://sites.google.com/site/ervsif716/home>.

G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998.

Ian Sommerville. Engenharia de Software. 6ª Edição, Makron Books, 2003.

Relatório da Equipe

Nesta última seção, segue a porcentagem de esforço de cada membro da equipe. As atividades realizadas por cada um estão descritas no Histórico de Revisões deste documento.


37

Anexo A – Sobre a Zeca’s

A tradicional sorveteria Zeca’s é oriunda da cidade de Olinda-‐‑PE. Fundada no ano de 1979 e consolidando-‐‑se no mercado através, não apenas da qualidade do seu produto, como também através do lançamento de exclusividades criativas como, por exemplo, o sorvete de tapioca.

A empresa tem por objetivo principal vender sorvetes de qualidade com criatividade e a preços competitivos. A sorveteria está instalada no município de Abreu e Lima – PE, em uma área de 10 Hectares com uma área construída de 8.000 metros quadrados. A fábrica atual foi construía no ano de 2010.

A empresa possui 550 colaboradores. Construída com conceitos modernos de instalação e é totalmente automatizada. Sua produção alcança na alta estação a produção de 1.700.00 litros por mês e sua câmara frigorifica suporta um armazenamento de 900.000 litros de sorvete.

Anexo B – Contato e coletas de informação

Ao entrar em contato com a empresa Zeca’s, foi possível identificar que o sistema de gerenciamento da empresa poderia ser agilizado e incrementado. Uma vez que o problema foi identificado, procuramos entender bem o funcionamento atual do sistema através de uma entrevista com o próprio dono da empresa. Segue abaixo os detalhes da entrevista realizada:

Entrevista:

Grupo: Como ocorrem as principais movimentações na empresa?

Paulo: A empresa é dividida basicamente em 5 departamentos: Gerência, Administração, Vendas, Fábrica e Estoque. Todos os 4 últimos departamentos devem, sempre que houver uma requisição qualquer, comunicar a gerência para que ela possa repassar as requisições aos outros departamentos.

Grupo: A empresa possui internet em todos os departamentos?

Paulo: Sim. Internet com e sem fio.

Grupo: Como os funcionários enviam as requisições com a gerência?

Paulo: Os funcionários levam um formulário completado à mão até a sala da gerência. Daí a gerência gera um documento que deve ser dirigido ao setor destinado. Por exemplo, se o setor de estoque precisa de novos materiais, ele deve encaminhar esse pedido a gerencia, para que a gerencia gere um documento requisitando capital ao setor financeiro.

Grupo: Os setores são informatizados?


38

Paulo: Sim, porém os computadores são bem simples.

Grupo: Nesse caso, pelo menos uma parte dos funcionários sabe utilizar o computador?

Paulo: Sim, em todos os setores há funcionários que utilizam computadores.

Anexo C – Deficiência no sistema de gerenciamento

Analisando o sistema de gerenciamento da empresa, identificamos alguns problemas que podemos resolver ou melhorar com alternativas.

Os principais problemas foram:

1. O mais grave, foi a demora na realização das atividades que envolvem mais de um setor da empresa, já que nesses casos a gerência tinha sempre que intermediar as atividades.

2. O fato de os requerimentos serem entregues à gerência em um formulário de papel, que não só é muito lento de ser preenchido, como também há riscos de ser perdido. Além disso, o fato de ter que ser levado pessoalmente atrasa ainda mais esses procedimentos.

3. Mesmo possuindo computadores na empresa, eles não foram utilizados para melhorar o sistema de gerenciamento da empresa.

Anexo D – Descrição dos Casos de Uso

[UC01] Criação de contas de usuários da empresa

Identificador: [UC01]

Descrição: Criação de uma nova conta no sistema para um funcionário de qualquer setor na empresa. Só após a criação da conta os funcionários terão acesso às funcionalidades do sistema.

Ator: Funcionário da empresa (qualquer setor).

Prioridade: Essencial

Pré-‐‑condições: Não se aplica.

Pós-‐‑condições: O funcionário poderá ter acesso ao sistema a partir de sua identificação, acessando as funções condizentes com a sua função na empresa.

Fluxo de Eventos Principal


39

1. Tendo acesso a tela do sistema, o funcionário que deseja criar uma nova conta deve selecionar a opção “Criar conta de usuário”.

2. Em seguida, um formulário de cadastro estará sendo exibido. O funcionário deve preencher os seus dados e criar a sua senha de acesso;

3. O funcionário clica em “concluir”.

Fluxo Secundário 1

1. O funcionário forneceu uma senha fraca, que não se adequa a política de escolha de senhas.

2. A mensagem “Senha imprópria. Escolha outra” aparece na tela.

3. O usuário executa novamente os passos 1 e 2 do FP, com todos os seus dados já preenchidos, exceto o campo de senha.

Fluxo Secundário 2

1. Ao checar os dados fornecidos pelo funcionário, o sistema não encontra o funcionário no seu banco de dados;

2. A mensagem “Este funcionário não está cadastrado nessa empresa” aparece na tela;

3. O administrador do sistema recebe uma notificação fornecendo os dados informados pelo usuário;

4. O sistema volta à tela de cadastro.

Requisitos Não Funcionais Específicos [RNF11], [RNF14]

[UC02] Cadastro de pedido


Descrição: Quando um cliente realizar um pedido de compra de mercadoria e efetuar o pagamento do mesmo, o setor administrativo deverá cadastrar no sistema as informações referentes ao pedido. Esse cadastro é essencial para que processo de documentação, fabricação, estoque e transporte sejam corretamente executados. As informações que devem ser preenchidas nesse cadastro são:

1. Nome do cliente

2. Telefone/Celular

3. Endereço de e-‐‑mail


40

4. Endereço físico

5. CPF/CNPJ

6. Listagem dos produtos e suas respectivas quantidades

7. Preço total

8. Endereço de entrega

9. Prazo limite para entrega

Cada cadastro possui um identificador único, atribuído pelo sistema automaticamente.

Ator: Cliente e funcionário do setor administrativo

Prioridade: Essencial.

Pré-‐‑condições:

O cliente precisa ter realizado um pedido de compra de mercadoria. O cliente precisa ter efetuado o pagamento relativo ao pedido de compra. O funcionário precisa estar logado no sistema para efetuar o cadastro.

Pós-‐‑condições:

O funcionário do setor administrativo que realizou o cadastro poderá ter novamente acesso ao cadastro através do sistema a partir de sua identificação. Isto possibilita mudanças nas informações do cadastro, caso seja necessário.


1. Tendo acesso a tela do sistema, o funcionário terá um ícone com a opção de “Cadastrar novos pedidos”. Este ícone deve ser clicado para prosseguir.

2. Um formulário será exibido. Haverá um campo de preenchimento para cada uma das informações (nove no total) listada na descrição do caso de uso.

3. Todos os campos devem ser preenchidos e revisados pelo funcionário. 4. O funcionário clica em “concluir” para efetuar o cadastro. 5. O sistema deve exibir uma confirmação “O cadastro do pedido [ID do pedido] foi

efetuado com sucesso!”

Fluxo Secundário 1


41

1. No passo 3 do FP, o funcionário clica em “cancelar”, encerrando o processo de cadastro;

2. O sistema exibe uma mensagem de alerta “Aviso. Tem certeza que deseja cancelar o cadastro do pedido [ID do pedido]? Todas as informações serão apagadas do sistema.”

3. Dois botões serão exibidos: “Sim” e “Não”. O funcionário aperta o botão “Sim”

4. O sistema volta à tela inicial.

Fluxo Secundário 2

1. Após o passo 4 do FP, se o funcionário tiver esquecido de preencher algum campo do formulário, uma mensagem de erro será exibida: “Formulário incompleto. Revise os campos e então aperte em ‘concluir’. O cadastro do pedido [ID do pedido] não foi concluído”.

2. O sistema volta à tela que exibe o formulário (volte ao passo 2 do FP).

Fluxo Secundário 3

1. Após o passo 4 do FP, se o funcionário tiver preenchido algum campo do formulário com informações inválidas, uma mensagem de erro será exibida: “Formulário incorreto. Revise as informações dos campos e então aperte em ‘concluir’. O cadastro do pedido [ID do pedido] não foi concluído.” Informações inválidas são: letras nos campos de “telefone/celular”, “CPF/CNPJ” e “preço total”; “endereço de e-‐‑mail” sem o símbolo ‘@’ seguido pelo domínio; “prazo limite com data anterior à data atual”.

2. O sistema volta à tela que exibe o formulário (volte ao passo 2 do FP).


[UC03] Envio de solicitação de dinheiro


Descrição: Algum dos setores da empresa realiza uma solicitação de dinheiro ao setor financeiro. Uma notificação da solicitação é enviada ao setor financeiro da empresa.

Ator: Funcionário que realiza o pedido (pode ser de qualquer setor da empresa).

Prioridade: Essencial.


42

Pré-‐‑condições:

O funcionário que fará a solicitação deve estar logado no sistema.

Pós-‐‑condições:

O setor financeiro recebe uma notificação do pedido de dinheiro, juntamente com a identificação do funcionário e do setor que a realizou.


1. Estando logado no sistema, o funcionário clica na opção “solicitar capital”; 2. Uma nova tela aparece no sistema, contendo a identificação do usuário

(juntamente com o setor no qual ele trabalha). Essa identificação não é editável. Além desses dados, a tela também contém um campo que deve ser completado com o valor do pedido e a justificativa para o mesmo;

3. Caso seja necessário, o funcionário terá a opção para anexar um documento que justifique sua solicitação. Esta opção será exibida na mesma tela em que o valor do pedido e a justificativa para o mesmo são requisitados. Ao contrário desses dois últimos, o item em anexo não é obrigatório.

4. Após completar os dados, o funcionário clica em “enviar pedido”; 5. O sistema exibe um aviso informando que o pedido foi enviado com sucesso. 6. O sistema notifica o setor financeiro sobre a solicitação.

Fluxo Secundário 1

1. No passo 4 do FP, o funcionário clica em “cancelar”;

2. O sistema volta à tela inicial.

Fluxo Secundário 2

1. O funcionário completa o campo relativo ao valor do pedido num formato inadequado (número negativo ou caracteres não numéricos);

2. O sistema exibe uma janela de aviso contendo a frase “formato de valor inadequado”;

3. O sistema volta à tela de solicitação de dinheiro, com todas as informações iguais as que foram anteriormente fornecidas, exceto o campo de valor do pedido, que estará vazio.

Fluxo Secundário 3


43

1. O funcionário deixa o campo referente à justificativa do pedido em branco;

2. O sistema exibe uma janela de aviso contendo a frase “favor justificar o seu pedido”;

3. O sistema volta à tela de solicitação de dinheiro, com todas as informações iguais as que foram anteriormente fornecidas.


[UC04] Recebimento de solicitações ao setor de estoque


Descrição: Envio de uma solicitação previamente aprovada pelo sistema, que deve ser enviada ao setor do estoque requisitando que matéria-‐‑prima seja entregue ao setor de produção, ou que alguns produtos sejam enviados ao setor de transporte.

Ator: Funcionários do setor de produção ou do setor administrativo que realizam a solicitação, funcionário do setor de estoque que recebe a solicitação.

Prioridade: Essencial

Pré-‐‑condições: O funcionário do setor de estoque deve estar logado no sistema e a requisição deve ter sido autorizada pelo sistema.

Pós-‐‑condições: O setor de produção recebe a matéria-‐‑prima ou o setor de transporte recebe os produtos manufaturados para o envio.



44

1. Ao receber a solicitação, o sistema deve verificar se o setor do funcionário que realizou a solicitação está de acordo com a solicitação, ou seja, se a solicitação se originou do setor de produção, então a solicitação deve ser de matéria-‐‑prima, caso a solicitação tenha se originado do setor de administração, então o solicitação deve ser de produtos.

2. Ao estar logado no sistema, o funcionário do setor de estoque deve ser informado sobre a requisição por um alerta na tela. Essa tela deve ter as informações do pedido com os dados do funcionário que solicitou (nome e setor da empresa), quais produtos ou matérias-‐‑primas e suas quantidades respectivamente e ainda para qual setor esses materiais serão enviados.

3. O funcionário deve utilizar o sistema para verificar se os produtos ou matérias-‐‑primas estão disponíveis

4. O funcionário deve enviá-‐‑los ao setor correspondente.

Fluxo Secundário 1

1. No passo 1 o setor do funcionário não corresponde ao tipo de solicitação feita.

2. O sistema recusa a solicitação.

3. Os passos 2 e 3 não ocorrerão.

Fluxo Secundário 2

1. No passo 3, se os materiais não estiverem disponíveis o setor de administração deve ser alertado.

2. Ao receber o alerta a gerencia deve tomar providencias para repor os materiais e o setor que fez a solicitação deve avisado que haverá um atraso.

3. Quando os materiais foram repostos o passo 3 deve se repetir.


[UC05] Elaboração de planejamento financeiro futuro.


Descrição: O sistema deverá armazenar todos os gastos e as receitas financeiras durante o mês. Ao final de cada mês, o sistema deve criar um planejamento financeiro, indicando como foi o faturamento do mês passado (positivo ou negativo) e prevendo os gastos do mês seguinte.


45

Ator: Funcionários do setor administrativo.

Prioridade: Importante

Pré-‐‑condições: Não se aplica.

Pós-‐‑condições: Um relatório com faturamento do mês passado e possíveis gastos futuros deve estar disponível para os funcionários do setor administrativo


1. A cada solicitação referente a um valor financeiro, seja um gasto ou uma receita, o valor da solicitação e seu tipo devem ser registrados pelo sistema e guardados no banco de dados.

2. No último dia de cada mês, todos os registros financeiros feito no passo anterior devem ser analisados, calculando o faturamento mensal da empresa e os possíveis gastos no próximo mês e colocados em um relatório.

3. Esse relatório deve ser disponibilizado para o setor administrativo da empresa.

Fluxo Secundário 1

1. O setor administrativo não recebe o relatório

2. Um funcionário do setor administrativo deve requisitar o relatório ao sistema.

3. O relatório é disponibilizado ao setor administrativo.

Requisitos Não Funcionais Específicos Nenhum

Anexo F – Glossário

• Banco de dados MySQL: O programa 'ʹMySQL'ʹ é um sistema de gerenciamento de banco de dados relacionais baseado em comandos SQL (Structured Query Language -‐‑ Linguagem Estruturada para Pesquisas) que vem ganhando grande popularidade, sendo atualmente um dos bancos de dados mais populares, com mais de 4 milhões de instalações.

• Notação i*: Abordagem criada por John Mylopoulos e EricYu, na Universidade de Toronto para descrição de requisitos organizacionais.

• NFR: Do inglês “Non-‐‑functional Framework Requirements”, NFR é um framework para abordagem de modelagem orientada a objetivos. Esta análise é composta pelos softgoals em que os stakeholders entraram em acordo. Esses softgoals podem ser decompostos em outros e que por fim devem ser operacionalizados. A estrutura da modelagem se assemelha a um grafo.

• Backup: atividade de armazenar dados redundantes para fornecer segurança. Assim, caso algum problema ocorra no sistema de armazenamento e os dados sejam corrompidos, uma


46

cópia desses dadas pode ser recuperada.

• Java: é uma linguagem de programação orientada a objeto desenvolvida na década de 90 por uma equipe de programadores chefiada por James Gosling, na empresa Sun Microsystems. Diferentemente das linguagens convencionais, que são compiladas para código nativo, a linguagem Java é compilada para um bytecode que é executado por uma máquina virtual.

• BPMN: Business Process Modeling Notation (BPMN) (em português Notação de Modelagem de Processos de Negócio) é uma notação da metodologia degerenciamento de processos de negócio e trata-‐‑se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário.

• Login: Trata-‐‑se de uma seqüência de caracteres utilizada para identificar um usuário de forma única.

• Log on: Termo utilizado para demonstrar a ação de um usuário quando entra no sistema dom login e senha.

• Log off: Termo utilizado para demonstrar a ação de um usuário quando este sai do sistema.

Documents

CORRIGIDO-FlaviaFelipeRenatoIsmar-Documento de …if716/projetos/2012_3/Projeto2/Equipe07... · 2013. 7. 30. · Tabela)de)Histórico)de)Revisões:)) Revisão)Data) Descrição) Autor)