Post on 12-Mar-2021
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
fsos, fpc, ipbn, rfp3 23/11/2012
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
fsos, fpc, ipbn, rfp3 23/11/2012
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 5 Diagrama de atividade: UC02 .......................................................................................... 333
Figura 6 Diagrama de atividade: UC03 ............................................................................................ 33
Figura 7 Diagrama de atividade: UC04 .......................................................................................... 335
Figura 8 Diagrama de atividade: UC05 .......................................................................................... 336
Figura 9 Diagrama de sequencia: UC01 ......................................................................................... 337
Figura 10 Diagrama de sequencia: UC02 ....................................................................................... 338
Figura 11 Diagrama de sequencia: UC03 ....................................................................................... 338
Figura 12 Diagrama de sequencia: UC04 ....................................................................................... 339
Figura 13 Diagrama de sequencia: UC05 ....................................................................................... 339
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.
fsos, fpc, ipbn, rfp3 23/11/2012
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.
fsos, fpc, ipbn, rfp3 23/11/2012
7
1.3 Modelo BPMN do processo atual
O modelo BPMN que retrata as atividades da empresa no cenário atual é apresentado logo abaixo.
fsos, fpc, ipbn, rfp3 23/11/2012
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.
fsos, fpc, ipbn, rfp3 23/11/2012
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
fsos, fpc, ipbn, rfp3 23/11/2012
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”.
Prioridade: Essencial Importante Desejável
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.
Prioridade: Essencial Importante Desejável
3.1.4 [RF04] Mudar senha
Identificação: [RF04] Mudar Senha
Casos de Uso relacionados: Nenhum
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.
Prioridade: Essencial Importante Desejável
3.1.5 [RF05] Receber senha
Identificação: [RF05] Receber senha
fsos, fpc, ipbn, rfp3 23/11/2012
11
Casos de Uso relacionados: Nenhum
Descrição: Solicitando a opção “Receber senha” a senha atual do usuário será encaminhado para o e-‐‑mail cadastrado.
Prioridade: Essencial Importante Desejável
3.2 Administração
3.2.1 [RF06] Cadastrar pedido
Identificação: [RF06] Cadastrar pedido
Casos de Uso relacionados: [UC02]
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
Prioridade: Essencial Importante Desejável
3.2.2 [RF07] Excluir pedido
Identificação: [RF07] Excluir pedido
Casos de Uso relacionados: [UC02]
Descrição: O setor administrativo deve ser capaz de excluir o pedido de um cliente no sistema.
fsos, fpc, ipbn, rfp3 23/11/2012
12
Prioridade: Essencial Importante Desejável
3.2.3 [RF08] Acessar andamento dos pedidos
Identificação: [RF08] Acessar andamento dos pedidos
Casos de Uso relacionados: Nenhum
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.
Prioridade: Essencial Importante Desejável
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.
Prioridade: Essencial Importante Desejável
3.3.2 [RF10] Fornecer respostas
Identificação: [RF10] Fornecer respostas
Casos de Uso relacionados: [UC03]
Descrição: O sistema deve apenas aprovar ou reprovar uma solicitação.
Prioridade: Essencial Importante Desejável
fsos, fpc, ipbn, rfp3 23/11/2012
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
Casos de Uso relacionados: [UC03][UC04]
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.
Prioridade: Essencial Importante Desejável
Identificação: [RF12] Reprovar solicitação
Casos de Uso relacionados: [UC03]
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.
Prioridade: Essencial Importante Desejável
Identificação: [RF13] Fazer planejamento financeiro
Casos de Uso relacionados: [UC05]
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.
Prioridade: Essencial Importante Desejável
fsos, fpc, ipbn, rfp3 23/11/2012
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
Casos de Uso relacionados: [UC05]
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.
Prioridade: Essencial Importante Desejável
Identificação: [RF15] Enviar solicitações ao setor de estoque
Casos de Uso relacionados: [UC04]
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.
Prioridade: Essencial Importante Desejável
Identificação: [RF16] Notificar setor financeiro
Casos de Uso relacionados: [UC03]
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.
Prioridade: Essencial Importante Desejável
fsos, fpc, ipbn, rfp3 23/11/2012
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
Casos de Uso relacionados: [UC04]
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.
Prioridade: Essencial Importante Desejável
Identificação: [RF18] Enviar solicitação de produção de picolé
Casos de Uso relacionados: Nenhum
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.
Prioridade: Essencial Importante Desejável
fsos, fpc, ipbn, rfp3 23/11/2012
16
linguagem bastante eficiente e portável.
Prioridade: Essencial Importante Desejável
4.1.2 [RNF02] Utilizar Banco de Dados MySQL
Identificação: [RNF02] Utilizar Banco de Dados MySQL
Casos de Uso relacionados: Todos
Descrição: O sistema deverá utilizar banco de dados MySQL porque ela oferece os recursos necessário e é economicamente viável.
Prioridade: Essencial Importante Desejá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.
Prioridade: Essencial Importante Desejável
4.2 Requisitos de Produto
4.2.1 [RNF04] Usabilidade
Identificação: [RNF04] Usabilidade
Casos de Uso relacionados: Todos
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.
Prioridade: Essencial Importante Desejável
fsos, fpc, ipbn, rfp3 23/11/2012
17
4.2.2 [RNF05] Disponibilidade
Identificação: [RNF05] Disponibilidade
Casos de Uso relacionados: Todos
Descrição: O sistema deve estar disponível e em funcionamento 24h por dia e 7 dias por semana.
Prioridade: Essencial Importante Desejável
4.2.3 [RNF06] Tempo de resposta
Identificação: [RNF06] Tempo de resposta
Casos de Uso relacionados: Todos
Descrição: Nenhuma das consultas feitas ao sistema deverá ultrapassar 5 segundos.
Prioridade: Essencial Importante Desejável
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.
Prioridade: Essencial Importante Desejável
4.2.5 [RNF08] Robustez
Identificação: [RNF08] Robustez
Casos de Uso relacionados: Todos
Descrição: O sistema deve ser robusto, rejeitando a entrada de dados inválidos.
Prioridade: Essencial Importante Desejável
fsos, fpc, ipbn, rfp3 23/11/2012
18
4.2.6 [RNF09] Consistência
Identificação: [RNF09] Consistência
Casos de Uso relacionados: Todos
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.
Prioridade: Essencial Importante Desejável
4.2.7 [RNF10] Tolerância a falhas
Identificação: [RNF10] Tolerância a falhas
Casos de Uso relacionados: Todos
Descrição: O sistema necessita ser tolerante a falhas, em que deverá gerenciar as falhas ocorridas nas operações.
Prioridade: Essencial Importante Desejável
4.2.8 [RNF11] Segurança
Identificação: [RNF11] Segurança
Casos de Uso relacionados: [UC01]
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.
Prioridade: Essencial Importante Desejável
4.2.9 [RNF12] Backup
Identificação: [RNF12] Backup
Casos de Uso relacionados:
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.
fsos, fpc, ipbn, rfp3 23/11/2012
19
Prioridade: Essencial Importante Desejável
4.2.10 [RNF13] Mensagens de erro
Identificação: [RNF13] Mensagens de erro
Casos de Uso relacionados: Todos
Descrição: As mensagens de erro fornecidas pelo sistema deverão ser objetivas, fornecendo ao usuário informações para solucionar o problema.
Prioridade: Essencial Importante Desejável
4.2.11 [RNF14] Restrição no acesso
Identificação: [RNF14] Restrição no acesso
Casos de Uso relacionados: Todos
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.
Prioridade: Essencial Importante Desejável
4.2.12 [RNF15] Privacidade
Identificação: [RNF15] Privacidade
Casos de Uso relacionados: Todos
Descrição: Garantir privacidade. Os dados armazenados só poderão ser acessíveis por máquinas localizadas dentro da empresa.
Prioridade: Essencial Importante Desejável
fsos, fpc, ipbn, rfp3 23/11/2012
20
4.2.13 [RNF16] Padronização
Identificação: [RNF16] Padronização
Casos de Uso relacionados: [UC03][UC04]
Descrição: As requisições só podem ser feitas a partir de formulários padronizados.
Prioridade: Essencial Importante Desejável
4.3 Requisitos Externos
4.3.1 [RNF17] Tempo de desenvolvimento
Identificação: [RNF17] Tempo de desenvolvimento
Casos de Uso relacionados:
Descrição: O tempo com o desenvolvimento do sistema não poderá ultrapassar mais de 20% do previsto no Estudo de Viabilidade.
Prioridade: Essencial Importante Desejável
4.3.2 [RNF18] Orçamento
Identificação: [RNF18] Orçamento
Casos de Uso relacionados:
Descrição: O custo total de desenvolvimento do sistema, não poderá ser maior do que o custo estimado com o estudo de viabilidade.
Prioridade: Essencial Importante Desejável
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.
fsos, fpc, ipbn, rfp3 23/11/2012
21
5.2 Modelo Estratégico da Razão
Figura 1 Modelagem de Dependência Estratégica.
fsos, fpc, ipbn, rfp3 23/11/2012
22
Figura 2 Modelo estratégico da razão com ator Sistema expandido.
fsos, fpc, ipbn, rfp3 23/11/2012
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:
fsos, fpc, ipbn, rfp3 23/11/2012
24
7.1 Diagrama de Atividades:
[UC01]:
Figura 4 Diagrama de atividade: UC01
fsos, fpc, ipbn, rfp3 23/11/2012
25
[UC02]:
Figura 5 Diagrama de atividade: UC02
fsos, fpc, ipbn, rfp3 23/11/2012
26
[UC03]:
Figura 6 Diagrama de atividade: UC03
fsos, fpc, ipbn, rfp3 23/11/2012
27
[UC04]:
Figura 7 Diagrama de atividade: UC04
fsos, fpc, ipbn, rfp3 23/11/2012
28
[UC05]:
Figura 8 Diagrama de atividade: UC05
fsos, fpc, ipbn, rfp3 23/11/2012
29
7.2 Diagrama de Sequência:
[UC01]:
Figura 9 Diagrama de sequencia: UC01
fsos, fpc, ipbn, rfp3 23/11/2012
30
[UC02]:
Figura 10 Diagrama de sequencia: UC02
[UC03]:
Figura 11 Diagrama de sequencia: UC03
fsos, fpc, ipbn, rfp3 23/11/2012
31
[UC04]:
Figura 12 Diagrama de sequencia: UC04
[UC05]:
Figura 13 Diagrama de sequencia: UC05
fsos, fpc, ipbn, rfp3 23/11/2012
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.
fsos, fpc, ipbn, rfp3 23/11/2012
33
Figura 14 Modelagem de Requisitos Não Funcionais
fsos, fpc, ipbn, rfp3 23/11/2012
34
Abaixo temos a imagem 5 dividida em duas novas figuras (Figura 6 e Figura 7) para melhor visualização.
Figura 15 Modelagem de Requisitos Não Funcionais
fsos, fpc, ipbn, rfp3 23/11/2012
35
Figura 16 Modelagem de Requisitos Não Funcionais
fsos, fpc, ipbn, rfp3 23/11/2012
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.
fsos, fpc, ipbn, rfp3 23/11/2012
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?
fsos, fpc, ipbn, rfp3 23/11/2012
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
fsos, fpc, ipbn, rfp3 23/11/2012
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
Identificador: [UC02]
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
fsos, fpc, ipbn, rfp3 23/11/2012
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.
Fluxo de Eventos Principal
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
fsos, fpc, ipbn, rfp3 23/11/2012
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).
Requisitos Não Funcionais Específicos [RNF08], [RNF09]
[UC03] Envio de solicitação de dinheiro
Identificador: [UC03]
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.
fsos, fpc, ipbn, rfp3 23/11/2012
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.
Fluxo de Eventos Principal
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
fsos, fpc, ipbn, rfp3 23/11/2012
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.
Requisitos Não Funcionais Específicos [RNF08], [RNF09]
[UC04] Recebimento de solicitações ao setor de estoque
Identificador: [UC04]
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.
Fluxo de Eventos Principal
fsos, fpc, ipbn, rfp3 23/11/2012
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.
Requisitos Não Funcionais Específicos [RNF08], [RNF09]
[UC05] Elaboração de planejamento financeiro futuro.
Identificador: [UC05]
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.
fsos, fpc, ipbn, rfp3 23/11/2012
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
Fluxo de Eventos Principal
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
fsos, fpc, ipbn, rfp3 23/11/2012
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.