UNIFEI - Documento de Requisitos (v1 0 0)_ENG DE_SOFTWARE_PCO_204_final

Prévia do material em texto

<BARBERSHOP LUIZ HENRIQUE> 
 
 
 
Documento de Requisitos 
Versão 1.0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
RESPONSÁVEL: ITAMAR JOSÉ COELHO 
 
 
 
 
 
Histórico de Revisões 
Data Versão Descrição Autor 
03/06/2022 0.1 Versão inicial do documento Itamar 
05/06/2022 0.2 Revisão do documento Itamar 
10/06/2022 1.0 Inserção de novos capítulos Itamar 
12/06/2022 1.1 Funcionalidades de agendamento Itamar 
13/06/2022 1.2 Aceite das inovações e versionamento Itamar 
15/06/2022 1.5 Diagrama de arquitetura Itamar 
18/06/2022 2.0 Versão final Itamar 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Barber Shop Luiz Henrique 
_______________________________________________________________________________________________________________________________________________________________________________________________________ 
 Documento de Requisitos 
_______________________________________________________________________________________________________________________________________________________________________________________________________ 
 
1 Introdução 
 
1.1 Propósito do documento de requisitos 
Este documento destina-se aos clientes, engenheiros e gerentes envolvidos no desenvolvimento do 
sistema, doravante referido apenas como BARBEARIA. O propósito deste documento é apresentar a 
descrição dos serviços e funções que o sistema a ser desenvolvido deve prover, bem como as suas 
restrições de operação e propriedades gerais, a fim de ilustrar uma descrição detalhada do sistema para 
um auxílio durante as etapas de análise, projeto e testes. O documento especifica todos os requisitos 
funcionais e não funcionais do sistema e foi preparado levando-se em conta as funcionalidades levantadas 
durante a fase de concepção do sistema. 
 
1.2 Escopo do produto 
O projeto consiste na construção de uma ferramenta para gerenciamento de barbearia, que possa atender 
os requisitos da Empresa Barber Shop Luiz Henrique no fator de serviços de beleza masculina. O projeto 
visa auxiliar o sistema de gerencia da barbearia através de ferramentas síncronas e assíncronas que serão 
usadas por funcionários e clientes empresa. 
 
Não fazem parte do escopo do projeto: 
● Instalação e configuração do ambiente tecnológico do cliente. 
● Treinamento de instalação, configuração, administração e utilização do sistema; 
● Integração com quaisquer sistemas ou base de dados do ambiente tecnológico do cliente; 
 
1.3 Concepção do sistema 
Foram usados dois métodos para que pudessem ser obtidos os requisitos do sistema: 
● Entrevista com o proprietário da barbearia: 
- Luiz Henrique, proprietário do estabelecimento comercial, no qual o mesmo apontou suas 
necessidades básicas, apresentou a regulamentação pertinente ao seu modelo de negócio, 
do qual foi retiradas as alíquotas dos impostos retidos; 
- Entrevista com clientes, os quais apontaram as necessidades/funcionalidades que julgavam 
interessante por parte do usuário. 
 
● Formulários: 
- Foi aplicados aos clientes um formulário, com base neste documento foi extraído os dados 
principais, referentes as funcionalidade essenciais desejáveis o sistema da barber shop. 
 
1.4 Convenções, termos e abreviações 
Para evitar interpretações incorretas deste documento, algumas convenções e termos específicos são 
descritos a seguir: 
1.4.1 Identificação dos Requisitos 
Cada requisito será unicamente identificado no formato [tipoRequisito.numero]. Para requisitos funcionais, 
o código do tipo de requisito será RF, e para requisitos não funcionais, RNF. Um número será assinalado 
a cada requisito de forma incremental, na ordem que forem mencionados neste documento. 
1.4.2 Prioridade dos Requisitos 
Foram adotadas as seguintes denominações para estabelecer a prioridade dos requisitos: essencial, 
importante e desejável. 
● Essencial: é o requisito sem o qual o sistema não entra em funcionamento, ou seja, são 
requisitos imprescindíveis tendo que ser implementados impreterivelmente. 
● Importante: é o requisito sem o qual o sistema entra em funcionamento, mas de maneira 
insatisfatória, ou seja, devem ser implementados, mas se não forem, o sistema poderá ser 
 
 
implantado e usado mesmo assim. 
● Desejável: é o requisito que não compromete as funcionalidades básicas do sistema, podendo 
funcionar de forma satisfatória sem ele, ou seja, são requisitos que podem ser deixados para 
versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que 
está sendo especificada. 
 
