Levantamento de Requisitos

Centro Universitário de Brasília
Instituto CEUB de Pesquisa e Desenvolvimento - ICPD
ANDRÉ LUIZ DOS SANTOS BARBOSA
DASHBOARD
Brasília
2017
DASHBOARD
Projeto apresentado ao Centro Universitário

de Brasília (UniCEUB/ICPD) como pré-
requisito para obtenção de Certificado de
Conclusão de Curso de Pós-graduação Lato
Sensu em Engenharia de Requisitos de
Software.
Orientadora: Professora Angelica Calazans
Brasília
2017
DASHBOARD
Trabalho apresentado ao Centro

Universitário de Brasília (UniCEUB/ICPD)
como pré-requisito para a obtenção de
Certificado de Conclusão de Curso de
Pós-graduação Lato Sensu em
Engenharia de Requisitos de Software.
Orientador: Professora Angelica Calazans
Brasília, 26 de Outubro de 2017.
Banca Examinadora
_________________________________________________
Prof. Msc Angelica Toffano Seidel Calazans
_________________________________________________
Prof. Msc Josiani Neves Pereira
RESUMO
Este projeto tem o objetivo de apresentar o desenvolvimento de um dashboard,

apresentação das informações mais importantes e necessárias para alcançar um ou
mais objetivos de negócio, consolidadas e ajustadas em uma tela para fácil
acompanhamento. Os requisitos foram levantados junto à empresa Pecista, uma das
maiores distribuidoras de autopeças de Brasília, foi utilizado o método iRON,
Integração de Requisitos Orientados ao Negócio. Seguindo a metodologia, na
primeira parte do trabalho é apresentado o DAN, Documento de Análise do Negócio,
que visa levantar informações do processo atual e propor uma solução, identificando
o objetivo geral e objetivos específicos e funcionalidades. Na segunda parte é
apresentado o DDR, Documento de Definição de Requisitos, que descreve os
requisitos funcionais, de dados, de execução e não funcionais, identificando a
relação entre eles, ao final é apresentado um protótipo não funcional com o objetivo
de validar o que está sendo desenvolvido. Na terceira parte do trabalho são
apresentados os modelos de dados, diagrama de casos de uso, diagrama de classe,
diagrama de contexto e mostra como será feita a gerência dos requisitos. Ao término
do trabalho conclui-se que o método utilizado facilitou muito o desenvolvimento do
projeto.
Palavras-chave: Dashboard; Gráfico; Ranking; Modelo; Diagrama.

ABSTRACT
This project has the purpose to show the development of a dashboard, a

presentation of the most important and necessary information to achieve one or more
business objectives, consolidated and adjusted on a screen for easy monitoring. The
requirements were collected from Pecista, one of the largest auto parts distributors in
Brasilia, using the iRON method, Business Oriented Requirements Integration.
Following the methodology, the first part of the paper presents the DAN, Business
Analysis Document, which aims to gather information about the current process and
offer a solution, identifying the general and specific objectives and functionalities. In
the second part is presented the DDR, Requirement Definition Document, which
describes the functional, data, execution and nonfunctional requirements, identifying
the relationship between them, at the end a non-functional prototype is presented
with the purpose of validating what is being developed. In the third part of the paper
it's presented the data models, use case diagram, class diagram, context diagram
and shows how the requirements management will be done. At the end of the work it
is concluded that the method used facilitated the development of the project very
much.
Key words: Dashboard; Chart; Ranking; Model; Diagram.

LISTA DE FIGURAS
Figura 1 – Organograma .......................................................................................10

Figura 2 – Processo atual ..................................................................................... 11
Figura 3 – Processo proposto ............................................................................... 14
Figura 4 – Cronograma ........................................................................................ 21
Figura 5 – Protótipo não funcional ....................................................................... 55
Figura 6 – Diagrama de Contexto ........................................................................ 56
Figura 7 – Diagrama de Nível 0 ............................................................................ 57
Figura 8 – Diagrama de Casos de Uso ................................................................ 58
Figura 9 – Diagrama de Classes .......................................................................... 61
Figura 10 – Modelo de Dados Conceitual ............................................................ 62
Figura 11 – Modelo de Dados Lógico ................................................................... 63
Figura 12 – Dimensões do Plano de Gerenciamento de Requisitos .................... 67
Figura 13 – Processo de gerenciamento de mudanças de requisitos .................. 68
Figura 14 – Ciclo de vida do software e inspeção ................................................ 73
Figura 15 – Checklist de Inspeção ........................................................................73
SUMÁRIO
INTRODUÇÃO ............................................................................................................ 9
1 DOCUMENTO DE ANÁLIDE DO NEGÓCIO (DAN) ........................................... 10
1.1 Análise Institucional – Visão Geral .................................................................. 10
1.2 Análise Funcional – Visão Específica .............................................................. 11
1.3 Proposta de solução ........................................................................................ 14
1.3.1 Descrição do novo processo proposto ............................................................ 14
1.3.2 Mapeamento do novo processo proposto ....................................................... 14
1.3.3 Objetivo Geral.................................................................................................. 15
1.3.4 Objetivos Específicos ...................................................................................... 15
1.4 Plano de Projeto .............................................................................................. 21
2 DOCUMENTO DE DEFINIÇÃO DE REQUISITO (DDR) .................................... 25
2.1 Requisitos ........................................................................................................ 25
2.2 Rastreabilidade................................................................................................ 51
2.2.1 Objetivos Específicos X Funcionalidades ........................................................ 51
2.2.2 Funcionalidades X Requisitos Funcionais ....................................................... 52
2.2.3 Requisitos Funcionais X Requisitos de Dados ................................................ 53
2.2.4 Requisitos Funcionais X Regras de Execução ................................................ 54
2.2.5 Requisitos Funcionais X Mensagens ............................................................... 56
2.3 Protótipo Não Funcional .................................................................................. 57
3 GERENCIA DE REQUISITOS E MODELOS ...................................................... 58
3.1 Modelagem dos Requisitos ................................................................................. 58
3.1.1 Modelagem Estruturada: ................................................................................. 58
3.1.2 Modelagem Orientada a Objetos ..................................................................... 60
3.2 Modelagem de Dados ..................................................................................... 63
3.2.1 Diagrama de Classes ...................................................................................... 63
3.2.2 Modelo de Entidades e Relacionamentos (MER) ............................................ 64
3.3 Métricas e Estimativas ..................................................................................... 66
3.3.1 Contagem das Funções de Dados .................................................................. 66
3.3.2 Contagem das Funções de Transação ............................................................ 68
3.3.3 Cálculo do Fator de Ajuste .............................................................................. 68
3.3.4 Estimativa de tempo e custo do Projeto .......................................................... 69
3.4 Plano de Gerência dos Requisitos .................................................................. 69
3.4.1 Processo de gerenciamento de requisitos ....................................................... 69
3.4.2 Indicadores de qualidade ................................................................................ 72
3.4.3 Lista de Classificação de Defeitos ................................................................... 75
3.4.4 Técnicas de inspeção ...................................................................................... 76
CONCLUSÃO............................................................................................................ 79
REFERÊNCIAS ......................................................................................................... 80
9
INTRODUÇÃO
Nos dias atuais, cada vez mais as empresas buscam maneiras capazes de
ajudar na interpretação e análise de dados comerciais e financeiros, muitas dessas
empresas fazem isso de maneira quase artesanal, buscando informações em
relatórios, que são consolidadas em planilhas para que sejam posteriormente
disponibilizadas a quem de fato vai analisar os dados, conforme a empresa cresce,
aumenta o volume de informação diária que precisa ser apurada e o tempo gasto
para consolidar essas informações só aumenta, acarretando perda de eficiência e
agilidade, surge então a necessidade de tornar esse trabalho mais ágil e controlado.
Nesse contexto encontra-se a empresa Pecista Distribuição e Representação

de Autopeças Ltda, umas das maiores distribuidoras de autopeças de Brasília. Em
razão do grande volume de transações diárias e com muitos dados para serem
consolidados e analisados todos os dias, tarefa que é feita atualmente com o uso de
vários relatórios e planilhas que são produzidos e enviados por e-mail para os
diretores, viu-se a necessidade de agrupar essas informações de maneira que
tornasse mais fácil e ágil a análise desses dados, surgindo a necessidade do
desenvolvimento de um dashboard, apresentação das informações mais
importantes e necessárias para alcançar um ou mais objetivos de negócio,
consolidadas e ajustadas em uma tela para fácil acompanhamento, tornando a
tarefa de consolidar dados automática e permitindo uma análise mais precisa e
rápida dos dados.
O trabalho a seguir apresenta o desenvolvimento do dashboard usando

