UNIVERSIDADE FEDERAL DO PARÁ
CAMPUS UNIVERSITÁRIO DO TOCANTINS/CAMETÁ
FACULDADE DE SISTEMAS DE INFORMAÇÃO
PROF. Dr. CARLOS DOS SANTOS PORTELA
ARLENIZI RODRIGUES FERREIRA
CAIO CORRÊA GAIA
EDINALDO HENRIQUES DE SOUSA
MANOEL DE S. C. PIMENTEL
ROSINELMA B. DE SOUZA OLIVEIRA
SAMILLY BATISTA MORAES
MÓDULO BI
Cametá-PA
2023
1
1. REQUISITOS FUNCIONAIS
Os requisitos funcionais são todos os problemas e necessidades que devem ser
atendidos e desenvolvidos pelo software por meio de funções ou serviços. São
relevantes para o desenvolvimento, pois, sem eles não há funcionalidades no sistema.
Desta forma, os requisitos especificados para o projeto serão apresentados na
tabela 1:
Tabela 1: Requisitos Funcionais
REQUISITOS FUNCIONAIS
ID DESCRIÇÃO
RF01 – Cadastro O sistema deverá utilizar os dados do usuário, tais como, nome
completo, e-mail, telefone, endereço e a senha, a fim de que o
usuário possa realizar o seu cadastro.
RF02 – O sistema deverá utilizar os dados do usuário cadastrado no
Autenticação de sistema do BI, a fim de que o usuário possa realizar o seu login
Login (e-mail e senha).
RF03 – Painel O usuário deverá ser capaz de acessar as informações dispostas
Administrativo na plataforma em forma de dashboards, gráficos, dados
com Dashboard estatísticos a fim de realizar análises, comparações, informações
gerais que possam ajudar na tomada de decisão.
RF04 - Selecionar O sistema deverá exibir uma lista onde o usuário irá selecionar a
Cidade cidade na qual poderá visualizar um gráfico com o valor em
vendas realizadas a partir de uma cidade selecionada.
RF05 – Selecionar O sistema deverá exibir uma lista onde o usuário irá selecionar
Período o período (semanal, quinzenal e mensal) na qual poderá
visualizar um gráfico com o valor em vendas realizadas pelas
lojas da cidade selecionada.
RF06 – Pedidos O sistema deverá mostrar a porcentagem dos pedidos realizados
Realizados e ao clicar, o mesmo deverá exibir uma lista de todos os pedidos
que foram realizados de acordo com cada loja e os pedidos que
foram entregues.
2
RF07 – Listar a O sistema deverá apresentar uma porcentagem dos pedidos que
quantidade de não foram entregues e ao clicar, o mesmo deverá exibir uma
pedidos que lista com as lojas e os pedidos que deixaram de serem entregues
deixaram de serem pela mesma.
entregues
RF08 – Lojas O sistema deverá exibir uma lista com as lojas habilitadas e
desabilitadas, por cidade selecionada, onde terá acesso aos
pedidos por lojas e a quantidade de lojas que estão cadastradas
no aplicativo.
RF09 – Clientes O sistema deverá exibir o número de clientes cadastrados no
aplicativo e ao clicar, o mesmo irá apresentar uma lista de todos
os clientes que estão cadastrados e o número de pedidos que
cada cliente realizou no aplicativo.
RF10 – Receita dos O sistema deverá exibir a soma total das vendas (em reais) dos
pedidos realizados pedidos realizados pelas lojas.
RF11 – Central de O sistema deverá exibir uma lista com os pedidos que estão
Pedidos pendentes de acordo com a cidade selecionada.
RF12 - Sair O sistema deverá exibir uma opção onde o usuário logado
poderá sair da tela do BI.
2. REQUISITOS NÃO-FUNCIONAIS
Os requisitos não-funcionais são restrições sobre os serviços ou as funções
oferecidas pelo sistema. Onde definem características e impõe limites do sistema como
método de desenvolvimento, espaço, usabilidade, confiabilidade, segurança,
disponibilidade, manutenabilidade e tecnologias envolvidas.
Desta forma, os requisitos não-funcionais especificados para projeto são
exemplificados na Tabela 2:
3
Tabela 2: Requisitos Não-Funcionais
REQUISITOS NÃO-FUNCIONAIS
ID DESCRIÇÃO
RNF01 - O sistema deverá ser uma aplicação web com linguagem
Plataforma desenvolvimento Java Script rodando na plataforma [Link]
(Back-End), com framework React Js (Front-End).
RNF02 - Interface O sistema deverá permitir facilidades de uso, tendo uma interface
gráfica clara e intuitiva, a fim de que pouco tempo seja
necessário para o usuário dominá-la sem a necessidade de um
treinamento intensivo prévio (Baseando-se nas diretrizes da área
de UX/UI Design).
RNF03 - Espaço O sistema deverá armazenar informações necessárias utilizando
o banco de dados MYSQL.
RNF04 - O sistema deverá melhorar a estrutura interna do código sem
Manutenibilidade alterar seu comportamento externo, auxiliando, assim, o
entendimento do código, a fim de evitar a deterioração durante o
ciclo de vida do sistema causada por mudanças de curto ou longo
prazo.
RNF05 - O sistema deverá ser protegido contra acesso não autorizado.
Segurança Para as comunicações externas entre o servidor de dados do
sistema e o cliente deve ser usada a criptografia SSL.
RNF06 - O sistema deverá ter seus servidores disponíveis para atender
Disponibilidade 99% das solicitações.
3. Diagrama de Casos de Uso
No diagrama ilustrado na Figura 1, o ator que representa o CEO, ao fazer Login,
através de um cadastro, o mesmo estará apto a acessar o Painel Administrativo com o
4
dashboard que visam proporcionar dados e informações relevantes para a gestão
eficiente no qual serão mostradas todas as vendas realizadas pelas lojas no período e
cidade selecionada. E ao clicar em “Central de pedidos” o usuário terá acesso a uma
lista com os pedidos que estão pendentes de acordo com a cidade selecionada.
Figura 1: Diagrama de Casos de Uso
[Link]ção de Casos de Uso
Tabela 3: Cenário UC01
ID UC01
Nome do Realizar Login
cenário
Ator CEO
Pré-condição Usuário deverá ter realizado seu cadastro
Fluxo normal 1 - O usuário deverá inserir seu e-mail e senha.
2 - O usuário consegue acessar o painel administrativo do BI.
5
Fluxos 1 - E-mail e/ou senha inválida.
alternativos
2 - Exibir uma mensagem informando ao usuário que a senha pode ser
recuperada.
Pós-condição 1 - Usuário logado ao sistema.
Tabela 4: Cenário UC02
ID UC02
Nome do Visualizar Painel
cenário
Ator CEO
Pré-condição O usuário deverá estar logado no sistema
Fluxo normal 1 - O usuário acessa o Painel Administrativo, onde terá acesso ao
Dashboard.
2 - O sistema deverá exibir uma lista onde o usuário irá selecionar a
cidade na qual poderá visualizar um gráfico com o valor em vendas
realizadas.
3 - O usuário poderá selecionar o período (semanal, quinzenal e mensal)
na qual poderá visualizar o valor em vendas realizadas pelas lojas.
4 - O usuário poderá clicar em “Pedidos Realizados”, onde deverá exibir
uma lista de todos os pedidos que foram realizados de acordo com cada
loja e os pedidos que foram entregues.
5 - O usuário poderá clicar em “Deixei de entregar” e o sistema deve
exibir uma lista com as lojas e os pedidos que deixaram de serem
entregues pela mesma.
6 - O usuário poderá clicar em “Lojas” e o sistema deverá exibir uma
lista com as lojas habilitadas e desabilitadas, por cidade selecionada,
onde terá acesso aos pedidos por lojas e a quantidade de lojas que estão
cadastradas no aplicativo.
6
7 - O usuário poderá clicar em “Clientes” e visualizar o número de
clientes cadastrados no aplicativo.
8 - O usuário poderá clicar em “Pedidos Receita” e o sistema deve exibir
a soma total das vendas (em reais) dos pedidos realizados pelas lojas.
Fluxos Não se aplica
alternativos
Pós-condição Não há pós-condição
Tabela 5: Cenário UC03
ID UC03
Nome do Monitorar pedidos
cenário
Ator CEO
Pré-condição O usuário deverá estar logado no sistema
Fluxo normal 1 - O usuário deverá acessar a “Central de Pedidos”, onde será exibida
uma lista com os pedidos que estão pendentes de acordo com a cidade
selecionada.
2 - O usuário poderá selecionar a cidade que deseja monitorar.
Fluxos Não se aplica
alternativos
Pós-condição Não há pós-condição.
7
4. Definir Padrão de Elicitação de Requisitos
Inicialmente para o desenvolvimento do sistema do BI foi utilizada a técnica de
engenharia reversa para destrinchar e entender o funcionamento de um produto por
meio da análise e investigação, assim sendo, utilizamos como modelo o Hambre BI para
explorar suas interfaces, funções e tecnologias, a fim de identificar quais caminhos
foram traçados para chegar até aquele modelo.
No entanto, a entrevista com o cliente se mostra indispensável no
desenvolvimento de tecnologia, pois este é que vai fazer uso direto da tecnologia
desenvolvida, sendo assim, foram realizadas reuniões com os Stakeholders, e por meio
disso foram indicadas necessidades de melhorias para serem implementadas no sistema.
5. REALIZAR RASTREABILIDADE ENTRE REQUISITOS
A rastreabilidade de requisitos consiste na identificação de relações entre
requisitos e outros produtos (artefatos) da Engenharia de Software. Ela permite a
realização de uma análise mais eficiente na evolução do software e é essencial para o
desenvolvimento e entrega de qualquer produto. Ao mapear requisitos para testes, por
exemplo, ela garante que todos os aspectos do produto sejam cobertos, reduzindo o
risco de surpresas durante ou após a entrega, trazendo muitos benefícios como maior
eficiência e qualidade em todo o processo de desenvolvimento de software.
[Link] Horizontal
Tabela 6: Rastreabilidade Horizontal
ID Requisitos Descrição da Dependência
Dependentes
RF01 RF02 O requisito (RF02) tem sua dependência sobre o requisito
(RF01), pois os mesmos de forma complementar necessitam
estar de acordo com as especificações definidas em
requisitos na plataforma para que a ação de validação de
8
login seja realizada na plataforma de BI.
RF02 RF03 A fim de visualizar o painel administrativo (RF03) o
usuário precisa ter efetuado o login (RF02).
RF03 RNF02 A fim de uma experiência agradável do usuário com a tela
do painel administrativo (RF03), deve-se implementar
componentes que melhorem a usabilidade do sistema
(RNF02).
RF02 RF04 A fim de selecionar a cidade no qual deseja visualizar o
gráfico com valor de suas vendas (RF04) o usuário deverá
estar logado ao sistema (RF02).
RF02 RF05 A fim de selecionar o período no qual deseja visualizar o
gráfico com valor de suas vendas (RF05) o usuário deverá
estar logado ao sistema (RF02).
RF02 RF06 A fim de visualizar os pedidos que foram realizados (RF06)
o usuário deverá estar logado (RF02).
RF02 RF07 A fim de visualizar os pedidos que não foram entregues
(RF07) o usuário deverá estar logado (RF02).
RF02 RF08 A fim de visualizar as lojas que estão cadastradas (RF08) o
usuário deverá estar logado (RF02).
RF02 RF09 A fim de visualizar o número de clientes que tem o
aplicativo (RF09) o usuário deverá estar logado (RF02).
RF02 RF10 A fim de visualizar a receita dos pedidos realizados (RF10)
o usuário deverá estar logado (RF02).
RF02 RF11 A fim de visualizar os pedidos que estão pendentes (RF11) o
usuário precisa ter efetuado o login (RF02).
RF02 RF12 O (RF12) depende do (RF02), pois para sair do sistema o
usuário precisa ter efetuado o login (RF02).
9
[Link] Vertical
Tabela 7: Rastreabilidade Vertical
ID Artefato Descrição da Dependência
Dependentes
RF02 UC01 O caso de uso UC01 é derivado do RF02.
RF03 UC02 O caso de uso UC02 é derivado do RF03.
RF10 UC03 O caso de uso UC03 é derivado do RF10.
6. Especificar Critérios de Verificação dos Requisitos
A Verificação de Requisitos é o processo de confirmação de que o requisito do
sistema a ser construído contém todos os elementos necessários para atender aos seus
objetivos e funções conforme pretendido. Ele é uma etapa crítica no desenvolvimento
do sistema, pois, antes do projeto, devem ser verificados e aprovados para evitar
retrabalho, caso contrário, a verificação deles será feita durante os processos de
criação e desenvolvimento do produto. Além disso, requisitos incompletos, incorretos
ou inconsistentes podem levar a problemas durante o desenvolvimento, teste e
implantação do sistema, por isso a melhor forma é verificar com antecedência.
10
Tabela 8: Verificação dos Requisitos
Descrição do Critério Atende Não
atende
Completude: Estão incluídas todas as funções e restrições
X
requeridas pelo cliente?
Validade: O sistema fornece as funções que melhor atendem às
X
necessidades do cliente?
Não ambíguos: Todos estão descritos de forma clara e objetiva?
X
Verificação: Os requisitos podem ser verificados?
X
Teste: Os requisitos podem ser testados? Pode ser escrito um
conjunto de testes que demonstrem que o sistema atende a todos os X
requisitos especificados.
Rastreável: Teve rastreabilidade entre os requisitos para garantir
X
que os requisitos sejam completos, consistentes e verificáveis?
Passo a passo: Os requisitos foram revisados por Stakeholders que
fornecem feedback e identificam quaisquer problemas ou sugeriram X
mudanças?
Facilidade de Uso: O sistema permite facilidades de uso com uma
X
interface gráfica clara e intuitiva?
Segurança: Os requisitos de segurança estão especificados?
X
11