1.5 Referências 
Esta subseção apresenta as referências aos documentos que utilizamos no auxílio à construção deste 
documento de requisitos. 
● Periódicos da CAPES - http://www.periodicos.capes.gov.br/ 
● Referências da Disciplina Engenharia de Software Educativo - 
http://www.cin.ufpe.br/~asg/nova_pagina_1.htm 
● Página da Disciplina Especificação de Requisitos e Validação de Sistemas- 
http://www.cin.ufpe.br/~if716/ 
 
1.6 Visão Geral 
Este documento está organizado da seguinte forma: 
● A seção 1 apresentou uma introdução ao documento de requisitos e ao sistema sendo 
especificado; 
● A seção 2 apresenta uma descrição geral do sistema; 
● A seção 3 apresenta as definições dos requisitos funcionais e não-funcionais do sistema; 
● A seção 4 apresenta o diagrama de casos de uso do sistema, bem como as descrições dos casos 
de uso definidos; 
● A seção 5 apresenta o diagrama de sequência, apresentado a visão geral e depois cada caso em 
separado; 
● A seção 6 apresenta o diagrama de classes, apresentado a visão geral e depois cada caso em 
separado, em sua ordem de criação; 
● A seção 7 apresenta o diagrama de Estado, apresentado a visão geral e depois cada caso em 
separado, em sua ordem de criação; 
● A seção 8 apresenta o diagrama arquitetura, apresentado a visão geral; 
● A seção 9 apresenta a previsão de manutenções, em forma de tabela. 
 
 
2 Descrição geral 
 
2.1 Usuários do sistema 
 
Cliente: realizam as tarefas comuns a todos os usuários, tal como: logar, agendar e enviar mensagens. 
Todos os demais usuários estendem as funcionalidades de Usuário; 
 
Proprietário: realiza tarefas de logar no sistema, recebe todas as solicitações de todos os usuários, tal 
como: pedido de agendamento, mensagens. 
 
2.2 Abrangência e sistemas similares 
 
Abrangência 
O sistema irá conter ferramentas para construção de uma agenda de atendimentos que esteja de acordo 
com as possibilidades de atendimento da barbearia. O barbeiro através de ferramentas (como Chat, 
calendário, e histórico de atendimento) irá aceitar ou não o atendimento, de acordo com a complexidade 
do corte exigido. O barbeiro terá a liberdade de aceitar ou não o pedido(levando-se em conta a 
complexidade do corte) e determinar o preparo do cabelo(lavagem, hidratação) e tempo estimado para a 
realização do procedimento. 
 
 
Sistemas similares: 
No cenário atual das barbearias e com o tempo cada vez mais escasso viu se a necessidade de dinamizar 
a utilização do tempo. 
 
No cenário nacional encontram-se três sistemas que se destacam: 
 
AVEC - é um ambiente de software baseado na Web, desenvolvido na cidade de São Paulo, para 
administração, criação, manutenção e participação no ramo de beleza e bem estar, atendendo salões de 
beleza, barbearias, esmalterias, estúdio de tatuagens, clínica de estética e spa, e franquias. 
 
Bling - é um produto formado por soluções integradas de gerenciamento de barbearias, é um 
ERP(Enterprise Resource Planning – Planejamento de recursos empresarias “tradução direta”). 
 
Belais - é um ambiente para a gestão e gerenciamento de barbearias. Ele foi concebido tendo como alvo 
a simplicidade, descomplicação, e agilidade no uso. 
 