técnicas da Engenharia de Requisitos, adotou-se o método iRON, Integração de
Requisitos Orientado ao Negócio, que se mostrou muito eficaz na produção e
gerência dos requisitos.
10
1 DOCUMENTO DE ANÁLIDE DO NEGÓCIO (DAN)
1.1 Análise Institucional – Visão Geral
1.1.1 A empresa
Em atividade desde 1994, a Pecista é uma empresa dedicada
exclusivamente ao atendimento a pessoas jurídicas e firmas individuais, pois
considera fundamental que um atacado não concorra com seus clientes.
A Pecista se tornou o mais ágil atacado de peças elétricas de Brasília, tendo
como pontos fortes o estoque, preços competitivos e um excelente sistema de
entrega. A empresa atua também nas áreas de mecânica, injeção, químicos
e acessórios.
1.1.2 O negócio
Possuindo dois diretores com atribuições distintas, um que cuida de
toda área comercial e outro responsável pelas áreas administrativa e
financeira, cada um necessita de informações consolidadas que dão suporte à
tomada de decisões. Com o aumento do negócio e volume de informações
essa tarefa tem se tornado cada vez mais complexa e demorada para serem
consolidadas.
1.1.3 A organização
11
Figura 1 - Organograma
1.2 Análise Funcional – Visão Específica
1.2.1 Áreas envolvidas

 Diretoria Administrativa / Financeira
 Diretoria Comercial
 Supervisão Financeira
 Supervisão Comercial
1.2.2 Descrição do processo atual

Com o mercado cada vez mais competitivo, se faz necessária uma
avaliação constante das informações comerciais, administrativas e
financeiras, para esse acompanhamento os diretores recebem no início da
manhã planilhas padronizadas que mostram essas informações, os dados
são colhidos e agrupados tendo como base vários relatórios que o ERP
disponibiliza.
1.2.3 Mapeamento do processo atual

12
Figura 2 – Processo atual
1.2.4 Identificação dos problemas
Grande problema Ineficiência do sistema atual de prover

informações analíticas de modo integrado e de
fácil acesso para a tomada de decisão.
Elemento Descrição
Problema raiz Dificuldade no acompanhamento das metas
estabelecidas.
Efeitos Não cumprimento das metas e dificuldade na
cobrança da equipe.
Problema raiz Dificuldade em acompanhar a carteira de
recebimentos.
Efeitos Descontrole com a inadimplência causando prejuízo.
Problema raiz Ineficiência no controle da média de prazos.
Efeitos Descontrole no fluxo de caixa.
Problema raiz Ineficiência no acompanhamento do ranking de
fornecedores. (Top 10)
13
Efeitos Os maiores fornecedores precisam ser

acompanhados de perto, caso isso não seja feito, as
metas estabelecidas pelos fornecedores podem não
ser cumpridas.
Problema raiz Ineficiência no acompanhamento do ranking de grupo
de produtos. (Top 10)
Efeitos Queda nas vendas dos grupos de produtos.
Problema raiz Ineficiência no acompanhamento do ranking de
clientes. (Top 10)
Efeitos Grandes clientes podem diminuir o fluxo de compras
se não houver um acompanhamento rigoroso.
Problema raiz Ineficiência no controle da performance dos
vendedores.
Efeitos Vendedores podem se desmotivar acarretando perda
de vendas.
Problema raiz Ineficiência no acompanhamento das linhas de
produtos.
Efeitos Dificuldade em medir como estão distribuídas as
vendas, ajudando a detectar possíveis perdas.
Problema raiz Dificuldade em verificar o indicador de inadimplência.
Efeitos Perda do controle de inadimplência acarretando em

prejuízo.
Problema raiz Ineficiência em acompanhar o indicador de cotação,
cujo o preço costuma ser mais barato.
Efeitos Dar descontos acima das metas estabelecidas.
Problema raiz Dificuldade em monitorar o indicador de margem de
contribuição
14
Efeitos Perda do momento certo para promoções mais

arrojadas.
Problema raiz Dificuldade em monitorar a evolução da venda nos
últimos 12 meses.
Efeitos Perda da eficiência na comparação das vendas com
base em meses anteriores.
Problema raiz Dificuldade de acompanhar de maneira rápida as
vendas do mês corrente.
Efeitos Queda nas vendas caso não seja acompanhada
diariamente.
1.3 Proposta de solução
1.3.1 Descrição do novo processo proposto

Os diretores poderão acessar todas as informações necessárias para a
análise e tomada de decisão através de uma única interface, um Dashboard
com gráficos, tabelas e indicadores que possibilitará acompanhar de perto e
em tempo real como anda a empresa.
1.3.2 Mapeamento do novo processo proposto
Figura 3 – Processo proposto

15
1.3.3 Objetivo Geral

Desenvolver um Dashboard com informações financeiras e
comerciais, que facilitará e agilizará a análise dos dados financeiros e
comerciais.
1.3.4 Objetivos Específicos
Objetivo Específico Fornecer informações agrupadas sobre as metas

da empresa.
Problema a resolver Dificuldade no acompanhamento das metas

estabelecidas.
Prioridade 1
Funcionalidade F01-Metas.
Objetivo Específico Fornecer informações consolidadas sobre a

carteira de recebimentos.
Problema a resolver Dificuldade em acompanhar a inadimplência.
Prioridade 1
Funcionalidade F02-Gráfico de distribuição de recebimentos.
Objetivo Específico Criar modo de acompanhamento do indicador

de prazo médio.
Problema a resolver Ineficiência no controle da média de prazos.
Prioridade 1
Funcionalidade F03-Gráfico de indicador de prazo médio.
Objetivo Específico Criar ranking dos 10 maiores fornecedores.
Problema a resolver Ineficiência no acompanhamento do ranking de

fornecedores. (Top 10)
16
Prioridade 1
Funcionalidade F04-Ranking de fornecedores.
Objetivo Específico Criar ranking dos 10 maiores grupos de

produtos.

grupo de produtos. (Top 10)
Prioridade 1
Funcionalidade F05-Ranking de grupo de produtos.
Objetivo Específico Criar ranking dos 10 maiores clientes.

clientes. (Top 10)
Prioridade 1
Funcionalidade F06-Ranking de clientes.
Objetivo Específico Criar ranking de vendedores.
Problema a resolver Ineficiência no controle da performance dos

vendedores.
Prioridade 1
Funcionalidade F07-Ranking de vendedores.
Objetivo Específico Fornecer informações consolidadas da

distribuição das vendas por linha de produtos.
Problema a resolver Ineficiência no acompanhamento das linhas de

produtos
Prioridade 1
Funcionalidade F08-Gráfico de distribuição por linha de produto.

17

de inadimplência.
Problema a resolver Dificuldade em verificar o indicador de

inadimplência.
Prioridade 1
Funcionalidade F09-Gráfico de indicador de inadimplência.

de cotações.
Problema a resolver Ineficiência em acompanhar o indicador de

cotação, cujo o preço costuma ser mais barato.
Prioridade 1
Funcionalidade F10-Gráfico de indicador de cotações.

de margem de contribuição.
Problema a resolver Dificuldade em monitorar o indicador de

margem de contribuição.
Prioridade 1
Funcionalidade F11-Gráfico de indicador de margem de

contribuição.
Objetivo Específico Criar modo de comparativo das vendas dos

últimos 12 meses.
Problema a resolver Dificuldade em monitorar a evolução da venda

nos últimos 12 meses.
Prioridade 1
Funcionalidade F12-Gráfico de vendas dos últimos 12 meses.

18
Objetivo Específico Criar modo de acompanhamento das vendas do

mês corrente dia a dia.
Problema a resolver Dificuldade de acompanhar de maneira rápida

as vendas do mês corrente.
Prioridade 1
Funcionalidade F13-Gráfico de vendas do mês corrente dia por

dia.
1.3.5 Funcionalidades
Funcionalidade F01-Metas.
Descrição Apresentar em forma de tabela informações

consolidadas sobre as metas da empresa, dos
vendedores e clientes com objetivo de
acompanhar se as metas serão ou não
atingidas.
19
Funcionalidade F02-Gráfico de distribuição de recebimentos.
Descrição Mostrar em forma de gráfico as faixas de

recebimentos.
Funcionalidade F03-Gráfico de indicador de prazo médio.
Descrição Mostrar em forma de gráfico o indicador de

prazo médio.
Funcionalidade F04-Ranking de fornecedores.
Descrição Acompanhar de perto os maiores fornecedores

coo o objetivo de não deixar a vendas desses
fornecedores cair.
Funcionalidade F05-Ranking de grupo de produtos.
Descrição Mostrar uma tabela com os grupos mais

vendidos com o objetivo de acompanhar a
performance dos grupos.
Funcionalidade F06-Ranking de clientes.
Descrição Mostrar uma tabela com os clientes que mais

compram com o objetivo de ter um tratamento
especial desses clientes.
Funcionalidade F07-Ranking de vendedores.
Descrição Mostrar uma tabela com o ranking de

vendedores para acompanhar de perto a
performance de cada um, podendo fazer
comparações entre eles.
20
Funcionalidade F08- Gráfico de distribuição por linha de

