Apostila Eng Requisitos

Prévia do material em texto

Ma. Simone Maria Viana Romano 
simone_viana@yahoo.com.br 
 
 
 
 
 
2015 
 
 
 
2 
 
Sumário 
 
PLANO DE ENSINO ......................................................................................................................... 7 
Ementa ...................................................................................................................................... 7 
Objetivo Geral ........................................................................................................................... 7 
Objetivos Específicos ................................................................................................................ 7 
Revisão Bibliográfica ................................................................................................................ 7 
Revistas e sites .......................................................................................................................... 7 
Software .................................................................................................................................... 7 
ENGENHARIA DE SOFTWARE - INTRODUÇÃO ................................................................. 8 
PROCESSO E DESENVOLVIMENTO DE SOFTWARE .......................................................... 8 
EXERCÍCIOS ..................................................................................................................................... 11 
MODELAGEM DE NEGÓCIOS ............................................................................................... 12 
OBJETIVOS........................................................................................................................................ 13 
BPMS – BUSINESS PROCESSO MANAGEMENT SYSTEM ............................................................. 13 
ELEMENTOS BÁSICOS ..................................................................................................................... 14 
TIPOS DE CONECTOR ..................................................................................................................... 14 
EXEMPLO .......................................................................................................................................... 16 
POOL E LANE (RAIA) ....................................................................................................................... 16 
ENTIDADE EXTERNA ....................................................................................................................... 17 
OBJETOS DE DADOS ....................................................................................................................... 17 
SUB-PROCESSO ................................................................................................................................ 18 
TIPOS DE FLUXO ............................................................................................................................. 19 
EVENTOS INTERMEDIÁRIOS .......................................................................................................... 19 
DETALHAMENTOS - OBJETOS DO FLUXO – ATIVIDADE .......................................................... 20 
SOFTWARE BIZAGI .......................................................................................................................... 20 
MODELAGEM DE PROCESSO ........................................................................................................ 23 
BENEFÍCIOS DO MAPEAMENTO E DA MODELAGEM DE PROCESSO ..................................... 24 
MELHORES PRÁTICAS .................................................................................................................... 24 
ABORDAGEM TOP-DOWN .............................................................................................................. 24 
DOCUMENTAÇÃO ............................................................................................................................ 25 
FERRAMENTAS ................................................................................................................................. 25 
TELA PRINCIPAL DO BIZAGI ..................................................................................................... 26 
ALTERAR O IDIOMA ........................................................................................................................ 27 
MENU PRINCIPAL ............................................................................................................................ 27 
FUNÇÕES ................................................................................................................................. 28 
PÁGINA PRINCIPAL ......................................................................................................................... 28 
FORMATAR ....................................................................................................................................... 28 
EXPORTAR/IMPORTAR .................................................................................................................... 28 
VISUALIZAR ...................................................................................................................................... 28 
FERRAMENTAS ................................................................................................................................. 28 
APOIAR .............................................................................................................................................. 28 
NOTAÇÃO .......................................................................................................................................... 29 
EXEMPLOS: ...................................................................................................................................... 30 
1) ESTUDO DE CASO: TEMPERATURA E PRESSÃO DE PACIENTES DA UTI ........................... 30 
3) ESTUDO DE CASO PIZZARIA ONLINE ...................................................................................... 31 
EXERCÍCIOS ..................................................................................................................................... 32 
TAREFA 01 – MODELAGEM DE NEGÓCIOS (VALOR 3,0 PONTOS) ........................................... 34 
REQUISITOS DE SOFTWARE ................................................................................................. 35 
IMPORTÂNCIA DOS REQUISITOS .................................................................................... 36 
 
3 
 
QUALIDADE DOS REQUISITOS ........................................................................................ 38 
TIPOS DE REQUISITOS ....................................................................................................... 39 
REQUISITOS FUNCIONAIS ............................................................................................................. 39 
REQUISITOS DE DOMÍNIO ............................................................................................................. 39 
REQUISITOS NÃO FUNCIONAIS .................................................................................................... 40 
EXEMPLO DE REQUISITOS NÃO FUNCIONAIS............................................................. 40 
PROBLEMAS COMUNS NOS REQUISITOS...................................................................... 41 
CLASSES DE REQUISITOS ................................................................................................. 41 
FONTES DE REQUISITOS ................................................................................................... 42 
PROTOTIPAÇÃO ............................................................................................................................... 42 
EXERCÍCIOS - REQUISITOS ............................................................................................................ 42 
TAREFA 02 – REQUISITOS(VALOR 2,0 PONTOS) ........................................................................ 44 
ENGENHARIA DE REQUISITOS ................................................................................................. 45 
OBJETIVOS DA ENGENHARIA DE REQUISITOS ........................................................... 46 
ENGENHEIRO DE REQUISITOS ........................................................................................ 47 
CERTIFICAÇÃO EM ENGENHARIA DE REQUISITOS ................................................... 48 
EXAME DE CERTIFICAÇÃO CPRE-FL ......................................................................................... 48 
TAREFA 03 – ENGENHARIA DE REQUISITOS (VALOR 1,0 PONTO) ........................................... 49 
ELICITAÇÃO DE REQUISITOS .................................................................................................... 51 
OBJETIVOS DA ELICITAÇÃO DE REQUISITOS ............................................................. 53 
PASSOS PARA A ELICITAÇÃO DE REQUISITOS ........................................................... 53 
DOCUMENTAÇÃO DO ELICITAÇÃO DE REQUISITOS ................................................. 53 
QUESTÕES QUE PRECISAM SER RESPONDIDAS ......................................................... 54 
IDENTIFICAÇÃO E ELICITAÇÃO DE REQUISITOS ....................................................... 54 
PROBLEMAS NA IDENTIFICAÇÃO DOS REQUISITOS ................................................................. 55 
EXEMPLO DE DECLARAÇÃO DO PROBLEMA ............................................................................. 55 
CARACTERÍSTICAS DA ELICITAÇÃO DE REQUISITOS .............................................. 56 
TÉCNICAS PARA ELICITAÇÃO DE REQUISITOS .............................................................. 56 
ETNOGRAFIA ....................................................................................................................... 58 
ENTREVISTAS ...................................................................................................................... 59 
Etapas ................................................................................................................................................. 59 
Forma de Entrevistar ......................................................................................................................... 59 
Perguntas que devem ser respondidas ............................................................................................... 59 
BRAINSTORMING ............................................................................................................... 59 
BRAINSWRITING ................................................................................................................. 61 
EXERCÍCIOS – ELICITAÇÃO DE REQUISITOS ............................................................................. 61 
TAREFA 4 – ELICITAÇÃO DE REQUISITOS (3,0 PONTOS) .......................................................... 63 
J.A.D. ............................................................................................................................................ 65 
Etapas para preparar uma reunião JAD ................................................................................... 65 
PREPARAÇÃO ................................................................................................................................... 66 
SESSÃO .............................................................................................................................................. 69 
 
4 
 
REVISÃO ............................................................................................................................................ 74 
PAPEIS DE CADA UM DENTRO DA REUNIÃO ............................................................... 74 
O CLIENTE (PATROCINADOR) ....................................................................................................... 75 
ENGENHEIRO DE SOFTWARE ........................................................................................................ 75 
EQUIPE ............................................................................................................................................. 75 
OBSERVADOR ................................................................................................................................... 75 
DOCUMENTADOR ........................................................................................................................... 75 
LÍDER DE SESSÃO OU FACILITADOR ........................................................................................... 75 
FIGURINHAS DIFÍCIEIS NA REUNIÃO .......................................................................................... 76 
TAREFA 05 – TECNICA JAD (1,0 PONTO) ...................................................................................... 79 
VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS .............................................................................. 80 
PRINCÍPIOS DA VALIDAÇÃO DE REQUISITOS ............................................................................ 81 
TIPOS DE DEFEITO .............................................................................................................. 81 
OMISSÃO ........................................................................................................................................... 81 
AMBIGUIDADE ................................................................................................................................. 82 
INCONSISTÊNCIA ............................................................................................................................. 82 
FATO INCORRETO ........................................................................................................................... 82 
INFORMAÇÃO ESTRANHA .............................................................................................................. 82 
DOCUMENTO DE REQUISITOS ......................................................................................... 82 
DEFEITOS NO DOCUMENTO DE REQUISITOS............................................................................ 82 
CONSEQUÊNCIAS ............................................................................................................................ 82 
PEQUENO CHECKLIST DE REQUISITOS ......................................................................... 83 
TÉCNICAS DE VALIDAÇÃO DE REQUISITOS ................................................................ 83 
REVISÃO DE REQUISITOS .............................................................................................................. 83 
REVISÕES DE SOFTWARE ................................................................................................. 83 
TIPOS DE REVISÃO DE SOFTWARE ............................................................................................... 84 
PROCESSO DE INSPEÇÃO DE SOFTWARE ................................................................................... 84 
PROCESSO TRADICIONAL DE INSPEÇÃO .................................................................................... 85 
GERENCIAMENTO DE MUDANÇA DE REQUISITOS ........................................................ 86 
EVOLUÇÃO DOS REQUISITOS .......................................................................................... 88 
REQUISITOS PERMANENTES E VOLÁTEIS.................................................................... 88 
CLASSIFICAÇÃO DOS REQUISITOS............................................................................................... 88 
PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS ........................................................ 88 
RASTREABILIDADE .......................................................................................................................... 89 
SUPORTE À FERRAMENTA: ............................................................................................................89 
ETAPAS PARA O RASTREAMENTO ................................................................................................. 89 
EXERCÍCIOS – VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS ................................................ 90 
MATRIZ DE RASTREABILIDADE ......................................................................................... 92 
RASTREABILIDADE ............................................................................................................ 92 
OBJETIVOS........................................................................................................................................ 93 
Matriz de Rastreabilidade Definidas ....................................................................................... 94 
EXERCÍCIOS – MATRIZ DE RASTREABILIDADE .......................................................................... 95 
ORIENTAÇÃO A OBJETOS ..................................................................................................... 96 
HISTÓRIA .............................................................................................................................. 96 
CONCEITOS FUNDAMENTAIS .......................................................................................... 97 
OBJETO ............................................................................................................................................. 97 
ATRIBUTO ......................................................................................................................................... 98 
OPERAÇÃO X MÉTODO .................................................................................................................. 98 
 