2.3 Suposições e dependências 
As seguintes suposições são válidas no decorrer do desenvolvimento do sistema sendo especificado: 
● O cliente está responsável pela aquisição de infra-estruturanecessária em seu ambiente de 
produção; 
● O cliente será responsável pela disponibilização de recursos de hardware, software, e outros 
requerimentos destinados à implantação do sistema desenvolvido. 
 
 
 
3 Requisitos do Software 
 
 
 
 
 
 
 
 
 
Os requisitos apresentam as funcionalidades do sistema de forma a apresentar dois 
contextos, um exigido e um opcional/diferencial. 
Temos o requisito funcional como sendo de caráter exigido/obrigatório RF e o 
requisito não funcional RNF como opcional/agregador de valor ao produto. 
 
 
 
 
 
 
 
 
 
 
3.1 Requisitos Funcionais 
Requisitos obrigatórios(RF – Requisitos Funcionais) 
Os requisitos que descrevem os aspectos funcionais do sistema são apresentados a seguir: 
 
3.1.1 Requisitos de Segurança 
Ident. Requisito Descrição 
RF/SEG-01 Autenticar-se no sistema ● Registro e autenticação de acesso ao 
sistema, exigido para cada usuário. 
 
3.1.2 Requisitos de Interface 
Ident. Requisito Descrição 
RF/INT-01 Apresentação de dados básicos ● O sistema deve apresentar dados 
básicos na tela principal, como por 
exemplo datas disponíveis e horários, 
com intuito de evitar equivocos. 
 
3.1.3 Requisitos de Operacionais 
Ident. Requisito Descrição 
RF/OPE-01 Agendamentos ● Adição de horários, remoção de 
horários,. 
RF/OPE-02 Reservar horário ● Reservar um horário na agenda do 
profissional(barbeiro escolhido). 
RF/OPE-03 Registrar consumação ● Inserção de produtos consumidos no 
local, pode ser o serviço em si ou 
outros produtos comercializados no 
ambiente. 
 
 
 
3.2 Requisitos Não-funcionais 
 
Requisitos não obrigatórios/adicional, criador de valor ao produto(RNF – Requisito Não Funcional). 
Os requisitos que descrevem os aspectos não-funcionais do sistema são apresentados a seguir: 
3.2.1 Requisitos de Segurança 
Ident. Descrição Descrição 
RNF/SEG-01 Autenticar-se no sistema ● Utilização de autenticação com mais de 
um fator de segurança 
3.2.2 aRequisitos de Interface 
Ident. Requisito Descrição 
 
 
RNF/INT-01 Interface de utilização. ● O sistema deve ter uma interface de 
fácil utilização. 
3.2.3 Requisitos de Operacionais 
Ident. Requisito Descrição 
RNF/OPE-01 O sistema deve ser desenvolvido em linguagem 
WEB 
● O sistema deve utilizar ferramentas 
WEB, a critério da desenvolvedora 
visando produtividade e manutenção 
posteriores. 
RNF/OPE-02 Camada de software. ● O sistema deve ser desenvolvido em 
uma arquitetura em camadas. 
RNF/OPE-03 A camada de aplicação ● A camada de aplicação para web 
compatível com browsers de mercado 
(Internet Explorer, Netscape). 
3.2.4 Requisitos de Confiabilidade 
Ident. Requisitos Descrição 
RNF/CON-01 Disponibilidade do sistema ● O sistema deve estar disponível 24 
horas por dia durante os 7 dias da 
semana. Por não se tratar de um 
sistema crítico, o sistema poderá ficar 
fora do ar até que seja corrigida 
alguma falha que possa ocorrer. 
 
 
 
4 Casos de uso 
 