produto.
Descrição Mostrar um gráfico da distribuição das vendas

por linha de produto.
Funcionalidade F09-Gráfico de indicador de inadimplência.
Descrição Mostrar em formato de gráfico como está o

indicador de inadimplência.
Funcionalidade F10-Gráfico de indicador de cotações.
Descrição Mostrar em formato gráfico como está o

indicador de cotações, vendas realizadas com
um desconto além do máximo permitido.
Funcionalidade F11-Gráfico de indicador de margem de

contribuição.
Descrição Mostrar em forma de gráfico o indicador de

margem de contribuição, que indica o momento
do mês que a venda realizada cobre as
despesas do mês.
Funcionalidade F12-Gráfico de vendas dos últimos 12 meses.
Descrição Mostrar em forma de gráfico a evolução das

vendas nos últimos 12 meses, possibilitando
fazer comparativos.
Funcionalidade F13-Gráfico de vendas do mês corrente dia por

dia.
Descrição Mostrar em forma de gráfico a venda diária do

mês corrente possibilitando um
21
acompanhamento mais de perto.

1.3.6 Metodologia
A documentação dos resultados obtidos observou o proposto pelo
método iRON, Integração de Requisitos Orientados a Negócio, com foco no
levantamento dos requisitos de acordo com o negócio (CASTRO et al, 2014).
 Ferramentas utilizadas
Nome Uso
Astah Community - Diagrama de casos de uso
- Diagrama de classe
Excel - Cronograma
- Protótipo não funcional
Power Designer - Modelo conceitual de dados
- Modelo lógico de dados
- Diagrama de contexto
- Diagrama de Nível 0
- Organograma
Word - Textos
- Tabelas
1.3.7 Usuários do Sistema

O Dashboard será acessado pelo diretor comercial e diretor financeiro,
os dois são administradores do sistema.
1.3.8 Sistemas Similares

Como o ERP utilizado foi desenvolvido especificamente para a
empresa, não existem sistemas similares.
1.4 Plano de Projeto
1.4.1 Restrições Técnicas e Administrativas do Projeto

O Dashboard deverá ser compatível com os computadores atualmente
utilizados pelos diretores:
 Processador: Intel i5 ou superior.
 Sistema Operacional: Windows 10 ou superior.
22
1.4.2 Premissas do Projeto

Os dados devem ser acessados diretamente da base de dados
existente, mantida pelo ERP em uso pela empresa.
1.4.3 Cronograma do Projeto
Figura 4 - Cronograma
1.4.4 Análise de Riscos do Projeto
Evento de Risco Entendimento equivocado das funcionalidades.
Probabilidade Baixa.
Impacto Não atender às necessidades da empresa.
Monitoramento Validação das etapas junto com os responsáveis pela

empresa.
Tipo de Ação Mitigação
Descrição da Ação Validar cada necessidade se possível com um

protótipo não funcional.
Contingência Refazer a funcionalidade.

23
Evento de Risco Dificuldade com o layout final do Dashboard.
Impacto Não ficar de fácil entendimento ou poluído.
Monitoramento Validação das etapas junto com os responsáveis pela

empresa.
Descrição da Validar a disposição de cada funcionalidade

Ação juntamente com o cliente.
Contingência Redesenhar o Dashboard.
Evento de Risco Solicitação de alteração em funcionalidade pronta.
Probabilidade Média.
Impacto Atraso no projeto.
Monitoramento Acompanhar a especificação e validação dos

requisitos.
Descrição da Ajustar os prazos prevendo que isso possa acontecer.

Ação
Contingência Negociar com o cliente se a alteração poderá ficar

para versões futura.
Evento de Risco Dificuldade com as ferramentas usadas no

desenvolvimento do projeto.
Impacto Aumento do prazo acordado para a atividade

acarretando no atraso no projeto.
Monitoramento Acompanhar se as atividades estão dentro do

cronograma.
Tipo de Ação Eliminação.

24
Descrição da Capacitação da equipe nas ferramentas.

Ação
Contingência Usar ferramentas que são de domínio da equipe.

25
2 DOCUMENTO DE DEFINIÇÃO DE REQUISITO (DDR)

2.1 Requisitos
2.1.1 Requisitos Funcionais
Funcionalidade: F01-Metas.
Requisito Requisito Regra de
Identificador
Funcional de Dados Execução Prioridade
O Dashboard
deve fornecer RE01,
informações RE02, 1
RF01- RD01
agrupadas sobre RE13
as metas da
empresa.
Funcionalidade: F02-Gráfico de distribuição de recebimentos.

Identificador
O Dashboard
deve fornecer RE01,
RF02 RD02
consolidadas RE06,
sobre a carteira RE11
de recebimentos.
Funcionalidade: F03-Gráfico de indicador de prazo médio.

Identificador
O Dashboard
deve criar modo RE01,
de RE02, 1
RF03 RD03
acompanhament RE03,
o do indicador de RE12
prazo médio.
26
Funcionalidade: F04-Ranking de fornecedores.

Identificador
RE01,
O Dashboard
RE02,
deve criar
RE03, 1
RF04 ranking dos 10 RD04
RE04,
maiores
RE07
fornecedores.
Funcionalidade: F05-Ranking de grupo de produtos.

Identificador
RE01,
O Dashboard
RE02,
deve criar
RE03, 1
RF05 ranking dos 10 RD05
RE04,
maiores grupos
RE07
de produtos.
Funcionalidade: F06-Ranking de clientes.

Identificador
RE01,
O Dashboard
RE02, 1
deve criar
RF06 RD06 RE03,
ranking dos 10
RE04,
maiores clientes.
RE07
Funcionalidade: F07-Ranking de vendedores.

Identificador
RF07 O Dashboard RD07 RE01,
27
deve criar RE02, 1

ranking de RE03,
vendedores. RE05,
RE07
Funcionalidade: F08- Gráfico de distribuição por linha de produto.

Identificador
O Dashboard
deve fornecer RE01,
RF08 consolidadas da RD08 RE03,
distribuição das RE07
vendas por linha
de produtos.
Funcionalidade: F09-Gráfico de indicador de inadimplência.

Identificador
O Dashboard
de RE02, 1
RF09 RD09
acompanhament RE06,
o do indicador de RE09
inadimplência.
Funcionalidade: F10-Gráfico de indicador de cotações.

Identificador
O Dashboard RE01,
RF10 RD10
de RE03, 1
acompanhamento RE10
28
do indicador de
cotações.
Funcionalidade: F11-Gráfico de indicador de margem de contribuição.

Identificador
O Dashboard
de RE02,
RF11 acompanhamento RD11 RE03, 1
do indicador de RE08
margem de
contribuição.
Funcionalidade: F12-Gráfico de vendas dos últimos 12 meses.

Identificador
O Dashboard
criar modo de RE01,
RF12 comparativo das RD12 RE02,
vendas dos RE14 1
últimos 12 meses.
Funcionalidade: F13-Gráfico de vendas do mês dia a dia.

Identificador
O Dashboard
de RE02,
RF13 RD13
acompanhamento RE03, 1
das vendas do RE15
mês corrente dia
29
a dia.
2.1.2 Requisitos de Dados

Funcionalidade: F01-Metas
Requisitos Funcional:
Identificador: RD01
RF01-
Nome O S L Descrição Exemplo Tipo

dt_referencia X Data de referência 05/05/2017 D
da meta (dia atual)
vl_venda_dia X Valor da venda até o 19.305,12 N
momento.
qt_dias_uteis X Quantidade de dias 4 N
uteis até o momento.
qt_dias_uteis_restam X Quantidade de dias 18 N
uteis que restam no
mês.
qt_dias_uteis_mes X Quantidade de dias 22 N
uteis no mês.
vl_venda_mes X Valor da venda 65.271,32 N
desde o início do
mês.
vl_venda_media_diaria X Valor da venda 16.317,83 N
média diária no mês.
vl_venda_mes_proj X Valor projetado da 358.992,26 N
venda mensal com
base na média.
vl_ticket_medio X Valor do ticket 230,95 N
médio.
vl_ticket_medio_ano_a X Valor o ticket médio 222,16 N
nt desse mês no ano
30
Identificador: RD01
RF01-

anterior.
qt_dias_uteis_mes_ant X Quantidade de dias 21 N
uteis no mês
anterior.
vl_venda_mes_ano_a X Valor da venda 197.455,00 N
nt mensal desse mês
no ano anterior.
vl_venda_media_diaria X Valor da venda 9.402,61 N
_ano_ant média diária do mês
no ano anterior.
pc_diferenca X Percentual de 73,55% N
diferença entre o
mês atual e o do ano
anterior.
vl_meta X Valor da meta da 330.972,19 N
empresa para o
mês.
pc_acrescimo_meta X Percentual de 1,5% N
acréscimo em
relação ao mês
anterior.
vl_meta_diaria_original X Valor da meta diária 15.044,19 N
original.
pc_diferenca_meta_di X Percentual de 108,47% N
aria diferença entre o
valor da meta diária
original e o valor da
média efetiva.
vl_venda_media_bater X Valor da venda 14.761,16 N
31
Identificador: RD01
RF01-