5 
 
CLASSE .............................................................................................................................................. 99 
ESTADO ............................................................................................................................................. 99 
MENSAGEM ...................................................................................................................................... 99 
ENCAPSULAMENTO ........................................................................................................................ 99 
HERANÇA ........................................................................................................................................ 100 
POLIMORFISMO ............................................................................................................................ 101 
ANÁLISE ORIENTADA A OBJETOS ............................................................................... 101 
EXERCÍCIOS – ORIENTAÇÃO A OBJETOS .................................................................................. 102 
UML ........................................................................................................................................... 105 
HISTÓRIA ............................................................................................................................... 105 
CONCEITO ........................................................................................................................... 106 
UTILIZAÇÃO ....................................................................................................................... 107 
NOTAÇÃO ........................................................................................................................... 107 
VANTAGENS ...................................................................................................................... 107 
FASES DO DESENVOLVIMENTO UML .......................................................................... 107 
COMPONENTES DA UML ................................................................................................. 108 
MODELOS DE ELEMENTOS ............................................................................................ 108 
CLASSES .......................................................................................................................................... 108 
OBJETOS ......................................................................................................................................... 108 
ESTADOS ......................................................................................................................................... 109 
PACOTES ......................................................................................................................................... 109 
COMPONENTES ............................................................................................................................. 109 
RELACIONAMENTOS ..................................................................................................................... 110 
MECANISMOS GERAIS .................................................................................................................. 113 
DIAGRAMAS ....................................................................................................................... 113 
DIAGRAMAS ESTRUTURAIS (ESTÁTICOS) .................................................................................. 113 
DIAGRAMAS COMPORTAMENTAIS (DINÂMICOS) .................................................................... 114 
EXERCÍCIOS - UML ........................................................................................................................ 115 
ESPECIFICAÇÃO DE REQUISITOS ................................................................................................ 117 
MODELO DE ESPECIFICAÇÃO DE REQUISITOS ......................................................... 117 
PASSOS PARA ESPECIFICAR OS REQUISITOS ........................................................................... 117 
VISÃO E ESCOPO ............................................................................................................... 119 
EXERCÍCIOS ................................................................................................................................... 119 
TAREFA 06 – ESPECIFICAÇÃO DE REQUISITOS (2,0 PONTOS) .............................................. 120 
DIA PORTABLE ...................................................................................................................... 120 
DIAGRAMA DE CASO DE USO ............................................................................................ 121 
CASOS DE USO ................................................................................................................... 121 
ATOR .................................................................................................................................... 122 
CASO DE USO ..................................................................................................................... 122 
COMO IDENTIFICAR CASOS DE USO ......................................................................................... 123 
CENÁRIO ............................................................................................................................. 123 
RELACIONAMENTO DE EXTENSÃO ............................................................................. 123 
RELACIONAMENTO DE INCLUSÃO .............................................................................. 124 
 
6 
 
RELACIONAMENTO DE ESPECIALIZAÇÃO................................................................. 124 
RELACIONAMENTO ENTRE CASOS DE USO .............................................................................. 124 
EXEMPLO: ESTUDO DE CASO – LOCADORA DE VEÍCULOS .................................................. 126 
ANÁLISE DE CASOS DE USO .......................................................................................... 127 
EXERCÍCIOS ...................................................................................................................................127 
TAREFA 07 – DIAGRAMA DE CASO DE USO .............................................................................. 131 
DIAGRAMA DE CLASSES .................................................................................................... 131 
CLASSE ................................................................................................................................ 131 
CONVENÇÕES ................................................................................................................................ 132 
ATRIBUTOS ........................................................................................................................ 132 
OPERAÇÕES ....................................................................................................................... 132 
Visibilidade ........................................................................................................................... 133 
RELACIONAMENTOS ....................................................................................................... 133 
ASSOCIAÇÃO .................................................................................................................................. 133 
AGREGAÇÃO .................................................................................................................................. 134 
COMPOSIÇÃO ................................................................................................................................ 134 
CLASSE DE ASSOCIAÇÃO ............................................................................................................. 134 
HERANÇA ........................................................................................................................................ 135 
DIAGRAMA DE CLASSE ................................................................................................... 136 
COMO FAZER UM DIAGRAMA DE CLASSES .............................................................................. 137 
IDENTIFICANDO AS CLASSES ...................................................................................................... 137 
IDENTIFICANDO OS ATRIBUTOS ................................................................................................ 137 
IDENTIFICANDO O COMPORTAMENTO .................................................................................... 138 
IDENTIFICANDO GENERALIZAÇÕES .......................................................................................... 138 
IDENTIFICANDO ASSOCIAÇÃO ................................................................................................... 138 
EXEMPLO – ESTUDO DE CASO: LOCADORA DE VEÍCULOS .................................................. 138 
EXERCÍCIOS ................................................................................................................................... 139 
DIAGRAMA DE OBJETOS .................................................................................................... 142 
EXERCÍCIOS ....................................................................................................................... 143 
TAREFA 08 – DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS ....................................... 144 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 
 
 
 
 
PLANO DE ENSINO 
 
Ementa 
 
Engenharia de Requisitos como um processo. Categorias de Requisitos: requisitos 
do usuário, requisitos do sistema, requisitos funcionais e requisitos não-funcionais. 
Elicitação e Análise de Requisitos. Especificação de Requisitos com UML: modelagem 
de casos de uso, especificação de casos de uso e modelagem do problema utilizando 
classes. Documentos de Requisitos. Gerenciamento de Requisitos: gerenciamento de 
mudanças e rastreabilidade. 
 
Objetivo Geral 
Compreender a responsabilidade ética, profissional, social e política. 
Compreender os princípios fundamentais da Engenharia de Requisitos. Desenvolver os 
métodos, técnicas e ferramentas de apoio às atividades da Engenharia de Requisitos. 
 
Objetivos Específicos 
Utilizar a UML para a especificação de Sistemas de Informação no contexto da 
Engenharia de Software. 
 
Revisão Bibliográfica 
GUEDES, Gilleanes T. A. UML 2 – Guia Prático. Novatec, 2014, 192 p. 
LIMA, Adilson da Silva. UML 2.5 – Do Requisito à Solução. Erica, 2014. 368 p. 
MACHADO, Felipe Nery. Análise e Gestão de Requisitos de Software – Onde Nascem 
os Sistemas. Erica, 2014. 288 p. 
PAULA, Wilson de Pádua Filho. Engenharia de Software – Fundamentos, Métodos e 
Padrões. Rio de Janeiro: LTC, 2009. 1358 p. 
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson, 2011. 544 p. 
 
Revistas e sites 
 Revista Engenharia de Software: www.devmedia.com.br; 
 http://engenhariadesoftware.blogspot.com/; 
 http://www.sigsoft.org/; 
 http://rildosan.blogspot.com/; 
 http://www.yuml.me; 
 http://www.wthreex.com/rup/; 
 http://www.engenharia-software.com; 
 http://www.ibqts.com.br/ 
 http://www.tmtestes.com.br/ 
 http://www.incremental.com.br/ilhadosrequisitos/ 
 
Software 
 Dia Portable http://dia-portable.softonic.com.br/ 
 Bizagi http://www.bizagi.com/eng/products/ba-modeler/modeler.html 
http://www.devmedia.com.br/
http://engenhariadesoftware.blogspot.com/
http://www.sigsoft.org/
http://rildosan.blogspot.com/
http://www.yuml.me/
http://www.wthreex.com/rup/
http://www.engenharia-software.com/
http://www.ibqts.com.br/
http://www.tmtestes.com.br/
http://www.incremental.com.br/ilhadosrequisitos/
http://dia-portable.softonic.com.br/
http://www.bizagi.com/eng/products/ba-modeler/modeler.html
 
8 
 
 
 
 
 
ENGENHARIA DE SOFTWARE - INTRODUÇÃO 
 