4.1 Diagrama de casos de uso 
O diagrama de casos de uso, expresso em UML (Unified Modeling Language), expressa os requisitos 
funcionais do sistema na forma de casos de uso. Segundo o RUP (Rational Unified Process), para cada 
requisito funcional tem-se um caso de uso. A descrição textual detalhada dos requisitos funcionais, seus 
fluxos de atividades e requisitos não funcionais associados pode ser encontrada na próxima seção. Na 
figura abaixo mostramos a representação gráfica em UML dos casos de uso do sistema. 
 
 
4.1.1 Visão geral 
 
 
4.2 Descrição dos casos de uso 
No caso de uso do sistema mostrado no diagrama de casos de uso, foram escolhidos quatro para serem 
detalhados e trabalhados nas fases de análise e projeto do sistema. 
 
4.2.1 Autenticar-se 
 
[CDU-01] 
Nome: Autenticar-se 
Atores: Cliente/Barbeiro 
Prioridade: Essencial 
Requisitos associados: ● 
Entradas e pré-condições: ● O Cliente/Barbeiro deve estar logado no sistema. 
Saídas e pós-condições: ● O Cliente/Barbeiro consegue realizar interações como o sistema 
Fluxos de eventos 
Fluxo principal: 1. O Cliente/Barbeiro ele escolhe a atividade a ser a ser 
realizada(atender/agendar/remarcar, entre outros) 
2. Realiza a atividade 
3. Efetua a conclusão, por exemplo, se for uma marcação, ele recebe uma 
confirmação posterior do barbeiro via sistema. 
4. Ele deve visualizar o status de cada interação existente. 
 
 
 
 
 
 
4.2.2 Atendimento 
 
[CDU-01] 
Nome: Atendimento 
Atores: Cliente 
Prioridade: Essencial 
Requisitos associados: 
Entradas e pré-condições: 
Saídas e pós-condições: ● O Barbeiro fica com a agenda ocupada durante a realização do atendimento 
Fluxos de eventos 
Fluxo principal: 5. O Cliente inicia a solicitação de atendimento(corte). 
6. O sistema procura em sua base de dados usuários agendados(caso o atendimento 
seja sem marcação, insere na agenda como horário ocupado, para este 
atendimento). 
7. O Barbeiro seleciona itens de atendimento realizado. 
 
 
4.2.3 Agenda 
 
[CDU-01] 
Nome: Agenda 
Atores: Cliente 
Prioridade: Essencial 
Requisitos associados: 
Entradas e pré-condições: ● O Cliente deve estar logado no sistema. 
Saídas e pós-condições: ● O Cliente consegue realizar interações como o sistema 
Fluxos de eventos 
Fluxo principal: 8. O Cliente ele escolhe uma data e horários disponível no sistema. 
9. Realiza a confirmação. 
 
 
4.2.4 Consumação 
 
[CDU-01] 
Nome: Consumação 
Atores: Cliente/Barbeiro 
Prioridade: Essencial 
Requisitos associados: 
Entradas e pré-condições: ● O Barbeiro deve estar logado no sistema. 
Saídas e pós-condições: ● O Barbeiro consegue realizar interações como o sistema(inclusões) 
Fluxos de eventos 
Fluxo principal: 10. O Barbeiro insere itens consumidos pelo cliente na barbearia. 
11. Realiza a confirmação. 
12. Ao final do atendimento o itens consumidos entram na conta final do 
atendimento. 
 
 
 
 
5 Diagrama de Sequencias 
No caso de uso do sistema mostrado no diagrama de sequência, foram escolhidos cinco para serem 
detalhados e trabalhados nas fases de análise e projeto do sistema. 
 
5.1.1 Autenticar-se 
 
 
5.1.2 Atendimento 
 
 
 
5.1.3 Agendamento/Marcação 
 
 
5.1.4 Consumação 
 
 
 
 
 
 
 
 
 
 
6 Diagrama de Classes 
Ilustra graficamente como será a estrutura do software a ser desenvolvida, podendo ser micro ou macro 
ou ambos a critério do desenvolvedor, ou levando se em conta o quão claro ele quer que a percepção do 
ambiente a ser desenvolvido seja. 
Modela a forma estática do sistema, podendo ser utilizados a quantidade de diagramas que forem 
necessárias. 
Neste caso foi utilizada apenas uma, pois o software é de baixíssima complexidade, ao decorrer do texto 
foi desmembrado para uma melhor visualização por classes logo a baixo. 
 
 
6.1.1 Autenticar-se 
 
