F ederal d e P ernambuco Centro d e I nformática - C Inif716/projetos/2017-2/Equipe4_2.pdf · Caso...

Universidade Federal de Pernambuco

Centro de Informática - CIn

Sistema de vendas para a loja Imbiribeira Autopeças e Serviços Ltda.

_____________________________________________

Documento de Requisitos

Equipe: Ivan Felipe

Messielly Souza Ricardo Malafaia

Professor:

Jaelson Freire Brelaz de Castro

Recife, Pernambuco Novembro de 2017

Índice

1. Introdução 1.1. Sobre a organização 1.2. Identificação do problema 1.3. Atores

2. Convenção aplicadas no trabalho 2.1. Convenção para identificação dos requisitos 2.2. Convenções para identificação dos casos de uso

3. Requisitos organizacionais 3.1. Requisitos funcionais 3.2. Requisitos não funcionais

4. Modelagens 4.1. Casos de uso 4.2. NFR Framework 4.3. Statechart

5. Conclusão 6. Relatório da equipe

Referências Glossário Apêndice A Apêndice B - Imagens completas das modelagens Apêndice C - Artefatos coletados

2 2 2 2 3 3 3 3 3 7 10 10 11 12 13 14 15 16 17 25 29

1

1. Introdução Este é o projeto final da disciplina de Especificação de Requisitos e Validação

de Sistemas ministrada pelo professor Jaelson Castro com o objetivo de apresentar documentação sobre a solução encontrada durante todo o estudo de viabilidade juntos aos atores relacionados a um problema real de uma corporação.

Para essa solução, temos como foco um sistema de gestão financeira e de estoque de uma loja de autopeças. Um dos grandes problemas que foi observado pela equipe na loja é a questão de controle que é feito atualmente de forma manual todos os dias, podendo causar falha humana em alguns momentos de maior complexidade, sem contar a falta de visibilidade nas questões financeiras do mesmo local.

Para resolver este problema, oferecemos um sistema que possibilita gerenciar o estoque, questões financeiras, avisos, cadastro de novos clientes e seus cartões de créditos, gerar relatórios de toda a loja e outros artifícios que facilitem o trabalho do gestor em conduzir suas finanças. Tal documento descreve os artefatos de especificação do sistema, bem como a modelagem dos processos que representam o comportamento do mesmo.

1.1 Sobre a organização A loja Imbiribeira Autopeças e Serviços, criada em 1999, e comandada por

Jorge Reynaux, é localizada na Avenida Marechal Mascarenhas de Moraes, 2284, na Imbiribeira.

A organização possui uma estrutura de vendas de peças automotivas, como também de oficina de carros visando prevenção, manutenção e reparo de modelos a diesel 4x4, das marcas Toyota (Bandeirante, Hilux), Nissan (Frontier), Mitsubishi (Triton, L-200, Pajero).

1.2 Identificação do problema No cenário atual, foi possível observar que no processo de vendas, os

clientes se sentem incomodados com a demora ou até mesmo a verificação incorreta dos materiais que estão disponíveis no estoque para poder realizar o seu pedido, gerando transtornos e aborrecimentos na sua compra e causando uma má impressão da organização.

Atualmente, a ferramenta utilizada para controle de peças da Imbiribeira Autopeças é o Excel, que é atualizada diariamente pela colaboradora Fabiana, não possuindo um sistema que informe falta de materiais. Outro diagnóstico observado, é o tempo levado para a chegada de novos recursos, pois ao ser detectado a falta de recursos, a colaboradora aciona e envia ao dono Jorge Reynaux, por meio de uma planilha excel, a lista dos materiais em falta. O dono é responsável por entrar em contato com os fornecedores, fazer a pesquisa de preços, negociar e finalizar a compra. Não existindo assim um sistema de apoio à decisão para facilitar esse processo.

1.3 Atores Designa-se atores, os usuários e/ou outros dispositivos que tenham um

correlação com o sistema desenvolvendo um papel relacional para seu funcionamento.

