MaiSys: especificação do componente orçamento do subsistema venda

Prévia do material em texto

i 
 
RENATO DE TARSO SANTOS DA SILVA 
 
 
 
 
 
 
 
 
 
 
MaiSys: especificação do componente orçamento do 
subsistema venda 
 
 
 
 
 
 
 
 
Trabalho de Conclusão de Curso 
(Especialização), apresentado à Faculdade 
Impacta Tecnologia, como requisito para 
obtenção do título de Especialista em 
Engenharia de Software. Orientador: Prof. 
Me. Osvaldo Kotaro Takai. 
 
 
 
 
 
 
 
 
 
 
 
SÃO PAULO 
2016 
ii 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Silva, Renato de Tarso Santos da 
 
MaiSys: especificação do componente orçamento do subsistema venda / 
Renato de Tarso Santos da Silva - São Paulo, 2016. 
72 f. : il. : color. 
 
Trabalho de Conclusão de Curso (Especialização) - Faculdade Impacta 
Tecnologia, Curso de Engenharia de Software, 2016. 
Orientador: Prof. Me. Osvaldo Kotaro Takai. 
 
1. Modelagem. 2. Software. 3. Processos de Negócio. 
I. Takai, Osvaldo Kotaro (Orient.). II. Faculdade Impacta Tecnologia. III. 
Título. 
 
iii 
 
RENATO DE TARSO SANTOS DA SILVA 
 
 
 
 
 
 
 
 
MaiSys: especificação do componente orçamento do subsistema venda 
 
 
 
Trabalho de Conclusão de Curso (Especialização), 
apresentado à Faculdade Impacta Tecnologia, 
como requisito para obtenção do título de 
Especialista em Engenharia de Software. 
Orientador: Prof. Me. Osvaldo Kotaro Takai. 
 
 
 
Aprovado em 31 de Outubro de 2016. 
 
 
 
BANCA EXAMINADORA: 
 
 
____________________________________________________________ 
Prof. Me. Osvaldo Kotaro Takai - Orientador 
Faculdade Impacta Tecnologia 
 
____________________________________________________________ 
Prof.ª Dra. Ana Cristina dos Santos 
Faculdade Impacta Tecnologia 
 
____________________________________________________________ 
Prof. Me. Wélerson Robaina Kanup 
Faculdade Impacta Tecnologia 
iv 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Dedicado este trabalho à minha mãe, Sra. Tânia 
Araújo, que pôde me transmitir maciços valores 
de vida e é quem sempre apoiou e orientou 
minhas empreitadas, como a deste curso. 
 
v 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
À minha família pelo suporte indispensável e 
apoio incondicional. 
 
Aos amigos do grupo por terem sido incansáveis 
ao abraçar o projeto, seus problemas e seus 
desafios. E por compartilharmos conhecimento, 
experiências e entrega, tão cobradas neste 
trabalho. 
 
À empresa Mais Revestimentos por ter permitido 
a exploração de seu domínio de negócio e a 
prática de parte dos conceitos obtidos no curso. 
 
Muito Obrigado. 
 
vi 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 “O que somos é consequência do que 
pensamos. É capaz quem pensa que é capaz.” 
(Buda) 
 
vii 
 
RESUMO 
Este trabalho tem cunho acadêmico e o objetivo de contribuir para a obtenção do título 
de Especialista em Engenharia de Software. Seu conteúdo apresenta a especificação 
do subsistema de Vendas do sistema MaiSys, idealizado para a empresa Mais 
Revestimentos, principalmente de processos relacionados à criação de pedidos de 
venda a partir de orçamentos de clientes da empresa. A especificação foi construída 
aplicando conhecimentos que englobam a engenharia e a qualidade de projetos de 
software, as modelagens de arquitetura e de processos de negócio, e o levantamento 
de requisitos. O resultado obtido foi uma série de artefatos em documentos formais 
que viabilizarão o desenvolvimento do software que melhorará os processos 
cotidianos da empresa. Conclui-se que esta solução atende necessidades básicas de 
análises sistêmicas, agrega valor ao negócio e desperta o interesse da empresa na 
construção deste software. 
 
Palavra-Chave: Modelagem, Software, Processos de Negócio, Vendas. 
 
viii 
 
ABSTRACT 
This work has academic nature and aims to contribute to the achievement of the 
Specialist's degree in Software Engineering. Its content shows the sales subsystem 
specification of MaiSys system, idealized for Mais Revestimentos company, mainly 
processes related to sale orders creation from budgets of company’s customers. The 
specification was built applying knowledges which embraces the engineering and 
quality of software projects, architecture and business processes modeling, and 
requirements elicitation. The obtained result was a series of artifacts in formal 
documents that will enable the software’s development that will improve the company's 
daily business processes. It concludes that this solution meets systemic analysis basic 
needs, adds value to the business and arouses the company’s interest on this 
software’s construction. 
 
Keywords: Modeling, Software, Business Process, Sales. 
 
ix 
 
LISTA DE FIGURAS 
Figura 1-1 - Fases da Engenharia .............................................................................. 3 
Figura 2-1 - Questionário de Entrevista ...................................................................... 7 
Figura 2-2 - Diagrama de Ishikawa - Contexto da Empresa ..................................... 10 
Figura 2-3 - Diagrama de Ishikawa - Contexto do Consumidor ................................ 10 
Figura 2-4 - Fronteira Sistêmica ............................................................................... 13 
Figura 3-1 - Workshop de Características ................................................................ 16 
Figura 4-1 - Estrutura Organizacional ...................................................................... 23 
Figura 4-2 - DFD Converter Orçamento em Pedido ................................................. 28 
Figura 4-3 - Ciclo de Vida para o depósito de dados Pedido ................................... 30 
Figura 4-4 - Modelo Conceitual ................................................................................ 33 
Figura 5-1 - Fluxo de Evolução de Requisitos .......................................................... 34 
Figura 6-1 - Diagrama de Componentes (Components) .......................................... 44 
Figura 6-2 - Diagrama de Projeto (Architecture)....................................................... 45 
Figura 6-3 - Diagrama de Pacotes (Package) .......................................................... 46 
Figura 6-4 - Diagrama de Implantação (Deployment) .............................................. 47 
Figura 7-1 - Diagrama de Caso de Uso Converter Orçamento em Pedido .............. 50 
Figura 7-2 - Realização do Caso de Uso Converter Orçamento em Pedido ............ 51 
Figura 7-3 - Diagrama de Sequência - Pedido Cadastrado com Êxito ..................... 53 
Figura 7-4 - Diagrama de Sequência - Facade FVenda - Incluir Pedido .................. 54 
Figura 8-1 - Modelagens de Projeto de Software ..................................................... 57 
Figura 8-2 - Tela de Conversão de Orçamento em Pedido ...................................... 59 
Figura 8-3 - Projeto Orientado a Objetos ................................................................. 60 
Figura 8-4 - Diagrama Entidade-Relacionamento .................................................... 62 
Figura 8-5 - Diagrama de Projeto Lógico de Banco de Dados ................................. 63 
Figura 8-6 - Diagrama de Projeto Físico de Banco de Dados ..................................64 
Figura 8-7 - Notações de Cardinalidade de Relacionamento ................................... 64 
 
 
x 
 
LISTA DE TABELAS 
Tabela 2-1 - Declaração do Problema - Empresa ...................................................... 8 
Tabela 2-2 - Declaração do Problema - Cliente ......................................................... 9 
Tabela 2-3 - Lista de Stakeholders Usuários ........................................................... 11 
Tabela 2-4 - Lista de Outros Stakeholders ............................................................... 12 
Tabela 2-5 - Lista de Restrições .............................................................................. 14 
Tabela 3-1 - Lista de Características........................................................................ 16 
Tabela 3-2 - Lista de Características com Descrição ............................................... 17 
Tabela 3-3 - Lista de Características - Prioridade x Esforço x Risco........................ 20 
Tabela 3-4 - Baseline de Características ................................................................. 21 
Tabela 4-1 - Análise de Eventos .............................................................................. 26 
Tabela 4-2 - Descrição dos eventos ......................................................................... 27 
Tabela 4-3 - Detalhes dos Processos ...................................................................... 31 
Tabela 5-1 - Lista de Requisitos ............................................................................... 35 
Tabela 5-2 - Requisitos x Características ................................................................. 37 
Tabela 5-3 - Processos de Negócio x Requisitos de Sistema .................................. 38 
Tabela 6-1 - Requisito Não Funcional x Decisão Arquitetural (Premissa) ................ 40 
Tabela 6-2 - FlowDown de Requisitos...................................................................... 42 
Tabela 7-1 - Caso de Uso X Requisitos (SSS / SRS) .............................................. 55 
 
 
xi 
 