A Engenharia de Software engloba, além dos processos técnicos de 
desenvolvimento de software, atividades de gerenciamento de projeto de software e 
desenvolvimento de ferramentas, métodos e teorias para apoiar a produção de software. 
Oferece também uma base para a construção de software de alta qualidade e 
produtividade. Suas áreas de conhecimento são: Projeto (Design) de Software, 
Construção de Software, Teste de Software, Qualidade de Software, Gerenciamento de 
Configuração de Software, Gestão de Engenharia de Software, Gestão de Engenharia de 
Software, Ferramentas e Métodos de Engenharia de Software, Processos de Engenharia 
de Software, Manutenção de Software e Requisitos de Software (objetivo desta 
disciplina). 
 
PROCESSO E DESENVOLVIMENTO DE SOFTWARE 
 
 
 
Para Davenport (1994) PROCESSO é um conjunto estruturado e dimensionado 
de atividades de trabalho, com começo, meio e fim, consumindo insumos e gerando 
produtos claramente especificados para um cliente ou mercado em particular. 
Ou ainda, é o conjunto de atividades inter-relacionadas ou interativas que 
transformam insumos(entradas) em produtos (saídas) (ABNT, 2000). 
Os principais componentes de um processo são: 
 
Figura 1 - Principais Componentes de um Processo 
Enquanto processo é um conjunto definido de atividades ou comportamentos 
executados por humanos ou máquinas, um processo de negócio pode ser definido como 
O que é processo de software? 
O que é desenvolvimento de 
software? 
 
 
9 
 
um trabalho realizado de ponta-a-ponta que entrega de valor aos clientes (ABPMP1, 
2009). 
A abordagem de processo está sendo aplicada na Engenharia de Software, pois as 
origens dos requisitos baseiam-se principalmente no processo de trabalho, 
conhecimento especialista e regras da organização. Por isto é importante estudar o 
processo, o processo de negócio e a interação entre negócios e sistemas (Pa et al 2011). 
 
Figura 2 - Relação entre Objetivos de Negócio, Processos de Negócio e Sistemas. 
De acordo com a hierarquia dos processos, pode-se compreender que: 
 Processo: conjunto de atividades inter-relacionadas, que transformam entradas 
em saídas; 
 Subprocessos: conjunto de atividades inter-relacionadas que transformam 
entradas em saídase podem envolver um ou mais departamentos; 
 Atividades: ações realizadas nos processos e/ou subprocessos do sistema na 
transformação das entradas e saídas. São realizadas por departamentos ou 
pessoas; 
 Tarefa: ações realizadas nas atividades do sistema na transformação das 
entradas e saídas, como por exemplo, departamentos ou pessoas; 
 Regras: condições de execução da atividade ou tarefa, ou seja, são normas, 
procedimentos e critérios necessários para a execução de uma tarefa. 
 
1 ABPMP – Associação de Profissionais de Gerenciamento de Processos de Negócio 
(http://www.abpmp-br.org/) 
 
http://www.abpmp-br.org/
 
10 
 
 
Figura 3 - Hierarquia de Processos 
PROCESSO DE SOFTWARE é um conjunto de atividades que objetivam o 
desenvolvimento e a evolução de software. Ou seja, envolve todas as atividades 
relacionadas ao desenvolvimento, desde a análise de negócio, definição de requisitos do 
sistema, construção do produto de software e gerenciamento de projetos até as técnicas 
de teste e manutenção de software: 
 
Figura 4 - Etapas de um Processo de Software 
Essas etapas podem ser executadas em diferentes sequências e agrupadas em 
diferentes etapas, de acordo com a metodologia adotada. Cada etapa pode ser 
considerada um processo ou um conjunto de processos. 
Em resumo, as principais atividades são: 
 ESPECIFICAÇÃO: define o que o sistema deverá fazer, considerando as suas 
restrições. 
 DESENVOLVIMENTO: produção do software. 
 VALIDAÇÃO: checagem se o software faz o que o usuário deseja. 
 EVOLUÇÃO: mudanças no software para atender às novas demandas. 
Desenvolvimento de software é um conjunto de atividades para especificar, 
projetar, implementar e testar sistemas de software. 
As atividades necessárias para o desenvolvimento de software são: especificação, 
projeto, validação e evolução. 
Para o sucesso do desenvolvimento do software é necessário um entendimento dos 
requisitos de software. Não importa se foi bem projetado e/ou codificado; se o software 
tiver tido uma análise e uma especificação mal feita, o usuário se sentirá frustrado. 
Análise de requisitos é um processo de descoberta, especificação, modelagem e 
refinamento. 
Negócios Requisitos Projeto Codificação Teste Implantação Manutenção 
 
11 
 
O analista de sistema ou engenheiro de software estabelece o escopo
2
 do software 
e durante o planejamento do projeto de software vai sendo refinado e seus detalhes 
sendo aperfeiçoados e através da criação de diagramas, fluxos e modelos, o problema 
torna-se compreensível. 
O analista/engenheiro e o usuário possuem um papel ativo na análise e 
especificação de requisitos. 
O cliente ou usuário tenta reformular um conceito de função e desempenho de 
software, sem detalhes concretos. Já o analista, indaga, consulta e soluciona os 
problemas. 
Porém, a análise e a especificação de requisitos parece ser uma tarefa simples, mas 
não é bem assim... 
A comunicação é um fator importante, pois as interpretações erradas e 
informações falsas surgem a todo momento. A ambiguidade é provável. 
Podemos entender o dilema, repetindo a declaração de um cliente anônimo: 
 
 
 
 
 
EXERCÍCIOS 
 
1. Quais as atividades do processo de desenvolvimento de software? 
a) Especificação, Desenho e Implementação, Validação e Manutenção; 
b) Planejamento, Desenho, Desenvolvimento e Instalação; 
c) Estudo, Desenho, Codificação e Implementação; 
d) Especificação, Desenho e Desenvolvimento. 
 
2. O processo de desenvolvimento de software é: 
 
2 ESCOPO: entendimento dos objetivos do projeto, dos resultados esperados e à descrição 
sumária do trabalho a ser realizado. É feita na etapa de iniciação do projeto e detalhada na 
etapa de planejamento. Descreve as características do produto e o trabalho necessário para 
realizá-lo. O consenso inicial sobre o escopo do projeto é estabelecido entre pessoas, 
organizações ou departamentos de organizações, sendo uma pessoa, empresa, o cliente, o 
demandante do serviço, o prestador de serviços designado ou outra pessoa, para fazê-lo. 
“Sei que você acredita que entendeu o que 
acha que eu disse, mas não estou certo que 
percebeu que aquilo que ouviu não é o que 
eu pretendia dizer...” 
 
ESCOPO 
É O QUE ESTÁ 
SENDO 
PROJETADO!!!! 
 
 
12 
 
a) É o processo em que cada atividade interage com outras para atingirem o 
sistema final; 
b) É o desenvolvimento de software num só processo; 
c) É o desenvolvimento de software ignorando um ou mais processos para 
cumprir os requisitos; 
d) Repetição das atividades dos processos de desenvolvimento de software para 
responder às mudanças de requisitos. 
 
3. Indique quais as atividades de um projeto que consome mais tempo: 
a) Atividades de gestão; 
b) Planejamento; 
c) Calendarização; 
d) Gestão de risco. 
 
04. PESQUISE: Colete dados sobre projetos de sistemas de software cancelados ou 
fracassados. Apresenta uma provável causa para essa consequência. 
 
 
 
MODELAGEM DE NEGÓCIOS 
 
A modelagem ajuda a entender os processos de negócio, permite ver todos os 
recursos envolvidos, as dependências e limitações de cada processo. O objetivo é definir 
e criticar o processo, identificar principalmente as regras de trabalho e as oportunidades 
de melhorias. Os seguintes questionamentos para a modelagem podem ser realizados: 
 
Tabela 1 - Questionamentos da Modelagem 
 
 
QUEM? 
 
Quem é o cliente ou usuário beneficiário do processo? 
Quem executa? 
Quem gerencia? 
Quem fornece? 
Quem participa das decisões? 
 
 
 
O QUE? 
Quais são as entradas do processo? 
Quais são as saídas? 
Quais são os indicadores? 
Quais são as metas? 
Quais são os recursos ou ferramentas? 
Quais são os problemas? 
Quais são os pontos positivos? 
Quais são os métodos ou tecnologias empregados? 
 
QUANDO? 
Quando é planejado o processo? 
Quando é executado? 
Quando é avaliado? 
 
ONDE? 
Onde é planejado o processo? 
Onde é executado? 
Onde é avaliado? 
POR QUE? Por que ou para que este processo existe. 
 
 
Como é planejado o processo? 
Como é executado? 
 