_meta média diária para
cumprimento da
meta.
vl_diferenca_media_b X Diferença entre o -1.556,67 N
ater valor da venda
média para
cumprimento da
meta e o valor médio
efetivo.
pc_diferenca_media_b X Percentual de 110,55% N
ater diferença entre o
valor da venda
média para
cumprimento da
meta e o valor médio
efetivo.
dthr_emissao X Data e hora de 04/05/2017 DH
emissão da venda. 11:35:03
vl_venda_total X Valor total da venda 345,67 N
dt_feriado X Feriados. 25/12/2016 D
nu_mes X Mês de referência 5 N
da meta.
nu_ano X Ano de referência da 2017 N
meta
Funcionalidade: F02-Gráfico de distribuição de recebimentos.

Identificador: RD02
RF02
32

ds_faixa X Descrição da faixa 16 a 30 dias C
de inadimplência
qt_dias_prazo_inicial X Quantidade de dias 16 N
a contar para o
prazo inicial da faixa.
qt_dias_prazo_final X Quantidade de dias 30 N
a contar para o
prazo final.
vl_aberto X Valor em aberto. 5.720,91 N
(não liquidado)
dt_vencimento X Data de vencimento 28/03/2017 D
da parcela a receber.
vl_conta_receber X Valor da parcela a 345,67 N
receber.
dt_pagamento X Data de pagamento 25/04/2017 D
da parcela.
Funcionalidade: F03-Gráfico de indicador de prazo médio.

Identificador: RD03
RF03

qt_dias_prazo_medio X Quantidade de dias 45 N
de prazo médio.
sq_venda X Número sequencial 35432 N
da venda. (ID)
33
Identificador: RD03
RF03

receber.
Funcionalidade: F04-Ranking de fornecedores.

Identificador: RD04
RF04

nu_posicao_ranking X Número da posição 1 N
do fornecedor no
ranking.
no_fornecedor X Nome do fornecedor. SAO C
PAULO
INDUSTRI
AL
vl_vendido X Valor da vendido. 12,345,67 N
pc_representacao X Percentual em 11,68% N
relação a venda total.
da venda. (ID)
sq_fornecedor X Número sequencial 468 N
do fornecedor. (ID)
sq_produto X Número sequencial 2345 N
do produto. (ID)
vl_venda_unitario X Valor unitário de 345,67 N
venda do produto.
qt_venda X Quantidade vendida. 12 N
34
Funcionalidade: F05-Ranking de grupo de produtos.

Identificador: RD05
RF05

do grupo no ranking.
no_grupo X Nome do grupo de LAMPADA C
produtos.
vl_vendido X Valor vendido. 4.403.45 N
relação a venda total.
da venda. (ID)
sq_grupo X Número sequencial 67 N
do grupo. (ID)
do produto. (ID)
venda do produto.
Funcionalidade: F06-Ranking de clientes.

Identificador: RD06
RF06

35
Identificador: RD06
RF06

do cliente no ranking.
no_cliente X Nome do cliente. GUARA C
AUTO
PECAS
vl_vendido X Valor vendido. 11.742,54 N
relação à venda total.
sq_cliente X Número sequencial 654 N
do cliente. (ID)
Funcionalidade: F07-Ranking de vendedores.

Identificador: RD07
RF07

do vendedor no
ranking.
no_vendedor X Nome do vendedor. LUCIO C
vl_vendido X Valor vendido 12.345,67 N
relação à venda total.
sq_vendedor X Número sequencial 23 N
do vendedor. (ID)
36
Identificador: RD07
RF07

Funcionalidade: F08-Gráfico de distribuição por linha de produto.

Identificador: RD08
RF08

ds_linha_produto X Descrição da linha de ELETRICA C
produto.
vl_vendido X Valor vendido 12,345,67 N
pc_representacao X Percentual de 23,45% N
representação em
relação à venda total
da venda. (ID)
sq_linha X Número sequencial 5 N
da linha de produto.
(ID)
do produto. (ID)
venda do produto.
Funcionalidade: F09-Gráfico de indicador de inadimplência.

Identificador: RD09
RF09
37

pc_inadimplencia X Percentual da 1,63% N
inadimplência
receber.
dt_pagamento X Data de pagamento 25/04/2017 D
da parcela.
Funcionalidade: F10-Gráfico de indicador de cotações.

Identificador: RD10
RF10

pc_cotacao X Percentual de 9,2% N
representação da
venda por cotação.
in_cotacao X Indicador se a venda S C
foi feita através de
cotação.
Funcionalidade: F11-Gráfico de indicador de margem de contribuição.

Identificador: RD11
RF11

pc_margem_contribui X Percentual de margem 75,9% N
cao de contribuição.
38
Identificador: RD11
RF11

dt_vencimento X Data de vencimento da 15/03/2017 D
conta a pagar.
vl_conta_pagar X Valor da conta a 1234,56 N
pagar.
sq_conta X Número sequencial do 78 N
tipo de conta.
in_tipo_conta X Indicador de tipo de A C
conta.
vl_compra_total X Valor total da venda a 234,56 N
preço de compra de
mercadoria.
vl_impostos_total X Valor total dos 65,78 N
impostos
vl_comissao_total X Valor total da 6,78 N
comissão.
Funcionalidade: F12-Gráfico de vendas dos últimos 12 meses

Identificador: RD12
RF12

nu_mes X Mês de referência 3 N
nu_ano X Ano de referência 2017 N
vl_venda X Valor venda no mês de 123456,78 N
referência.
39
Identificador: RD12
RF12

Funcionalidade: F13-Gráfico de vendas do mês corrente dia por dia

Identificador: RD13
RF12

nu_dia X Dia de referência 5 N
vl_venda X Valor venda no mês de 123456,78 N
referência.
2.1.3 Regras de Execução
Requisito
Identificador Descrição Observação
Funcional
RF01, RF02,
RF03, RF04,
Os dados devem ser atualizados 10 RF05, RF06,
RE01 minutos após a última atualização de forma RF07, RF08,
automática. RF09, RF10,
RF11, RF12,
RF13
RF01, RF02,
RF03, RF04,
Os dados podem ser atualizados sob
RE02 RF05, RF06,
demanda.
RF07, RF08,
RF09, RF10,
40
RF11, RF12,
RF13
RF03, RF04,
RF05, RF06,
Levar em consideração as vendas do mês
RE03 RF07, RF08,
corrente.
RF10, RF11,
RF13
Mostrar apenas os 10 maiores. RF04, RF05,
RE04
RF06
Mostrar todos os vendedores, inclusive se
RE05 RF07
não tiverem realizados vendas.
Considerar as contas a receber dos últimos
RE06 RF02, RF09
365 dias.
Para calcular o percentual aplicar a
fórmula:
P = (VV / VTP) * 100
Onde:
P – Percentual
VV – Valor Vendido (venda.vl_venda_total).
VTP – Venda Total do Período, totalizar a
venda do período, não apenas das linhas RF04, RF05,
RE07 que estão sendo mostradas RF06, RF07,
(venda.vl_venda_total). RF08
Exemplo:
VV = 14.678,17
VT P = 100.548,85
Aplicando a fórmula:
P = (14.678,17 / 100.548,85) * 100

P = 14,60%
Para calcular o indicador de margem de
contribuição aplicar a fórmula:
RE08 RF11
MC = (VMLB / VTD) / 100

41
Onde:
MC – Margem de Contribuição.
VMLB – Valor da Margem de Lucro Bruta.
VTD – Valor Total das Despesas.
(conta_pagar.vl_conta_pagar), considerar
apenas as contas a pagar do mês que
sejam despesas (tipo_conta.n_tipo_conta =
‘D’).
VMLB = (VTP – VTI – VTC – VTVPC)

VTP – Venda Total Período
(venda.vl_venda_total).
VTI – Valor Total dos Impostos
(venda.vl_total_impostos).
VTC – Valor Total das Comissões
(venda.vl_total_comissao).
VTVPC – Valor Total da Venda a Preço de
Compra (venda.vl_compra_total).
Exemplo:
VMLB = 41.696.26
VTF = 54.935,78
MC = (41.696,26 / 54.935,78) * 100

MC = 75,9%
Para calcular o indicador de inadimplência
aplicar a formula:
II = (VCRA / VTCR) * 100
RE09 RF09
Onde:
II – Indicador de Inadimplência
VCRA – Valor Contas Receber
(conta_receber.vl_conta_receber) em
42
Aberto (conta_receber.dt_pagamento) no
período de 365 dias.
VTCR – Valor Total Contas a Receber no
período de 365 dias
(conta_receber.vl_conta_receber).
Exemplo:
VCRA = 36.636,06
VTCR = 2.247.611,30
II = (36.636,06 / 2.247.611,30) * 100