2

Atores Representação Função

Gestor Ator que representa a diretoria

Atribuir restrições de acesso ao sistema

Cliente Ator responsável pela compra

Enviar pedido para loja

2. Convenções aplicadas no trabalho

2.1 Convenção para identificação dos requisitos Está estabelecido como padrão de registro, os códigos dos requisitos com o

formato [RFxxx] para requisitos funcionais, e [RNFxxx] para requisitos não funcionais, onde xxx se refere a numeração sequencial dos requisitos registrados neste documento. Os mesmos também possuem uma descrição detalhada e uma relação com casos de uso.

2.2 Convenções para identificação dos casos de uso Por convenção, os casos de uso possuem o código no formato [UCxxx], onde

xxx se refere a numeração sequencial dos requisitos registrados neste documento. Os mesmos também possuem uma descrição e uma relação com requisitos funcionais. 3. Requisitos organizacionais Os requisitos funcionais serão classificados em prioridade como:

Essencial - Requisitos os quais possuem mais alta prioridade e que são indispensáveis para o funcionamento do sistema. Este tipo de requisito deve ser implementado no sistema, caso contrário o sistema não atingirá seu objetivo final.

Importante - Requisitos os quais fazem parte do objetivo do sistema, mas sua falta não impossibilita o funcionamento do sistema.

Desejável - Requisitos os quais não influenciam nas funcionalidades básica do sistema. São requisitos que provavelmente serão implementados em outras versões do sistema.

3.1. Requisitos funcionais

Requisitos funcionais descrevem as funcionalidades que o sistema deve ter. No sistema de gestão do Imbiribeira Auto-Peças Ltda., identificamos até o momento os seguintes requisitos:

3.1.1. [RF01] Efetuar login no sistema

3

Descrição Permite que o usuário tenha acesso às funcionalidades do sistema. Para isso, o usuário deve informar login e senha. Não

deve haver outra maneira de entrar no sistema

Caso de uso relacionado

[UC01]

Prioridade Essencial

3.1.2. [RF02] Efetuar logoff no sistema

Descrição Permite que o usuário realize o logoff do sistema


[UC02]


3.1.3. [RF03] Buscar peças no sistema

Descrição O sistema deverá possuir uma interface simples e intuitiva para encontrar as peças que o cliente precisar.


[UC03]

Prioridade Importante

3.1.4. [RF04] Aprovação de compras

Descrição O sistema deverá permitir que o responsável por administrar o site possa verificar cada solicitação de compra recebida e

processada.


[UC04]


3.1.5. [RF05] Gerar relatórios Financeiros

Descrição O sistema deverá ser capaz de gerar relatórios sobre todas as vendas e devoluções ocorridas.


[UC05]

4

Prioridade Desejável

3.1.6. [RF06] Gerar relatórios de Estoque

Descrição O sistema deverá ser capaz de gerar relatórios sobre todos os itens de seu estoque.


[UC06]


3.1.7. [RF07] Cadastro de Informações

Descrição O sistema deverá permitir que o administrador do sistema registre informações de estoque, e informações de acesso

(credenciais para empregados, endereço da loja).


[UC07]


3.1.8. [RF08] Edição de informações

Descrição O sistema deverá permitir que o administrador do site edite suas informações e as informações de usuários, de acordo com a

permissão de cada um.


[UC08]


3.1.9. [RF09] Visualização de informações

Descrição O sistema deverá permitir que os usuários visualizem informações (nomes, descrições, valores e fotos) sobre os

produtos disponíveis ou não.


[UC09]


5

3.1.10. [RF10] Notificar o cliente da disponibilidade de retirada

Descrição O sistema deverá enviar um aviso, via e-mail ou sms, para o cliente quando o produto estiver disponível para ser retirado na

loja.


[UC10]


3.1.11. [RF11] Cadastro de cliente

Descrição O sistema deverá permitir que o cliente, quando acessar, seja capaz de cadastrar suas próprias credenciais e informações