SUMÁRIO 
1 INTRODUÇÃO .................................................................................................... 1 
1.1 Objetivos ........................................................................................................... 1 
1.1.1 Objetivo Geral ............................................................................................. 1 
1.1.2 Objetivo Específico ..................................................................................... 2 
1.2 Justificativa ....................................................................................................... 2 
1.3 Metodologia ...................................................................................................... 3 
2 ANÁLISE DO PROBLEMA .................................................................................. 6 
2.1 Declaração do Problema................................................................................... 8 
2.2 Análises das Causas Raízes ............................................................................ 9 
2.3 Usuários e outros Stakeholders ...................................................................... 11 
2.4 Delimitação da Fronteira Sistêmica ................................................................ 12 
2.5 Restrições e Limitações .................................................................................. 13 
3 CARACTERÍSTICAS DA SOLUÇÃO ................................................................. 15 
3.1 Lista de Características................................................................................... 16 
3.2 Descrições das Características ....................................................................... 17 
3.3 Prioridade x Esforço x Risco ........................................................................... 19 
3.4 Definição de Baselines.................................................................................... 21 
4 MODELAGEM DE NEGÓCIOS ......................................................................... 23 
4.1 Lista de Eventos ............................................................................................. 25 
4.2 Descrições dos Eventos.................................................................................. 26 
4.3 DFD Essencial de Negócio ............................................................................. 27 
4.4 Detalhes dos Processos de Negócio .............................................................. 30 
4.5 Modelo Conceitual .......................................................................................... 32 
5 REQUISITOS DO SISTEMA ............................................................................. 34 
5.1 Detalhes dos Requisitos do Sistema............................................................... 35 
5.2 Requisitos do Sistema x Características ......................................................... 37 
5.3 Processos de Negócio x Requisitos ................................................................ 38 
6 ARQUITETURA DO SISTEMA .......................................................................... 40 
6.1 Subsistemas / COTS....................................................................................... 41 
6.2 Flowdown de Requisitos do Sistemas............................................................. 41 
6.3 Definição das Interfaces Internas .................................................................... 43 
6.4 Definição das Interfaces Externas .................................................................. 44 
xii 
 
6.5 Organização dos Pacotes ............................................................................... 46 
6.6 Modelo de Implantação ou Publicação ........................................................... 47 
7 MODELAGEM DE CASOS DE USO ................................................................. 49 
7.1 Diagrama de Casos de Uso ............................................................................ 49 
7.2 Realização do Caso de Uso ............................................................................ 51 
7.3 Casos de Uso x Requisitos (SSS/SRS) .......................................................... 54 
8 PROJETO DE SOFTWARE .............................................................................. 57 
8.1 Interface Homem-Máquina .............................................................................. 58 
8.2 Projeto Orientado a Objetos ............................................................................ 59 
8.3 Banco de Dados ............................................................................................. 61 
8.3.1 Diagrama Entidade Relacionamento (DER) ............................................. 61 
8.3.2 Projeto Lógico ........................................................................................... 62 
8.3.3 Projeto Físico ............................................................................................ 63 
9 CONSIDERAÇÕES FINAIS ............................................................................... 66 
REFERÊNCIAS ........................................................................................................ 67 
GLOSSÁRIO ............................................................................................................ 68 
APÊNDICE A - Storyboard da realização “Converter Orçamento em Pedido” ......... 70 
APÊNDICE B - Dicionário de Dados do Storyboard “Converter Orçamento em 
Pedido”. .................................................................................................................... 71 
APÊNDICE C - Artefatos - Enterprise Architect .......................................................72 
 
 
1 
 
1 INTRODUÇÃO 
A Mais Revestimentos é uma empresa que atua no ramo do comércio de 
produtos para projetos da área da construção civil. Tem sede no estado de São Paulo 
e filiais nas cidades de São Paulo (SP), Santo André (SP), Campinas (SP) e Rio de 
Janeiro (RJ). Além de ser especializada na venda de produtos de revestimentos, 
oferece produtos e soluções de decoração para projetos arquitetônicos. Atua neste 
mercado há aproximadamente vinte anos, possui faturamento médio mensal em torno 
de dois milhões de reais e já atendeu mais de vinte mil clientes. 
Com o crescimento na demanda comercial da empresa, problemas no controle 
dos processos de venda começaram a impactar na produtividade operacional do 
negócio. A diretoria percebeu a necessidade de um mecanismo de gerenciamento 
mais eficaz que possibilitasse a otimização de processos e apontamento de falhas. 
Observou-se, ainda, que era preciso garantir integridade e rastreabilidade das 
informações a fim de permitir geração de métricas e avaliação de desempenho. Este 
projeto tem o objetivo de apresentar os resultados de análises e especificações para 
uma possível solução que deve atender determinadas necessidades básicas da 
empresa. Os subsistemas de portfólio e de vendas foram elencados primordiais neste 
projeto, priorizando a operação comercial do negócio. 
1.1 Objetivos 
1.1.1 Objetivo Geral 
Durante as fases de análise e modelagem de negócio foram identificadas 
graves lacunas nos processos atuais da empresa. Um aspecto se destaca, tais 
lacunas foram encontradas apenas com a aplicação de conceitos aprendidos durante 
o curso, mesmo sem projetos nem equipes formalmente constituídos ou pré-existentes 
dentro da empresa. 
Em sua concepção, o sistema MaiSys visa integrar eficazmente processos do 
núcleo comercial da empresa, além de agilizar o acesso e a transmissão de 
informações entre os envolvidos. Os modelos elaborados compreendem tarefas 
realizadas no manejo de portfólio de produtos e serviços, na elaboração e controle de 
orçamentos e pedidos, e nas devoluções de venda. A solução deve contemplar o 
acompanhamento destes processos no negócio, com interações de atores e alertas, 
2 
 
conforme necessidades apresentadas pela empresa. Por fim, serão especificados os 
relatórios gerenciais e operacionais que permitirão apurar e consolidar as 
conformidades dos processos da empresa. 
O negócio da empresa contém processos de ordem administrativa, como 
financeiros e logísticos. Mas devido às questões de objetividade e de prazo, este 
trabalho sofreu redução de escopo e foca no fluxo operacional de vendas. 
1.1.2 Objetivo Específico 
O departamento de venda concentra as atenções da cúpula gestora deste 
negócio por ser a divisão da empresa que tem maior contato com os clientes, capta 
recursos para o negócio e traz retorno de investimentos. Atribuições de outros 
departamentos existem, em suma, para atender necessidades dos processos de 
venda. Vista sua relevância ao negócio e a variedade de atividades a serem 
analisadas, o núcleo de venda foi escolhido como ponto central para os estudos e 
especificações deste projeto. 
O objetivo específico desta monografia é analisar as atividades relacionadas à 
transformação de orçamentos em pedidos de venda, o que inicia procedimentos 
administrativos, financeiros e logísticos. Os resultados destas análises devem apoiar 
a especificação e o desenvolvimento de parte de uma solução de software que auxilie 
estas atividades da empresa. 
1.2 Justificativa 
Este trabalho é parte dos requisitos necessários para a obtenção do título de 
Especialista em Engenharia de Software pela Faculdade Impacta Tecnologia - FIT. 
Também atende à demanda prática exigida pelo curso de projetar e especificar um 
sistema, neste caso o MaiSys, com o intuito de aprimorar e automatizar processos da 
empresa. Esta solução sistêmica servirá como ferramenta no controle e no 
gerenciamento dos processos de negócio, colaboradores, parceiros e clientes da 
empresa. 
A oportunidade que os integrantes do grupo tiveram de vivenciar a construção 
de uma complexa especificação, por si só, justifica este trabalho. Destacou-se o 
anseio pela experiência em análise de cenários e suas evidências. Tais análises 
ensinaram que premissas consagradas na engenharia de software devem ser 
3 
 
necessariamente conhecidas e praticadas para se definir sistemas de software 
complexos, como o especificado neste trabalho. 
1.3 Metodologia 
As fases macro que dividem este projeto são: Planejamento do Projeto, Análise 
de Sistemas, Projeto de Sistemas, Análise de Software e Projeto de Software. Estes 
domínios de conhecimento são compostos por métodos que apoiam a engenharia 
aplicada na solução de software especificada neste trabalho. Logo, são as referências 
utilizadas para a construção dos artefatos que orientarão a implementação deste 
projeto. 
A figura 1-1 ilustra em um diagrama como se dispõe as fases, nele percebe-se 
quais são seus entregáveis e quais ferramentas auxiliaram na manutenção dos 
artefatos. 
 
Figura 1-1 - Fases da Engenharia 
Na fase de Planejamento do Projeto, estimaram-se o uso de recursos, além do 
tempo e do custo necessários para desenvolver cada artefato. Os resultados foram o 
ganho de previsibilidade e a redução de riscos no projeto, bem como manter os 
stakeholders atualizados acerca do andamento do projeto. 
4 
 
A fase de Análise de Sistemas permitiu levantar os problemas do cliente, as 
características da solução, além de processos e regras de negócio. Estas descobertas 
apoiaram estudos de viabilidade, elicitação, especificação e validação dos requisitos 
do sistema. 
Na fase de Projeto de Sistemas, foram analisadas interações entre atores e 
subsistemas. Nela, foram construídos os documentos que especificam a arquitetura, 
as interfaces, os componentes e as classes do sistema. 
A fase de Análise de Software permitiu compreender comportamentos 
existentes no sistema da empresa. Se descobrem os diálogos entre atores que 
inspiram a criação de casos de uso que apoiarão soluções a serem implementadas no 
software, de modo que atendam aos requisitos elicitados. Dela, resultaram 
documentos provenientes dos estudos das metas do negócio que são passíveis de 
virtualização. 
Por fim, na fase de Projeto de Software, são demonstradas as estruturas 
necessárias para se manter o software e suas propriedades. Nela, foram produzidos 
modelos dos dados a serem persistidos, da arquitetura do software e das interfaces 
humano-computador. 
Para auxiliar na materialização destas evidências, os integrantes do grupo se 
beneficiaram do uso de quatro ferramentas: 
 MS Project: usado para fazer planejamentos, permite acompanhar o 