13 
 
 
COMO? 
Como é avaliado? 
Como as informações são registradas e disseminadas? 
Como é avaliada a satisfação do cliente? 
Como está o desempenho do processo? 
 
 
É uma notação de Modelagem de Processos de Negócio ou BPMN (Business 
Process Modeling Notation). 
Lançada em 2004 e desenvolvida pelo BPMI3, que tinha o apoio das principais 
empresas de TI do mundo, como IBM, SAP, Oracle e Microsoft. 
Em 2005, o BPMI juntou-se ao OMG (Object Management Group), mesma 
organização internacional que controla a UML. A OMG é uma associação aberta e não 
lucrativa que existe desde 1989. O objetivo da OMG é desenvolver e manter padrões e 
especificações técnicas para a indústria de software. 
BPMN é uma notação visual para representação de fluxos de processos que pode 
ser mapeada para diversos formatos de execução: 
 A notação BPMN proporciona às ferramentas de desenho o uso de uma 
representação gráfica padronizada; 
 E esta representação padronizada facilita o entendimento na própria 
organização e também entre organizações. 
OBJETIVOS 
 
 Prover uma notação padronizada que seja facilmente inteligível pelos Stakeholders; 
 Há vários tipos de stakeholders: Os analistas de negócio que criam e refinam os 
processos, os desenvolvedores que são responsáveis por implementá-los e os 
administradores que os gerenciam e monitoram; 
 Assim, o BPMN deve servir como uma linguagem comum para tentar diminuir as 
falhas de comunicação existentes entre o design do processo e sua implementação. 
BPMS – BUSINESS PROCESSO MANAGEMENT SYSTEM 
 
É um tipo de software que age como uma ferramenta para o gerenciamento 
completo (modelagem, redesenho, implementação e monitoramento) dos processos de 
negócios de uma organização. 
Hoje, de acordocom a OMG, existem aproximadamente 40 produtos 
“homologados” que implementam no todo ou em parte, a notação BPMN. 
São produtos de modelagem ou mesmo de execução (Workflow-BPM). 
 