II = 1,63%
Para calcular o indicador de cotação aplicar
a fórmula:
IC = (VVC / VTP) * 100
Onde:
IC – Indicador de Cotação.
VVC – Valor Venda Cotação
(venda.vl_venda_total e venda.in_cotacao
= ‘S’)
RE10 VTP – Venda Total Período RF10
(venda.vl_venda_total).
Exemplo:
VVC = 9.250,49
VTP = 100.548,85
IC = (9.250,49 / 100.548,85) * 100

IC = 9,2%
Distribuir os recebimentos em aberto nas
RE11 RF02
seguintes faixas:
43
Pendentes (não vencidos)

Até 15 dias de vencido
De 16 a 30 dias de vencido
Acima de 120 dias de vencido
Para calcular o indicador de prazo médio

aplicar a fórmula:
IPM = SOMA(DTV-DTE*VCR) / VTCR
Onde:
DTV – Data de Vencimento

DTE – Data de Emissão
VCR – Valor do Contas a Receber
RE12 VTCR – Valor Total do Contas a Receber RF03
Exemplo:
SOMA(DTV-DTE*VCR) = 2.004.618,42
VTRC = 44.646,29
IPM = 2.004.618,42 / 44.646,29

IPM = 45 (Arredondar para cima)
Para calcular as metas aplicar as fórmulas
abaixo:
Média Diária:
RE13 VMD = VTP / DU RF01
Onde:
VMD – Valor Médio Diário

VTP – Venda Total no Período
44
DU – Dias Úteis
Exemplo:
VTP = 65.271,32
DU = 4
VMD = 65.271,32 / 4
VMD = 16.317,83
Projeção para o mês:
VPM = VMD * DUM
Onde:
VPM – Venda Projetada para Mês

VMD – Venda Média Diária
DUM – Dias Úteis no Mês
Exemplo:
VMD = 16.317,83
DUM = 22
VPM = 16.317,83 * 22
VPM = 358.992,26
Ticket Médio:
VTM = VTP / QV
Onde:
VTM – Valor Ticket Médio

QV – Quantidade de Vendas
45
Exemplo:
VTP = 65.271,32
QV = 283
VTM = 65.271,32 / 283

VTM = 230,64
Diferença entre ano corrente e anterior:
PDAA = ((VMD / VMDAA) – 1) * 100
Onde:
PDAA – Percentual de diferença para o ano

anterior (mesmo mês)
VMDAA – Valor Médio Diário Ano Anterior
(mesmo mês)
Exemplo:
VMD = 16.317,83
VMDAA = 9.402,62
PDAA = ((16.317,83 / 9.402,62) - 1) * 100
Meta da empresa:
Buscar no arquivo de metas o valor

correspondente ao mês e ano de
referência.
Percentual de acréscimo:
PAM = ((VM / VMMA) - 1) * 100

46
Onde:
PAM – Percentual de Acréscimo da Meta

VM – Valor da Meta
VMMA – Valor da Meta do Mês Anterior
Exemplo:
VM = 330.972,19
VMMA = 326.080,97
PAM = ((330.972,19 / 326.080,97) -1) * 100

PAM = 1,50%
Meta diária:
VMMD = VM / DUM
Onde:
VMMD – Valor Médio da Meta Diária

DUM – Dias Úteis no Mês
Exemplo:
VM = 330.972,19
DUM = 22
VMMD = 330.972,19 / 22
VMMD = 15.044,19
Percentual da meta diária:
PMD = (VMD / VMMD) * 100

47
Onde:
PMD – Percentual da Meta Diária

VMMD – Valor Médio da Meta Diária
Exemplo:
VMD = 16.317,83
VMMD = 15.044,19
PMD = (16.317,83 / 15.044,19) * 100

PMD = 108,47%
Valor médio para bater meta:
VMBM = (VM – VTP) / DUR
Onde:
VMBM – Valor Médio Bater Meta

DUR – Dias Úteis Restantes
Exemplo:
VM = 330.972,19
VTP = 65.271,32
DUR = 18
VMBM = (330.972,19 - 65.271,32) / 18

VMBM = 14,761,16
Diferença para média atual:
DMA = VMD – VMBM

48
Onde:
DMA = Diferença Média Atual

Exemplo:
VMD = 16.317,83
VMBM = 14,761,16
DMA = 16.317,83 - 14,761,16

DMA = 1.556,67
Percentual atingido:
PA = (VMD / VMBM) * 100
Onde:
PA – Percentual Atingido
Exemplo:
VMBM = 14,761,16
VMD = 16.317,83
PA = (16.317,83 / 14,761,16) * 100

PA = 110,55%
Vendas do início do mês subsequente ao
RE14 RF12
atual no ano anterior até o momento.
RE15 Vendas do início do mês até o momento. RF13
2.1.4 Mensagens
49
Requisito
Funcional
RF01
RF02
RF03
RF04
RF05
RF06
MSG01 Erro na atualização dos dados. RF07
RF08
RF09
RF10
RF11
RF12
RF13
2.1.5 Requisitos Não Funcionais

Requisito
Funcional
RF01
RF02
RF03
RF04
RF05
RF06
O tempo de atualização dos dados não
RNF01- RF07
deverá ultrapassar 20 segundos.
RF08
RF09
RF10
RF11
RF12
RF13
2.1.6 Lista de Perfis

Perfil Área
Administrador Acesso integral às informações do Dashboard.
50
2.1.7 Quadro de Permissões
Perfil Requisito Funcional Permissão
F01-Metas.
X
F02-Gráfico de distribuição de
recebimentos.
X
F03-Gráfico de indicador de prazo
médio.
X
F04-Ranking de fornecedores.
X
F05-Ranking de grupo de produtos.
X
F06-Ranking de clientes.
X
F07-Ranking de vendedores.
X
F08- Gráfico de distribuição por
Administrador
linha de produto.
X
F09-Gráfico de indicador de
inadimplência.
X
cotações.
X
margem de contribuição.
X
F12-Gráfico das vendas dos últimos
12 meses.
X
F13-Gráfico da venda diária do mês.
X
51
2.2 Rastreabilidade
2.2.1 Objetivos Específicos X Funcionalidades
F F F F F F F F F F F F F
Objetivo Específico 0 0 0 0 0 0 0 0 0 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3
Fornecer informações agrupadas sobre as metas da empresa. X
Fornecer informações consolidadas sobre a carteira de recebimentos. X
Criar modo de acompanhamento do indicador de prazo médio. X
Criar ranking dos 10 maiores fornecedores. X
Criar ranking dos 10 maiores grupos de produtos. X
Criar ranking dos 10 maiores clientes. X
Criar ranking de vendedores. X
Fornecer informações consolidadas da distribuição das vendas por linha de
X
produtos.
Criar modo de acompanhamento do indicador de inadimplência. X
Criar modo de acompanhamento do indicador de cotações. X
Criar modo de acompanhamento do indicador de margem de contribuição. X
Criar modo de comparativo das vendas dos últimos 12 meses. X
Criar modo de acompanhamento das vendas do mês corrente dia a dia. X
52
2.2.2 Funcionalidades X Requisitos Funcionais

R R R R R R R R R R R R R
F F F F F F F F F F F F F
Funcionalidade
0 0 0 0 0 0 0 0 0 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3
F01-Metas. X
F02-Gráfico de distribuição de recebimentos. X
F03-Gráfico de indicador de prazo médio. X
F04-Ranking de fornecedores. X
F05-Ranking de grupo de produtos. X
F06-Ranking de clientes. X
F07-Ranking de vendedores. X
F08-Gráfico de distribuição por linha de produto. X
F09-Gráfico de indicador de inadimplência. X
F10-Gráfico de indicador de cotações. X
F11-Gráfico de indicador de margem de contribuição. X
F12-Gráfico de vendas dos últimos 12 meses. X
F13-Gráfico de vendas do mês corrente dia por dia. X
53
2.2.3 Requisitos Funcionais X Requisitos de Dados

54
R R R R R R R R R R R R R
D D D D D D D D D D D D D
Requisito Funcional
0 0 0 0 0 0 0 0 0 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3
RF01-O Dashboard deve fornecer informações agrupadas sobre as metas da empresa. X
RF02-O Dashboard deve fornecer informações consolidadas sobre a carteira de
recebimentos.
X
RF03-O Dashboard deve criar modo de acompanhamento do indicador de prazo médio. X

RF04-O Dashboard deve criar ranking dos 10 maiores fornecedores. X
RF05-O Dashboard deve criar ranking dos 10 maiores grupos de produtos. X
RF06-O Dashboard deve criar ranking dos 10 maiores clientes. X
RF07-O Dashboard deve criar ranking de vendedores. X
RF08-O Dashboard deve fornecer informações consolidadas da distribuição das vendas
por linha de produtos.
X
RF09-O Dashboard deve criar modo de acompanhamento do indicador de