cronograma e os custos do projeto; 
 Kanboard: Solução Web baseada no quadro de tarefas do método ágil 
KanBan, que trouxe ao projeto dinamismo e transparência na 
produtividade; 
 Google Drive: mantém um repositório colaborativo do grupo que 
armazena os artefatos deste projeto e suporta seu controle de versões; 
 Enterprise Architect: permitiu a construção dos artefatos, mantendo 
suas rastreabilidades com eficiência. Foi utilizada para criar modelos e 
diagramas. 
 
5 
 
Os artefatos de modelagem criados no Enterprise Architect e apresentados 
neste trabalho têm o objetivo de apoiar as explicações das técnicas utilizadas durante 
as análises, neste caso, voltadas para componentes de relacionados à Orçamentos e 
Pedidos do Subsistema Venda. Artefatos de outros componentes e subsistemas da 
solução encontram-se no Apêndice D. 
No decorrer dos próximos capítulos são apresentadas as abordagens dasfases 
da engenharia e os artefatos que propõem melhor compreensão das análises 
realizadas, iniciando pela apreciação dos problemas evidenciados na empresa. 
6 
 
2 ANÁLISE DO PROBLEMA 
A análise do problema tem como objetivo assimilar a necessidade do cliente e 
quais problemas ele espera que a solução de software ajude a resolver. 
Consequentemente, se lança uma questão de alta relevância: “a tendência dos 
desenvolvedores (analistas, arquitetos e programadores) é dar soluções para o 
problema. Como se poderiam dar soluções se o problema ainda não foi 
compreendido?” (HIRAMA, 2011. p.68). Para colher informações nesta fase de 
descobertas, a equipe de analistas necessita de pessoas conhecedoras dos 
problemas que o cliente enfrenta. “Na concepção do projeto, estabelecemos um 
entendimento básico do problema, as pessoas que querem uma solução, a natureza 
da solução desejada e a eficácia da comunicação e colaboração preliminares entre os 
demais interessados e a equipe de software” (PRESSMAN, 2011. p.128). 
Para identificar problemas e necessidades, aplicaram-se entrevistas com 
funcionários experientes no negócio e foi utilizado o método dos cinco passos da 
análise do problema. A técnica de entrevistas é baseada em um questionário, ilustrado 
parcialmente na figura 2-1, que serve para conduzir a entrevista com o funcionário e 
consiste em uma conversa informal. O ideal é que o entrevistado se sinta à vontade a 
ponto de falar sobre o seu perfil, as suas atividades profissionais, as dificuldades que 
ele enfrente nestas atividades, como ele crê que projeto pode auxiliar em sua rotina 
de trabalho e quais as suas expectativas para o software. A entrevista também objetiva 
estabelecer vínculo com o entrevistado aproximando-o do objetivo do projeto. 
7 
 
 
Figura 2-1 - Questionário de Entrevista 
O método dos cinco passos da análise do problema consiste em ritos que 
resultam nos seguintes artefatos: 
 Declaração do problema: identifica o problema, quem ele afeta, as 
suas causas e os benefícios de mitigá-los usando o software; 
 Análise de Causas Raízes: aponta as origens de problemas, 
ramificando suas causas, utilizando diagrama de Ishikawa; 
 Lista de Stakeholders: mostra entidades (colaborador, um usuário ou 
um sistema externo) que afetam ou são afetados, direta ou indiretamente 
no andamento projeto; 
 Delimitação da Fronteira da Solução: define limites de atuação e de 
interação entre os atores e o sistema; 
 Lista de Restrições: determina condições da empresa que devem ser 
atendidas e observadas no projeto. 
Os próximos tópicos abordam com maior grau de detalhe as atividades de cada 
um dos passos, citados acima, que este método compreende. 
8 
 
2.1 Declaração do Problema 
O primeiro passo da fase de análise do problema serve para descrever as 
dificuldades que o negócio enfrenta. A declaração do problema foi constituída 
seguindo um modelo baseado em uma frase, disposta em uma tabela para facilitar o 
entendimento, que instiga a construção da descrição indagando qual o problema, 
quem é afetado pelo problema, como o problema afeta os envolvidos e quais os 
benefícios da solução. 
A tabela do modelo de declaração do problema é composta por duas colunas. 
Na coluna “elementos” se posicionam as indagações do modelo da declaração do 
problema, enquanto na coluna “descrição” são apresentadas suas respostas. Ainda 
que haja uma divisão textual, a leitura deve ser feita continuamente como um 
parágrafo, iniciando com “o problema” e findando nos “benefícios” da solução de 
software para resolver o problema. 
A tabela 2-1 contém a declaração do problema sob o aspecto empresarial 
elencando o que afeta o ambiente interno do negócio. Consecutivamente a tabela 
2-2 elenca problemas que afetam o âmbito dos clientes da empresa. 
Tabela 2-1 - Declaração do Problema - Empresa 
Elementos Descrição 
O Problema da ineficácia na gestão das vendas e de processos operacionais 
afeta os administradores da empresa, os gerentes de loja, os 
vendedores, os compradores, o encarregado do estoque, o 
encarregado do financeiro e o administrador do sistema 
devido ao desperdício de tempo e de investimento, unidos à diminuição 
de competitividade mercadológica, causando perda de 
credibilidade e de satisfação do cliente, e estresse dos 
funcionários por atritos entre departamentos. 
Os 
benefícios 
do 
Sistema MaiSys são: a eficiência em atendimentos e 
procedimentos pós-venda, a entrega de valores e de boa 
experiência ao cliente, a maior eficácia de especificação e venda 
de produtos, o aumento de poder estratégico, o 
autoconhecimento e melhores estimativas do negócio, o aumento 
de faturamento e rentabilidade, a diminuição de custo e de 
prejuízos, e maior interatividade interna. 
 
9 
 
Tabela 2-2 - Declaração do Problema - Cliente 
Elementos Descrição 
O Problema do mau atendimento e má entrega de valor 
afeta ao consumidor 
devido a atrasos na obra, ao desperdício financeiro, à perda de 
tempo. 
Os benefícios 
do 
Sistema MaiSys são: o aumento da agilidade do 
recebimento dos produtos na obra, a satisfação ao 
comprar, a boa experiência na aquisição e contratação, e 
o ganho de relação de confiança com a empresa. 
 
As análises de causas raízes realizadas na etapa seguinte têm como estímulo 
as declarações do problema e objetiva elevar o entendimento dos problemas. 
2.2 Análises das Causas Raízes 
A criação do Diagrama de Ishikawa1 permitiu apontar as causas primárias dos 
problemas. A investigação de problemas começa com a disposição de um problema 
central no eixo do diagrama, problema este declarado no tópico anterior, através do 
qual são derivadas causas mais profundas com a persistência dos questionamentos 
“por quê?”. 
A figura 2-2 demonstra razões dos problemas na visão da empresa. 
Sucessivamente a figura 2-3 aborda problemas na visão do consumidor. São artefatos 
que ilustram, no Diagrama de Ishikawa, como foram investigadas as causas raízes 
dos problemas que afetam os stakeholders em perspectivas diferentes. 
 
 
 
1 Ishikawa, Kaoru é o nome do engenheiro de controle de qualidade japonês que, em 1982, introduziu 
o conceito de Círculo de Qualidade e desenvolveu uma ferramenta poderosa para analisar problemas, 
o Diagrama de Ishikawa. 
10 
 
 
Figura 2-2 - Diagrama de Ishikawa - Contexto da Empresa 
 
Figura 2-3 - Diagrama de Ishikawa - Contexto do Consumidor 
A leitura desse diagrama pode ser feita da direita para a esquerda, onde cada 
seta representa uma causa. Na figura 2-2, por exemplo, pode-se admitir que: O 
problema da ineficácia na gestão das vendas e de processos operacionais - 
disposto na “cabeça” do diagrama - ocorre porque há falta de comunicação entre os 
setores, causada pela falta de treinamento. 
Outra forma da leitura do diagrama é da esquerda para a direita, porém a 
interpretação deve ser de consequência das causas. Na figura 2-3, por exemplo, 
entende-se que: A falta de atenção na conferência causa erros na separação dos 
11 
 
produtos, acarretando erro no fracionamento de entrega dos itens do pedido que, 
por consequência, ocasiona o problema do mau atendimento e má entrega de valor. 
Nas duas formas de leitura há uma demonstração de como compreender as 
causas dos problemas existentes na empresa. Assimilando tais problemas foi possível 
iniciar discussões sobre soluções que visem mitigá-los. No tópico seguinte, serão 
detalhados os usuários e outros stakeholders que são os afetados pelos problemas 
citados. 
2.3 Usuários e outros Stakeholders 
Identificados na declaração do problema, envolvidos no projeto compõem as 
listasde usuários e de outros stakeholders. Os stakeholders usuários são os que 
interagem diretamente com o sistema, os outros stakeholders são pessoas ou 
sistemas que não serão usuários, mas afetam ou são afetados de alguma maneira 
pelo projeto ou pelo software que será desenvolvido. Na tabela 2-3 são demonstrados 
alguns usuários que irão interagir através de ações diretas com a solução. Em 
seguida, a tabela 2-4 relaciona os interessados na solução que são afetados pelo 
sistema ou que o afetam. 
Tabela 2-3 - Lista de Stakeholders Usuários 
Nome Comentários 
Administrador Responsável pela manutenção e controle do sistema. Configura 
permissões que cada usuário obterá no sistema. Possui acesso a todos os 
módulos e operações do sistema. 
Gerente de 
Loja 
Responsável pela gestão de loja e de seus consultores. Controla 
concessões de descontos nos orçamentos e valida determinados 
processos administrativos. 
Consultor Responsável por inicias processos de vendas no sistema com dados 
fornecidos pelo cliente, por negociar com o Departamento de Compras 
produtos e serviços para venda, acompanhar o cliente e entregas de 
pedidos. Possui acesso restrito à sua loja e limites de descontos 
determinados na política comercial da empresa. 
Recepcionista Responsável por realizar o atendimento inicial dos clientes na loja. Caso 
um determinado cliente demonstre interesse em adquirir um produto, o 
Recepcionista colhe os dados cadastrais do cliente e os informa no 
sistema. Posteriormente, o cliente é direcionado pelo recepcionista a um 
consultor. 
Encarregado 
de Produtos 
É o responsável por manter o portfólio de produtos, serviços e promoções. 
Deve classificar as características técnicas de produtos no sistema e 
alinhar com a área de compras a necessidade de quais produtos devem 
ser adquiridos e quais serão classificados como fora de linha. 
12 
 