3 BPMI – Business Process Management Initiative (http://www.bpmi.org). 
 
http://www.bpmi.org/
 
14 
 
ELEMENTOS BÁSICOS 
 
Figura 5 – Elementos básicos da modelagem de negócios 
TIPOS DE CONECTOR 
 
Há seis formas de conectar as tarefas: 
 SEQUÊNCIA: é como as atividades são ligadas de forma mais simples. Elas são 
executadas sequencialmente, conforme o fluxo das setas: 
 
Figura 6 - Exemplo de Sequência 
 PARALELA: quando duas ou mais atividades podem ser executadas paralelamente em 
qualquer ordem, ao mesmo tempo ou não. As atividades paralelas não interferem uma 
nas outras, mas todas as atividades devem terminar para o fluxo poder continuar: 
 
Figura 7 - Exemplo de Paralela 
 CONDICIONAL (EXCLUSIVE XOR): o fluxo segue um caminho ou outro, 
dependendo de uma condição: 
 
15 
 
 
Figura 8 - Exemplo de condição (XOR) 
 
 CONDICIONAL (INCLUSIVE OR): neste caso é permitido que mais de uma 
condição associada à conexão seja verdadeira ao mesmo tempo (no mínimo uma), dando 
origem a fluxos em paralelo: 
 
Figura 9 – Exemplo de condição (OR) 
 
 CONDICIONAL (COMPLEXOS): foram criados para dar mais flexibilidade ao 
BPMN, permitindo que o analista de negócio determine regra de negócio que irá dar 
origem ou não às atividades subsequentes. A regra deve estabelecer, SEMPRE que pelo 
menos 1 caminho será verdadeiro e o fluxo terá continuidade: 
 
Figura 10 - Exemplo de condição complexo 
 
16 
 
 GATEWAY (PARALELO): vários caminhos executados ao mesmo tempo, 
executando atividades em paralelo. Não há processo de decisão, todos os caminhos são 
seguidos. Objetivo é otimizar o tempo de processamento com atividades ocorrendo em 
paralelo: 
 
Figura 11 - Exemplo de Gateway 
EXEMPLO 
 
O paciente chega na clínica e é atendido na recepção. Após isto, enquanto aguarda 
a consulta, uma enfermeira mede a pressão e temperatura. Se for necessário 
(dependendo do estado do paciente), deve ser feito algum exame laboratorial. O 
próximo passo é a consulta em si e, finalmente, o paciente paga a consulta e é liberado. 
Apenas olhando o diagrama, não terá uma noção exata de quem está fazendo o quê. 
 
Figura 12 – Exemplo de modelagem de negócios 
POOL E LANE (RAIA) 
 
Cada pool representa uma entidade (um sistema, sub-sistema ou um participante) 
do processo e cada raia representa um ator contido nesta entidade. 
 
17 
 
 
Figura 13 - Exemplo de Pool e Lane 
ENTIDADE EXTERNA 
 
Obs. A mensagem só pode ser utilizada entre pools. 
 
Figura 14 – Exemplo de Mensagem Interna 
OBJETOS DE DADOS 
 
Utilizados para mostrar como os dados e os documentos são utilizados 
dentro do processo. 
Podem ser utilizados para definir as entradas e saídas de uma atividade e 
também podem conter o "estado" atual de um documento, que pode ser alterado 
durante o processo. 
O documento "Pedido", que é utilizado para as atividades se comunicarem, pode 
possuir os estados de [Aprovado] ou [Rejeitado], dependendo da condição. 
 
18 
 
 
Figura 15 – Exemplo de objeto de dados 
SUB-PROCESSO 
 
Normalmente é utilizado para tornar mais simples alguns diagramas 
muito complexos. Agrupa-se atividades em um sub-processo, deixando o 
diagrama mais limpo. Ao se clicar no sinal de mais, o sub-processo é 
expandido. 
 
Exemplo: A aprovação do empréstimo em si é um sub-processo dentro do 
processo todo de solicitação. 
 
Figura 16 – Exemplo de sub-processo 
 
Podemos expandir um sub-processo: 
 
Figura 17– Exemplo de expansão de sub-processo 
 
19 
 
TIPOS DE FLUXO 
 
TIPO DESCRIÇÃO 
 
None (nenhum): Serve para indicar um início de um sub-processo, ou então 
quando o início do processo não é definido por nenhum dos outros tipos de evento 
de início. 
 
Message (mensagem): Indica que o fluxo somente inicia quando uma determinada 
mensagem é recebida. Por exemplo: "Novo usuário incluído". 
 
Timer (temporizador): Indica que o fluxo inicia após um determinado tempo ter 
passado, ou quando chegar uma determinada hora específica. 
 
Rule (Regra): Indica que o fluxo inicia quando uma determinada condição é 
atingida. Por exemplo: "100 pedidos incluídos", "Temperatura maior que 35 
graus". 
 
Link (ligação): Basicamente, liga o final de um fluxo ao início de outro. 
 
Multiple (múltiplos): Indica que existem várias maneiras de se iniciar o fluxo, mas 
basta apenas uma delas para que o fluxo se inicie. Junto ao elemento de início, 
deve-se colocar a lista de "triggers" que farão o fluxo iniciar. Por exemplo: 
Message: "Novo usuário incluído". 
Rule: "Mais que 10 pedidos pendentes". 
 
Fim do fluxo. 
 
EVENTOS INTERMEDIÁRIOS 
 
Os eventos intermediários, quando colocados entre as tarefas, representam fatos 
que podem ocorrer entre as tarefas. Tanto pode ser de entrada (receber uma mensagem, 
por exemplo), quanto de saída (enviar uma mensagem). 
 
Figura 18 – Exemplo de eventos intermediários 
Quando os eventos intermediários estão anexados às tarefas, significa que a tarefa 
deve ser interrompida caso o evento seja acionado. Veja o exemplo abaixo, em que a 
tarefa é interrompida caso não receba o evento de confirmação em dois dias. 
 
20 
 
 
Figura 19 – Exemplo de eventos intermediários temporários 
DETALHAMENTOS - OBJETOS DO FLUXO – ATIVIDADE 
 
 SUB-PROCESSO LOOP – possui uma condição associada que é 
verificada após cada execução; se a condição for verdadeira, a tarefa 
é reiniciada automaticamente! O Loop ocorre até a condição ser 
falsa; 
 
 
 
SUB-PROCESSO MULTI-INSTÂNCIA – possui uma 
expressão ou condição padrão associada que é pré-avaliada para 
determinar a quantidade de vezes que a tarefa será executada; 
 
 
 AD HOC – grupo de atividades que não tem sequência 
pré-definida. Não fazemos as ligações internas; 
 
 
 
 
 COMPENSAÇÃO – conjunto de atividades necessárias para 
cancelar o que foi realizado em uma outra atividade. 
 
 
SOFTWARE BIZAGI 
 
O Tutorial BizAgi é sobre a modelagem (ou diagramação) de processos, que é 
segundo passo da metodologia Process-M3®(1º. Mapeamento, 2º. Modelagem e 3º. 
Melhoria). A modelagem ajuda a entender os processos de negócio, permite ver todos 
os recursos envolvidos, as dependências e limitações de cada processo. Contudo, para 
modelar os processos, é preciso conhecer Gestão por Processo (BPM), saber escolher 
uma notação adequada e selecionar a ferramenta “certa”, estes são fatores críticos. 
 
 
21 
 
 
Figura 20 – Tela principal do Bizagi 
A BPMN é uma notação gráfica e visual, reconhecida como padrão para desenho 
de processo, para aumentar produtividade devemos utilizar uma boa ferramenta. A 
ferramenta certa é aquela que depois da Análise de Custo versus Benefício, é a que 
melhor atende as necessidades do negócio. 
Quem está acostumado a gerenciar processos e quer aprender a criar modelos do 
ponto de vista do negócio, pode utilizar a notação BPMN (Business Process Modeling 
Notation), mantida pela OMG. Na tarefa de criar estes modelos o Process Modeler da 
BizAgi é a ferramenta ideal para aprender a modelar. Ela suporta integralmente a 
BPMN. Tem as principais estruturas, core elements, full element se atributos. A 
ferramenta permite exportar os gráficos para diversos tipos de formatos, tais como: 
imagem, PDF, Microsoft Visio e Word e XPDL. A partir da versão 1.5.1(que é base 
deste tutorial) é também possível fazer a publicação do modelo na Web, exportar para 
ferramenta Wiki ou ainda exportar para Microsoft Sharepoint. 
Descrição segundo o fabricante: O BizAgi Process Modeler é a forma mais fácil 
de utilizar um modelador de processos do mercado. Desenhe e documente seus 
processos de uma forma rápida e direta. Com comportamento "intelisense" e com um 
visual único, vocêpoderá modelar os processos rapidamente sem esperar longas rotinas 
de validação. 
O BizAgiProcessModeler, permite modelar (desenhar), documentar e publicar os 
processos de negócio. 
 
22 
 
Para fazer o download da ferramenta BizAgi Process Modeler vá ao 
endereço:http://www.bizagi.com/index.php?option=com_content&view=article&id=27
&catid=5&Itemid=98. 
REQUISITOS 
 
-Processador: 500 Mhz ou maior; 
-Memória: 256 MB de Ram ou maior; 
-Hard Drive (HD): 50 MB de espaço disponível ou mais; 
-Monitor : Resolução de 800 x 600 ou maiorSistema Operacional: (BizAgi “roda” 
somente em Windows)-Windows Server 2008; 
-Windows Vista; 
-Windows 7; 
-Windows 2000 Service Pack 3; 
Software (BizAgi “roda” somente em Windows)-Microsoft Framework .Net 2.0; 
-Opcionais: 
-Microsoft Word 2003 ou maior (para fazer exportar diagramas); 
-Microsoft Visio 2003 ou maior (para fazer exportar diagramas)-PDF Reader (Ler 
diagramas/documentação exportados); 
Browser (Ler diagramas/documentação exportados). 
 
Dica: O BizAgi utiliza o Microsoft framework .Net 2.0, se framework não estiver 
instalado, a ferramenta não funcionará, para ela funcionar será necessário instalar o 
framework .Net 2.0. 
CARACTERÍSTICAS 
 
-Suporte a BPMN versão 1.2(http://www.bpmn.org); 
-Suporte XPDL versão 2.1(http://www.wfmc.org/xpdl.html); 
-Publicação de Modelo (Web, Wiki e exportação para Sharepoint; 
-Não existe versão para Linux ou MAC; 
-Versão “free” ; 
-Vídeos e tutoriais; 
-Possibilidade de “anexar” documentos, planilhas e etc.; 
-Exportar o modelo para PDF, Visio, Word e imagens; 
-Suporte ao idioma português; 
-Fácil de aprender (baixa curva de aprendizado) O que faltou na ferramenta: 
-A simulação de processos (somente na versão paga) 
-Suporte a BPEL (Business Process Execution Language); 
-Mais documentação. 
MAPEAMENTO DE PROCESSO 
 
O Mapeamento de Processo é uma ferramenta gerencial e de comunicação que 
tem a finalidade de ajudar a melhorar os processos existentes ou de implantar uma nova 
estrutura voltada para processos. 
Os processos de negócio são os primeiros processos a serem identificados, depois 
os processos de apoio (aos processos de negócio) e por fim os processos de controle 
e/ou reguladores. O mapeamento também auxilia a empresa a enxergar claramente os 
pontos fortes, pontos fracos (pontos que precisam ser melhorados tais como: 
complexidade na operação, reduzir custos, gargalos, falhas de integração, atividades 
 
23 
 
redundantes, tarefas de baixo valor agregado, retrabalhos, excesso de documentação e 
aprovações), além de ser uma excelente forma de melhorar entendimento sobre os 
processos e aumentar a performance do negócio. 
OBJETIVO DO MAPEAMENTO DE PROCESSOS 
 
Identificar e buscar um melhor entendimento dos processos de negócios existentes 
(AS-IS) e dos futuros (TO-BE) para melhorar o nível de satisfação do cliente e 
aumentar desempenho do negócio. 
 
Técnicas de Mapeamento de Processos: 
 
 Entrevistas, questionários, reuniões e workshops. 
 Observação de campo. 
 Análise da documentação existente. 
 Análise de sistemas legados. 
 Coleta de evidências. 
MODELAGEM DE PROCESSO 
 
 
Figura 21 - Modelagem de Processo 
É a elaboração de um diagrama ou mapa do processo de negócio e a 
documentação que descreve suas propriedades e características, que identifica as 
atividades realizadas e as informações que fluem entre elas. 
Após o Mapeamento, inicia-se o trabalho de Modelagem. O primeiro documento 
resultante deste trabalho é o Mapa de Processos, o objetivo deste mapa é fornecer uma 
única visão dos processos da empresa, seus relacionamentos, atividades/tarefas, 
stakeholders, papéis e responsabilidades e o fluxo de valor dos processos. 
O Mapa de processos deve ser apresentado em uma linguagem gráfica que seja 
simples e que facilite o entendimento de todos os envolvidos e que permita: 
 Exibir os detalhes dos processos de modo gradual e controlado; 
 Encorajar precisão na descrição do processo; 
 
24 
 
 Focar a atenção nas interfaces entre os processos; 
 Prover uma análise de processos poderosa e consistente com o vocabulário de 
negócio. 
A modelagem de processo aplicada no contexto da Engenharia de Requisitos, 
principalmente no desenvolvimento e manutenção de sistemas, permite identificar, as 
informações necessárias do sistema facilitando assim, a definição de seus requisitos 
funcionais e não funcionais, auxiliando assim uma melhor análise e projeto do sistema 
(Eriksson; Penker, 2011). 
BENEFÍCIOS DO MAPEAMENTO E DA MODELAGEM DE PROCESSO 
 
 Melhora a comunicação; 
 Facilita a visualização; 
 Reduz o nível de abstração; 
 Ajuda no entendimento do que deve ser feito; 
 Auxilia na identificação de quem deve fazer o quê; 
 É a base documentação. 
MELHORES PRÁTICAS 
 
 Objetivo do modelo é comunicar; 
 Modelos devem ser simples e intuitivos; 
 Modelos devem ser adequados a cultura da empresa; 
 Ferramentas podem influenciar na escolha da notações, portanto escolha primeiro a 
notação de depois a ferramenta.-Modelos evoluem com a organização; 
 A combinação de notações e técnicas pode ser usada para facilitar o entendimento; 
 Para melhorar a produtividade considere adotar uma ferramenta; 
 Procure adotar uma notação para que seja padrão de mercado. 
ABORDAGEM TOP-DOWN 
A decomposição do processo facilita entendimento e identificação dos seus sub-
processos e/ou as atividades. 
 
 
Figura 22 – Abordagem Top-Down 
 
25 
 
DOCUMENTAÇÃO 
 
Parte da documentação é o próprio modelo com seus elementos, com os nomes, 
atributos, descrições, papéis entidades de negócio... Mas, também documentos 
suplementares externos ao diagrama, tais como: Politicas, Procedimentos, Instruções de 
trabalho, Planilhas, Textos, Especificações técnicas, Fotos, Desenhos e etc. 
FERRAMENTAS 
 
As ferramentas de modelagem são softwares usados para mapear os processos de 
negócios criando modelos que retratam a atividade produtiva da empresa ou órgão 
estudado. Reproduzem o comportamento dos negócios, seus processos e suas 
atividades, propiciando ações de análise e simulação. Podem ser classificadas em: 
 Modelagem (diagramação): mapeia mas não disponibiliza meios de registros de 
informações de forma estruturada visando sua caracterização. Exemplo: 
o Ms Visio – www.microsoft.com; 
o Ingrafx Flowcharter – www.igrafx.com; 
o SmartDraw – www.smartdraw.com. 
 BPM (Gestão de Processos): suporte em gestão de processos em qualquer nível com 
modelagem, documentação, análise, simulação e demais recursos de gestão de 
processos. Exemplo: 
o Bizagi – www.bizagi.com; 
o Savvion – www.savvion.com; 
o ARIS – www.ids-scheer.com. 
http://www.microsoft.com/
http://www.igrafx.com/
http://www.smartdraw.com/
http://www.bizagi.com/
http://www.savvion.com/
http://www.ids-scheer.com/
 
26 
 
TELA PRINCIPAL DO BIZAGI 
 
Figura 23 – Tela do BizAgi 
A BPMN é divida em três áreas, nós vamos discuti-las: 
 Core Elements (Elementos Básicos); 
 Full Elements (Todos Elementos); 
 Atributtes (Atributos); 
 Core Elements: São elementos básicos da notação para modelar processos 
com baixo nível de complexidade (ou seja simples); 
 Full Elements: Todos os elementos da notação estão disponíveis, processos 
simples e complexos podem ser modelados. 
 Atributos: São as propriedades dos elementos e diagramas: 
[1] No BizAgi (áreas equivalem a Modo), assim temos dois modos: 
-Core (Básico) = Core Elements; 
-Extended (Estendido) = Full Elements. 
 
 COMO SELECIONAR O MODO: 
[1.1] Clique no botão para abrir a lista de seleção; 
[1.2] Selecione o modo. 
 
27 
 
ALTERAR O IDIOMA 
 
Figura 24 – Alteração do Idioma 
BizAgi tem suporte a idiomas (línguas), você poderá 
selecionar a língua de sua preferência a partir de uma lista 
predefinida. 
[2]–Para selecionar a Língua (idioma) que será utilizada no 
BizAgi. 
 
COMO SELECIONAR A LINGUAGEM: 
 
[2.1] Clique no botãopara abrir a lista de seleção; 
[2.2 ] Selecione a língua desejada; 
[2.3] Após a seleção da língua, será necessária fechar a 
ferramenta e abrir novamente para que a mudança tenha efeito. 
Clique no botão OK. 
MENU PRINCIPAL 
 NOVO – Criar um novo arquivo; 
 ABRIR – Abrir um arquivo existente [1] mostra dos últimos arquivos abertos; 
 IMPORTAR – Importar os modelos e os dados de outra localidade opções: Visio, 
XPDL e Atributos; 
 GRAVAR – Grava em disco o arquivo atual. 
 
28 
 
 GRAVAR COMO – Grava em disco arquivo atual com novo nome ou novo local 
(pasta). 
 IMPRIMIR – Impressão do diagrama, você tem três opções: Print, envia para 
impressora, Quick Print envia o digrama direto para impressora padrão e Print 
Preview, faz pre-visualização antes da impressão. 
 ENVIAR – Enviar um cópia do modelo para outras pessoas, opções: e-mail, enviar 
como anexo, enviar o modelo como imagem ou enviar o modelo como XPDL. 
 EXPORTAR – Exportar os modelos para uso em outras aplicações Opções: 
Imagens, Word, PDF, Visio, XPDL e Atributos. 
 PUBLICAR – Exportar e publicar o modelo opções: Web, Sharepoint e Wiki. 
 REGISTRAR – Fazer registro do usuário da ferramenta no site da BizAgi 
 
FUNÇÕES 
PÁGINA PRINCIPAL 
 Executar processo –Somente na versão paga; 
 Curso Online –Assistir curso on-line (é necessário uma conexão com internet); 
 Participantes–Permite Incluir, Alterar e Excluir participantes; 
 Validar–Fazer a validação das conexões do diagrama. 
FORMATAR 
 Alinhar em horizontal e/ou Alinhar em vertical; 
 Alinhar expandir (permite Alinhar parte de cima, baixo, à esquerda e à direita). 
EXPORTAR/IMPORTAR 
 Importar –Criar novos diagramas baseado no formato: Visio, XPDL e Atributos 
(Importar atributos estendidos para XML); 
 Publicar –Publicar o modelo como arquivo Web, Exportar e publicar o modelo em 
Sharepoint e Exportar e publicar o modelo em Wiki. 
VISUALIZAR 
 Bloquear –Permite bloquear a edição, quando bloqueado somente é possível ver 
o modelonão será possível editá-lo; 
 Ampliar/Diminuir Zoom ou informar o percentual de Zoom; 
 Alinhar expandir. 
FERRAMENTAS 
 Anexos–Mostrar todos os anexos do modelo; 
 Contagem do elemento – Mostrar a contagem dos elementos por ordem de tipo. 
APOIAR 
 Vídeos Tutoriais – Visualizar vídeos e tutoriais do BizAgi Process Modeler 
(necessário conexão com a Internet); 
 Resource Center – Visualizar vídeos, tutorias e documentos (necessário conexão 
com a Internet); 
 Central de Processos – Suporte da ferramenta (Fórum), é necessário fazer o 
Registro e também é preciso ter conexão com a Internet); 
 Observações Divulgadas – Informação sobre a versão e requisitos. 
 
 
29 
 
 
Figura 25 – Tarefas e Sub-processos 
NOTAÇÃO 
 
FIGURA TIPO DESCRIÇÃO 
 
 
 
 
 
Atividade 
É um termo genérico para um trabalho executado. Os 
tipos de atividades são: tarefa e Sub-processo]. O Sub-
processo é distinguido por uma pequena cruz no centro 
inferior da figura. Principais Atributos: Tipo de 
atividade(Sub-processo ou tarefa), Status(Ativo, 
Inativo, Cancelado, Pronto, Completado e etc.) e 
Performers, Executantes,(0-n): Um Performer 
(executante) ou mais executantes podem ser inscritos. O 
atributo performer (executante) define o recurso que irá 
executar ou quem serão responsáveis pela a atividade. A 
entrada do Performer poderia ser na forma de um 
indivíduo, um grupo, um papel funcional, uma posição 
ou uma empresa. 
 
30 
 
EXEMPLOS: 
 
1) ESTUDO DE CASO: TEMPERATURA E PRESSÃO DE PACIENTES DA UTI 
 
Necessita-se de um sistema para monitorar a temperatura e a pressão de pacientes 
da UTI, que deverão ficar ligados on-line â rede de computadores do hospital. Os 
pacientes devem ser cadastrados pelo responsável. Essa rede é formada por um 
computador principal e vários terminais que monitoram os pacientes. Se a temperatura 
ou pressão do paciente lida pelo terminal se tornarem críticas, o computador principal 
deverá mostrar uma tela de alerta com um histórico das medidas realizadas para o 
paciente. Um aviso sonoro deve ser ativado nesse caso. A verificação da temperatura é 
realizada comparando-se a temperatura do paciente a temperatura padrão digitada pelo 
responsável. A verificação da pressão paciente é realizada comparando-se com um valor 
padrão de pressão (máximo e mínimo) a ser digitado pelo responsável e verificando-se a 
pressão medida está dentro dos parâmetros considerados normais para o paciente 
(valores próximos ao máximo e mínimo são permitidos). Existem vários sistemas online 
no computador principal e todos devem rodar ao mesmo tempo. 
Vamos 
fazer juntos 
???? 
Vamos fazer 
juntos??? 
???? 
 
31 
 
 
 
3) ESTUDO DE CASO PIZZARIA ONLINE 
 