inadimplência.
X
RF10-O Dashboard deve criar modo de acompanhamento do indicador de cotações. X

RF11-O Dashboard deve criar modo de acompanhamento do indicador de margem de
contribuição.
X
RF12-O Dashboard criar modo de comparativo das vendas dos últimos 12 meses. X
RF13-O Dashboard deve criar modo de acompanhamento das vendas do mês corrente X
dia a dia.
2.2.4 Requisitos Funcionais X Regras de Execução
55
R R R R R R R R R R R R R R R
E E E E E E E E E E E E E E E
Requisito Funcional
0 0 0 0 0 0 0 0 0 1 1 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
RF01-O Dashboard deve fornecer informações agrupadas sobre as metas da empresa. X X X
RF02-O Dashboard deve fornecer informações consolidadas sobre a carteira de recebimentos. X X X X
RF03-O Dashboard deve criar modo de acompanhamento do indicador de prazo médio. X X X X
RF04-O Dashboard deve criar ranking dos 10 maiores fornecedores. X X X X X
RF05-O Dashboard deve criar ranking dos 10 maiores grupos de produtos. X X X X X
RF06-O Dashboard deve criar ranking dos 10 maiores clientes. X X X X X
RF07-O Dashboard deve criar ranking de vendedores. X X X X X
RF08-O Dashboard deve fornecer informações consolidadas da distribuição das vendas por linha de X
X X X
produtos.
RF09-O Dashboard deve criar modo de acompanhamento do indicador de inadimplência. X X X X
RF10-O Dashboard deve criar modo de acompanhamento do indicador de cotações. X X X X
RF11-O Dashboard deve criar modo de acompanhamento do indicador de margem de contribuição. X X X X
RF12-O Dashboard criar modo de comparativo das vendas dos últimos 12 meses. X X X
RF13-O Dashboard deve criar modo de acompanhamento das vendas do mês corrente dia a dia. X X X
X
56
2.2.5 Requisitos Funcionais X Mensagens
Requisito Funcional MSG01
RF01-O Dashboard deve fornecer informações agrupadas sobre as metas da empresa. X

RF02-O Dashboard deve fornecer informações consolidadas sobre a carteira de recebimentos. X
RF03-O Dashboard deve criar modo de acompanhamento do indicador de prazo médio. X
RF04-O Dashboard deve criar ranking dos 10 maiores fornecedores. X
RF05-O Dashboard deve criar ranking dos 10 maiores grupos de produtos. X
RF06-O Dashboard deve criar ranking dos 10 maiores clientes. X
RF07-O Dashboard deve criar ranking de vendedores. X
RF08-O Dashboard deve fornecer informações consolidadas da distribuição das vendas por linha de
X
produtos.
RF09-O Dashboard deve criar modo de acompanhamento do indicador de inadimplência. X
RF10-O Dashboard deve criar modo de acompanhamento do indicador de cotações. X
RF11-O Dashboard deve criar modo de acompanhamento do indicador de margem de contribuição. X
RF12-O Dashboard criar modo de comparativo das vendas dos últimos 12 meses. X
RF13-O Dashboard deve criar modo de acompanhamento das vendas do mês corrente dia a dia. X
57
2.3 Protótipo Não Funcional
Figura 5 – Protótipo não funcional

58
3 GERENCIA DE REQUISITOS E MODELOS

3.1 Modelagem dos Requisitos
3.1.1 Modelagem Estruturada:
 Diagrama de Contexto
Figura 6 – Diagrama de Contexto

59
 Diagrama de Nível 0
Figura 7 – Diagrama de Nível 0

60
3.1.2 Modelagem Orientada a Objetos

 Diagrama de Casos de Uso
Figura 8 – Diagrama de Casos de Uso

61
 Especificação dos Casos de Uso

Número do Caso de Uso UC11 – Gerar Gráfico de Indicador de Margem de
Contribuição.
Descrição Este caso de uso possibilita o diretor acompanhar
se a margem de lucro bruto já supera as
despesas do mês.
Ator(es) Diretor
Pré-Condições Não há
Pós-Condições Não há
Fluxo Principal
Ações do ator Resposta(s) do Sistema
1 – O diretor acessa o
dashboard.
2 – O dashboard inicia o processo de
atualização dos dados.
3 – Totalizar os valores de todas as contas a
pagar no mês que possuem o campo
tipo_conta.in_tipo_conta = ‘D’ (Despesas)
4 – Totalizar a margem de lucro bruta das
vendas no mês.
5 – Dividir a margem de lucro bruta pelo total
das despesas e multiplicar por 100 para
encontrar o indicador de margem de
contribuição.
6 – O diretor analisa os
dados para tomar
decisões.
Fluxos Alternativos
Não há.
Fluxos de Exceção
MSG1 - Erro na atualização dos dados.
Regras de execução
RE01 – Os dados devem ser atualizados 10 minutos após a última atualização
62
de forma automática.
RE02 – Os dados podem ser atualizados sob demanda.
RE03 – Levar em consideração as vendas do mês corrente.
RE08 – Para calcular o indicador de margem de contribuição aplicar a fórmula:
MC = (VMLB / VTD) / 100
Onde:
MC – Margem de Contribuição.
VMLB – Valor da Margem de Lucro Bruta.
VTD – Valor Total das Despesas. (conta_pagar.vl_conta_pagar), considerar
apenas as contas a pagar do mês que sejam despesas
(tipo_conta.n_tipo_conta = ‘D’).
VMLB = (VTP – VTI – VTC – VTVPC)

VTP – Venda Total Período (venda.vl_venda_total).
VTI – Valor Total dos Impostos (venda.vl_total_impostos).
VTC – Valor Total das Comissões (venda.vl_total_comissao).
VTVPC – Valor Total da Venda a Preço de Compra (venda.vl_compra_total).
Exemplo:
VMLB = 41.696.26
VTF = 54.935,78
MC = (41.696,26 / 54.935,78) * 100

MC = 75,9%
63
3.2 Modelagem de Dados

3.2.1 Diagrama de Classes
Figura 9 – Diagrama de Classes

64
3.2.2 Modelo de Entidades e Relacionamentos (MER)
 Modelo Conceitual
Figura 10 – Modelo de Dados Conceitual

65
 Modelo Lógico
Figura 11 – Modelo de Dados Lógico

66
3.3 Métricas e Estimativas
Segundo PFLEEGER, 2004, medição é um processo de atribuir

números e símbolos a entidades do mundo real, a fim de caracterizá-la por
meio de regras claramente definidas. Já PRESSMAN, 2002, diz que medida é
uma indicação quantitativa de extensão, dimensão, capacidade ou tamanho
de algum atributo de um produto ou processo, métrica é uma medida
quantitativa do grau em que um sistema, componente ou processo possui
determinado atributo.
A medição a seguir leva em consideração a APF, Análise por Ponto de
Função, segundo o IFPUG - International Function Point User Group, que
estabeleceu as regras básicas desta métrica funcional, o tamanho de um
software é estabelecido a partir das funcionalidades definidas pelo usuário, e
independente de aspectos de implementação tecnológica. Portanto, está
técnica é basicamente fazer a contagem do software a partir dos seus
requisitos.
3.3.1 Contagem das Funções de Dados

Todos os dados que servem de base para o dashboard são mantidos
pelo ERP utilizado pela empresa.
Nome Tipo DER RLR Complexidade PF

Linha_Produto AIE 2 1 Baixa 5
Grupo AIE 2 1 Baixa 5
Produto AIE 10 1 Baixa 5
Fornecedor AIE 2 1 Baixa 5
Venda AIE 17 2 Baixa 5
Vendedor AIE 2 1 Baixa 5
Cliente AIE 3 1 Baixa 5
Conta_Receber / Conta_Pagar AIE 8 1 Baixa 5
Tipo_Conta AIE 2 1 Baixa 5
Meta AIE 3 1 Baixa 5
Feriado AIE 1 1 Baixa 5
Total 55
67
68
3.3.2 Contagem das Funções de Transação

Transação Tipo ALR DER Complexidade PF
F01-Metas SE 3 20 Alta 7
F02- Gráfico de distribuição de SE 1 2 Baixa 4
recebimentos
F03-Gráfico de indicador de prazo médio SE 2 1 Baixa 4
F04-Ranking de fornecedores SE 2 4 Baixa 4
F05-Ranking de grupo de produtos SE 3 4 Baixa 4
F06-Ranking de clientes SE 2 4 Baixa 4
F07-Ranking de vendedores SE 2 4 Baixa 4
F08-Gráfico de distribuição por linha de SE 3 2 Baixa 4
produto
F09-Gráfico de indicador de inadimplência SE 1 1 Baixa 4
F10-Gráfico de indicador de cotações SE 1 1 Baixa 4
F11-Gráfico de indicador de margem de SE 2 1 Baixa 4
contribuição
F12-Gráfico de vendas dos últimos 12 SE 1 2 Baixa 4
meses
F13-Gráfico de vendas do mês corrente SE 1 2 Baixa 4
dia por dia
Total 55
3.3.3 Cálculo do Fator de Ajuste