Tabela 2-4 - Lista de Outros Stakeholders 
Nome Comentários 
Cliente Principal afetado pelo sistema. O sucesso do projeto afeta o grau de 
satisfação do mesmo para com a empresa. 
Fornecedor Afeta o sistema por ser responsável pelas informações do catálogo de 
produtos. Trata solicitações de compra e de portfólio da empresa, afetável 
pela demanda comercial da empresa. 
Diretor 
Administrativo 
É um dos principais interessados no Retorno do Investimento feito no 
projeto. Decisões sobre o projeto tomadas por este stakeholder são 
consideradas cruciais e prioritárias. Tais decisões podem beneficiar ou 
prejudicar significativamente o projeto. 
Desenvolvedor 
do Sistema 
Seu objetivo no projeto é desenvolver o sistema e garantir sua qualidade 
atuando no processo de desenvolvimento de software, além de dar 
suporte aos usuários listados na tabela anterior. O bom desempenho 
deste stakeholder alavanca o retorno de investimento deste projeto. Ele é 
subordinado ao Encarregado de Sistemas. 
Encarregado 
de Sistemas 
Sua função é analisar os problemas e classificar as melhorias que serão 
desenvolvidas no software junto à Diretoria. Além de analisar requisitos do 
sistema, ele cria e mantém atualizados os documentos técnicos. A gestão 
que este stakeholder realiza pode influenciar no desempenho do projeto. 
Empresa de 
Serviços de 
E-mail 
Suporta o envio de e-mails destinados a clientes e parceiros da empresa a 
partir do sistema. Informações sobre processos de vendas e de compra 
utilizam este serviço, o que pode influenciar nos prazos dos processos. 
 
Outros usuários e stakeholders, também ligados ao negócio, não estão 
presentes nas listas acima, pois conforme descrito na seção 1.1.1 - objetivos gerais - 
deste trabalho, não fazem parte do escopo estabelecido neste projeto. 
Essas listas identificam todos os envolvidos com a solução, desde seus 
idealizadores até seus utilizadores, permitindo a definição do limite sistêmico abordada 
no item seguinte. 
2.4 Delimitação da Fronteira Sistêmica 
Com a lista de usuários definida, foi possível especificar a delimitação da 
Fronteira Sistêmica. Nela foram identificados os atores usuários que poderão interagir 
com a solução, contemplando coerência e adesão à lista de stakeholders usuários. 
O diagrama, ilustrado na figura 2-4, é o resultado de processos das análises 
antepostas e serve ainda para prevenir existência de usuários não declarados 
interagindo com o sistema. 
13 
 
 
Figura 2-4 - Fronteira Sistêmica 
As representações de outros stakeholders, presentes na tabela 2-4, não 
participam desse diagrama pois nenhum deles usará diretamente o sistema. Eles 
surgirão em outros diagramas explicados posteriormente, quando apresentam 
necessidades de comunicação. Após definidos os limites da solução o passo seguinte 
foi descobrir as restrições e limitações que o sistema deve atender, estudo 
aprofundado no próximo tópico. 
2.5 Restrições e Limitações 
A lista de Restrições e Limitações aborda condições e regras impostas pela 
empresa sobre o projeto. A equipe deve conseguir desenvolver um projeto de solução 
viável mesmo frente às restrições impostas neste artefato. Uma restrição imposta pela 
empresa neste projeto é: “O sistema precisa funcionar em plataforma web”. Assim, o 
projeto deve apresentar uma solução que seja acessível via internet para atender à 
necessidade da empresa. O exemplo apresentado é uma restrição de ordem 
arquitetural, porém outras restrições podem surgir por outras razões, por exemplo, de 
custo ou de infraestrutura. Adiante, na tabela 2-5, pode-se observar a lista de 
restrições impostas pela empresa e suas lógicas. 
 
 
14 
 
Tabela 2-5 - Lista de Restrições 
ID Restrição Lógica 
1 O sistema precisa 
estar hospedado na 
infraestrutura da 
empresa. 
O código fonte e o banco de dados ficarão 
instalados e configurados no servidor disponível no 
centro de distribuição da empresa, devido ao 
investimento já realizado em sua infraestrutura. 
2 Precisa rodar em 
plataforma web. 
O acesso ao sistema será feito através de qualquer 
computador que possua um navegador instalado, 
permitindo o acesso remoto de fora da empresa por 
vendedores internos e externos, e devido à 
empresa possuir filiais em cidades diferentes. 
3 Deve ser desenvolvido 
e suportado por 
serviços e soluções de 
licença livre. 
Nenhuma licença será requisitada para o pleno 
funcionamento do sistema. A empresa decidiu não 
alocar recursos para este tipo de gasto. 
4 O sistema deve estar 
disponível de segunda 
a domingo das 07h às 
23h. 
O sistema deve ficar disponível durante o 
funcionamento das filiais para criação de 
orçamentos, vendas e visualização de relatórios. 
 
Na tabela, a coluna “Restrição” possui as descrições das restrições impostas 
pela empresa. A Coluna “Lógica” contém as razões pelas quais as restrições surgiram. 
As Restrições devem ser negociadas e revisadas pelos stakeholders da empresa em 
conjunto com os analistas responsáveis antes de dar continuidade ao projeto, uma vez 
que as restrições podem ser tão impeditivas que podem inviabilizar o envolvimento da 
equipe de desenvolvimento no projeto. 
Analisando as restrições deste projeto, a equipe de desenvolvimento chegou 
ao consenso de que o projeto era viável. Assim, deu-se prosseguimento ao projeto 
levantando-se as características da solução. Tais características, bem como as 
técnicas de levantamento de requisitos utilizadas em suas descobertas, são abordas 
no próximo capítulo. 
15 
 
3 CARACTERÍSTICAS DA SOLUÇÃO 
As Características da Solução são oriundas de ideias de determinados 
stakeholders sobre funcionalidades, atribuições ou restrições que a equipe de 
analistas deverá compreender, para atendê-las através de requisitos, ao especificar a 
solução de software. Preferencialmenteestas ideias devem ser colhidas com pessoas 
experientes do domínio no negócio, que mais agregam nesta fase heurística. 
As primeiras características foram produzidas – juntamente às partes 
interessadas no sistema – em um workshop de características. Se tornam em artefatos 
que têm total colaboração na fase de levantamentos de requisitos e têm como principal 
objetivo formar a primeira baseline do projeto. A compilação destes artefatos foi 
conjunta e consensual. Segundo Pressman (2011. p.131), “Cada uma destas partes 
contribuirá com informações para o processo de engenharia de requisitos. As 
informações dos diversos pontos de vista são coletadas, requisitos emergentes talvez 
sejam inconsistentes ou entrem em conflito uns com os outros.”. O Workshop de 
Características é uma técnica similar à um brainstorming que consiste em realizar 
descobertas de ideias, sugestões ou expectativas que os participantes têm sobre 
funcionalidades do sistema. Segundo McMenamim (1984) “a essência de um sistema 
é um conjunto intangível de ideias”. 
A dinâmica do workshop inicia-se com um intermediador que instiga os 
stakeholders e os analistas a escreverem suas ideias em papéis adesivos. Em um 
quadro devem ser escritas as divisões organizacionais da empresa e as anotações de 
ideias devem ser alocadas, se possível, na divisão da empresa cuja característica 
relacione-se. Após a coleta de características, os participantes realizaram discussões 
sobre a permanência ou a remoção de cada característica e sobre suas prioridades. 
Durante este processo a equipe de analistas realizou argumentos técnicos para que 
os funcionários pudessem tomar decisões mais acertadas. Este processo englobou 
debates sobre viabilidades das características, que foram feitos a fim de alcançar a 
adesão dos stakeholders sobre a definição da primeira baseline. A figura 3-1 
participantes interagindo durante o workshop. 
16 
 
 
Figura 3-1 - Workshop de Características 
O próximo tópico aprofunda a abordagem das características, onde se 
observam: descrições, relacionamentos, prioridades, complexidades e riscos. 
Também, mostra a primeira baseline de características, que alimentou as futuras 
análises sistêmicas do projeto. 
3.1 Lista de Características 
A classificação ordenada dessas características e a definição de uma baseline 
primária permitiram aos integrantes especularem as primeiras projeções de escopo 
deste projeto. A tabela 3-1 mostra esta primeira baseline, que é composta pelas 
características vistas como prioritárias e viáveis. Os posteriores artefatos produzidos 
neste trabalho foram elaborados, em suma, para atendê-las. A identificação de cada 
característica é única, visando a rastreabilidade individual, pois elas se relacionarão 
com vários diagramas e modelos propostos no projeto. 
Tabela 3-1 - Lista de Características 
ID CARACTERÍSTICA 
CAR0002 Exibir tela com todos os processos e históricos do cliente. 
CAR0003 Gerar orçamentos. 
CAR0005 Gravar datas e usuários que modificaram os pedidos. 
CAR0010 Transformar o orçamento em pedido de vendas. 
CAR0011 Controle de promoções. 
CAR0012 Mudar situação dos cortes exclusivos já vendidos. 
CAR0025 Controlar devolução de produtos. 
CAR0034 Cadastrar produtos e serviços de fornecedores. 
CAR0038 Importação e exportação de produtos por CSV. 
CAR0041 Classificação e tipologia de produtos. 
CAR0046 Cadastrar especificadores. 
17 
 