para utilizá-lo..


[UC11]


3.1.12. [RF12] Cadastro de Cartão de Crédito

Descrição O sistema deverá ser capaz de cadastrar cartões de crédito dos clientes com validação.


[UC12]


3.1.13. [RF13] Criar Avisos

Descrição O sistema deverá apresentar uma notificação quando necessário.


[UC13]


3.1.14. [RF14] Realizar compras

Descrição O sistema deverá permitir que o cliente faça uma compra.

6

Caso de uso relacionado [UC14]


3.2. Requisitos não funcionais

Requisitos não funcionais descrevem as qualidades e características de sistemas que são importantes tanto para os usuários como para os desenvolvedores. No sistema de gestão de conhecimento da Imbiribeira Auto-Peças Ltda. , é possível destacar os requisitos não funcionais abaixo:

3.2.1. [RNF01] Integridade dos dados

Descrição Os dados do sistema devem estar corretos.


3.2.2. [RNF02] Usabilidade

Descrição O sistema deve ser simples de usar. Com uma interface amigável e intuitiva.


3.2.3. [RNF03] Disponibilidade

Descrição O sistema deve estar disponível sempre que o usuário necessitar.


3.2.4. [RNF04] Segurança dos dados

Descrição Os dados do sistema devem trafegar pela rede e serem armazenados de forma segura, com a encriptação necessária.


3.2.5. [RNF05] Confidencialidade

Descrição Os dados do sistema devem ser confidenciais, portanto podendo ser acessados apenas por pessoas que possuam as

permissões necessárias.


7

3.2.6. [RNF06] Backup

Descrição O sistema deve realizar o backup dos dados mensalmente.


3.2.7. [RNF07] Compatibilidade

Descrição O sistema deverá executar perfeitamente nos navegadores Chrome, Mozilla, Internet Explorer e Safari.


3.2.8. [RNF08] Processar compras

Descrição O sistema deve processar o estado de todas as compras que estão sendo processadas, do início ao fim.


3.2.9. [RNF09] Credenciais do Administrador

Descrição A senha do administrador deve ter complexidade alta.


3.2.10. [RNF10] Feedback

Descrição O sistema deve alertar o usuário utilizando mensagens de confirmação ou de erro


3.2.12. [RNF11] Linguagem simples e clara

Descrição Disposição das informações triviais dos textos e objetividade do conteúdo de forma a facilitar o acesso ao fluxo das telas do

sistema.


3.2.13. [RNF12] Eficiência

8

Descrição Desempenho do sistema, restrições de performance, tempo de resposta em processamentos específicos, cargas, velocidade de

resposta de processamentos em telas.


3.2.13. [RNF13] Alta capacidade de armazenamento de dados

Descrição O sistema deve ser capaz de armazenar uma grande quantidade de dados.


3.2.15. [RNF14] Plataforma WEB

Descrição O sistema deverá executar sobre plataforma WEB.


3.2.16. [RNF15] Tempo de Desenvolvimento

Descrição O tempo de desenvolvimento (primeira versão) deve ser inferior a seis meses (tempo de um semestre).


9

4. Modelagens

4.1. Casos de uso

A modelagem dos requisitos funcionais através do diagrama de casos de uso é apresentada abaixo. A descrição detalhada dos casos de uso se encontra no apêndice A.

Figura 1 - Diagrama de casos de uso

10

4.2. NFR Framework Parte da modelagem dos requisitos não funcionais através da NFR

Framework. Os NFR’s do sistema se subdividiram em duas características principais: Os requisitos de segurança e os requisitos estruturais da aplicação.

Na imagem a seguir, um detalhamento dos NFR’s relacionados a segurança:

Figura 2 - NFR - segurança

11

Na imagem a seguir, detalhamento dos requisitos não funcionais na parte de infraestrutura do ambiente em que a aplicação irá ficar, neste caso, o ambiente WEB:

Figura 3 - NFR - Infraestrutura

12