A Pizzaria On-Line trabalha exclusivamente com entrega de pizza. 
Os clientes fazem os pedidos exclusivamente pela internet. Para 
fazer um pedido é necessário que o cliente informe o endereço de 
entrega, selecione o sabor da pizza e bebidas. Escolher o cartão para o 
 
32 
 
pagamento: cartão de crédito ou cartão de débito. Após o pagamento o pedido é gerado. 
A equipe da Preparação do Pedido tem como atribuição receber, gerar ticket de 
entrega, priorizar e encaminhar o pedido para a Cozinha, que tem uma equipe, que é 
responsável por fazer a pizza, separar as bebidas e pela embalagem. 
Quando a pizza esta pronta os itens do pedido são embalados e enviado para a 
equipe de entrega. 
Os entregadores fazem a entrega do pedido. 
Vamos fazer em três partes: MODELAR, DOCUMENTAR e PUBLICAR. 
 
A) MODELAGEM 
1. QUESTIONÁRIO DE APOIO 
1. Qual é o evento que inicia o processo? 
2. Quando o processo acaba (qual é o resultado esperado)? 
3. Quem são os participantes? 
4. Quais são as funções de negócios que estão envolvidas no processo? 
5. Quais são as principais atividades e tarefas? 
6. Quais são as restrições? 
 
2. TIPOS DE PROCESSO 
1. Temos como saber os detalhes do processo de Cliente? 
2. Site Pizzaria On-Line precisamos saber / conhecer os detalhes deste processo? 
3. Precisamos conhecer / saber os detalhes do processo de Pizzaria para completar a 
operação? 
 
3. FAZER O MODELO DE NEGÓCIOS 
4. FAZER UM SUB-PROCESSO 
5. VALIDAR O PROCESSO 
6. FAZER O LINK ENTRE O PROCESSO E O SUB-PROCESSO 
7. DEFINIR OS EXECUTANTES 
B) DOCUMENTAÇÃO 
1. ADICIONAR O DOCUMENTO 
2. SELECIONAR O DOCUMENTO 
3. VISUALIZAR O DOCUMENTO 
4. EDITAR O DOCUMENTO 
 
C) PUBLICAÇÃO 
 
EXERCÍCIOS 
 
1) No software BizAgi faça o modelo conforme o layout abaixo: CONFIRMAR RESERVA 
 
33 
 
 
 