6.1.2 Atendimento 
 
 
 
 
6.1.3 Agenda 
 
 
6.1.4 Marcar 
 
6.1.5 Consumação 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 Diagrama de Estado 
O Diagrama de Estado apresenta basicamente eventos dos objetos, utilizando para isso máquinas de 
estado, que armazenam os status de objetos em determinados momentos, podendo mudar a qualquer 
momento este status a depender de receber uma entrada diferente. 
Retratando principalmente transições e estados, que demonstram as mudanças de estado. 
Utilizados com mais frequência em essência em: 
1) Descreve objetos orientados a eventos em um sistema reativo; 
2) Ilustrar cenários com casos de uso aplicados ao negócio; 
3) Mostrar a máquina de estado ou comportamento geral, um conjunto relacionado. 
7.1.1 Autenticar-se 
 
 
7.1.2 Atendimento 
 
 
 
 
7.1.3 Agenda 
 
 
7.1.4 Marcar 
 
 
 
 
7.1.5 Consumação 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 Diagrama de Arquitetura 
Funcionamento básico para dispositivos móveis(celulares) iOS e Android, utiliza os recursos provenientes 
do próprio SO(sistema operacional) para a conexão com a base de dados, fazendo a persistência dos dadose a consulta dos dados de login. 
Pode-se observar a disposição interna do sistema, com App, BackEnd e aplicação, senso: 
1) App: Android ou iOS(componentes Web, Conexão externa com o banco); 
2) Backend: armazenamento(persistência de dados), banco de dados(BD) e usuários(gerencia e 
autenticação); 
3) Aplicação Web: Angular e Java Script. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
9 Previsões de Manutenção 
No caso da manutenção de software temos a premissa de o produto ter um início, meio e fim. Porém este 
fim ele não é pleno, oi seja, ele sofre manutenções, afim de manter-se útil(vivo). A atividade de 
manutenção acompanha o software por toda sua vida, sendo uma parte muito importante e cara para 
empresas, consumindo grande parte de recursos para manutenção. Segundo Sommerville (2001), dois 
terços de custos de software são de evolução. Com certeza, os custos para mudança de software requerem 
grande parte do orçamento de TI para todas as empresas. 
Manter uma equipe qualificada é em tempo integral para a manutenção de sistemas e software legados é 
muito caro e desgastante. Manter o software aperfeiçoado e estável tentando ao máximo diminuir seu 
envelhecimento. 
MANUTENÇÃO DE SOFTWARE 
ADAPTATIVA Alteração da regra de negócio, o ambiente no qual o sistema está inserido, mudança 
de legislação ou alíquotas de impostos. 
CORRETIVA Altera parte do código, parte que apresenta defeitos, podendo ser por má codificação 
ou por atualização de algum software assessor. Necessários avaliar a gravidade para 
plano de correção 
EVOLUTIVA Agrega novas funções, criando uma sobrevida ao sistema. Mantém a competitividade 
do negócio 
 
 
MANUTENÇÃO DE SOFTWARE - CONTRATO 
 Tipos de manutenções Contratadas 
- X 
Contratadas Descrição 
ADAPTATIVA Não Software orçado sem previsibilidade de 
manutenções adaptativas. 
CORRETIVA Não Software orçado com manutenções 
corretivas oriundas do desenvolvimento, 
não cobrindo mudanças estruturais ou de 
fluxos não acordadas. 
EVOLUTIVA X Sim O contrato prevê evoluções de caráter 
normativo, ou seja, mudanças em 
alíquotas governamentais nas esferas: 
municipais, estaduais e federais, num 
prazo de até 2(dois) anos.