Abaixo a modelação completa relacionando as duas subdivisões do modelo NFR

Figura 4 - Parte da modelagem NFR Framework completo

13

4.3. Statechart

Esta modelagem foi realizada em Statechart, descrevendo detalhadamente como o sistema deve operar quando realizada as atividades presentes nos casos de uso descritos anteriormente.

Na modelagem são descritos três tipos de usuários com suas respectivas ações, Usuario, Administrador e Cliente. As imagens de todos os sub-diagramas encontram-se no apêndice B.

Figura 5 - Statechart: Tela principal administrador

Figura 6 - Statechart: Tela principal cliente

14

5. Conclusão

O desenvolvimento desse projeto permitiu praticar o que foi absorvido em toda a convivência com o discente na disciplina de Especificação de Requisitos e Validação de Sistemas ministrada pelo professor Jaelson Castro.

Baseado nas entrevistas com membros da empresa Imbiribeira Auto Peças Ltda., fizemos um estudo aprofundado sobre as suas reais necessidades descrevendo neste documento um projeto conciso e estruturado, visando facilitar e garantir a gestão do conhecimento.

Foram realizados trabalhos de especificação de requisitos, casos de uso, análise e estudo de comportamentos, e modelagem de dados utilizando as ferramentas Statechart e NFR Framework que objetivam a estruturação e qualidade do sistema. Com as análises realizadas, oferecemos uma solução com os cenários focados em perspectivas estratégicas de forma a integrar o maior número de dados em um único sistema que garante rastreabilidade.

A solução apresentada reflete outra forma de armazenamento das informações concretizando com eficiência a gestão do conhecimento e apoio à decisão. Tendo em vista a necessidade de uma implementação concisa, criamos modelagens de um sistema que oferece auxílio significativos para as práticas diárias, bem como o registro de dados das gestões passadas e futuras.

15

6. Relatório da equipe

Nome Papel Esforço Assinatura

Ivan Felipe Diagrama de casos de uso + Statechart + Relatório

33%

Messielly Souza Statechart + Relatório + Revisão

33%

Ricardo Malafaia Diagrama de RFN + Relatório

33%

16

Referências [1] Requisitos funcionais, disponível em: <http://www.ateomomento.com.br/o-que-e-requisito-funcional/> [2] Especificação de Requisitos e Validação de Sistemas, disponível em: <http://www.cin.ufpe.br/~if716/index.php> [4] Ian Sommerville. Engenharia de Software. 6ª Edição, Makron Books, 2003 [5] Java EE, disponível em : <http://www.oracle.com/technetwork/java/javaee/overview/index.html> [6] O que é Java EE, disponível em: <https://www.caelum.com.br/apostila-java-web/o-que-e-java-ee/#3-1-como-o-java-ee-pode-te-ajudar-a-enfrentar-problemas>

17

http://www.ateomomento.com.br/o-que-e-requisito-funcional/

http://www.cin.ufpe.br/~if716/index.php

http://www.oracle.com/technetwork/java/javaee/overview/index.html

https://www.caelum.com.br/apostila-java-web/o-que-e-java-ee/#3-1-como-o-java-ee-pode-te-ajudar-a-enfrentar-problemas

https://www.caelum.com.br/apostila-java-web/o-que-e-java-ee/#3-1-como-o-java-ee-pode-te-ajudar-a-enfrentar-problemas

Glossário Login - inserir credenciais dentro do sistema. Logoff - sair do sistema. Backup - cópia de segurança dos dados do sistema. Java EE - o Java EE (Java Enterprise Edition) consiste de uma série de especificações bem detalhadas, dando uma receita de como deve ser implementado um software que faz cada um desses serviços de infraestrutura. Bug - é um erro no funcionamento comum de um software.

18

Apêndice A - Descrição dos casos de uso UC01 Efetuar Login no Sistema

Descrição Permite que o usuário tenha acesso às funcionalidades do sistema. Para isso, o usuário deve informar login e senha. Não deve haver outra maneira de entrar no sistema