2) Faça o layout abaixo de processo e sub-processo: 
 
 
 
3) Faça o layout abaixo: 
 
 
 
 
34 
 
4) Criar um modelo de negócio para o subsistema VERIFICAÇÃO DE FREQUENCIA: 
 Sistema: Controle de Aluno; 
 Subsistema: Verificação de Frequência; 
 Componentes: Professor e Aluno; 
 Processos: Professor gera pauta, Professor realiza chamada, Professor lança 
frequência e Aluno visualiza frequência. 
 
 
 
TAREFA 01 – MODELAGEM DE NEGÓCIOS (VALOR 3,0 PONTOS) 
 
 
 
 
 
 
 
 
35 
 
REQUISITOS DE SOFTWARE 
 
Figura 26 – Levantamento de Requisitos (Fonte: Web) 
 
A área de conhecimento Requisitos de Software inclui definições de requisitos, os 
principais tipos de requisitos: produto versus processo, funcionais versus não funcionais 
e propriedades. Também identifica a importância dos requisitos quantificáveis e 
diferencia sistemas e requisitos de software. 
Requisito de software é uma AÇÃO que o software deve executar que possui 
características e condições próprias para automatizar um processo de negócio de cliente. 
Segundo o IEEE, define requisitos de software como: 
“Uma condição ou uma capacidade de que o usuário necessita 
para solucionar um problema ou alcançar um objetivo; 
Uma condição ou uma capacidade que deve ser alcançada ou 
possuída por um sistema ou componente do sistema, para 
satisfazer um contrato, um padrão, uma especificaçãoou outros 
documentos impostos formalmente; 
Uma representação documentada de uma condição ou 
capacidade”. 
 
Outros conceitos de requisitos de software... 
 Requisito é uma ação a ser executada por um sistema, possuindo características e 
condições próprias e que devem ser atendidas conforme as necessidades de negócio 
do usuário (VAZQUEZ; 2010). 
 
 Requisitos de um sistema são descrições do que o software deve fazer, os serviços 
que devem ser fornecidos por esse sistema e as suas restrições operacionais. Os 
requisitos descrevem o que o software deve fazer e o que não deve fazer sem dizer 
como fazer. (SOMMERVILLE, 2011); 
 
http://gestaodeprojetospmi.com.br/wp-content/uploads/2011/08/requisitos-dilbert.jpg
 
36 
 
 Um requisito é alguma coisa que o produto tem de fazer ou uma qualidade que ele 
precisa apresentar (ROBERTSON; ROBERTSON, 2006). 
 Um requisito de um sistema é uma característica do sistema ou a descrição de algo 
que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004); 
 
 Um requisito é descrito como uma propriedade que o software deve exibir para 
resolver algum problema no mundo real (SWEBOK, 2004); 
 
Existem em diversos níveis: 
 
Figura 27 – Requisitos (extraído da WEB) 
 
IMPORTÂNCIA DOS REQUISITOS 
 
Várias pesquisas apontam a deficiências nos requisitos dos sistemas como uma 
das principais causas de fracassos em projetos de software e por isto a engenharia de 
requisitos é uma das áreas mais importantes da engenharia de software. 
Quanto mais cedo no ciclo de desenvolvimento do sistema se descobre um erro, 
mais barato fica para acertá-lo. 
 
FASE CUSTO DE ERRO 
REQUISITO 1 
ANÁLISE 5 
PROJETO 10 
IMPLEMENTAÇÃO 20 
TESTE 50 
MANUTENÇÃO 200 
Figura 28 – Custo dos erros nas fases 
A dificuldade de descobrir erros na fase de requisitos está no fato de neste 
momento da análise, o analista está descobrindo o funcionamento do negócio que ele 
desconhece, e ainda a relação analista X usuário é muito recente, fazendo com que a 
relação de confiança ainda esteja em avaliação de ambas as partes. Ambiguidades 
decorrentes de nossa linguagem, omissões e fatos incorretos, são as principais causas. 
O uso de inspeções, validação dos requisitos através de encontros sucessivos com 
o usuário, ajudam a minimizar estes problemas. 
 
37 
 
 
Figura 29 - Importância da Engenharia de Requisitos 
Pesquisa realizada na Standish Group com 350 companhias e 8.000 projetos 
diferentes, onde: 
 Sucesso é quando cobre todas as funcionalidades em tempo e dentro do custo; 
 Limitações ou Problemáticos são quando não cobre todas as funcionalidades 
exigidas, custo maior e atraso; 
 Fracasso é quando o projeto foi cancelado durante o desenvolvimento. 
 
Figura 30 – Pesquisa de projetos em desenvolvimento nos Estados Unidos 
 
38 
 
As causas podem ser: 
 
Figura 31 – Tipos de Fatores 
Precisamos dos requisitos para entender o que o cliente quer, para documentar o 
que o cliente quer e para assegurar a qualidade e a satisfação do cliente. Também 
podemos entender o problema do negócio, documentar o escopo do projeto e definir 
suas restrições e definir os critérios de aceitação e gerenciar as expectativas do cliente. 
 
QUALIDADE DOS REQUISITOS 
 
A norma ISO/IEC 25030 (ISO 2007) fornece recomendações para especificação 
de requisito de qualidade do produto de software. Segundo essa norma, os requisitos 
de qualidade de software, assim como todos os requisitos não podem ser vistos 
isoladamente, mas em um contexto amplo. E, existe uma forte relação entre os 
requisitos de qualidade e os requisitos funcionais. Além disso, os requisitos de 
qualidade podem resultar em requisitos funcionais adicionais que apoiam os primeiros. 
Os requisitos de qualidade de um sistema frequentemente não são documentos ou 
se o são ocorre de forma inadequada. Por este motivo o engenheiro de requisitos deve 
dar atenção à elicitação e a documentação de requisitos durante o processo de 
desenvolvimento. 
As qualidades “desejáveis” para um requisito são: 
 Verificável: Tem que existir uma maneira de verificar se o produto contempla o 
requisito; 
 Priorizável: Se todos os requisitos têm a mesma prioridade, há algum 
problema, etc.; 
 Modificável: As ideias sempre mudam e logo os requisitos devem mudar 
também (Scott Ambler); 
 Inteligível, Rastreável, Completo e Claro (não ambíguo). 
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
13% 12% 11% 10% 
93% 
9% 8% 8% 
Fatores 
Fatores
 
39 
 
TIPOS DE REQUISITOS 
REQUISITOS FUNCIONAIS 
 
Os requisitos funcionais descrevem o que o sistema deve fazer, isto é, as funções 
necessárias para atender os objetivos do sistema. Exemplos: Cadastrar Clientes; Fazer 
Análise de Crédito; Fazer uma Transação com Banco de Dados; Cadastrar um Registro 
de Atendimento; Imprimir Relatório, etc. 
Definem a funcionalidade oferecida pelo sistema a ser desenvolvido. Estes 
requisitos são divididos em: FUNCIONAIS, COMPORTAMENTAIS e 
ESTRUTURAIS. Outras Definições: 
 Segundo SOMMERVILLE (2007), são declarações de serviços que o sistema deve 
prover, descrevendo o que o sistema deve fazer; 
 PFLEEGER (2004), diz que um requisito funcional descreve uma interação entre o 
sistema e o seu ambiente; 
 Ainda em SOMMERVILLE (2007) seria como o sistema deve reagir a entradas 
específicas, como o sistema deve se comportar em situações específicas e o que o 
sistema não deve fazer; 
 Para Pohl; Ruppy (2012) é um requisito relacionado ao resultado de algum 
comportamento a ser fornecido por uma função do sistema. 
 
Exemplo De Requisitos Funcionais 
“O software deve permitir que o atendente consulte o relatório com os resultados 
dos testes clínicos de um paciente.” 
[RF01] O software deve permitir que o atendente efetue cadastro de clientes; 
[RF02] O software deve permitir que o caixa efetue o registro de itens vendidos; 
[RF03] O software deve permitir que o administrador gere o um relatório de 
vendas por mês. 
REQUISITOS DE DOMÍNIO 
 
Também chamado de Restrição, está relacionado às regras de negócio ou 
comportamento próprio do sistema numa determinada aplicação ou no contexto 
funcionando para uma empresa. Estes requisitos restringem o próprio sistema, por 
exemplo, o sistema deverá ser implementado utilizando os serviços da Web. Estes 
requisitos não são implementados, mas são cumpridos, pois limitam o espaço da 
solução disponível durante o processo de desenvolvimento. Outras Definições: 
 POHL; RUPP (2012) informam que limitam o espaço da solução além do que seria 
necessário para cumprir os respectivos requisitos funcionais de qualidade; 
 SOMMERVILLE (2007) diz que descrevem restrições sobre os serviços ou funções 
oferecidos pelo sistema; 
 Ou ainda, as quais limitam as opções para criar uma solução para o problema 
(PFLEEGER, 2004). 
 
Exemplo De Requisitos De Dominio 
 [RN1] os campos referentes ao orçamento do projeto vinculado só estarão ativos 
se o tipo de projeto for vinculado; 
 
40 
 
 [RN2] o campo valor total orçado para o projeto é calculado somando-se os 