ID CARACTERÍSTICA 
CAR0047 Vários endereços por cliente. 
CAR0048 Cadastrar fornecedores. 
CAR0049 Cadastrar clientes. 
CAR0050 Cadastro de funcionários e usuários. 
CAR0052 Cadastrar Lojas/Filiais. 
CAR0055 Dividir produtos em orçamentos e pedidos por ambiente. 
CAR0056 Relatório de vendas. 
CAR0057 Permitir descontos no preço, por item, em orçamentos e pedidos. 
CAR0061 Acessar ao sistema pela WEB. 
CAR0064 Banco de Dados relacional e com FK estabelecidas. 
 
Esta tabela exibe a coluna “ID” e a coluna “Característica”, que contém a 
anotação das características da solução do mesmo jeito que surgiram no workshop. 
No entanto, é necessário um detalhamento para maior compreensão da cada 
característica por parte dos analistas. Este detalhamento é expressado no tópico 
seguinte. 
3.2 Descrições das Características 
As descrições das características têm como objetivo elucidar seus significados. 
Por isso devem ser objetivas, claras e pouco extensas, visando sempre melhorar a 
compreensão dos conceitos nelas contidos. A tabela 3-2 demonstra descrições de 
características presentes na lista anterior, identificados através do ID. 
Tabela 3-2 - Lista de Características com Descrição 
ID DETALHAMENTO LÓGICO 
CAR0002 Uma tela, acessível através do cadastro de clientes exibirá os principais processos 
(orçamentos, pedidos, devoluções, etc.) e últimos históricos do cliente no sistema. 
CAR0003 
Processo onde o consultor, após conhecer a necessidade do cliente, inserirá os 
ambientes da obra, os produtos e seus quantitativos especificados junto com o 
especificador e/ou com o cliente. 
CAR0005 Pedidos de venda podem ser alterados por usuários com acessos especiais, mas o 
sistema deve gravar qual data e qual usuário alterou. 
CAR0010 Ação que deve transformar um orçamento em aberto em pedido de venda, que dará início 
aos processos financeiros, de estoque e administrativos. 
18 
 
ID DETALHAMENTO LÓGICO 
CAR0011 Promoção de produto deve ter atualização e cadastramento por importação, vigência e 
limitações de quantitativo. 
CAR0012 
Cortes personalizados exclusivos só são usados para um cliente específico e perde 
utilidade após a venda. O recurso vai servir para otimizar e higienizar as consultas dos 
cortes considerados comuns. 
CAR0019 São parcelas de pedidos de venda (cadastradas quando o pedido é aberto), créditos com 
fornecedores ou recebimentos de comissão por venda de representação. 
CAR0020 Valores de créditos ao cliente oriundos de devoluções de pedidos de venda podem ser 
abatidos em parcelas abertas de pedidos do mesmo cliente. 
CAR0025 
O processo de devolução de produtos segue os seguintes passos: conferência do produto 
no retorno (se este for entregue ao cliente); entrada no estoque e; geração de crédito ao 
cliente ou abatimento do valor devolvido em parcelas do cliente que estejam em aberto. 
CAR0034 
Compreende funcionalidades que permitem o cadastramento de produtos. Este pode ser 
feito através de preenchimento das informações em formulário ou importação de uma lista 
em formato CSV. 
CAR0038 
Este recurso compreende a importação de arquivos CSV, alimentados com dados 
passados pelos fornecedores, para incluir ou atualizar produtos no sistema. Também 
compreende a exportação de dados de produtos em arquivos CSV. 
CAR0041 
Compreende uma gama de parâmetros que os produtos possuem para correta definição e 
melhor distinção, tais como: grupo, família, classe comercial, produção, situação, 
classificação fiscal. 
CAR0046 Cadastro de informações, contatos e endereços de especificadores (profissionais do 
ramo: arquitetos, engenheiros, decoradores, etc.). 
CAR0047 Um cliente pode ter vários endereços de entrega cadastrados, pois pode comprar para 
várias obras e em momentos diferentes. 
CAR0048 
Compreende cadastro de dados do fornecedor, polos de fornecedores (filiais de fábricas), 
prazos de entrega, formas de pagamento e faturamento, e contatos dos representantes 
do fornecedor. 
CAR0049 Compreende cadastro de dados do cliente, endereços de entrega, contatos telefônicos, 
características pessoais e números de documentos. 
CAR0050 Cadastro de funcionários da empresa e usuários do sistema com definição de permissões 
de acesso. 
CAR0052 Cadastro de informações das filiais e lojas da empresa Mais Revestimentos,tais como 
endereços, telefones, documentos e parâmetros de sistema. 
CAR0055 
Os orçamentos devem ter lógica de separação de produtos por ambiente de acordo com o 
que o cliente especifica sobre a obra, e esta característica de divisão deve continuar no 
pedido de venda. 
CAR0056 Consiste em um relatório de valores e quantitativos de pedidos de venda realizados, 
podendo ser filtrados por produtos, lojas, vendedores, clientes, especificadores e período. 
CAR0057 Itens do mesmo orçamento ou pedido, podem receber desconto no preço. 
CAR0061 O sistema deve estar disponível para acesso através da internet utilizando navegadores 
web. 
CAR0064 O sistema gerenciador de banco de dados deve ser relacional, de licença livre e o motor 
de armazenamento deve aceitar a declaração de chaves estrangeiras (Foreign Key). 
19 
 
As características não devem induzir interpretações dúbias em suas 
descrições. As partes integrantes do projeto devem entrar em acordo sobre o 
detalhamento de cada característica e garantir suas rastreabilidades. 
Avaliar os artefatos anteriores, com descritivo conteúdo, e dimensionar 
complexidades e os riscos são tarefas fundamentais ao planejamento, pois 
características comumente têm relacionamento com tomadas de decisões 
estratégicas no projeto. A seguir, nota-se o cruzamento realizado entre cada 
característica e itens avaliativos essenciais. 
3.3 Prioridade x Esforço x Risco 
Este artefato tem o objetivo de definir determinados aspectos que classificam 
as características da solução. O primeiro, denominado Prioridade, define a 
necessidade de participação no projeto de determinada característica. Nele, as 
características são classificadas em três níveis: 
1. Crítico: o que será indispensável na solução; 
2. Importante: o que será relevante ter na solução; 
3. Útil: o que ajudará ser tiver na solução. 
O segundo é denominado Esforço, que mensura a complexidade, ou 
dificuldade, prevista para atender determinada característica no projeto. Os 
indicadores utilizados para definir o nível de esforço são: difícil, médio e baixo. 
O terceiro chama-se Risco, que define o quanto determinada característica 
pode impactar no restante do projeto. Os indicadores que definem o nível de risco são: 
alto, médio e baixo. 
Uma das técnicas utilizadas para definir a prioridade de cada característica foi 
a das fichas, onde cada participante do workshop defendeu seu ponto de vista. Após 
a avença entre os participantes, determinaram-se tais prioridade. Após esta 
priorização, os analistas do projeto - também com o uso da técnica das fichas - 
definiram os esforços necessários e o nível de risco para cada característica da 
solução de acordo com suas visões. A tabela 3-3 demonstra estas apropriadas 
classificações das características levantadas no workshop. 
 
20 
 
Tabela 3-3 - Lista de Características - Prioridade x Esforço x Risco 
ID PRIORIDADE ESFORÇO RISCO 
CAR0002 IMPORTANTE BAIXO BAIXO 
CAR0003 CRÍTICO MÉDIO MÉDIO 
CAR0005 CRÍTICO BAIXO BAIXO 
CAR0009 CRÍTICO BAIXO BAIXO 
CAR0010 CRÍTICO MÉDIO MÉDIO 
CAR0011 CRÍTICO BAIXO BAIXO 
CAR0012 CRÍTICO BAIXO BAIXO 
CAR0015 CRÍTICO MÉDIO MÉDIO 
CAR0019 CRÍTICO BAIXO BAIXO 
CAR0020 CRÍTICO MÉDIO BAIXO 
CAR0025 CRÍTICO DIFÍCIL BAIXO 
CAR0034 CRÍTICO MÉDIO MÉDIO 
CAR0038 CRÍTICO MÉDIO BAIXO 
CAR0041 CRÍTICO MÉDIO BAIXO 
CAR0046 CRÍTICO BAIXO BAIXO 
CAR0047 CRÍTICO BAIXO MÉDIO 
CAR0048 CRÍTICO MÉDIO MÉDIO 
CAR0049 CRÍTICO BAIXO MÉDIO 
CAR0050 CRÍTICO BAIXO MÉDIO 
CAR0052 CRÍTICO BAIXO BAIXO 
CAR0055 CRÍTICO MÉDIO MÉDIO 
CAR0056 CRÍTICO DIFÍCIL ALTO 
CAR0057 CRÍTICO BAIXO MÉDIO 
CAR0061 CRÍTICO BAIXO BAIXO 
CAR0064 CRÍTICO MÉDIO MÉDIO 
 