Características Gerais do Sistema NI
01 – Comunicação de Dados 4
02 – Funções Distribuídas 5
03 – Performance 4
04 – Configuração do Equipamento 2
05 – Volume de Transações 5
06 – Entrada de Dados On-line 0
07 – Interface com o Usuário 3
08 – Atualização On-line 0
09 – Processamento Complexo 3
10 – Reusabilidade 0
11 – Facilidade de Implantação 1
12 – Facilidade Operacional 5
13 – Múltiplos Locais 3
14 – Facilidade de Mudanças 2
69
Total dos Níveis de Influência 37

Fator de Ajuste (37 * 0,01) + 0,65
Valor do Fator de Ajuste (VAF) 1,02
Valor da Soma das Funções 110
Valor Final 112,2
3.3.4 Estimativa de tempo e custo do Projeto

Considerando um média de produtividade de 10 horas por ponto de
função, o tempo estimado para o projeto é de 1.122 horas. Cada ponto de
função possui o valor de R$ 600,00 (seiscentos reais), o valor total estimado
para o projeto é de R$ 67.320,00 (sessenta e sete mil, trezentos e vinte
reais).
O valor e a quantidade de horas por ponto de função tiveram como
base a ata da Polícia Federal para o contrato com a Stefanini em 2014.
3.4 Plano de Gerência dos Requisitos
3.4.1 Processo de gerenciamento de requisitos
O processo de desenvolvimento de software envolve várias atividades,

análise do negócio, definição dos requisitos, codificação, testes, implantação
e manutenção. Vários projetos são cancelados ou fracassam devido aos
problemas verificados durante a fase de requisitos. Em razão da volatilidade e
do surgimento de novos requisitos ao longo do processo, faz-se necessária
uma gerência eficaz dos requisitos, visando garantir que eles sejam claros,
consistentes, não ambíguos e ainda controlar suas mudanças e
rastreabilidades objetivando a qualidade de todo o processo. Esses controles
podem ser feitos através de um Plano de Gerenciamento de Requisitos
(PGR), que aplicará um enfoque sistemático para a elicitação, organização,
documentação e qualidade dos requisitos do sistema, utilizando um processo
que permitirá estabelecer e manter um acordo entre usuários e equipe do
projeto à medida que os requisitos se modificam.
CASTRO et al (2014), diz que um plano de gerência de requisitos tem
como objetivo apresentar como os requisitos serão documentados,
analisados e gerenciados do início ao fim do projeto. Esse plano é elaborado
no início do projeto e norteia todo o processo de requisitos. Identifica o
70
processo de construção de requisitos e o processo a ser seguido em caso de

solicitação de mudanças. Também apresenta como será feita a gerência de
configuração dos requisitos, a rastreabilidade e quais os indicadores de
qualidade serão utilizados para verificar a qualidade dos requisitos.
A figura abaixo mostra como está dividido o Plano de Gerenciamento
de Requisitos:
Figura 12 – Dimensões do Plano de Gerenciamento de Requisitos – Método iRON

Fonte: CASTRO et al (2014)
Para administrar requisitos, é importante definir o processo que será

adotado para gerenciar os requisitos na organização. Definir como os
requisitos serão considerados (funcionais, não funcionais, regras de
execução, complementares, etc.), como eles serão descritos e quais os
artefatos serão utilizados para isso. Definir como os requisitos devem ser
nomeados, marcados e numerados.
 Definições, acrônomos e abreviações:
MSG Mensagens
RD Requisitos de Dados
RE Regras de Execução
RF Requisitos Funcionais
RNF Requisitos Não Funcionais
O gerenciamento de mudanças dos requisitos controla as solicitações

de mudança do cliente. Os requisitos evoluem com o tempo, seja por erros
detectados, seja pela evolução do conhecimento. O gerenciamento das
71
mudanças dos requisitos é necessário para que se possa controlar as

mudanças, refletir as alterações no sistema e nos objetivos de negócios e da
organização, para isso é importante definir os itens de configuração que são
eles:
 DAN
 DDR
 DER
 Modelo de Dados
 Diagramas (Caso de Uso, Classes, Contexto)
 Matriz de Rastreabilidade
Figura 13 – Processo de gerenciamento de mudanças de requisitos – Método iRON

Fonte: CASTRO et al (2014)
Sobre o gerenciamento de rastreabilidade dos requisitos, CASTRO et

al (2014) diz que consiste na identificação de relações entre as fontes dos
requisitos, entre os requisitos propriamente ditos e entre requisitos e os outros
produtos (artefatos) da Engenharia de Software. Podem abranger também
documentos da organização, padrões a serem seguidos, legislação etc.
O gerenciamento de qualidade dos requisitos é um processo
sistemático que abrange todas as etapas e artefatos produzidos e tem o
objetivo de garantir a conformidade de processos e produtos, prevenindo e
eliminando defeitos.
72
O gerenciamento de requisitos por si só não garante o sucesso de um

projeto, porém as chances aumentam em razão de um maior controle que
visa garantir a qualidade do processo como um todo.
3.4.2 Indicadores de qualidade

Medições devem ser realizadas e usadas para determinar a situação
das atividades de gerência dos requisitos, para realizar essa tarefa alguns
indicadores de qualidade devem ser mantidos, SCHWINDT (2009), sugere
alguns indicadores:
Indicadores
Categoria
Dimensão
Entender Controlar Aprimorar
PAR - Produtividade IVP - Índice de Variação
nas Atividades de de Produtividade =
PVE - Percentual de
Requisitos = (Percentual do esforço
Variação do Esforço =
(Somatório de horas gasto em atividades de
Tempo (Esforço realizado até o
despendidas em requisitos por ponto de
momento / Esforço
atividades de função) / (média
estimado) * 100
requisitos) / (Tamanho histórica de esforço por
do software) ponto de função) * 100
CAR - Custos da IVC - Índice de Variação