valores definidos para todas as rubricas incluídas no orçamento do projeto, seja 
ele vinculado ou não-vinculados; 
 [RN3] A soma dos percentuais a ser distribuído entre os fundos incluídos no plano 
de aplicação deve ser entre 0 e 100%. 
 
REQUISITOS NÃO FUNCIONAIS 
 
Também chamado de RNF, Suplementares ou de Qualidade, declaram as 
características que o sistema deve possuir e que estão relacionadas às suas 
funcionalidades. Com as características: performance, portabilidade, segurança, 
usabilidade, qualidade do serviço (QoS), confidencialidade, confiabilidade, 
portabilidade, precisão, integridade, eficiência, entre outras. Estes tipos de requisitos são 
as causas as principais insatisfações dos usuários com relação ao software. 
Os requisitos não funcionais têm origem nas necessidades dos usuários, em 
restrições de orçamento, em políticasorganizacionais, em necessidades de 
interoperabilidade com outros sistemas de software ou hardware ou em fatores externos 
como regulamentos e legislações (SOMMERVILLE, 2007). 
Definem qualidades desejadas do sistema a ser desenvolvido e muitas vezes 
influenciam a arquitetura do sistema mais do que os requisitos funcionais. Definem 
desempenho, disponibilidade, confiabilidade, escalabilidade ou a portabilidade de um 
sistema (Pohl; Rupp, 2012). 
 
Principais características: 
o Confiabilidade: identifica o quanto um programa satisfaz a sua especificação e 
cumpre os objetivos; 
o Confiabilidade: avalia o quanto um programa executa as funções pretendidas com 
a precisão exigida; 
o Eficiência: verifica a quantidade de recursos computacionais exigida para que um 
programa execute suas funções; 
o Integridade: identifica o controle de acesso ao software ou aos dados por pessoas 
não autorizadas; 
o Usabilidade: verifica o esforço necessário para aprender, inserir dados e 
interpretar a saída de um programa; 
o Manutenibilidade: relativa ao esforço necessário para localizar e eliminar erros 
em um programa; 
o Flexibilidade: esforço necessário para modificar um programa; 
o Testabilidade: engloba o esforço necessário para testar um programa; 
o Portabilidade: esforço necessário para transferir um programa de uma plataforma 
de hardware ou software para outra; 
o Reusabilidade: identifica a reutilização de um programa (ou parte dele) em outros 
programas; 
o Interoperabilidade: envolve o quantitativo de esforço necessário para se acoplar 
um programa a um outro. 
 
EXEMPLO DE REQUISITOS NÃO FUNCIONAIS 
 
 
41 
 
 
Figura 32 - Características dos Requisitos não Funcionais 
Há diversas classificações de requisitos utilizadas na prática, como por exemplo 
CMMI ou SPICE. 
 
PROBLEMAS COMUNS NOS REQUISITOS 
 
 Nem sempre são óbvios; 
 São originados de várias fontes (=conflitos de interesse); 
 Nem sempre retratam um problema que é possível ser expressado por palavras; 
 Sempre mudam; 
 Os usuários nem sempre sabem o que desejam; 
 Os usuários têm uma tendência de privilegiar a sua área ou o seu ponto de vista; 
 Os analistas pensam que entendem os problemas melhor do que os próprios 
usuários! 
 
CLASSES DE REQUISITOS 
 
Os requisitos podem ser vistos em três classes distintas: 
o Essenciais; 
o Importantes; 
o Desejáveis. 
 
42 
 
Em princípio, sistema deve resolver todos os requisitos de essenciais para 
requisitos desejáveis. 
 
 
 
 
 
 
FONTES DE REQUISITOS 
 
Há três fontes de requisitos: 
 STAKEHOLDERS – conforme já dito anteriormente, são pessoas ou 
organizações que direta ou indiretamente influenciam os requisitos de um sistema; 
 DOCUMENTOS – contém informações importantes que podem fornecer 
requisitos; 
 SISTEMAS EM OPERAÇÃO: sistemas anteriores ou legados, bem como 
sistemas concorrentes. 
PROTOTIPAÇÃO 
 
A prototipação é um processo que tem como objetivo facilitar o entendimento dos 
requisitos, apresentar conceitos e funcionalidades do software. Desta forma, podemos 
propor uma solução adequada para o problema do cliente, aumentando sua percepção de 
valor. 
Os protótipos também são grandes aliados das metodologias ágeis de 
desenvolvimento, uma vez que garantem maior alinhamento entre a equipe e o 
cliente. Eles podem ser desenvolvidos em diferentes níveis de fidelidade: quanto maior 
ela for, mais o protótipo se assemelhará ao resultado entregue. No entanto, um protótipo 
de alta fidelidade leva mais tempo para ser criado ou modificado. A escolha do 
protótipo ideal varia de acordo com o nível de entendimento do negócio, a 
complexidade dos requisitos, prazo e orçamento para elaboração. 
EXERCÍCIOS - REQUISITOS 
 
1) Um requisito de software expressa as necessidades e restrições colocadas em um 
produto de software que contribuem para a solução de algum problema do mundo 
real. Acerca desse assunto, assinale a opção correta. 
a) Os contratantes ou clientes são os principais colaboradores envolvidos no 
fornecimento de informações para o processo de levantamento ou elicitação de 
requisitos de software, os demais grupos de pessoas que podem fornecer 
informações são considerados de importância secundária. 
b) As necessidades dos usuários a serem atendidas por um produto de software 
constituem a classe de requisitos funcionais, e as restrições mencionadas na 
definição de requisitos constituem a classe de requisitos não funcionais. 
c) Entre as fontes de informação para a elicitação de requisitos, destacam-se, além 
dos colaboradores, o conhecimento do domínio de aplicação em que o software 
funcionará, o ambiente operacional do software e o ambiente organizacional. 
RECORDANDO!!!!! 
A especificação de um requisito 
funcional deve determinar O QUE 
o sistema deve fazer sem a 
preocupação de COMO fazer. 
 
43 
 
d) A técnica de casos de uso, empregada em alguns modelos de desenvolvimento 
de software atuais, é mais aderente à construção de cenários durante a 
construção de protótipos que durante a elicitação de requisitos. 
e) A negociação de requisitos, de forma similar à observação do ambiente 
organizacional, é uma atividade típica da fase de elicitação de requisitos. 
 
2) A respeito de análise de requisitos, julgue os itens a seguir. 
I O usuário deve ser capaz de pesquisar tanto no banco de dados inteiro como 
em uma parte dele. 
II A interface de usuário para o sistema deve ser implementada em HTML sem 
frames ou em applets Java. 
III O sistema deve fornecer visões apropriadas para que o usuário possa ler 
documentos. 
IV Cada ordem deve ter um identificador único (OSID), que o usuário deve poder 
copiar na área permanente de armazenamento da conta. 
V O processo de desenvolvimento do sistema e os documentos devem ser 
realizados conforme o padrão interno da empresa. 
São requisitos funcionais apenas os itens: 
a) I, II e III. 
b) I, II e V. 
c) I, III e IV. 
d) II, IV e V. 
e) III, IV e V. 
 
3) Requisitos não-funcionais estão diretamente relacionados com a satisfação dos 
usuários. Assinale a alternativa que não indique um requisito não-funcional: 
a) O sistema de arquivos deve ser protegido, para acesso, apenas, de usuários 
autorizados. 
b) O software deve ser implementado usando os conceitos de orientação a objetos. 
c) O tempo de desenvolvimento do software não deve ultrapassar seis meses. 
d) O software poderá ser executado em plataforma Windows e Linux. 
e) O software deve emitir relatórios de vendas a cada quinze dias. 
 
4) As declarações de serviços que o sistema deve fornecer, de como ele deve reagir a 
entradas específicas ou se comportar em determinadas situações, são chamadas de 
requisitos: 
a) Não-funcionais 
b) De domínio. 
c) De sistema. 
d) Funcionalidades. 
e) De usuário. 
 
5) Um requisito de software expressa as necessidades e restrições colocadas em um 
produto de software que contribuem para a solução de algum problema do mundo 
real. Acerca desse assunto, assinale a opção correta. (CESPE - 2010 - SAD-PE - 
Analista de Controle Interno – Tecnologia da Informação) 
a) Os contratantes ou clientes são os principais colaboradores envolvidos no 
fornecimento de informações para o processo de levantamento ou elicitação de 
requisitos de software, os demais grupos de pessoas que podem fornecer 
informações são considerados de importância secundária. 
http://www.questoesdeconcursos.com.br/provas/cespe-2010-sad-pe-analista-de-controle-interno-tecnologia-da-informacao
http://www.questoesdeconcursos.com.br/provas/cespe-2010-sad-pe-analista-de-controle-interno-tecnologia-da-informacao
 
44 
 
b) As necessidades dos usuários a serem atendidas por um produto de software 
constituem a classe de requisitos funcionais, e as restrições mencionadas na 
definição de requisitos constituem a classe de requisitos não funcionais. 
c) Entre as fontes de informação para a elicitação de requisitos, destacam-se,