Atores Usuário


Pré-condições Estar cadastrado no sistema

Pós-condições Ter acesso ao sistema

Fluxo de eventos principais 1. O usuário preenche os campos de login e senha 2. O usuário clica no botão de entrar 3. O sistema valida senha e login

Fluxo de eventos secundários 1. No passo 1, caso o usuário erre seu login ou senha, não conseguirá ter acesso ao sistema e deverá tentar novamente.

UC02 Efetuar Logout no Sistema

Descrição Permite que o usuário realize o logoff do sistema

Atores Usuário


Pré-condições O usuário deve estar logado no sistema

Pós-condições O usuário não tem mais acesso ao sistema

Fluxo de eventos principais 1. O usuário clica no botão sair 2. O usuário encerra a sessão no sistema

Fluxo de eventos secundários Se no passo 1, o usuário estiver no

19

meio de uma ação, sistema deve confirmar se o mesmo quer realmente sair do sistema.

UC03 Buscar peças no sistema

Descrição O sistema deverá possuir uma interface simples e intuitiva para encontrar as peças que o cliente precisar.

Atores Usuário



Pós-condições

Fluxo de eventos principais 1. O usuário clica no campo de digitação 2. O usuário digita o item desejado 2. O sistema apresenta a informação desejada.

Fluxo de eventos secundários Se no passo 2, o usuário informar um item que não se encontre na base de dados, o sistema deve informar que não existe o item procurado.

UC04 Aprovação de compras

Descrição O sistema deverá permitir que o responsável por administrar o site possa verificar cada solicitação de compra recebida e processada.

Atores Administrador



Pós-condições A compra se encontrará aprovada ou não.

Fluxo de eventos principais 1. O usuário clica em aprovar compras 2. O usuário visualiza a lista de pedidos

20

de aprovação 3. O administrador clica em aprovar 4. O pedido vai se encontrará aprovado

Fluxo de eventos secundários Se no passo 3, o usuário recusar o pedido, o fluxo é terminado e a compra é negada.

UC05 Gerar relatórios Financeiros

Descrição O sistema deverá ser capaz de gerar relatórios sobre todas as vendas e devoluções ocorridas.




Pós-condições Visualizar informações Financeiras

Fluxo de eventos principais 1. O usuário clica na opção detalhamento do gráfico financeiro desejado 2. O usuário visualiza todas as informações desejadas

Fluxo de eventos secundários Se no passo 1, o gráfico se encontra sem valores e métricas, o relatório não vai poder ser gerado.

UC06 Gerar relatórios de Estoque

Descrição O sistema deverá ser capaz de gerar relatórios sobre todos os itens de seu estoque.




Pós-condições Visualizar informações Financeiras

Fluxo de eventos principais 1. O usuário clica na opção

21

detalhamento do gráfico de estoque desejado 2. O usuário visualiza todas as informações desejadas

Fluxo de eventos secundários Se no passo 1, o gráfico se encontra sem valores e métricas o relatório não vai poder ser gerado.

UC07 Cadastro de Informações

Descrição O sistema deverá permitir que o administrador do sistema registre informações de estoque, e informações de acesso (credenciais para empregados, endereço da loja).




Pós-condições A informação visível na sua base de dados

Fluxo de eventos principais 1. O usuário clica no botão de editar informações 2. Clica no botão adicionar informações do estoque 3. O usuário digita o item desejado 4. E o usuário cadastra o item novo.

Fluxo de eventos secundários Se no passo 3, o usuário informar um item que se encontre na base de dados, o sistema deve dá opção de editar os informações já presentes.

UC08 Edição de informações

Descrição O sistema deverá permitir que o administrador do site edite suas informações e as informações de usuários, de acordo com a permissão de cada um.

22




Pós-condições A informação visível da base de dados e alterada

Fluxo de eventos principais 1. O usuário clica no botão de editar informações 2. Clica no botão adicionar informações do estoque 3. O usuário digita o item desejado já presente na base de dados 4. E o usuário edita as informações do item.