Com a lista de características definidas por prioridade, complexidade e risco se 
definiu a ordem na qual as características serão entregues primeiro, formando as 
baselines, abordadas a seguir. 
21 
 
3.4 Definição de Baselines. 
As características mais críticas, com baixo risco e com baixo esforço são 
inclusas na chamada primeira baseline (ou baseline 1). As características restantes 
serão divididas seguindo o mesmo critério nas baselines posteriores. Com isso a 
equipe e o cliente têm mais uma maneira de validar se o andamento do projeto está 
de acordo com as expectativas. A tabela 3-4 lista algumas características da primeira 
baseline do projeto. 
Tabela 3-4 - Baseline de Características 
ID CARACTERÍSTICA 
Base 
Line 
CAR0002 Exibir tela com todos os processos e históricos do cliente. 1 
CAR0003 Gerar orçamentos. 1 
CAR0005 Gravar datas e usuários que modificaram os pedidos. 1 
CAR0009 Notificação de pendência de produtos nos pedidos de venda. 1 
CAR0010 Transformar o orçamento em pedido de vendas. 1 
CAR0011 Controle de promoções. 1 
CAR0012 Mudar situação dos cortes exclusivos já vendidos. 1 
CAR0015 Gerar relatório de comissões. 1 
CAR0019 Cadastrar contas a receber. 1 
CAR0020 Permitir abater créditos de devolução em parcelas de pedido de vendas. 1 
CAR0025 Controlar devolução de produtos. 1 
CAR0034 Cadastrar produtos e serviços de fornecedores. 1 
CAR0038 Importação e exportação de produtos por CSV. 1 
CAR0041 Classificação e tipologia de produtos. 1 
CAR0046 Cadastrar especificadores. 1 
CAR0047 Vários endereços por cliente. 1 
CAR0048 Cadastrar fornecedores. 1 
CAR0049 Cadastrar clientes. 1 
CAR0050 Cadastro de funcionários e usuários. 1 
CAR0052 Cadastrar Lojas/Filiais. 1 
CAR0055 Dividir produtos em orçamentos e pedidos por ambiente. 1 
CAR0056 Relatório de vendas. 1 
CAR0057 Permitir descontos no preço, por item, em orçamentos e pedidos. 1 
22 
 
Na tabela anterior percebe-se que determinadas características, mesmo não 
sendo de baixo risco ou de menor complexidade, foram definidas no baseline 1 por 
serem prioritárias para o negócio. 
No próximo capítulo iniciam-se as modelagens de negócios onde serão 
abordados contextos organizacionais e operacionais do domínio do negócio da 
empresa. 
23 
 
4 MODELAGEM DE NEGÓCIOS 
A fase de modelagem de negócios tem como finalidade enxergar uma 
arquitetura organizacional e conhecer fluxos de informações relacionados aos 
processos inseridos no contexto do negócio que, justamente por serem complexos, 
justificam as abordagens através de métodos maduros de análise de negócios. A 
figura 4-1 mostra parte da estrutura organizacional da empresa. 
 
Figura 4-1 - Estrutura Organizacional 
A modelagem do negócio aconteceu de forma encadeada a partir das 
descobertas dos seguintes elementos identificados na organização do negócio: 
 Cenários de negócio: Ambientes contextuais formados por nós 
operacionais nos quais se desenrolam atividades e eventos operacionais 
do negócio; 
 Nós operacionais: Entidades abstratas e internas do domínio real do 
negócio, como uma divisão ou um departamento por exemplo, que têm 
24 
 
capacidades de realizar processos a fim de alcançar objetivos do 
negócio; 
 Capacidades de negócio: Competências próprias de um nó 
operacional, formadas por um conjunto de processos de negócio com 
vários objetivos; 
 Processos de negócio: Uma cadeia de tarefas que atende um evento 
operacional em uma determinada capacidade de negócio. 
Cada capacidade de negócio foi diagramada em um modelo essencial de 
negócio, explicado no item 4.3 deste capítulo. Durante as análises destas capacidades 
e de seus processos, foram descobertos os seguintes elementos: 
 Entidades Externas: Interagem com os processos por estímulos 
enviando ou recebendo informação, mas não pertencem ao nó 
operacional ou não está dentro do negócio; 
 Depósitos de dados: Guardam informações criadas ou requisitadas porprocessos de negócio; 
 Fluxos de dados: Informações que fluem nos processos durante 
interações com as entidades externas ou com os depósitos de dados. 
Regras de negócio são comumente descobertas nesta fase, mas são oriundas 
de uma visão não automatizada do ambiente operacional. Foram utilizados conceitos 
que definem padrões de organização através da premissa de serem abordados em 
um prisma funcional e empírico, de modo que obtiveram-se modelos que representam 
procedimentos existentes no ambiente do negócio inerentemente da existência de 
componentes tecnológicos. 
Através do ferramental existente no DODAF2, obteve-se o embasamento para 
a modelagem de uma arquitetura organizacional sem precedentes para a empresa 
propiciando a documentação de elementos e fluxos do negócio. Isso promove 
alinhamento entre as necessidades do negócio e a infraestrutura sistêmica 
especificada para apoiar tais necessidades. Uma definição de arquitetura é: “uma 
 
 
 
2 DODAF - Department of Defense Architecture Framework. Método criado pelo departamento de 
defesa dos Estados Unidos da América que oferece definições de estrutura para modelagem de 
arquiteturas organizacionais, permitindo melhor compreensão e integração das arquiteturas. 
25 
 
representação de um domínio definido, a partir de um ponto no tempo atual ou futuro, 
no que diz respeito às partes dos seus componentes, como essas partes funcionam, 
as regras e restrições com as quais essas partes funcionam, e como essas partes se 
relacionam entre si e com o ambiente.” (DODAF, 2007). 
O próximo passo desta fase foi a descoberta de eventos de negócio utilizando 
o conceito da partição por eventos. Nesta, por definição, cada evento deve ser tratado 
única e exclusivamente por um processo de negócio. Segundo Pompilho (1994), “um 
evento pode ser definido informalmente como um acontecimento do mundo exterior 
que requer do sistema uma resposta”. 
Uma das atividades cotidianas da empresa apresentou inviabilidade na análise 
essencial de negócio e na partição por eventos. Chamada de “Acompanhamento”, tem 
o intuito de reforçar resultados e o controle de processos de venda - como orçamentos 
e pedidos de venda - ou atores do negócio - como especificadores e clientes. Depois 
de tentativas sem sucesso, notou-se que os estímulos para os processos 
compreendidos nesta atividade não estão bem definidos, bem como em que contextos 
sua utilização é necessária. Esta dificuldade tornou impraticável a realização da 
partição por eventos do processo de “Acompanhamento”, considerado uma genérica 
prática de agendamentos e planejamento. 
No capítulo 5 serão abordados os requisitos de sistema, elementos de âmbito 
sistêmico, cujos maioria foram criados para atender em nível de software as regras e 
características provenientes da fase de modelagem de negócios. 
Nos tópicos adiante são tratados os eventos, identificados nesta fase de 
modelagem, decorrentes de análises essenciais de negócio sobre o nó operacional de 
Vendas. 
4.1 Lista de Eventos 
A lista de eventos tem as finalidades de detalhar os momentos, de indicar os 
atores envolvidos nas atividades de negócio e de enxergar como os eventos são 
estimulados. A tabela 4-1 apresenta a análise de eventos das capacidades citadas 
com um fluxo básicos (FB) e um alternativo (FA) classificados de forma contínua. 
 
 
26 
 
Tabela 4-1 - Análise de Eventos 
 Externo Temporal 
C
a
p
a
c
id
a
d
e
s
 
T
ip
o
 d
e
 F
lu
x
o
 
S
e
q
u
ê
n
c
ia
 
E
v
e
n
to
 
P
re
v
is
ív
e
l 
N
ã
o
 P
re
v
is
ív
e
l 
R
e
la
ti
v
o
 
A
b
s
o
lu
to
 
N
ã
o
 E
v
e
n
to
 
E
x
te
m
p
o
râ
n
e
o
 
Converter 
Orçamento 
Em pedido 
FB 
7 Cliente aprova orçamento. x 
8 Cliente responde preferências. x(7) 
9 
Consultor Imprime Pedido Venda e Termo 
Entrega. 
 x(8) 
10 Cliente assina e entrega documentos. x(9) 
FA 
11 Consultor solicita instruções de entrega. x(8) 
12 Cliente responde questionário de entrega. x(11) 
 
Nesta análise, eventos devem ser classificados entre os seguintes tipos de 
estímulos: 
 Externos: Compreendem interações iniciadas por entidades externas 
inerentes aos estímulos internos, sendo estes Previsíveis ou Não 
Previsíveis; 
 Temporais: Provocados pelo próprio negócio e precisam ser tratados 
internamente. São divididos em Relativos, Absolutos e Não Eventos; 
 Extemporâneos: Acontecem sem previsão e independentemente da 