PVC - Percentual de
Atividades de dos Custos =
Variação dos Custos =
Requisitos = (Percentual dos custos
(Somatório dos custos
Custo (Somatório dos erros de requisitos por ponto
até o presente momento
identificados em de função / (média
/ Custos estimados) *
requisitos) / (Tamanho histórica dos custos por
100
do software) ponto de função) * 100
IVQ - Índice de Variação

QDR - Quantidade de PRR - Percentual de de Qualidade =
Defeitos em Requisitos Requisitos Rejeitados = [(Porcentagem de
= (Somatório dos erros (Percentual de requisitos requisitos rejeitados) /
Qualidade
identificados em rejeitados / Percentual (Porcentagem histórica
requisitos) / (Tamanho estimado de rejeição) * de requisitos rejeitados
do software) 100 por ponto de função)] *
100
73
CTD - Custo Total de

Defeitos em Requisitos
= (Somatório dos
custos de correção de
erros identificados em
requisitos / (Tamanho
do software)
QRI - Quantidade de
Requisitos
Incorporados ao
escopo = (Quantidade
de Requisitos após o
fechamento da linha de
base) / (Quantidade de
requisitos ao final do
projeto) * 100
PPU - Percentual de
Participação do Usuário
= (Número de reuniões
que representantes dos PSN - Percentual de IVR - Índice de Variação
usuários participaram / Solicitações de Mudança de Risco =
número de reuniões = (Percentual de (Porcentagem de
Risco realizadas) * 100 solicitações de mudança requisitos concluídos na
de escopo / Percentual release / porcentagem
PVR - Percentual de estimado de alterações histórica de requisitos
Validação de no escopo) * 100 concluídos) * 100
Requisitos pelo cliente
= (Número de
requisitos validados /
Número total de
documentos de
requisitos) * 100
PAR - Percentual de
Alteração dos
Requisitos já
aprovados = (Número
de solicitações de
mudanças de requisitos
/ número total de
requisitos já aprovados)
* 100
PMT - Quantitativo de
Mudanças nos
74
Requisitos de acordo
com o Tamanho do
software = (Número de
requisitos alterados /
Tamanho do software)
* 100
75
3.4.3 Lista de Classificação de Defeitos
O processo de inspeção pode detectar inúmeros defeitos, por essa razão, é

importante classifica-los, padronizando o tratamento desses defeitos, CASTRO et al
(2014) cita alguns exemplos para essa classificação:
Defeito de Informações necessárias ao sistema são omitidas, como por

omissão exemplo: algum requisito importante relacionado à
funcionalidade, ao desempenho, às restrições do projeto, ao
atributo, ou à interface externa não foi incluído; não está definida
a resposta do software para todas as possíveis situações de
entrada de dados; faltam seções na especificação de requisitos.
Defeito de fato Há informações nos artefatos do sistema que são contraditórios
incorreto com o domínio da aplicação.
Defeito de A informação aparece mais de uma vez no artefato e de forma
inconsistência diferente em cada aparição causando incoerência.
Defeito de Um requisito tem várias interpretações devido a diferentes termos
ambiguidade utilizados para uma mesma característica.
Defeito de Uma informação que aparece no artefato e embora esteja
informação relacionada ao domínio, não é necessária para o sistema em
estranha questão.
Outros Tais como a inclusão de requisito em uma seção errada.
defeitos
Já BERTINI, (2006) sugere a classificação de defeitos conforme abaixo:
Classe Tipo Descrição

Alguma informação, relativa à descrição do
Funcionalidade
comportamento esperado do sistema, não
Omitida (FO)
aparece no documento.
Alguma informação, relativa à descrição da
Performance
performance desejada, não aparece no
Omissão Omitida (PO)
documento ou aparece de forma inaceitável
Alguma informação, relativa à descrição do
Ambiente Omitido hardware, do software, do banco de dados e
(AO) do pessoal envolvido, não aparece no
documento.
Interface Omitida Alguma informação, relativa à forma como o
76
(IO) sistema interagirá ou se comunicará com

componentes que está fora do escopo do
sistema, não aparece no documento.
Um termo importante, uma frase ou uma
sentença, essenciais para o entendimento do
Informação
sistema não foi definido no documento ou foi
Ambígua (IA)
definido de forma que possa causar
confusão.
Duas sentenças contradizem-se mutuamente
Informação
Comissão ou expressam ações de que não estão
Inconsistente (II)
corretas ou não podem ser executadas.
Alguma sentença expressa um fato que não
Funcionalidade
pode ser verdade de acordo com as
Incorreta (FI)
condições especificadas.
Alguma informação está em um lugar errado
Seção Incorreta (SI)
no documento.
Outros (O) Defeitos que não se enquadram nos tipos
acima.
3.4.4 Técnicas de inspeção

O processo de desenvolvimento de software produz vários artefatos
que servem de instrumento de entrada para novas etapas, erros cometidos
durante uma etapa podem causar muitos problemas nas etapas seguintes,
para diminuir a incidência desses erros, costuma-se aplicar técnicas de
inspeção que tem por objetivo encontrar erros. O principal objetivo da técnica
de inspeção é a descoberta antecipada de falhas (produção de uma saída
incorreta em relação à especificação), para garantir que as falhas não se
propaguem para o passo seguinte do processo de construção ou manutenção
software.
Sommerville (2011) cita que revisões e inspeções são atividades de
controle de qualidade que verificam a qualidade dos entregáveis de projeto.
Isso envolve examinar o software, sua documentação e os registros do
processo para descobrir erros e omissões e verificar se os padrões de
qualidade foram seguidos.
A figura 13 mostra a inspeção dos artefatos em cada etapa do ciclo de
vida do software.
77
Figura 14 – Ciclo de vida do software e inspeção
Existem várias técnicas de inspeção, baseadas em checklist,

perspectiva, cenários e ad-hoc. A técnica adotada ao longo do
desenvolvimento foi a de checklist, uma lista de verificação é entregue aos
inspetores para auxiliar na detecção de problemas, a seguir o modelo
adotado:
78
Figura 15 – Checklist de Inspeção

Fonte: Castro et al (2014)
O uso de técnicas de inspeção por si só não garante a qualidade dos

artefatos produzidos ao longo do projeto, porém as chances aumentam em
razão de um maior controle que visa garantir a qualidade do processo como
um todo.
79
CONCLUSÃO
O projeto permitiu compreender a real necessidade da empresa, foram

identificados os problemas do processo atual que serviu de base para propor uma
solução que identificou o objetivo geral e os objetivos específicos, possibilitando a
definir os requisitos do dashboard e suas funcionalidades. A empresa se mostrou
satisfeita com os resultados obtidos até o momento.
A utilização do método iRON foi um diferencial que facilitou na elaboração e

documentação nas etapas de produção de requisitos (elicitação, análise, definição e
validação) e na etapa de gerência dos requisitos (administração, gerência de
mudança, gerência de rastreabilidade e gerência de qualidade).
80
REFERÊNCIAS
BERTINI, Lilian Aparecida. Técnicas de inspeção aplicadas à avaliação de requisitos

de sistemas de software: um estudo comparativo. Dissertação. Programa de Pós-
graduação em Ciência da Computação. Faculdade de Ciências Exatas e da
Natureza, Universidade Metodista de Piracicaba, SP, 2006.
CASTRO, Eduardo; PALDÊS, Roberto; CALAZANS, Angélica; GUIMARÃES,

Fernando. Engenharia de Requisitos: Um enfoque prático na construção de software
orientado a negócio. 1 ed. Florianópolis: Bookess, 2014.
IFPUG – International Function Point Users Group. Manual de Práticas de Contagem

de Ponto de Função. Versão 4.3, 2010.
PFLEEGER, Shari L. Engenharia de Software – Teoria e Prática, 2ª. Edição, São

Paulo: Prentice Hall, 2004.
PRESSMAN, Roger S. Engenharia de Software – Uma abordagem profissional, 7ª.

Edição, São Paulo: Makron Books, 2011
SCHWINDT, Leonardo. "Abordagem para definição de requisitos em projetos de

software." (2009).
SOMMERVILLE, Ian. Engenharia de Software, 9. ed. São Paulo: Pearson do Brasil,

2011.

Levantamento de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Levantamento de Requisitos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Levantamento de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Centro Universitário de Brasília

Instituto CEUB de Pesquisa e Desenvolvimento - ICPD

ANDRÉ LUIZ DOS SANTOS BARBOSA

Projeto apresentado ao Centro Universitário

Orientadora: Professora Angelica Calazans

Trabalho apresentado ao Centro

Orientador: Professora Angelica Calazans

Brasília, 26 de Outubro de 2017.

Este projeto tem o objetivo de apresentar o desenvolvimento de um dashboard,

Palavras-chave: Dashboard; Gráfico; Ranking; Modelo; Diagrama.

This project has the purpose to show the development of a dashboard, a

Key words: Dashboard; Chart; Ranking; Model; Diagram.

Figura 1 – Organograma .......................................................................................10

Nesse contexto encontra-se a empresa Pecista Distribuição e Representação

O trabalho a seguir apresenta o desenvolvimento do dashboard usando

1 DOCUMENTO DE ANÁLIDE DO NEGÓCIO (DAN)

1.1 Análise Institucional – Visão Geral

1.2.1 Áreas envolvidas

1.2.2 Descrição do processo atual

1.2.3 Mapeamento do processo atual

Figura 2 – Processo atual

1.2.4 Identificação dos problemas

Grande problema Ineficiência do sistema atual de prover

Efeitos Os maiores fornecedores precisam ser

Efeitos Perda do controle de inadimplência acarretando em

Efeitos Perda do momento certo para promoções mais

1.3 Proposta de solução

1.3.1 Descrição do novo processo proposto

1.3.2 Mapeamento do novo processo proposto

Figura 3 – Processo proposto

1.3.3 Objetivo Geral

1.3.4 Objetivos Específicos

Objetivo Específico Fornecer informações agrupadas sobre as metas

Problema a resolver Dificuldade no acompanhamento das metas

Objetivo Específico Fornecer informações consolidadas sobre a

Problema a resolver Dificuldade em acompanhar a inadimplência.

Funcionalidade F02-Gráfico de distribuição de recebimentos.

Objetivo Específico Criar modo de acompanhamento do indicador

Problema a resolver Ineficiência no controle da média de prazos.

Funcionalidade F03-Gráfico de indicador de prazo médio.

Objetivo Específico Criar ranking dos 10 maiores fornecedores.

Problema a resolver Ineficiência no acompanhamento do ranking de

Funcionalidade F04-Ranking de fornecedores.

Objetivo Específico Criar ranking dos 10 maiores grupos de

Problema a resolver Ineficiência no acompanhamento do ranking de

Funcionalidade F05-Ranking de grupo de produtos.

Objetivo Específico Criar ranking dos 10 maiores clientes.

Problema a resolver Ineficiência no acompanhamento do ranking de

Funcionalidade F06-Ranking de clientes.

Objetivo Específico Criar ranking de vendedores.

Problema a resolver Ineficiência no controle da performance dos

Funcionalidade F07-Ranking de vendedores.

Objetivo Específico Fornecer informações consolidadas da

Problema a resolver Ineficiência no acompanhamento das linhas de

Funcionalidade F08-Gráfico de distribuição por linha de produto.

Objetivo Específico Criar modo de acompanhamento do indicador

Problema a resolver Dificuldade em verificar o indicador de

Funcionalidade F09-Gráfico de indicador de inadimplência.

Objetivo Específico Criar modo de acompanhamento do indicador