Fluxo de eventos secundários

UC09 Visualização de informações

Descrição O sistema deverá permitir que os usuários visualizem informações (nomes, descrições, valores e fotos) sobre os produtos disponíveis ou não.

Atores Usuário


Pré-condições

Pós-condições A visualização das informações do estoque

Fluxo de eventos principais 1. O usuário abre o site da loja 2. O usuário visualiza informações de todas as peças disponíveis.


UC10 Notificar o cliente da disponibilidade

de retirada

Descrição O sistema deverá enviar, via e-mail ou

23

sms, para o cliente quando o produto estiver disponível para ser retirado na loja.

Atores Cliente


Pré-condições O cliente deve estar cadastrado no sistema

Pós-condições

Fluxo de eventos principais 1. O cliente realiza uma solicitação de compra 2. A compra foi aprovada 2. Cliente recebe um SMS ou E-mail informando que pode retirar a peça na loja.

Fluxo de eventos secundários Se no passo 2, a compra não for aprovada ele irá receber um SMS ou E-mail informando da reprovação do seu pedido.

UC011 Cadastro de Cliente

Descrição O sistema deverá permitir que o cliente, quando acessar, seja capaz de cadastrar suas próprias credenciais e informações para utilizá-lo sistema.

Atores Cliente


Pré-condições O usuário deve acessar o site da loja

Pós-condições

Fluxo de eventos principais 1. O usuário clica no botão de se cadastrar 2. O usuário digitar todas as informações necessárias 2. O sistema apresenta um confirmação do cadastro.

Fluxo de eventos secundários Se no passo 2, o usuário informar

24

dados repetidos o sistema não vai permitir finalizar.

UC12 Cadastro de Cartão de Crédito

Descrição O sistema deverá ser capaz de cadastrar cartões de crédito dos clientes com validação.

Atores Cliente



Pós-condições O cartão vai ser aprovado ou não.

Fluxo de eventos principais 1. O Cliente clica no botão editar informações 2. O Cliente clica no botão adicionar cartão de crédito 3. Digita as informações do cartão 4. O cartão é liberado.

Fluxo de eventos secundários Se no passo 3, o cliente informar algum dado errado o sistema não deve permitir.

UC13 Criar avisos

Descrição O sistema deverá apresentar uma notificação quando necessário.

Atores Usuário


Pré-condições

Pós-condições

Fluxo de eventos principais 1. O usuário recebe notificações do sistema


25

UC14 Realizar Compras

Descrição O sistema deverá permitir que o cliente faça uma compra.

Atores Cliente



Pós-condições Notificação que a solicitação foi encaminhada com sucesso

Fluxo de eventos principais 1. O cliente clica no item 2. O cliente finaliza a compra


26

Apêndice B - Imagens completas das modelagens

Figura 7 - Statechart: Tela principal Produtos (Cliente)

Figura 8 - Statechart: Tela principal Pagamento (Cliente)

27

Figura 9 - Statechart: Tela Produtos (Administrador)

Figura 10 - Statechart: Tela Compras (Administrador)

28

Figura 11 - Statechart: Tela Relatório Financeiro (Administrador)

Figura 12 - Statechart: Tela Relatório Estoque(Administrador)

29

Figura 13 - Statechart: Tela Detalhes Cliente (Administrador)

30

Apêndice C - Artefatos coletados

Figura 14 - Tela Login

31

Figura 15 - Tela Relatório Financeiro

Figura 16 - Tela Relatório Estoque

32

Figura 17 - Tela Detalhes Relatório Estoque

Figura 18 - Tela Detalhes Relatório Financeiro

33

F ederal d e P ernambuco Centro d e I nformática - C Inif716/projetos/2017-2/Equipe4_2.pdf · Caso...

Documents

Transcript of F ederal d e P ernambuco Centro d e I nformática - C Inif716/projetos/2017-2/Equipe4_2.pdf · Caso...