sequência ou estímulos dos processos. 
Existem eventos anteriores aos listados nesta tabela, por isso a sequência inicia 
em com o número sete. Após a análise dos eventos foram elaboradas suas descrições 
minuciosamente com o objetivo de esclarecer suas propriedades, apontadas no 
próximo tópico 
4.2 Descrições dos Eventos 
Os eventos foram descritos seguindo um padrão de forma que se normatizaram 
suas orações textuais. “A maneira de descrever os eventos requer algumas 
27 
 
considerações. Todo evento deve ser descrito por única sentença, geralmente uma 
estrutura frasal que atende as necessidades de descrição dos eventos” (Pompilho, 
1994). 
É possível visualizar na tabela 4-2 as descrições dos eventos com seus 
respectivos detalhamentos referentes aos processos de venda. 
Tabela 4-2 - Descrição dos eventos 
N° Descrição Detalhamento 
7 Cliente aprova 
orçamento. 
Contempla o momento em que o cliente informa ao 
consultor a aprovação da especificação e de valores do 
orçamento elaborado, e que o consultor inicia a 
conversão deste em pedido. 
8 Cliente responde 
preferências. 
Contempla o momento em que o consultor colhe com o 
cliente preferências sobre pagamento e entrega de 
produtos para poder elaborar o pedido de venda. 
9 
Consultor Imprime 
Pedido Venda e Termo 
Entrega. 
Trata o procedimento em que o consultor imprime o 
pedido de venda e o termo de entrega para serem 
conferidos e assinados pelo cliente. 
10 Cliente assina e entrega 
documentos. 
Contempla o momento em que o cliente entrega ao 
consultor os documentos de venda assinados que devem 
ser vinculados ao pedido de venda. 
11 Consultor solicita 
instruções de entrega. 
Momento em que o consultor indaga o cliente sobre 
informações e regras de entrega para cadastramento do 
formulário do questionário de entrega. 
 
Apesar da descrição do evento seguir uma norma que facilita sua 
compreensão, informações relevantes podem se perder nesta descrição sucinta. O 
detalhamento é importante para uma melhor compreensão dos fluxos e estímulos dos 
eventos. 
Como produto das análises e descrições dos eventos, obteve-se a 
materialização do entendimento das capacidades do negócio nos artefatos 
conhecidos como DFD (Diagrama de Fluxo de Dados), discorridos a seguir. 
4.3 DFD Essencial de Negócio 
O DFD ilustra como e por quais processos os eventos são tratados, como as 
informações fluem entre os elementos de negócio e em quais depósitos de dados tais 
informações são armazenadas. “Embora a modelagem de fluxo de dados seja vista 
como uma técnica ultrapassada por alguns engenheiros de software, continua a ser 
28 
 
uma das notações de análise de requisitos mais largamente usadas hoje em dia” 
(PRESSMAN, 2011, p. 182). 
Os processos prospectados estimularam a descoberta de regras de negócio. O 
que favoreceu tanto a elicitação de requisitos quanto a criação dos casos de uso que 
representarão metas de usuários no software. Os depósitos de dados fundamentarão 
a criação de classes do software ede modelos de banco de dados. 
A seguir, a figura 4-1 ilustra o resultado da elaboração deste artefato para a 
capacidade “Converter Orçamento em Pedido” do nó operacional “Departamento 
Venda”. 
 
Figura 4-2 - DFD Converter Orçamento em Pedido 
Neste DFD são ilustrados os processos possíveis para se transformar um 
orçamento em um pedido de vendas, onde o cliente - uma entidade externa – estimula 
o primeiro processo desta capacidade de negócio através da “aprovação do 
orçamento” elaborado por um consultor da Mais Revestimentos. 
29 
 
Após a aprovação, são confirmadas as preferências do cliente sobre entrega - 
como endereço e datas previstas - e acerca das datas de vencimento e formas de 
pagamento para o pedido que será criado. Feitas as confirmações, estes dados são 
guardados no depósito de dados de “Pedido” e a situação orçamento é atualizada 
para “Fechado”. 
No próximo processo, o consultor realiza a impressão dos documentos de 
venda e os entrega para que o cliente assine-os. Após a assinatura dos documentos 
o cliente os devolve ao consultor, que os anexa junto ao compromisso de pagamento 
e os encaminha ao responsável pela área de cobrança, logo, o sistema deverá permitir 
que os dados digitalizados sejam anexados ao pedido. 
Os processos “Solicitar respostas do questionário de entrega” e “Cadastrar 
Respostas do questionário de entrega” são referentes à um fluxo alternativo, ou seja, 
estes processos só acontecerão se o cliente optar pela entrega por transportadora. 
Quando o cliente decidir retirar os produtos no CD (Centro de Distribuição) da 
empresa, o consultor não precisa especificar regras ou endereço de entrega para o 
pedido. 
Alguns depósitos de dados apresentam considerável complexidade e se 
mostram merecedores de outro tipo de estudo, conhecido como análise de ciclo de 
vida, um diagrama que complementa a análise essencial. Nele são demonstrados os 
estados que as informações podem assumir ao serem guardadas em depósito de 
dados. O depósito de dados “Pedido” mostrou esta necessidade. A figura 4-2 ilustra 
o artefato, ele demonstra três estados alterados por informações geradas nesta 
capacidade de negócio: “Cadastrado”, “Anexado aos documentos de entrega” e 
“Anexado ao Questionário de entrega”. 
30 
 
 
Figura 4-3 - Ciclo de Vida para o depósito de dados Pedido 
A informação pode assumir um estado em consequência da ocorrência de um 
evento. A figura mapeia os estados relativos a determinada informação contida no 
depósito de dados e desvenda continuidades a partir do estado no qual a informação 
estiver. 
No item a seguir os processos de negócio descobertos são descritos em 
detalhes para maior entendimento das atividades que os compõem. 
4.4 Detalhes dos Processos de Negócio 
Após a identificação dos processos de negócio através do DFD, foi realizada a 
descrição detalhada de cada um deles. Este detalhamento busca esclarecer fluxos 
que acontecem internamente no negócio quando ocorre um determinado estímulo ou 
evento. 
Através deste detalhamento, também se identificam algumas normas que 
dirigem atividades e comportamentos dentro dos processos. Neste momento são 
descobertas a maioria das regras de negócio, que se tornam elementos relacionados 
aos processos do DFD com o intuito de aumentar a compreensão do negócio. 
31 
 
Tabela 4-3 - Detalhes dos Processos 
N Nome Detalhe 
1 
P
ro
c
e
d
e
r 
A
p
ro
v
a
ç
ã
o
 d
e
 
O
rç
a
m
e
n
to
 
Evento: Cliente aprova orçamento. 
Objetivo: Iniciar a conversão do orçamento aprovado pelo cliente em um pedido de venda. 
Trabalhadores Envolvidos: Consultor. 
Consultor acessa o orçamento que o cliente aprovou, confirma com o cliente preferências de 
forma de entrega e de pagamento para o pedido. Se o cliente desejar retirar as mercadorias 
no CD, valor de frete e preenchimento do questionário de entrega são dispensados. 
2 
C
a
d
a
s
tr
a
r 
P
e
d
id
o
 d
e
 
V
e
n
d
a
 e
 P
re
fe
rê
n
c
ia
s
 
Evento: Cliente responde preferências. 
Objetivo: Cadastrar informações oriundas do orçamento, juntamente com escolhas e 
informações sobre entrega, pagamentos e endereços fornecidos pelo cliente no Pedido de 
Venda. 
Trabalhadores Envolvidos: Consultor 
Cliente responde preferências sobre forma de entrega, endereço de entrega e forma de 
pagamento; Consultor atualiza preferências do cliente (forma de pagamentos e forma de 
entrega) e cadastra o pedido de venda; Consultor atualiza o orçamento convertido impedido 
como Fechado. 
3 
Im
p
ri
m
ir
 
D
o
c
u
m
e
n
to
s
 
d
e
 V
e
n
d
a
 
Evento: Consultor Imprime Pedido Venda e Termo Entrega. 
Objetivo: Entregar cópia do pedido de venda e do termo de entrega ao cliente para que o 
cliente os assine e os devolva ao consultor. 
Trabalhadores Envolvidos: Consultor. 
Consultor imprime o pedido de venda e o termo de entrega, e solicita ao cliente que os 
assine para servir como compromissos de pagamento junto ao financeiro. 
4 
R
e
c
e
b
e
r 
C
o
m
p
ro
m
is
s
o
s
 
d
e
 P
a
g
a
m
e
n
to
 
Evento: Cliente assina e entrega documentos. 
Objetivo: Receber documentos de venda assinados pelo cliente, junto com comprovantes 
de pagamento. 
Trabalhadores Envolvidos: Consultor 
O consultor recebe os documentos de venda assinados pelo cliente; O consultor anexa ao 
pedido de venda o termo de entrega e os compromissos de pagamento. 
5 
S
o
li
c
it
a
r 
R
e
s
p
o
s
ta
s
 a
o
 
Q
u
e
s
ti
o
n
á
ri
o
 d
e
 
E
n
tr
e
g
a
s
 
Evento: Consultor Solicita instruções de entrega ao Cliente. 
Objetivo: Preencher o questionário de entrega com informações e regras sobre a entrega 
que será feita no local determinado pelo cliente. 
Trabalhadores Envolvidos: Consultor 
O consultor, se o cliente optar por receber os produtos por transportadora, faz perguntas 
sobre a entrega como: datas, horários, restrições e contatos para realização da entrega; O 
consultor deve vincular o questionário de entrega preenchido ao pedido. 
6 
C
a
d
a
s
tr
a
r 
R
e
s
p
o
s
ta
s
 d
o
 
Q
u
e
s
ti
o
n
á
ri
o
 d
e
 
E
n
tr
e
g
a
s
 
Evento: Cliente responde questionário de entrega. 
Objetivo: Cadastrar o questionário de entrega com as instruções passadas pelo cliente 
sobre a entrega e anexá-lo ao pedido de venda. 
Trabalhadores Envolvidos: Consultor. 
O consultor, se a forma de entrega for por transportadora, solicita informações e regras de 
entrega ao cliente, cadastra o questionário de entrega com informações passadas pelo 
cliente e o anexa ao pedido de venda; O consultor fornece uma cópia do questionário de 
entrega e o entrega ao cliente. 
 
Na construção da tabela, foi adotado um leiaute para detalhamento de 
processos de negócio. O padrão define que devem estar presentes os seguintes 
elementos: o evento que desencadeia as atividades dentro do processo, qual seu 
objetivo, os trabalhadores envolvidos e uma breve descrição sobre o desenrolar 
dessas atividades. 
Finalizando a modelagem de negócio criou-se conceitualmente as estruturas 
de dados e relacionamentos existentes nas análises de negócio anteriores, o que se 
apresenta no próximo tópico. 
32 
 
4.5 Modelo Conceitual 
O modelo conceitual é amplamente definido como uma estruturação dos 
elementos presentes no domínio do negócio, representados por classes, e que utiliza 
notações similares as do diagrama de classes da UML. Ele tem o objetivo de descrever 
um sistema coeso de objetos,com propriedades e associações claras, que 
representam as informações tratadas no desenrolar das tarefas dos atores do negócio, 
que serão usuários do software. O modelo conceitual é mais compreensível que os 
modelos de banco de dados pois não expressam notações ou aplicação de tecnologia 
específica. 
Os processos descobertos na análise essencial de negócio, expostos no 
diagrama DFD, leem e guardam informações em “depósitos de dados” que deverão 
estar representados e persistidos estaticamente no sistema de software. O modelo 
conceitual procura demonstrar uma estrutura de objetos baseada nestes depósitos de 
dados. Seus atributos são baseados nas informações lidas ou gravadas nos depósitos 
de dados através dos fluxos dos processos. As associações são definidas para 
representar relacionamentos, e suas multiplicidades, de objetos que se referenciem 
no domínio do negócio. A partir desta análise serão obtidas as classes de domínio do 
sistema, isso enriquece o glossário sistêmico definindo conceitos elementares do 
domínio do negócio. Se nota que estas estruturas de dados são similares às que 
guardarão informações no banco de dados, porém não especifica de que maneira isso 
acontece. Segundo Pressman (2011), “modelos orientados a classes, entre outros, 
dão ao projetista de software as informações que podem ser traduzidas em projetos 
de arquitetura, de interfaces e de componentes.” 
No processo de delegação de responsabilidades a classes, fez-se uma análise 
com base em esquemas estruturais pertencentes aos padrões GOF (Gang Of Four). 
Estes padrões foram desenvolvidos por quatro amigos e compilados em obras 
reconhecidas no meio da análise de sistemas que servem como catálogo que 
apresenta vinte e três padrões de projeto. Eles estabelecem normas e soluções de 
comportamento dos elementos estruturais, contextos em que podem ser utilizados, 
como devem ser aplicados e eventuais consequências de sua utilização. O estudo dos 
padrões GOF possibilitou a organização dos dados de maneira a evitar problemas na 
utilização e na implementação destas estruturas de classes. Na figura 4-3 é 
33 
 
apresentado o modelo conceitual do subsistema Venda, particularmente da estrutura 
que remete a capacidade “Converter Orçamento em Pedido”. 
 
Figura 4-4 - Modelo Conceitual 
Neste diagrama observa-se o objeto “Pedido” exercendo papel central. Alguns 
dos seus dados estão contidos em outros objetos que o compõem, são eles: 
“Ambiente de Pedido”, “Parcela de Pedido”, “Questionário de Entrega” e “Termo de 
Entrega”. Embora façam parte do objeto “Pedido”, estes objetos exercem 
responsabilidades diferentes, seus nomes indicam suas responsabilidades dentro do 
“Pedido”. Outros objetos participam do artefato por auxiliarem estes objetos centrais, 
tanto para classificá-los ou compô-los - no caso das agregações - quanto para 
exercerem papéis independentes - representados por uma ligação simples – o que 
pede descrição da associação que indique seu papel e sentido associativo. 
O capítulo seguinte detalha os Requisitos do Sistema, elementos provenientes 
desta fase de análise e modelagem do negócio. 
34 
 
5 REQUISITOS DO SISTEMA 
Os requisitos de sistema são elementares na engenharia de software, pois 
idealizam no projeto a formação da solução sistêmica. São constatados em diferentes 
prismas do projeto como de arquitetura, de comportamento e de funcionalidade do 
sistema. Categoricamente, eles surgem desde as análises iniciais do domínio do 
problema. Pressman (2011) afirma que “a engenharia de requisitos é uma ação de 
engenharia de software importante que se inicia durante a atividade de comunicação 
e continua na modelagem. Ela deve ser adaptada às necessidades do processo, do 
projeto, do produto e das pessoas que estão realizando o trabalho”. 
Os requisitos servem às características que os stakeholders da empresa 
declararam necessitar que o sistema compreenda, assim o sucesso da construção 
desta solução de software está altamente ligado ao bom levantamento, gerenciamento 
e atendimento destes requisitos. A figura 5-1 nota a evolução destes elementos, entre 
os domínios analisados, e a sequência na qual as elicitações ocorreram neste projeto. 
 
Figura 5-1 - Fluxo de Evolução de Requisitos 
A sequência de elicitação de requisitos é iniciada com a análise das 
necessidades, descobertas nos domínios dos problemas que o sistema deverá ajudar 
a resolver. Então elaboraram-se as características esperadas em forma de requisitos 
funcionais ou não funcionais no projeto do sistema. 
A especificação de um sistema, mais ainda de um que tenha escopo grande - 
como é o sistema MaiSys - deve identificar de maneira clara onde estão sendo 
entregues estes requisitos. Assim, aliam-se ao projeto os ganhos de garantia de 
rastreamento e da justificativa dos artefatos que foram elaborados para atendê-los. 
Quaisquer alterações de requisitos devem ser feitas com cautela. De acordo 
com Hirama (2014, p.56), “nem sempre uma mudança é viável, mas a análise de 
35 
 
impactos baseada em registros de uma matriz de rastreabilidade permite argumentar 
com o cliente sobre as consequências no processo de desenvolvimento e nos custos 
do projeto.” 
No tópico seguinte são relacionados os requisitos de sistema com seus 
descritivos que os expressam mais nitidamente. 
5.1 Detalhes dos Requisitos do Sistema 
O detalhamento dos requisitos foi feito para aprofundar conhecimentos sobre 
cada requisito elicitado e sobre como eles atenderão às necessidades de negócio a 
serem realizadas no sistema. É preciso descrevê-los de forma clara e coesa para que 
sejam corretamente atendidos e alocados nos artefatos. Foi adotada uma 
padronização de identificação dos requisitos, sempre começam com “SSS” e a 
sequência numérica iniciando em “0001”. As descrições começam com “O sistema 
deve…”, a continuação dessa frase determina o que deve ser atendido pelo requisito, 
já o detalhamento define suas razões e agrega esclarecimentos aos mesmos. 
Na tabela 5-1, encontram-se alguns requisitos do subsistema de venda da 
capacidade “Converter Orçamento em Pedido” com as suas descrições e detalhes. 
Tabela 5-1 - Lista de Requisitos 
REQUISITOS DETALHAMENTO 
SSS0001 - O sistema deve inserir 
no pedido informações contidas no 
orçamento. 
No momento da conversão de Orçamento em Pedido de 
Venda, todas as informações de produtos, formas de 
entrega e pagamento contidas no orçamento, caso não 
seja necessário alterá-las, devem ser inseridas no pedido. 
SSS0002 - O sistema deve 
assegurar que um processo de 
venda contenha, no mínimo, um 
item. 
Caso o usuário tente registrar um processo de venda 
(orçamento, pedido ou devolução) sem itens, o sistema 
deve bloquear a ação e exibir uma notificação de erro. 
SSS0003 - O sistema deve impedir, 
em orçamentos e pedidos, a 
inserção de itens sem determinar o 
ambiente. 
Os itens de orçamentos e pedidos devem estar contidos 
em ambientes. Cada ambiente é levantado no momento 
em que o consultor realiza a sondagem da obra com o 
cliente. 
SSS0004 - O sistema deve permitir 
que arquivos sejam anexados ao 
pedido de venda. 
Arquivos assinados e pagamentos devem ser anexados ao 
pedido de venda. São documentos como: pedido de 
venda, termo de entrega e questionário de entrega, além 
de comprovantes de pagamentos, cheques ou boletos. 
SSS0005 - O sistema deve calcular 
o valor de frete quando o tipo de 
entrega for por transportadora. 
O sistema deve calcular o valor do frete quando o cliente 
optar pela entrega dos produtos por uma transportadora. 
36 
 
REQUISITOS DETALHAMENTO 
SSS0006 - O sistema deve alertar 
nas notificações do departamento 
financeiro os pedidos de venda