Babok 2.0 PDF

Um guia para o
Corpo de
Conhecimento de
Anlise de Negcios
(Guia BABOK)
Verso 2.0
www.theiiba.org
Cpia de cortesia exclusiva para membros do IIBA. No pode ser vendida ou distribuida exceto pelo prprio IIBA.
International Institute of Business Analysis. Toronto, Ontario, Canad.
2005, 2006, 2008, 2009, 2011 International Institute of Business Analysis. Todos os direitos reser-
vados.
Partes do Apndice A: Glossrio so oriundos do The Software Requirements Memory Jogger, de El-
len Gottesdiener, 2005 GOAL/QPC e so utilizados com permisso.
Imagem da Capa 2006 iStockphoto.com/Damkier Media Group.
Verso 1.0 e 1.4 publicadas em 2005. Verso 1.6 Draft publicada em 2006. Verso 1.6 Final publicada
em 2008. Verso 2.0 publicada em 2009. Edio em Portugus publicada em 2011.
ISBN-10: 0-9811292-4-2
ISBN-13: 978-0-9811292-4-2
Permisso concedida para reproduzir este documento para seu uso exclusivo pessoal, profissional
ou educacional. Se voc adquiriu uma licena do IIBA para utilizar este documento, voc tem o
direito de transferir essa licena a um terceiro. Membros do IIBA no tm o direito de transferir a
licena de sua cpia gratuita a terceiros.
Este documento disponibilizado comunidade de anlise de negcios para propsitos educa-

cionais. IIBA no garante que ele seja adequado para qualquer outro propsito, no faz qualquer
garantia expressa ou implcita de qualquer tipo e no assume a responsabilidade por erros ou
omisses. Nenhuma responsabilidade assumida por danos incidentais ou consequentes do uso
das informaes contidas aqui.
IIBA, o logo do IIBA, BABOK e Business Analysis Body of Knowledge so marcas de propriedade
do International Institute of Business Analysis. CBAP uma marca registrada do International Insti-
tute of Business Analysis. Instituto Internacional de Anlise de Negcios, Corpo de Conhecimento
de Anlise de Negcios, CCBA, Certification of Competency in Business Analysis, Certified Busi-
ness Analysis Professional, EEP e o logo EEP somarcas de propriedade do International Institute
of Business Analysis.
CMMI uma marca registrada da Carnegie Mellon University.
COBIT uma marca da Information Systems Audit and Control Association e do IT Governance
Institute.
ITIL uma marca registrada do Office of Government Commerce no Reino Unido e outros pases.
TOGAF uma marca registrada de The Open Group nos EUA e outros pases.
O Zachman Framework para Arquitetura Corporativa uma marca registrada do Zachman Insti-
tute for Framework Advancement.
O Instituto Internacional de Anlise de Negcios no tem a inteno de fazer qualquer objeo ao

status de propriedade destas ou de quaisquer outros termos de marcas registradas contidas neste
documento.
Qualquer questionamento relacionado a esta publicao, solicitao de direitos de uso do material

contido neste documento, ou correes devem ser enviados para o endereo de email bok@theiiba.org.
Tabela de Contedos
Contents
Prefcio1
Prefcio da Edio em Lngua Portuguesa 3
Introduo5
1.1 O que o Corpo de Conhecimento de Anlise de Negcios? 5
1.2 O que Anlise de Negcios? 5
1.3 Conceitos-Chave 6
1.4 reas de Conhecimento 8
1.5 Tarefas 10
1.6 Tcnicas 16
1.7 Competncias Fundamentais 17
1.8 Outras Fontes de Informao sobre Anlise de Negcios 18
Planejamento e Monitoramento da Anlise de Negcios 21

2.1 Planejar a abordagem da Anlise de Negcios 22
2.2 Conduzir a Anlise das Partes Interessadas 28
2.3 Planejar Atividades da Anlise de Negcios 35
2.4 Planejar a Comunicao da Anlise de Negcios 41
2.5 Planejar o Processo de Gerenciamento de Requisitos 46
2.6 Gerenciar o Desempenho da Anlise de Negcios 53
Elicitao57
3.1 Preparar a Elicitao 58
3.2 Conduzir a Atividade de Elicitao 60
3.3 Documentar os Resultados da Elicitao 63
3.4 Confirmar Resultados da Elicitao 65
Gerenciamento e Comunicao dos Requisitos 67

4.1 Gerenciar o Escopo e os Requisitos da Soluo 67
4.2 Gerenciar Rastreabilidade dos Requisitos 72
4.3 Manter Requisitos para Reutilizao 75
4.4 Preparar o Pacote de Requisitos 77
4.5 Comunicar Requisitos 82
Anlise Corporativa 87
5.1 Definir a Necessidade do Negcio 88
5.2 Avaliar Gaps (Lacunas) de Capacidades 91
5.3 Determinar a Abordagem da Soluo 94
5.4 Definir o Escopo da Soluo 97
5.5 Definir o Business Case 100
Guia BABOK Verso 2.0 III

Tabela de Contedos
Anlise de Requisitos 105

6.1 Priorizar Requisitos 105
6.2 Organizar Requisitos 109
6.3 Especificar e Modelar Requisitos 113
6.4 Definir Suposies e Restries 117
6.5 Verificar Requisitos 120
6.6 Validar Requisitos 123
Avaliao e Validao da Soluo 127

7.1 Avaliar Soluo Proposta 127
7.2 Alocar Requisitos 130
7.3 Avaliar a Prontido Organizacional 133
7.4 Definir Requisitos de Transio 137
7.5 Validar a Soluo 140
7.6 Avaliar o Desempenho da Soluo 143
Competncias Fundamentais 147

8.1 Pensamento Analtico e Resoluo de Problemas 147
8.2 Caractersticas Comportamentais 150
8.3 Conhecimento de Negcios 151
8.4 Habilidades de Comunicao 154
8.5 Habilidades de Interao 156
8.6 Aplicativos de Software 158
Tcnicas161
9.1 Definio dos Critrios de Aceite e Avaliao 161
9.2 Benchmarking 162
9.3 Brainstorming 163
9.4 Anlise de regras de negcio 165
9.5 Dicionrio de dados e glossrio 166
9.6 Diagramas de fluxos de dados 167
9.7 Modelagem de dados 169
9.8 Anlise de deciso 172
9.9 Anlise de documentos 175
9.10 Estimativa 176
9.11 Grupos focais 178
9.12 Decomposio funcional 180
9.13 Anlise de interface 182
9.14 Entrevistas 183
9.15 Processo de lies aprendidas 186
9.16 Mtricas e Indicadores-Chave de Desempenho 187
9.17 Anlise de Requisitos No-Funcionais 190
9.18 Observao 192
9.19 Modelagem Organizacional 194
9.20 Rastreamento de problemas 196
IV Um guia para o Corpo de Conhecimento de Anlise de Negcios

Tabela de Contedos
9.21 Modelagem de processos 198

9.22 Prototipagem 202
9.23 Workshop de requisitos 204
9.24 Anlise de riscos 206
9.25 Anlise de Causa-Raiz 208
9.26 Cenrios e Casos de uso 209
9.27 Modelagem do Escopo 212
9.28 Diagramas de Sequncia 214
9.29 Diagramas de Estados 215
9.30 Reviso Estruturada 216
9.31 Pesquisa / Questionrio 219
9.32 Anlise SWOT 222
9.33 Histrias do usurio 224
9.34 Avaliao de fornecedores 225
Glossrio227
Bibliografia241
Contribuintes247
C.1 Verso 2.0 247
C.2 Verso 1.6 250
Sumrio de Mudanas da verso 1.6 253

D.1 Viso Geral 253
D.2 Anlise Corporativa 253
D.3 Planejamento e Gerenciamento de Requisitos 254
D.4 Elicitao de Requisitos 255
D.5 Documentao e Anlise de Requisitos 256
D.6 Comunicao de Requisitos 258
D.7 Avaliao e Validao da Soluo 258
D.8 Fundamentos Bsicos 259
Guia BABOK Verso 2.0 V

Prefcio
O IIBA (Instituto Internacional de Anlise de Negcios) foi fundado em Toronto, Canad,
em outubro de 2003, para apoiar a comunidade de anlise de negcios atravs das seguintes
iniciativas:
Criao e desenvolvimento da conscincia e reconhecimento do valor e da contribuio

do Analista de Negcios;
Definio de Um Guia para o Corpo de Conhecimento de Anlise de Negcios (BABOK);
Estabelecimento de um frum para compartilhamento do conhecimento e contribuio

para a profisso de Anlise de Negcios;
Reconhecimento pblico e certificao dos praticantes de Anlise de Negcios atravs

de um programa de certificao internacionalmente reconhecido.
O comit do corpo de conhecimento foi formado em outubro de 2004 para definir e esboar
um padro global para a prtica da anlise de negcios. Em janeiro de 2005, o IIBA lanou a
verso 1.0 de Um Guia para o Corpo de Conhecimento de Anlise de Negcios (Guia BABOK)
para feedback e comentrios. Aquela verso inclua as linhas gerais para o contedo proposto
e algumas definies-chave. A verso 1.4 foi lanada em outubro de 2005, com rascunhos
do contedo de algumas reas de conhecimento. A verso 1.6, que inclua informaes
detalhadas a respeito da maior parte das reas de conhecimento, foi publicada em formato
de rascunho em junho de 2006 e atualizada para incorporar erratas em outubro de 2008.
Esta publicao substitui Um Guia para o Corpo de Conhecimento de Anlise de Negcios,

verso 1.6. Aps a publicao da verso 1.6, o IIBA procurou especialistas em anlise
de negcios e campos relacionados e solicitou o seu feedback a respeito do contedo
daquela verso. Seus comentrios foram utilizados para planejar o escopo desta reviso.
Os voluntrios do IIBA ento trabalharam para definir a estrutura da verso 2.0 e
desenvolveram o texto revisado que foi liberado para a comunidade de anlise de negcios
para reviso em 2008. Durante aquele perodo de exposio, o IIBA tambm solicitou
feedback de especialistas na rea e praticantes da anlise de negcios atravs de um processo
formal de reviso. O IIBA recebeu milhares de comentrios durante este processo e este
documento foi reformulado para incorporar o mximo possvel desses comentrios.
O Guia BABOK contm a descrio de prticas geralmente aceitas no campo da anlise

de negcios. O contedo includo nesta verso foi verificado atravs de revises feitas por
praticantes, pesquisas entre a comunidade de anlise de negcios e consultas junto a
renomados especialistas neste campo. Os dados repassados ao IIBA demonstram que as
tarefas e tcnicas descritas nesta publicao so utilizadas pela maioria dos praticantes
de anlise de negcios. Como resultado, ns podemos ter a confiana de que as tarefas e
tcnicas descritas no Guia BABOK podem ser aplicadas na maioria dos contextos onde a
anlise de negcios executada, na maior parte das vezes.
O Guia BABOK no deve ser interpretado como uma imposio de que todas as prticas
descritas nessa publicao devam ser seguidas em todas as circunstncias. Qualquer
conjunto de prticas deve ser adaptado para condies especficas, sob as quais a anlise
de negcios est sendo executada. Alm disso, prticas que no so geralmente aceitas
pela comunidade de anlise de negcios no momento da publicao podem ser igualmente
efetivas, ou mais efetivas que prticas descritas no Guia BABOK. Conforme essas prticas
tornem-se aceitas e conforme os dados sejam colhidos para verificao da sua eficcia,
Guia BABOK Verso 2.0 1

Prefcio
elas sero incorporadas em futuras edies desta publicao. O IIBA incentiva todos os
praticantes da anlise de negcios a serem abertos para novas abordagens e novas idias e
pretende incentivar a inovao na prtica da anlise de negcios.
Esta reviso tem como meta:
Completar a descrio de todas as reas de conhecimentos;
Simplificar a estrutura e torn-la mais fcil de entender e aplicar;
Aperfeioar a consistncia e qualidade do texto e ilustraes;
Integrar reas de conhecimento e evitar reas de sobreposio;
Aperfeioar a consistncia em relao a outros padres geralmente aceitos relacionados

prtica da anlise de negcios;
Estender a cobertura do Guia BABOK para descrever a anlise de negcios para

contextos alm das abordagens tradicionais de desenvolvimento customizado de
aplicaes em software, incluindo mas no limitado a as metodologias geis, Business
Process Management (BPM), avaliao e implementao de software de prateleira;
Esclarecer o relacionamento entre a anlise de negcios e outras disciplinas,

particularmente, gerenciamento de projetos, testes, usabilidade e arquitetura da
informao;
Foco na prtica da anlise de negcios no contexto da iniciativa individual, com

ateno especial na estratgia ou na anlise de negcios que leva em conta a empresa
como um todo, executada separadamente, para incluso em uma extenso de uma
aplicao futura.
As principais mudanas nesta edio incluem:
Mudanas gerais direcionadas para as metas descritas acima;
Todo o contedo foi revisado e editado, e uma parcela relevante foi reescrita;
Muitas das tarefas encontradas na verso 1.6 foram consolidadas, resultando em uma
reduo de 77 para 32 tarefas;
Tarefas na rea de Conhecimento Planejamento e Gerenciamento dos Requisitos

foram transferidas para Planejamento e Monitoramento de Anlise de Negcios e
Gerenciamento e Comunicao de Requisitos;
Outras trs reas de conhecimento foram renomeadas para refletir melhor seus
propsitos;
Tcnicas so aplicveis entre mltiplas reas de Conhecimento;
Entradas e Sadas foram definidas para todas as tarefas.
O IIBA gostaria de estender seus agradecimentos e os agradecimentos da comunidade de

anlise de negcios para todos aqueles que doaram voluntariamente seu tempo e esforo
para o desenvolvimento desta reviso, bem como aos que nos forneceram feedback informal
atravs de outros meios.
2 Um guia para o Corpo de Conhecimento de Anlise de Negcios

Prefcio da Edio em Lngua Portuguesa
O IIBA Captulo So Paulo foi criado em 2008 com o objetivo de trazer para o pas as
iniciativas do IIBA. Seu trabalho possibilitar que praticantes brasileiros tambm
possam se beneficiar da conscincia e reconhecimento do valor de sua contribuio,
da definio clara do escopo da anlise de negcios atravs do Guia BABOK para o
Corpo de Conhecimento de Anlise de Negcios, e do reconhecimento pblico atravs
do programa de certificao.
Um dos primeiros e mais importantes passos na busca por esses objetivos o acesso
dos praticantes da anlise de negcios de lngua portuguesa ao contedo do BABOK.
O IIBA Captulo So Paulo, por ser o primeiro do Brasil, assumiu o desafio de traduzir
frases e ilustraes e, principalmente, de definir de forma criteriosa os nomes das
reas de conhecimento, tarefas e tcnicas, que at ento s existiam em ingls.
Este trabalho envolveu profissionais analistas de negcios membros do Captulo e

sofreu a reviso de especialistas brasileiros na rea, alm de ter sido homologado
pelo IIBA.
Junte-se ao IIBA Captulo So Paulo e faa parte desse trabalho. Para informaes
sobre como tornar-se um membro visite o nosso site www.theiiba.org.br.

Introduo
Captulo UM
1.1 O que o Corpo de Conhecimento de Anlise de Negcios?

Um Guia para o Corpo de Conhecimento de Anlise de Negcios (Guia BABOK)
um padro para a prtica da anlise de negcios globalmente reconhecido. O Guia
BABOK descreve as reas de Conhecimento da anlise de negcios, suas atividades
e tarefas associadas e as habilidades necessrias para que a sua execuo seja efetiva.
O propsito primrio do Guia BABOK definir a profisso de Anlise de Negcios.

Ele serve como uma base de consenso sobre a qual os praticantes podem discutir o
trabalho que executam e garantir que todos possuam as habilidades necessrias para
executar o papel de forma efetiva. Ele tambm define as habilidades e conhecimentos
que quem trabalha com os analistas de negcios, ou quem os emprega, deve esperar
que um praticante habilidoso demonstre. um framework que descreve as tarefas
de anlise de negcios que devem ser executadas no intuito de compreender como
uma soluo ir gerar valor para a organizao patrocinadora. A forma que essas
tarefas assumem, a ordem na qual elas so executadas, a importncia relativa dessas
tarefas e outros fatores podem variar, mas cada tarefa contribui de alguma forma,
direta ou indiretamente, para o objetivo global.
Este captulo introduz os principais conceitos relacionados anlise de negcios

e descreve a estrutura do Guia BABOK. Os captulos 2 a 7 definem as tarefas que um
analista de negcios deve ser capaz de executar. O captulo 8 descreve as competncias
que apoiam o desempenho efetivo da anlise de negcios e o captulo 9 descreve um
conjunto de tcnicas habitualmente aceitas que apoiam a prtica da anlise de negcios.
1.2 O que Anlise de Negcios?

Anlise de Negcios o conjunto de atividades e tcnicas utilizadas para servir
como ligao entre as partes interessadas, no intuito de compreender a estrutura,
polticas e operaes de uma organizao e para recomendar solues que permitam
que a organizao alcance suas metas.
Anlise de Negcios envolve compreender como as organizaes funcionam e

alcanam seus propsitos, e definir as capacidades que uma organizao deve possuir
para prover produtos e servios para as partes interessadas externas. Isso inclui a
definio de metas organizacionais, como essas metas se conectam a objetivos
especficos, a identificao das aes que uma organizao deve executar para
alcanar as metas e objetivos, e a definio de como interagem as diversas unidades
organizacionais e as partes interessadas, dentro e fora daquela organizao.
A Anlise de Negcios pode ser executada para compreender o estado atual de uma
organizao ou para servir como base para posterior identificao das necessidades
do negcio. Em muitos casos, contudo, a anlise de negcios executada para definir
e validar solues que atendam s necessidades do negcio, suas metas e objetivos.
Analistas de negcios devem analisar e sintetizar informaes fornecidas por grande

nmero de pessoas que interage com o negcio, como clientes, colaboradores,

Conceitos-Chave Introduo
profissionais de TI e executivos. O analista de negcios responsvel por desvendar

as verdadeiras necessidades das partes interessadas, no simplesmente seus desejos
explcitos. Em muitos casos, o analista de negcios ir trabalhar tambm para
facilitar a comunicao entre unidades organizacionais. Em particular, analistas
de negcios costumam ter um papel central no alinhamento entre as necessidades
das unidades de negcio e as funcionalidades desenvolvidas pela tecnologia da
informao e podem servir como um tradutor entre esses grupos.
Um analista de negcios qualquer pessoa que executa atividades de anlise de

negcios, no importa qual o seu cargo ou funo organizacional. O grupo dos
praticantes de anlise de negcios no se limita a pessoas com o cargo de Analista
de Negcios, mas inclui tambm: analistas de sistemas de negcios, analistas de
sistemas, engenheiros de requisitos, analistas de processos, gerentes de produtos,
responsveis por produtos (product owners), analistas corporativos, arquitetos de
negcio, consultores, ou qualquer outra pessoa que executa as tarefas descritas
no Guia BABOK, incluindo aqueles que executam disciplinas relacionadas, como
gerenciamento de projetos, desenvolvimento de software, QA (quality assurance
garantia da qualidade) e desenho de interface.
1.3 Conceitos-Chave
1.3.1 Domnios
Um domnio uma rea submetida anlise. Sua definio pode corresponder s
fronteiras de uma organizao ou unidade organizacional, como tambm s principais
partes interessadas fora dessas fronteiras e s interaes com essas partes interessadas.
1.3.2 Solues
Uma soluo um conjunto de mudanas no estado atual da organizao que
so feitas com o intuito de permitir que ela atenda a uma necessidade do negcio,
resolva um problema ou se beneficie de uma oportunidade. O escopo da soluo
geralmente mais restrito do que o escopo do domnio no qual ela implementada e
servir como base para a definio do escopo de um projeto de implementao da
soluo e seus componentes.
Grande parte das solues envolve um sistema de componentes de soluo que

interagem entre si e cada componente potencialmente uma soluo em si mesmo.
Exemplos de solues e de componentes de soluo so aplicativos de software,
servios web, processos de negcios, as regras de negcios que governam esses
processos, um aplicativo de tecnologia da informao, uma estrutura organizacional
revisada, terceirizao (outsourcing), internalizao (insourcing), redefinio de cargos
ou qualquer outro mtodo de criao de uma capacidade requerida pela organizao.
A anlise de negcios auxilia a organizao a definir a melhor soluo para suas

necessidades, levando em conta um conjunto de restries (incluindo tempo,
oramento, regulamentaes, entre outros) sob os quais a organizao opera.
1.3.3 Requisitos
Um requisito1 :
1. Uma condio ou capacidade necessria para uma parte interessada resolver

um problema ou atingir um objetivo.
1 Baseado no IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.

Introduo Conceitos-Chave
2. Uma condio ou capacidade que deve ser alcanada ou possuda por uma
soluo, ou componente de soluo, para satisfazer um contrato, padro,
especificao ou outros documentos formalmente impostos.
3. Uma representao documentada de uma condio ou capacidade como em (1)

ou (2).
Como indicado na sua definio, um requisito pode ser implcito, inferido a partir
de, ou derivado de outros requisitos, ou ser diretamente enunciado e gerenciado. Um
dos objetivos principais da anlise de negcios garantir que os requisitos sejam
visveis e compreendidos por todas as partes interessadas.
O termo requisito gera muitas discusses na comunidade de anlise de negcios.

Muitos desses debates focam no que deve, ou no, ser considerado um requisito
e quais so as suas caractersticas necessrias. Ao ler o Guia BABOK, entretanto,
vital que requisito seja tomado pelo sentido mais amplo possvel. Requisitos
incluem, mas no esto limitados a condies ou capacidades passadas, presentes
e futuras em uma organizao e descries de estruturas organizacionais, papis,
processos, polticas, regras e sistemas de informao. Um requisito pode descrever o
estado presente ou futuro de qualquer aspecto da organizao.
Muito da literatura existente a respeito de anlise de negcios escrita com

a premissa de que requisitos descrevem apenas um sistema de tecnologia da
informao que est sendo considerado para implementao. Outras definies
tambm podem incluir futuras funes do negcio ou restringir o significado do
termo para definir os resultados que as partes interessadas querem atingir e no
os meios atravs dos quais esses resultados so alcanados. Mesmo sendo todos
esses diferentes usos justificveis, eles so significantemente mais restritos do que a
maneira com a qual o termo empregado aqui.
De forma semelhante, ns no assumimos que requisitos so analisados em algum

nvel especfico de detalhe. Eles devem ser analisados no nvel de profundidade
necessrio para compreenso e ao. No contexto de uma iniciativa de BPM
(Business Process Management), os requisitos podem ser uma descrio dos processos
de negcio atualmente em uso na organizao. Em outros projetos, o analista de
negcios pode escolher desenvolver requisitos no intuito de descrever o estado
atual de uma organizao (o que j por si s uma soluo para necessidades de
negcio existentes ou passadas) antes de investigar mudanas necessrias para que
as condies do negcio sejam atendidas.
.1 Esquema de classificao de requisitos

Para os propsitos do Guia BABOK, o seguinte esquema de classificao usado
para descrever requisitos:
Requisitos do Negcio so metas de mais alto nvel, objetivos ou necessidades

da organizao. Descrevem as razes pelas quais um projeto foi iniciado, os
objetivos que o projeto vai atingir e as mtricas que sero utilizadas para medir
o seu sucesso. Requisitos do Negcio descrevem necessidades da organizao
como um todo e no de grupos ou partes interessadas dentro dela. So
desenvolvidos e definidos na Anlise Corporativa.
Requisitos das partes interessadas so necessidades de uma parte interessada

em particular ou classe de partes interessadas. Descrevem as necessidades que
uma dada parte interessada possui e como a parte interessada ir interagir
com a soluo. Requisitos das partes interessadas servem como uma ponte

reas de Conhecimento Introduo
entre os requisitos do negcio e as vrias classes de requisitos da soluo. So

desenvolvidos e definidos ao longo da Anlise de Requisitos.
Requisitos da soluo descrevem as caractersticas de uma soluo que

atende aos requisitos do negcio e aos requisitos das partes interessadas. So
desenvolvidos e definidos ao longo da Anlise de Requisitos. So frequentemente
divididos em duas subcategorias, particularmente quando os requisitos
descrevem uma soluo de software:
Requisitos Funcionais descrevem o comportamento e a informao que a

soluo ir gerenciar. Descrevem capacidades que o sistema ser capaz de
executar em termos de comportamentos e operaes aes ou respostas
especficas de aplicativos de tecnologia da informao.
Requisitos No-Funcionais capturam condies que no se relacionam

diretamente ao comportamento ou funcionalidade da soluo, mas
descrevem condies ambientais sob as quais a soluo deve permanecer
efetiva, ou qualidades que os sistemas precisam possuir. Tambm so
conhecidos como requisitos de qualidade ou suplementares. Podem incluir
requisitos relacionados capacidade, velocidade, segurana, disponibilidade,
arquitetura da informao e apresentao da interface com o usurio.
Requisitos de transio descrevem capacidades que a soluo deve possuir

com o objetivo de facilitar a transio do estado atual da organizao para
um estado futuro desejado, mas que no sero mais necessrias uma vez
concluda a transio. So diferenciados dos outros tipos de requisitos porque
so sempre temporrios por natureza e porque no podem ser desenvolvidos
at que ambas as solues, a nova e a existente, sejam definidas. Tipicamente
cobrem a converso de dados a partir dos sistemas existentes, lacunas (gaps)
de habilidade que devem ser resolvidas e outras mudanas relacionadas para
alcanar o estado futuro desejado. So desenvolvidos ao longo da Avaliao e
Validao da Soluo.
1.4 reas de Conhecimento

reas de conhecimento definem o que um praticante de anlise de negcios precisa
compreender e as tarefas que um praticante deve ser capaz de executar.
Analistas de negcios tendem a executar tarefas de todas as reas de conhecimento

em uma sucesso rpida, iterativa ou simultaneamente. Tarefas podem ser
executadas em qualquer ordem, contanto que as entradas necessrias estejam
disponveis. Teoricamente, um esforo de anlise de negcios pode ser iniciado com
qualquer tarefa, todavia, os candidatos mais provveis so Definir a Necessidade do
Negcio (5.1) ou Avaliar o Desempenho da Soluo (7.6).
reas de conhecimento no pretendem representar fases em um projeto.

certamente possvel e permissvel partir das atividades de Anlise Corporativa
para as atividades de Anlise de Requisitos e, ento, para a Avaliao e Validao da
Soluo, e tratar cada uma como uma fase distinta em um projeto. Contudo, o Guia
BABOK no exige que voc proceda desta forma e ele no deve ser imposto como
uma metodologia para a execuo da anlise de negcios.
Planejamento e Monitoramento da Anlise de Negcios (Captulo 2) a rea

de conhecimento que descreve como os analistas de negcios determinam quais
atividades so necessrias para que se execute uma iniciativa de anlise de negcios.

Introduo reas de Conhecimento
Ela cobre a identificao das partes interessadas, seleo de tcnicas de anlise de

negcios, o processo que ser utilizado para o gerenciamento de requisitos e como
avaliar o progresso do trabalho. As tcnicas nessa rea de conhecimento governam
a execuo de todas as outras tarefas de anlise de negcios.
Elicitao (Captulo 3) descreve como analistas de negcios trabalham junto

s partes interessadas para identificar e compreender suas necessidades e
preocupaes, e compreender o ambientes no qual trabalham. A elicitao visa
garantir que as reais necessidades das partes interessadas sejam compreendidas e
no somente seus desejos explcitos ou superficiais.
Gerenciamento e comunicao dos requisitos (Captulo 4) descreve como os

analistas de negcios gerenciam conflitos, questes e mudanas no intuito de
garantir que as partes interessadas e o time do projeto permaneam em acordo
a respeito do escopo da soluo, como os requisitos so comunicados s partes
interessadas e como o conhecimento obtido pelo analista de negcios mantido
para o uso futuro.
Anlise Corporativa (Captulo 5) descreve como os analistas de negcios

identificam uma necessidade do negcio, refinam e esclarecem a definio daquela
necessidade, e definem um escopo de soluo que pode ser implementado pelo
negcio de forma vivel. Esta rea de conhecimento descreve a definio e anlise
do problema, desenvolvimento do business case, estudos de viabilidade e a definio
do escopo da soluo.
Anlise de Requisitos (Captulo 6) descreve como os analistas de negcios

priorizam e progressivamente elaboram os requisitos das partes interessadas e da
soluo, no intuito de permitir que a equipe do projeto implemente a soluo que ir
atender s necessidades da organizao patrocinadora e das partes interessadas. Ela
envolve a anlise das necessidades das partes interessadas para definir solues que
atendam essas necessidades, avaliando o estado atual do negcio para identificar e
recomendar melhorias, e a verificao e validao dos requisitos resultantes.
Avaliao e Validao da Soluo (Captulo 7) descreve como os analistas de

negcios avaliam as solues propostas para determinar qual soluo se encaixa
melhor nas necessidades do negcio, identificando lacunas (gaps) e falhas em
solues, e determinando solues provisrias ou mudanas necessrias na soluo.
Tambm descreve como os analistas de negcios avaliam as solues entregues
para ver quo bem elas atendem necessidade original para que a organizao
patrocinadora possa julgar o desempenho e eficcia da soluo.
Competncias Fundamentais (Captulo 8) descrevem os comportamentos,

conhecimentos e outras caractersticas que apoiam o desempenho efetivo da anlise
de negcios.

Tarefas Introduo
Figure 11: Relacionamentos entre as reas de Conhecimento
Planejamento e
Monitoramento da
Anlise de Negcios
Avaliao e
Anlise
Validao da
Corporativa Gerenciamento e
Soluo
Elicitao Comunicao dos
Requisitos
Anlise de
Requisitos
Competncias
Fundamentais
1.5 Tarefas
Cada rea de conhecimento descreve as tarefas desempenhadas por analistas de
negcios para atingir o propsito daquela rea. Cada tarefa no Guia BABOK
apresentada no seguinte formato:
1.5.1 Propsito
Cada tarefa possui um propsito. O propsito uma breve descrio da razo pela
qual um analista de negcios executa a tarefa e o valor criado atravs da sua execuo.
1.5.2 Descrio
Uma tarefa um segmento essencial do trabalho que precisa ser desempenhado
como parte da anlise de negcios. Cada tarefa deve ser executada ao menos uma
vez durante a grande maioria das iniciativas de anlise de negcios, mas no h um
limite para o nmero de vezes que uma tarefa possa ser executada.
As tarefas podem ser executadas em qualquer escala. Cada tarefa pode ser executada
em perodos que variam de muitos meses a poucos minutos. Por exemplo, um
business case pode ser um documento de algumas centenas de pginas, justificando
um investimento de bilhes de dlares, ou uma nica frase explicando o benefcio
que uma mudana ir produzir para um nico indivduo.
Uma tarefa possui as seguintes caractersticas:
Alcana um resultado numa sada que gera valor para a organizao

patrocinadora isto , se uma tarefa executada, ela deve produzir algum
resultado positivo e demonstrvel que seja til, especfico, visvel e mensurvel.

Introduo Tarefas
completa por princpio, tarefas sucessoras que fazem uso de suas sadas
devem poder ser executadas por outra pessoa ou grupo.
uma parte necessria do propsito da rea de conhecimento a qual est associada.
O Guia BABOK no determina um processo ou uma ordem na qual tarefas so

executadas. Alguma ordenao das tarefas inevitvel, uma vez que certas tarefas
produzem as sadas que constituem entradas obrigatrias para outras tarefas.
Contudo, importante manter em mente que o Guia BABOK apenas determina que
a entrada deve existir. A entrada pode ser incompleta ou sujeita a mudana e reviso,
o que pode levar a tarefa a ser executada diversas vezes. Ciclos de vida iterativos
ou geis podem requerer que tarefas, em todas as reas de conhecimento, sejam
executadas em paralelo e ciclos de vida com fases claramente definidas ainda iro
requerer que tarefas de mltiplas reas de conhecimento sejam executadas em cada
fase. Tarefas podem ser executadas em qualquer ordem, contanto que as entradas
necessrias estejam presentes.
A descrio de uma tarefa explica em maior detalhe porque ela executada, o que a
tarefa e os resultados que deve atingir.
1.5.3 Entrada
Uma entrada representa as informaes e as pr-condies necessrias para que a
tarefa seja iniciada. Entradas podem ser:
Explicitamente geradas fora do escopo da anlise de negcios (ex.: a construo

de um aplicativo de software);
Gerada por uma tarefa de anlise de negcios.
No assumido que a presena de uma entrada ou de uma sada signifique que a

entrega associada esteja completa ou em seu estado final. A entrada apenas precisa
estar suficientemente completa para permitir que o trabalho subsequente seja
iniciado. Podem existir vrias instncias de uma mesma entrada durante o ciclo de
vida de uma iniciativa.
Figura 1-2: Diagramas de Entrada/Sada de Tarefa
Entrada/Sada
X.Y *
Produzido Produzido pela tarefa Produzido por
Externamente (veja a tarefa #) mltiplas tarefas
Associao
Tarefas e reas de Conhecimento

X.Y rea de
Tarefa Conhecimento Externo
(com a Seo #)
+ +

Tarefas Introduo
.1 Requisitos
Os requisitos so um caso particular de entrada ou sada, o que no deve ser
surpresa dada a sua importncia para anlise de negcios. Eles so as nicas
entradas e sadas que no so produzidas por uma nica tarefa. Os requisitos
podem ser classificados de diferentes maneiras e existir em diferentes estados.
Quando listado como sendo uma entrada ou uma sada de uma tarefa, o seguinte
formato ser utilizado para indicar a classificao e o estado de um requisito ou de
um grupo de requisitos:
Requisitos Classificao [Estado ou Estados]. Se classificaes ou estados no

estiverem listados, quaisquer ou todos os requisitos podem ser utilizados como
entrada ou sada. Por exemplo, Requisitos [declarados] significa que o requisito
pode possuir qualquer classificao, j Requisitos do Negcio significaria que os
requisitos do negcio podem estar em qualquer estado possvel (ex.: verificados,
priorizados, declarados ou combinaes desses estados).
Estados tambm podem ser combinados em alguns casos. Por exemplo, Requisitos
[Priorizados e Verificados] devem ser entendidos como indicao de que os requisitos
foram priorizados e tambm verificados. Requisitos [Priorizados ou Verificados]
significa que os requisitos podem estar priorizados, verificados ou ambos.
No texto geral, a classificao ser escrita antes, seguida pelo estado (ex.: requisitos
declarados, requisitos de negcios verificados, etc.) Novamente, se o estado ou
classificao no forem indicados, significa que o requisito no est restrito a
qualquer estado ou classificao em particular.
1.5.4 Elementos
O formato e a estrutura desta seo so nicos para cada tarefa. A seo elementos
descreve os principais conceitos que so necessrios para compreender como
executar a tarefa.
1.5.5 Tcnicas
Cada tarefa contm uma lista de tcnicas relevantes. Algumas tcnicas so
especficas para a execuo de uma nica tarefa, enquanto outras so relevantes
para a execuo de grande nmero de tarefas (e esto listadas no Captulo 9:
Tcnicas). Se uma determinada tarefa pode utilizar ambos os tipos de tcnicas, as
encontradas no Captulo 9 sero listadas dentro da subseo Tcnicas Gerais. Se no
houver subsees, ento todas as tcnicas podem ser encontradas no Captulo 9.
Para informao adicional, veja Tcnicas (1.6).
1.5.6 Partes interessadas

Cada tarefa inclui uma lista de partes interessadas genricas que tendem a participar
na execuo daquela tarefa ou que sero afetadas por ela. Uma parte interessada
genrica representa uma classe de pessoas com a qual o analista de negcios
provavelmente ir interagir de alguma forma. O Guia BABOK no impe que esses
papis sejam ocupados em cada projeto. Qualquer parte interessada pode ser uma
fonte de requisitos, suposies ou restries.
Esta lista no uma lista exaustiva de todas as classificaes possveis de partes

interessadas, uma vez que seria simplesmente impossvel compilar tal lista. Alguns
exemplos adicionais de pessoas que se encaixam em cada um desses papis genricos
so indicados na Figura 1-3. Na maior parte dos casos, haver vrios papis de partes

Introduo Tarefas
interessadas dentro de cada categoria. Da mesma forma, um mesmo indivduo pode

preencher mais de um papel.
.1 Analista de Negcios
Por definio, o analista de negcios parte interessada em todas as atividades de
anlise de negcios. O Guia BABOK escrito com base na suposio de que o analista
de negcios responsvel pela execuo dessas atividades e pode ser cobrado pelo
resultado final (acionvel). Em alguns casos, o analista de negcios poder tambm
ser responsvel pela execuo das atividades que se encaixam no papel de outra
parte interessada. Os papis mais comuns atribudos para analistas de negcios,
alm do seu papel como analista, so o de Especialista no assunto, Especialista em
implementao da soluo, Gerente de Projeto e Testador. Diretrizes a respeito da
execuo desses papis adicionais esto fora do escopo do Guia BABOK, uma vez
que estes papis no fazem parte da disciplina de anlise de negcios.
Figura 1-3: Exemplos de partes interessadas genricas

Parte Interessada Genrica Exemplos e Papis Alternativos
Analista de Negcios Analista de Negcios e Sistemas, Analista de Sistemas, Analista
de Processos, Consultor, Dono do Produto, etc.
Cliente Segmentado por mercado, geografia, indstria, etc.
Especialista no assunto Por unidade organizacional, cargo, etc.
Usurio final Por unidade organizacional, cargo, etc.
Especialista em implementa- Bibliotecrio do projeto, gerente de mudanas, gerente de con-
o da soluo figurao, arquiteto de soluo, desenvolvedor, DBA, arquiteto
da informao, analista de usabilidade, instrutor, consultor de
mudana organizacional, etc.
Suporte operacional Help Desk, tcnicos de rede, gerente de verso (release)
Gerente de Projetos Scum Master, lder de equipe
Fornecedor Provedores de produto ou servio, consultores, etc.
Testador Analista de qualidade
Regulador Governo, entidades de regulamentao, auditores
Patrocinador Gerentes, executivos, gerentes de produtos, donos de processos
.2 Cliente
Um cliente uma parte interessada fora das fronteiras de uma determinada
organizao ou unidade organizacional. Clientes fazem uso dos produtos ou servios
produzidos pela organizao e podem possuir direitos morais ou contratuais que a
organizao obrigada a atender.
.3 Especialista no assunto.
Um especialista no assunto qualquer indivduo com profundo conhecimento de
um tpico relevante para a necessidade do negcio ou escopo da soluo. Este papel
frequentemente preenchido por pessoas que iro tambm ser usurios finais ou
pessoas que sero usurios indiretos da soluo, como gerentes, donos do processo,
funcionrios do departamento jurdico (que podero agir como representantes de
reguladores), consultores e outros.

Tarefas Introduo
.4 Usurio Final
Usurios finais so partes interessadas que iro interagir diretamente com a soluo.
O termo mais frequentemente usado no contexto de desenvolvimento de software,
onde usurios finais so aqueles que iro de fato utilizar o aplicativo que est sendo
desenvolvido. Em contexto mais amplo de uma soluo, porm, eles podem incluir
todos os participantes em um processo de negcio.
.5 Especialista em Implementao da Soluo

Os especialistas em implementao da soluo so responsveis por desenhar e
implementar potenciais solues. O especialista em implementao da soluo
prover competncias especializadas no desenho e construo dos componentes da
soluo que esto fora do escopo da anlise de negcios.
Apesar de no ser possvel definir uma lista de especialistas em implementao

da soluo que seja apropriada para todas as iniciativas, alguns dos papis mais
comuns so:
Desenvolvedores/Engenheiros de Software
Desenvolvedores so responsveis pela construo dos aplicativos de software. reas
de expertise dos desenvolvedores ou engenheiros de software incluem linguagens
especficas ou componentes de aplicativos. Boas prticas de desenvolvimento de
software reduziro significativamente o custo de se construir um aplicativo, traro
previsibilidade ao processo de desenvolvimento e a habilidade de implementar
mudanas nas funcionalidades suportadas por um aplicativo.
Profissionais de Gerenciamento de Mudanas Organizacionais

Profissionais de Gerenciamento de Mudanas Organizacionais so responsveis
por facilitar a aceitao e adoo de novas solues e superar a resistncia s
mudanas. reas de expertise de profissionais de gerenciamento de mudanas
incluem conhecimento de fatores culturais e conhecimento de mercado. Um bom
gerenciamento de mudanas pode ajudar a criar defensores das mudanas dentro de
uma organizao.
Arquitetos de sistemas
Arquitetos de sistemas so responsveis por dividir um aplicativo de software em
componentes e definir as interaes entre eles. reas de expertise de arquitetos
de sistemas incluem a compreenso de metodologias e de solues oferecidas por
fornecedores especficos. Uma boa arquitetura de sistemas facilitar o desenvolvimento
rpido de solues e a reutilizao de componentes em outras solues.
Instrutores
Instrutores so responsveis por garantir que os usurios finais de uma soluo
entendam como ela deve funcionar e sejam capazes de utiliz-la de maneira eficaz.
reas de expertise de instrutores podem incluir educao presencial ou virtual. Um
treinamento eficaz facilitar a aceitao e a adoo de uma soluo.
Profissionais de usabilidade
Profissionais de usabilidade so responsveis pelo desenho da interao entre um
usurio e solues tecnolgicas e por fazer com que essas solues sejam o mais
simples possvel de serem usadas. reas de expertise de profissionais de usabilidade
incluem design de interface com o usurio e arquitetura da informao. Uma boa
usabilidade aumentar a produtividade e a satisfao dos clientes e reduzir custos
de manuteno da soluo e de treinamentos.

Introduo Tarefas
.6 Gerente de Projeto
Gerentes de Projeto so responsveis por gerenciar o trabalho necessrio para
entregar uma soluo que atenda necessidade do negcio e por garantir que os
objetivos do projeto sejam atingidos enquanto so balanceadas as restries do
projeto, incluindo escopo, oramento, cronograma, recursos, qualidade, risco,
entre outras.
.7 Testador
Testadores so responsveis por determinar como verificar se uma soluo atende
aos requisitos da soluo definidos pelo analista de negcios, como tambm por
conduzir o processo de verificao. Testadores tambm procuram garantir que a
soluo atenda aos padres de qualidade aplicveis e que o risco de defeitos seja
compreendido e minimizado.
.8 Regulador
Reguladores so responsveis pela definio e pelo cumprimento de padres.
Padres podem ser os que a equipe de desenvolvimento da soluo deve seguir,
os padres que a soluo deve atender ou ambos. Reguladores podem fazer com
que seja cumprida a legislao, os padres de governana corporativa, padres de
auditoria ou padres definidos por centros de competncia Organizacional.
.9 Patrocinador
Patrocinadores so responsveis por iniciar o esforo para definio de uma
necessidade do negcio e desenvolver uma soluo que atende quela necessidade.
Eles autorizam o trabalho que ser executado e controlam o oramento da iniciativa.
.10 Fornecedor
Um fornecedor uma parte interessada fora das fronteiras de uma determinada
organizao ou unidade organizacional. Fornecedores proveem produtos ou servios
para a organizao e podem possuir direitos e obrigaes morais ou contratuais que
precisam ser considerados.
1.5.7 Sada
Uma sada um resultado necessrio do trabalho descrito na tarefa. Sadas so
criadas, transformadas ou mudam de estado como resultado da finalizao bem
sucedida de uma tarefa. Apesar de uma sada especfica ser criada e mantida por
uma nica tarefa, uma tarefa pode possuir mltiplas sadas.
Uma sada pode ser uma entrega ou ser uma parte de uma entrega maior. A forma de
uma sada depende do tipo de iniciativa em andamento, dos padres adotados pela
organizao e do bom senso do analista de negcios sobre a maneira apropriada de
se satisfazer s necessidades de informao das principais partes interessadas.
Como ocorre com as entradas, uma instncia de uma tarefa pode ser completada
sem que a sada esteja em seu estado final. necessrio apenas que a entrada ou
sada esteja suficientemente completa para permitir que o trabalho subsequente
seja iniciado. Da mesma forma, pode haver uma ou vrias instncias de uma mesma
sada criadas como parte de qualquer iniciativa. Finalmente, a criao de uma sada
no requer necessariamente que as tarefas subsequentes, que utilizam o produto
daquele trabalho como entrada, devam ser iniciadas.

Tcnicas Introduo
1.6 Tcnicas
As tcnicas proveem informaes adicionais sobre as diferentes maneiras atravs
das quais uma tarefa pode ser executada, ou diferentes formas que as sadas da
tarefa podem assumir. Uma tarefa pode no possuir nenhuma, uma ou mais tcnicas
relacionadas. Uma tcnica deve ser relacionada a pelo menos uma tarefa.
O Guia BABOK no determina um grupo de tcnicas de anlise que deve ser usado.
As tcnicas descritas nesse documento so aquelas que demonstraram possuir
valor e estar em uso pela maior parte da comunidade de analistas de negcios.
Analistas de Negcios que esto familiarizados com essas tcnicas provavelmente
sero capazes de execut-las de forma eficaz sob a maior parte das circunstncias
com as quais podem se deparar. Contudo, essas tcnicas no so necessariamente
as melhores escolhas em todas as situaes possveis, nem mesmo so capazes
de atuar em todas as situaes de forma eficaz. Igualmente, pouco provvel que
um analista de negcios seja chamado para demonstrar competncia em todas as
tcnicas definidas no Guia BABOK.
Pode-se dizer que uma parte das tcnicas do Guia BABOK tem uso amplamente
difundido. Essas tcnicas so usadas regularmente pela maior parte dos analistas de
negcios e so ocasionalmente usadas pela vasta maioria dos praticantes. provvel
que muitas ou a maioria das organizaes tero a expectativa de que os analistas
de negcios possuam experincia prtica com essas tcnicas. As tcnicas que esto
nesta categoria so:
Definio de critrios de aceite e avaliao (9.1)
Brainstorming (9.3)
Anlise de Regras de Negcio (9.4)
Dicionrio de Dados e Glossrio (9.5)
Diagramas de Fluxo de Dados (9.6)
Modelagem de Dados (9.7)
Anlise de Deciso (9.8)
Anlise de Documentos (9.9)
Entrevistas (9.14)
Mtricas e Indicadores-Chave de Desempenho (9.16)
Anlise de Requisitos No-Funcionais (9.17)
Modelagem da Organizao (9.19)
Rastreamento de Problemas (9.20)
Modelagem de Processos (9.21)
Workshops de Requisitos (9.23)
Cenrios e casos de uso (9.26)

Introduo Competncias Fundamentais
O Guia BABOK pode, em alguns casos, agrupar tcnicas similares, ou tcnicas

que compartilham um mesmo propsito sob um mesmo ttulo. Por exemplo, a
tcnica Modelagem de Dados (9.7) inclui modelos de classes e diagramas de
entidade-relacionamento e poderia, por princpio, incluir mapas conceituais,
modelos de termos e fatos, modelos de papis de objetos e outras tcnicas de
anlise menos difundidas.
Cada tcnica no Guia BABOK apresentada no seguinte formato:
1.6.1 Propsito
Define para que a tcnica usada e as circunstncias sob as quais a sua aplicao
mais provvel.
1.6.2 Descrio
Descreve o que a tcnica e como ela usada.
1.6.3 Elementos
O formato e estrutura dessa seo so nicos para cada tcnica. A seo elementos
descreve os principais conceitos que so necessrios para compreender como usar
a tcnica.
1.6.4 Consideraes do uso

Descreve condies sob as quais a tcnica pode ser mais ou menos eficaz.
1.7 Competncias Fundamentais

As competncias fundamentais so habilidades, conhecimentos e caractersticas
pessoais que do suporte ao desempenho eficaz da anlise de negcios. As reas de
competncias fundamentais relevantes para anlise de negcios incluem:
Pensamento Analtico e Capacidade de Soluo de Problemas do suporte

identificao eficaz dos problemas do negcio, avaliao das solues propostas
para os problemas e compreenso das necessidades das partes interessadas.
Pensamento analtico e capacidade de soluo de problemas envolvem avaliar uma
situao, compreend-la da maneira mais completa possvel e fazer julgamentos
sobre possveis solues para um problema.
Caractersticas comportamentais do suporte ao desenvolvimento de

relacionamentos de trabalho efetivos com as partes interessadas e incluem
qualidades como tica, confiabilidade e organizao pessoal.
Conhecimento do Negcio d suporte compreenso do ambiente no qual a anlise

de negcios desempenhada e o conhecimento de princpios gerais dos negcios e
solues disponveis.
Habilidades de Comunicao do suporte ao analista de negcios na elicitao

e comunicao dos requisitos entre as partes interessadas. Habilidades de
comunicao atendem necessidade de se escutar e compreender a audincia,
compreender como a audincia percebe o analista de negcios, compreender o(s)
objetivo(s) da comunicao, a mensagem em si e o meio e formato mais apropriados
para a comunicao.
Habilidades de Interao do suporte ao analista de negcios para trabalhar com

grande nmero de partes interessadas e envolvem tanto a habilidade de trabalhar

Outras Fontes de Informao sobre Anlise de Negcios Introduo
como parte de um time maior, quanto a de ajudar o grupo a tomar decises. A maior
parte do trabalho de anlise de negcios envolve a identificao e a descrio de
uma situao futura. Porm, o analista de negcios deve tambm ser capaz, atravs
da combinao de liderana e facilitao, de auxiliar a organizao a chegar a um
acordo de que a situao em questo realmente a desejada.
Aplicativos de Software so usados para facilitar o desenvolvimento colaborativo,

registro e distribuio de requisitos para as partes interessadas. Analistas de
Negcios devem ser usurios habilidosos das ferramentas utilizadas em suas
organizaes e devem compreender as foras e fraquezas de cada uma delas.
1.8 Outras Fontes de Informao sobre Anlise de Negcios

O Guia BABOK uma sntese da informao sobre o papel da anlise de negcios
desenhada a partir de uma ampla variedade de abordagens para a melhoria
e mudana dos negcios. Uma lista completa dos trabalhos referenciados no
desenvolvimento do Guia BABOK pode ser encontrada no Apndice B: Bibliografia.
Analistas de negcios buscando estender sua compreenso de anlise de negcios
podem desejar consultar trabalhos dessas outras disciplinas, obter treinamentos
com especialistas nessas reas ou buscar outras oportunidade de educao e
desenvolvimento profissional.
Mais especificamente, utilizamos informaes das seguintes reas (e corpos de

conhecimentos a elas relacionados) sobre suas aplicaes anlise de negcios:
Desenvolvimento gil (Agile development)
Business Intelligence (BI)
Gerenciamento de Processos de Negcio (Business Process Management)
Regras de Negcio
Teoria dos Jogos e Anlise de Deciso
Arquitetura Corporativa (incluindo Zachman Framework for Enterprise

Architecture e TOGAF)
Frameworks de Governana e de Conformidade, incluindo Sarbanes-Oxley,

BASEL II e outros
Gerenciamento de Servios de TI (incluindo ITIL)
Lean e Six Sigma
Gerenciamento de Mudanas Organizacionais
Gerenciamento de Projetos
Gerenciamento da Qualidade
Arquitetura Orientada a Servios (SOA)
Engenharia de Software (particularmente Engenharia de Requisitos)

Introduo Outras Fontes de Informao sobre Anlise de Negcios
Melhoria de Processos de Software (Sofware Process Improvement)

(incluindo CMMI )
Garantia de Qualidade de Sofware (Software Quality Assurance)
Planejamento Estratgico
Usabilidade e User Experience Design
O Guia BABOK foca na definio do papel da anlise de negcios ao longo de um

amplo leque de abordagens de anlise de negcios e, por isso, apenas toca brevemente
em muitas das informaes desenvolvidas por praticantes trabalhando nestas
disciplinas. Analistas de Negcios descobriro que o estudo de qualquer dessas reas
ser recompensado com uma maior compreenso da profisso do analista de negcios,
a habilidade para colaborar com outros profissionais e a compreenso das diversas
maneiras com as quais analistas podem beneficiar as organizaes que os empregam.

Planejamento e Monitoramento
da Anlise de Negcios
Captulo DOIS
A rea de conhecimento Planejamento e Monitoramento da Anlise de Negcios
define as tarefas associadas com o planejamento e o monitoramento das atividades
de anlise de negcios, incluindo:
Identificao das partes interessadas;
Definio dos papis e responsabilidades das partes interessadas dentro do

esforo de anlise de negcios;
Desenvolvimento de estimativas para as tarefas de anlise de negcios;
Planejamento da forma de comunicao entre o analista de negcios e as partes

interessadas;
Planejamento de como os requisitos sero abordados, rastreados e priorizados;
Determinao das entregas que o analista de negcios ir produzir;
Definio e determinao dos processos de anlise de negcios;
Determinao das mtricas que sero utilizadas para monitorar o trabalho de

anlise de negcios.
Alm disso, esta rea de conhecimento descreve o trabalho envolvido em

monitoramento e comunicao sobre o trabalho executado para garantir que o
esforo de anlise de negcios produza os resultados esperados. Se estes resultados
no ocorrem, o analista de negcios deve tomar aes corretivas para atender s
expectativas das partes interessadas.
Figura 2-1: Diagrama de Entrada/Sada do Planejamento e Monitoramento da Anlise de Negcios
Sadas
Entradas
2.1 2.4 2.6
* 5.1 Tarefas
Abordagem Plano de Avaliao do
2.1 2.2
Mtricas de Necessidade de Anlise de Comunicao Desempenho
Planejar a Conduzir a Anlise
Desempenho do Negcio Negcios da Anlise de da Anlise de
Abordagem da de Partes
da Anlise de Negcios Negcios
Anlise de Negcios Interessadas
Negcios
2.3 2.4 2.3 2.6 2.5
Planejar Atividades Planejar a
da Anlise de Comunicao da Plano(s) da Ativos de Plano de
Arquitetura Opinio de Negcios Anlise de Negcios Anlise de Processos de Gerenciamento
Corporativa Especialistas Negcios Anlise de de Requisitos
2.5 2.6 Negcios
Planejar o Processo Gerenciar o
de Gerenciamento Desempenho da 2.2
Ativos de de Requisitos Anlise de Negcios
Processos Lista de Partes
Organizacionais Interessadas, Papis e
Responsabilidade

Planejar a abordagem da Anlise de Negcios Planejamento e Monitoramento da Anlise de Negcios
2.1 Planejar a abordagem da Anlise de Negcios

2.1.1 Propsito
Esta tarefa descreve como selecionar uma abordagem para o desempenho da anlise
de negcios, quais partes interessadas devem ser envolvidas na deciso, quem ser
consultado e informado a respeito da abordagem e a lgica do seu uso.
2.1.2 Descrio
Abordagens da Anlise de Negcios descrevem o processo geral que ser seguido
para a execuo do trabalho de anlise de negcios em uma determinada iniciativa,
como e quando as tarefas sero executadas, as tcnicas que sero utilizadas e as
entregas que devem ser produzidas.
Existem muitos meios j estabelecidos para a abordagem do trabalho de anlise

de negcios. No desenvolvimento de software, eles variam daqueles ditados pela
abordagem cascata, at o uso de metodologias geis. Da mesma forma, existe um
nmero considervel de metodologias de melhorias em processos de negcio bem
conhecidas, incluindo Lean e Seis Sigma, como tambm metodologias, customizaes
e prticas proprietrias ou desenvolvidas internamente nas empresas. Elementos
de diferentes abordagens podem ser combinados, contudo apenas um subconjunto
de todas as combinaes possveis ser vivel para o ambiente organizacional em
particular onde uma iniciativa est sendo executada.
No intuito de planejar a abordagem da anlise de negcios, o analista de negcios deve

compreender as necessidades e objetivos do processo organizacional que se aplicam
iniciativa. Essas necessidades e objetivos podem incluir compatibilidade com outros
processos organizacionais, restries de tempo para o lanamento de um produto
(time-to-market), obedincia a questes regulatrias e estruturas de governana,
o desejo de experimentar novas abordagens para o desenvolvimento da soluo ou
outros objetivos do negcio. Se os objetivos no so conhecidos, o analista de negcios
pode ser chamado a definir os requisitos aos quais o processo deve atender.
Em muitos casos, as organizaes tero padres formais ou informais sobre como a

anlise de negcios feita e como ela se encaixa no projeto e em outras atividades.
Se este for o caso, o analista de negcios revisa quaisquer padres organizacionais
existentes, incluindo normas, diretrizes e processos relativos iniciativa atual. Eles
podem sugerir ou impor qual abordagem utilizar. Mesmo onde uma abordagem
padro existe, ela deve ser adaptada para as necessidades de uma iniciativa
especfica. A adaptao pode ser governada por padres organizacionais que
definem quais abordagens so permitidas, quais elementos desses processos podem
ser adaptados, orientaes gerais para a seleo de um processo e assim por diante.
Caso no existam padres, o analista de negcios trabalha com as partes

interessadas apropriadas para determinar como o trabalho ser completado.
O analista de negcios deve ser capaz de selecionar ou criar uma abordagem e
trabalhar junto s principais partes interessadas, em especial o gerente do projeto e
o time do projeto, para garantir que ela adequada.
A abordagem da anlise de negcios frequentemente baseada, ou relacionada,

abordagem do projeto, mas em alguns casos elas devem ser determinadas de
forma independente (por exemplo, uma organizao pode utilizar uma abordagem
orientada ao planejamento para definir os processos de negcios e ento utilizar
uma abordagem orientada mudana para construir aplicativos de software para
suporte desses processos de negcios).

Planejamento e Monitoramento da Anlise de Negcios Planejar a abordagem da Anlise de Negcios
2.1.3 Entradas
Necessidade do Negcio: A abordagem da anlise de negcios ser moldada pelo
problema ou oportunidade enfrentada pela organizao. Geralmente necessrio
considerar os riscos associados, o prazo no qual a necessidade deve ser atendida
e quo bem a necessidade foi compreendida. Isso ajudar a determinar se uma
abordagem orientada ao planejamento ou mudana apropriada.
Opinio de especialistas: Usada para determinar a abordagem ideal para a

anlise de negcios. Este conhecimento pode ser oferecido por um vasto nmero
de fontes, incluindo as partes interessadas da iniciativa, Centros de Competncia
Organizacional, consultores ou associaes e grupos da indstria. Experincias
anteriores do analista de negcios e outras partes interessadas devem ser levadas
em conta quando selecionando ou modificando uma abordagem.
Ativos de Processos Organizacionais: Incluem os elementos de abordagens de anlise

de negcios existentes em uso pela organizao. Ativos de processos organizacionais
que podem ser teis na definio da abordagem da anlise de negcios incluem
metodologias para processos de mudana ou desenvolvimento de software, ferramentas
e tcnicas que se encontram em uso ou compreendidas pelas partes interessadas,
padres de governana corporativa (como COBIT, Sarbanes-Oxley e Basel II) e modelos
de entregas. Alm desses padres gerais, a organizao pode possuir orientaes em
vigor para adaptao de processos para atender a uma iniciativa especfica.
Figura 2-2: Diagrama de Entrada/Sada de Planejar a Abordagem da Anlise de Negcios

Entradas
5.1
Necessidade Opinio de Ativos de Processos

de Negcio Especialistas Organizacionais
2.1
Planejar a
Abordagem da
Anlise de Negcios
2.1
Abordagem da
Anlise de Negcios
Tarefas que usam esta sada

2.3 2.5
Planejar Atividades Planejar o Processo
da Anlise de de Gerenciamento
Negcios de Requisitos

2.1.4 Elementos
Quase todas as metodologias se encaixam em algum ponto do espectro entre
a abordagem orientada ao planejamento e a abordagem orientada mudana.
Abordagens orientadas ao planejamento focam em minimizar, de antemo, a

incerteza e em garantir que a soluo seja totalmente definida antes do incio
da implementao, no intuito de maximizar o controle e reduzir o risco. Essas
abordagens tendem a ser preferidas em situaes onde os requisitos podem ser
efetivamente definidos antes da implementao, o risco de uma implementao
incorreta inaceitavelmente alto, ou quando gerenciar as interaes das partes
interessadas apresenta desafios significativos. A autoridade para aprovar requisitos
tipicamente reside em partes interessadas selecionadas e no patrocinador do projeto.
O patrocinador do projeto ter autoridade final para aprovar os requisitos da soluo,
mas comum que patrocinadores insistam que outras partes interessadas concedam
a sua aprovao antes que ele o faa. Metodologias cascata de desenvolvimento de
software e iniciativas de reengenharia de processos de negcio so exemplos tpicos
das abordagens orientadas ao planejamento.
Abordagens orientadas mudana focam na entrega rpida de valor de negcio em

pequenas iteraes em troca da aceitao de um grau maior de incerteza a respeito
da entrega geral da soluo. Essas abordagens tendem a ser preferidas quando
tomada uma abordagem exploratria para se encontrar a melhor soluo ou
para a melhoria incremental de uma soluo existente. A autoridade para aprovar
requisitos geralmente reside em um nico indivduo, que um participante ativo nas
atividades dirias do time outros podem aconselhar ou ser informados, mas no
podem recusar o seu consentimento, e o processo de aprovao deve ser completado
dentro de um estrito limite de tempo. Metodologias geis de desenvolvimento de
software, como tambm projetos de melhorias contnuas, so exemplos tpicos de
abordagens orientadas mudana.
O desempenho desta tarefa depende de onde a abordagem selecionada se encaixa no

espectro. As descries abaixo atingem as extremidades do espectro e abordagens
hbridas podem combinar aspectos de ambas. Consideraes semelhantes devem
ser levadas em conta quando o analista de negcios est selecionando ou adaptando
a abordagem.
.1 Tempo de Trabalho de Anlise de Negcios

Determinar quando os esforos de anlise de negcios devem ocorrer, quando
tarefas precisam ser executadas e se o nvel do esforo de anlise de negcios
precisar variar ao longo do tempo. Isso inclui determinar se atividades da anlise
corporativa, da anlise de requisitos e da definio e validao da soluo sero
desempenhadas primariamente em fases especficas do projeto, ou iterativamente
ao longo do curso da iniciativa.
Abordagens orientadas ao planejamento possuem a maior parte do trabalho

de anlise de negcios acontecendo no incio do projeto ou durante uma fase
especfica. O nome exato da fase varia de acordo com a metodologia especfica, mas
o foco principal da fase inclui atividades como elicitao , anlise, documentao,
verificao e comunicao dos requisitos, como tambm relatrio de posio das
atividades de anlise de negcios do projeto.
Abordagens orientadas mudana podem possuir um esforo antecipado de anlise

de negcios conduzido para produzir uma lista inicial de requisitos de alto nvel
(tambm conhecida como viso dos requisitos). Este backlog do produto ento

atualizado ao longo do projeto conforme novos requisitos emerjam. Ao longo do

projeto, esses requisitos sero priorizados e repriorizados com base na necessidade
do negcio. Os requisitos mais prioritrios sero removidos do backlog para uma
anlise de requisitos detalhada, conforme os recursos tornem-se disponveis para
implementao e a implementao ir comear assim que a anlise estiver completa.
.2 Formalidade e Nvel de Detalhe das Entregas da Anlise de Negcios

Determinar se os requisitos sero entregues como documentao formal ou atravs
de comunicao informal junto s partes interessadas e o nvel apropriado de
detalhe que deve estar contido nesses documentos. As entregas esperadas devem ser
definidas como parte da abordagem. Veja o Captulo 4: Gerenciamento e Comunicao
dos Requisitos para exemplos de entregas da anlise de negcios.
Abordagens orientadas ao planejamento tipicamente requerem uma quantidade

significativa de formalismo e detalhe. Requisitos so capturados em um documento
formal ou em um conjunto de documentos que seguem modelos padronizados.
Isto pode ser precedido por uma srie de documentos de requisitos relacionados,
elaborados com nveis crescentes de detalhe, incluindo uma viso de alto nvel e
documento de escopo com foco nos requisitos do negcio, e documentos descrevendo
os requisitos do ponto de vista de grupos especficos de partes interessadas. Partes
interessadas relevantes geralmente devem aprovar formalmente cada um desses
documentos antes de se iniciar o detalhamento dos requisitos. O contedo e
formato especficos dos documentos de requisitos podem variar, dependendo das
metodologias, processos e modelos de documentos da organizao.
As abordagens orientadas mudana favorecem a definio dos requisitos atravs

da interao com a equipe e atravs da coleta de feedback sobre uma soluo em
funcionamento. Documentao de requisitos obrigatria frequentemente limitada
a uma lista de requisitos priorizada. Documentao adicional pode ser criada a
critrio da equipe e geralmente consiste de modelos desenvolvidos para aumentar o
entendimento da equipe sobre um problema especfico. Uma abordagem alternativa
documentar os requisitos na forma de critrios de aceiteacompanhados por testes.
Documentao formal frequentemente produzida aps a implementao da
soluo para facilitar a transferncia de conhecimento.
.3 Priorizao dos Requisitos

Determinar como os requisitos sero priorizados e como aquelas prioridades sero
usadas para definir o escopo da soluo. Mtodos de priorizao de requisitos so
discutidos em Priorizar Requisitos (6.1). Veja tambm o Captulo 5: Anlise corporativa
para informaes sobre a definio do escopo da soluo e Captulo 4: Gerenciamento
e Comunicao de Requisitos para informao sobre o gerenciamento do escopo da
soluo. Mtodos de Priorizao tambm sero utilizados na execuo de Alocar
Requisitos (7.2). Abordagens orientadas mudana tendem a colocar muita nfase
na eficcia dos mtodos de priorizao de requisitos devido ao pequeno escopo de
cada iterao ou release.
.4 Gerenciamento da Mudana
Mudanas nos requisitos podem ocorrer a qualquer momento.
Considere a possibilidade prevista e a frequncia de mudana e garanta que o

processo de gerenciamento de mudana efetivo para esses nveis de mudana.
Prticas efetivas de anlise de negcios podem reduzir significativamente a
quantidade de mudanas requisitadas em um ambiente estvel de negcios, mas
no pode elimin-las completamente.

Abordagens orientadas ao planejamento buscam garantir que as mudanas

ocorrero somente quando elas forem genuinamente necessrias e claramente
justificadas. Cada mudana frequentemente manipulada como um mini-projeto,
completo, com elicitao de requisitos, estimativas, desenho, etc. Mudanas em
requisitos impactam ambos os escopos, da soluo e do projeto, e o processo de
gerenciamento de mudana ser incorporado no processo geral de gerenciamento
de projeto.
Muitas organizaes possuem um processo formal que inclui uma requisio de

mudana, um registro de mudanas que rastreia todas as mudanas que foram
recebidas e uma anlise do impacto da mudana, no s para o projeto, mas tambm
para outros negcios e sistemas automatizados. Na prtica, o nmero e impacto das
solicitaes de mudana frequentemente aumentam no final do projeto.
Isso pode ocorrer devido a qualquer combinao de fatores, incluindo projetos com
escopo no definido, falta de propriedade dos requisitos pelas partes interessadas
do projeto, anlise de negcios mal executada, mudanas nas prioridades
gerenciais, reorganizao do negcio, mudanas regulatrias ou mudanas nos
requisitos do negcio.
Abordagens orientadas mudana presumem que difcil identificar todos os

requisitos com antecedncia sua implementao. Geralmente no existe um
processo de gerenciamento de mudanas separado da seleo dos requisitos de
uma dada iterao. Mudanas nas capacidades de uma soluo existente so
simplesmente priorizadas e selecionadas para uma iterao, usando os mesmos
critrios usados com novas caractersticas e capacidades.
.5 Processo de Planejamento da Anlise de Negcios

O analista de negcios deve determinar o processo que ser seguido para planejar a
execuo das atividades de anlise de negcios. Na maioria dos casos, este processo
ser integrado a um plano de projeto maior.
.6 Comunicao com as Partes Interessadas

As comunicaes podem ser escritas ou verbais, formais ou informais. As decises
devem ser feitas desde o incio do projeto quanto aplicabilidade de tecnologias de
comunicao, tal como email, no que diz respeito ao projeto de deciso e aprovao
de entregas.
Abordagens orientadas ao planejamento tendem a contar com mtodo formal

de comunicao. Grande parte da comunicao dos requisitos escrita e
frequentemente usa formulrios pr-definidos que requerem aprovao atravs de
assinatura. Toda documentao do projeto normalmente arquivada como parte
do histrico do projeto.
Abordagens orientadas mudana focam mais na frequncia da comunicao que

na documentao formal. A documentao oficial frequentemente escrita, mas a
comunicao informal tem precedncia sobre a comunicao escrita mais formal. A
documentao frequentemente ocorre seguida da implementao.
.7 Ferramentas de Anlise e Gerenciamento dos Requisitos

O analista de negcios deve identificar todas as ferramentas de anlise ou de
gerenciamento de requisitos que sero usadas. Essas ferramentas podem moldar
a seleo das tcnicas de anlise de negcios, notaes a serem usadas e a forma
atravs da qual os requisitos sero empacotados.

.8 Complexidade do Projeto
A complexidade do projeto, a natureza das entregas e o risco geral para as
necessidades do negcio precisam ser levados em considerao. Os fatores listados
abaixo, entre outros, aumentam a complexidade dos esforos de anlise de negcios
conforme eles crescem:
Nmero de partes interessadas;
Nmero de reas de negcio afetadas;
Nmero de sistemas de negcios afetados;
Quantidade e natureza do risco;
Singularidade dos requisitos;
Nmero de recursos tcnicos requeridos.
O nvel de incerteza dos requisitos parcialmente dependente do domnio do projeto.
Por exemplo, novos empreendimentos, projetos de pesquisa ou marketing tendem

a ter uma maior incerteza dos requisitos, enquanto projetos de contabilidade e
finanas tendem a ter um nvel relativamente mais baixo de incerteza dos requisitos.
Muitas organizaes tm a necessidade que o conhecimento a respeito de uma

soluo seja mantido a longo prazo, porque a responsabilidade da soluo pode ser
terceirizada, pois h rotatividade na equipe do projeto, por causa da distribuio
geogrfica dos participantes ou porque as principais pessoas esto trabalhando por
contrato e no permanecero disponveis para a organizao aps a implementao.
Uma documentao formal pode ser requerida para tratar desses riscos.
2.1.5 Tcnicas
Anlise de Deciso (9.8): Pode ser usada para avaliar metodologias diante s
necessidades e objetivos organizacionais.
Modelagem de Processos (9.21): Modelos de processos podem ser usados para

definir e documentar a abordagem da anlise de negcios.
Reviso Estruturada (9.30): Esta tcnica pode ser usada como meio de validao
de uma abordagem de anlise de negcios criada, selecionada ou adaptada.
2.1.6 Partes Interessadas

Cliente, Especialista no Assunto, Usurio Final ou Fornecedor: A abordagem
adotada pode depender da sua disponibilidade e envolvimento com a iniciativa.
Especialista em Implementao da Soluo: A abordagem de anlise de negcios

adotada deve ser compatvel com o ciclo de vida de implementao utilizado pela
equipe de implementao.
Gerente do Projeto: O gerente do projeto deve garantir que a abordagem da anlise

de negcios compatvel com outras atividades do projeto.
Testador: A abordagem da anlise de negcios deve facilitar as atividades de teste

apropriadas.

Conduzir a Anlise das Partes Interessadas Planejamento e Monitoramento da Anlise de Negcios
Regulador: Aspectos da abordagem ou decises feitas no processo de adaptao

podem requerer aprovao.
Patrocinador: A abordagem adotada pode depender da sua disponibilidade e

envolvimento com a iniciativa. O patrocinador pode tambm ter necessidades e
objetivos que se aplicam abordagem em si.
2.1.7 Sada
Abordagem da Anlise de Negcios: Esta a definio da abordagem que ser
adotada para a anlise de negcios em uma dada iniciativa. Uma abordagem da
anlise de negcios deve especificar papis na equipe, entregas, tcnicas de anlise,
os momentos e a frequncia das interaes com as partes interessadas e outros
elementos do processo de anlise de negcios. Uma metodologia uma abordagem
de anlise de negcios formalizada e repetvel. Ela inclui uma deciso sobre quais
ativos de processo organizacional sero aplicados e quaisquer decises feitas a
respeito da adaptao do processo para uma situao especfica. A documentao a
respeito da abordagem pode ser eventualmente adicionada ao repositrio de ativos
de processos da organizao.
2.2 Conduzir a Anlise das Partes Interessadas

2.2.1 Propsito
Esta tarefa cobre a identificao das partes interessadas que podem ser afetadas
por uma iniciativa proposta ou por quem compartilha uma necessidade de negcio
em comum, identificando as partes interessadas apropriadas para o projeto ou para
uma fase do projeto e a determinao da influncia das partes interessadas e/ou a
sua autoridade para a aprovao das entregas do projeto.
2.2.2 Descrio
A anlise das partes interessadas desempenhada assim que a necessidade do negcio
identificada e ser usualmente uma atividade contnua enquanto a anlise de negcios
estiver sendo executada. A anlise das partes interessadas comea com a identificao
das partes interessadas que podem ser afetadas pela necessidade do negcio ou pela
nova soluo. As partes interessadas podem ser agrupadas em categorias que reflitam
seu envolvimento e interesse na iniciativa. Os papis, responsabilidade e autoridade
sobre os requisitos para cada parte interessada ou grupo de partes interessadas
devem ser claramente descritos. A anlise das partes interessadas tambm envolve
o entendimento das partes interessadas sobre a influncia e atitude em relao a
iniciativa e a avaliao de atitudes positivas e negativas e comportamentos que podem
afetar o resultado da iniciativa e aceitao da soluo.
2.2.3 Entradas
Necessidade do Negcio: Identificar e analisar a posio das partes interessadas
afetadas pela necessidade do negcio. Como a compreenso desta necessidade
evolui atravs da definio dos requisitos do negcio, escopo da soluo, requisitos
das partes interessadas e requisitos da soluo, a informao adicional ser usada
para auxiliar na identificao das partes interessadas adicionais ou na compreenso
de como as partes interessadas existentes podem ter mudado de posio.
Arquitetura corporativa: Descreve as unidades organizacionais que existem,

suas interaes com outras unidades organizacionais, clientes e fornecedores, suas
responsabilidades dentro da organizao e os papis e relacionamentos dentro de
cada unidade organizacional.

Planejamento e Monitoramento da Anlise de Negcios Conduzir a Anlise das Partes Interessadas
Ativos de Processos Organizacionais: Estes incluem polticas e procedimentos

organizacionais, formulrios que precisam ser preenchidos, metodologias sugeridas
ou prescritas, modelos e autorizao de diretrizes de projetos. Eles podem ser
ditados ou expressos na forma de diretrizes.
Figura 2-3: Diagrama de Entrada/Sada de Conduzir a Anlise das Partes Interessadas
Entradas
5.1
Necessidade Arquitetura Ativos de

do Negcio Corporativa Processos
Organizacionais
2.2
Conduzir a Anlise
das Partes
Interessadas
2.2
Lista de Partes
Interessadas, Papis e
Responsabilidades
2.3 2.4
Planejar Atividades Planejar a 3.1
da Anlise de Comunicao da Preparar a Elicitao
Negcios Anlise de Negcios
4.1
Gerenciar escopo e 6.1
requisitos da Priorizar Requisitos
soluo
2.2.4 Elementos
Os papis das partes interessadas devem ser identificados no incio do projeto para
ajudar a garantir que as entregas de requisitos sejam finalizadas em tempo hbil.
Note que alguns indivduos podem ser chamados a desempenhar uma srie de
papis de partes interessadas dentro de um mesmo projeto, como tambm diferentes
papis em diferentes projetos.

.1 Identificao
Entender quem so as partes interessadas e o impacto das mudanas propostas
sobre elas vital para o entendimento de quais necessidades, desejos e expectativas
devem ser satisfeitas por uma soluo.
Devido aos requisitos serem baseados nas necessidades, desejos e expectativas

das partes interessadas, aqueles que so descobertos tardiamente ou que no so
descobertos podero gerar a necessidade de uma reviso completa dos requisitos,
modificando ou tirando propsito de tarefas completas ou de tarefas em progresso,
aumentando custos e diminuindo a satisfao. Abordagens orientadas mudana
podem acomodar melhor este risco, mas no conseguem elimin-lo e uma
identificao tardia de partes interessadas pode continuar resultando em alteraes
ao roadmap do projeto e ao contedo da verso.
Quem participa de cada atividade de anlise de negcios pode variar entre projetos,
metodologias e organizaes. Por exemplo, algumas organizaes podem incentivar
seus membros da equipe tcnica a participar de workshops de requisitos para
fornecer custos, estimativas de esforo tcnico e informaes sobre os impactos
tcnicos, enquanto outras podem decidir que no permitida a discusso tcnica
durante essas reunies.
.2 Complexidade do Grupo de Partes Interessadas

A complexidade das interaes com um grupo de partes interessadas pode ser
afetada por aspectos como:
Nmero e variedade de usurios finais diretos na sua clientela. Diferentes

abordagens, planos, relatrios, nvel de formalismo e a quantidade de
documentao podem ser personalizados, baseados no nmero de partes
interessadas que cada especialista no assunto representa. Partes interessadas
com uma clientela menor podem ser capazes de representar seu grupo de partes
interessadas sem muita dificuldade. Partes interessadas representando grande
nmero de membros, ou representando diferentes reas funcionais ou divises
podem precisar pesquisar informaes ou se dedicar elicitao de requisitos.
Nmero de processos de negcio e sistemas automatizados com que fazem

interface. O planejamento para partes interessadas que representam processos
de negcios complexos, cheios de interfaces ou sobreposio diferente do feito
para aqueles que representam processos mais autocontidos. Uma vez que nem
todas as partes interessadas podem ou desejam participar de todos os workshops
de requisitos, elas podem facilmente ser persuadidas a participar, se o workshop
for focado em seus processos e nos aplicativos de software associados.
.3 Atitude e Influncia
Avaliar as atitudes das partes interessadas em relao influncia sobre a iniciativa.
Fatores a considerar incluem:
Atitude em relao a:
Os objetivos e metas do negcio e a abordagem da soluo:
Eles acreditam que a soluo ir beneficiar a organizao?
Os benefcios os afetaro diretamente?
Os benefcios sero refletidos em outro lugar?

Os possveis efeitos negativos da iniciativa nessa parte interessada so

maiores do que as recompensas?
Atitude em relao anlise de negcios:
Eles vem valor na definio dos seus requisitos?
Eles apresentam solues e esperam que os requisitos estejam contidos

naquela soluo e acreditam que isso permitir que eles evitem a definio
de requisitos?
Atitude em relao colaborao:
Eles tiveram sucesso em esforos colaborativos anteriores?
A organizao premia a colaborao?
A organizao possui uma natureza hierarquizada ao invs de baseada em

equipes?
Os interesses pessoais so a norma?
Atitude em relao ao patrocinador:
Em esforos interfuncionais, todos os especialistas no assunto apoiam o

patrocinador?
Existem especialistas no assunto que preferem outro patrocinador?
Atitude em relao aos membros da equipe:
H membros-chave da equipe do projeto (incluindo, mas no limitado ao

analista de negcios) que tenham construdo relacionamentos de confiana ou
houve projetos ou fases de projetos que falharam, envolvendo essas pessoas?
Influncia: Compreender a natureza da influncia e a estrutura e canal da

influncia dentro da organizao pode ser valioso quando se procura construir
relacionamentos e trabalhar na construo de confiana. Compreender a influncia
que cada parte interessada pode ter, bem como suas atitudes, pode auxiliar a
desenvolver estratgias para a obteno de seu comprometimento e colaborao.
Alguns fatores relacionados influncia a serem considerados so:
Influncia no projeto. Quanto de influncia a parte interessada tem no projeto?

Por exemplo, devido ao fato dos patrocinadores obterem financiamento,
incluindo recursos, e tomarem decises vitais, eles usualmente exercem mais
influncia que os usurios finais.
Influncia na organizao. Usualmente existem estruturas formais e informais

dentro das organizaes, e certos cargos e funes que, mesmo podendo revelar
autoridade ou posio de poder, nem sempre podem refletir a real importncia
ou autoridade que uma parte interessada possui.
Influncia necessria para o bem do projeto. O analista de negcios deve analisar

o quo influente necessrio tornar o projeto bem sucedido, comparado
com a quantidade de influncia que as principais partes interessadas, como
o patrocinador do projeto, tm. Por exemplo, um projeto grande e complexo,

requerendo muitos recursos internos e externos, necessitar de um patrocinador

que possui relacionamentos efetivos com grupos de financiamento para garantir
que os recursos adequados estejam disponveis para trabalho. Projetos que so
pequenos podem requerer patrocinadores com menos influncia. Se existir
incompatibilidade entre a influncia requerida e a quantidade de influncia
que a parte interessada tem, ou aparentemente tem, o analista de negcios deve
desenvolver planos de riscos e respostas e outras estratgias que possam ser
necessrias para obter o nvel requerido de suporte.
Influncia com outras partes interessadas. Dentro da maioria das organizaes

existe uma maneira informal atravs da qual a influncia ocorre. melhor estar
a par desta estrutura informal de influncia. Por exemplo, se existirem partes
interessadas que se consideram campees em projetos, elas podem ser teis na
converso daqueles que esto menos entusiasmados ou mesmo que so hostis ao
propsito do projeto e aos seus resultados.
.4 Nveis de Autoridade para o Trabalho de Anlise de Negcios

Identificar quais partes interessadas tero autoridade sobre as atividades de anlise
de negcios, tanto em relao ao trabalho de anlise de negcios, quanto s entregas
do produto. As partes interessadas podem possuir autoridade de:
Aprovar as entregas;
Inspecionar e aprovar os requisitos;
Requisitar e aprovar mudanas;
Aprovar os processos de requisitos que sero usados;
Revisar e aprovar a estrutura de rastreabilidade;
Vetar requisitos e solues propostas (individualmente ou em um grupo).
Informaes adicionais sobre os nveis de autoridade podem ser encontradas em

Planejamento do Processo de Gerenciamento de Requisitos (2.5).
2.2.5 Tcnicas
.1 Tcnicas Gerais
Definio dos Critrios de Aceite e Avaliao (9.1): O analista de negcios deve,
como parte da anlise das partes interessadas, identificar quais partes interessadas
possuem autoridade suficiente para aceitar ou rejeitar uma soluo.
Brainstorming (9.3): Pode auxiliar na identificao das necessidades e requisitos

que levam s possveis partes interessadas ou na criao de uma lista de possveis
papis de partes interessadas.
Entrevistas (9.14): Entrevistados podem ser capazes de identificar outras partes

interessadas.
Modelagem Organizacional (9.19): Avaliar para determinar se as unidades

organizacionais ou pessoas listadas possuem quaisquer necessidades e interesses
nicos que devam ser considerados. Descrever os papis e funes na organizao
e as maneiras com as quais as partes interessadas interagem e, ento, auxiliaro a
identificar partes interessadas que so afetadas por uma mudana.

Modelagem de Processos (9.21): Qualquer pessoa envolvida na execuo de

processos de negcios afetados pela soluo ser uma parte interessada. Modelos
de processos podem ser uma fonte para a identificao de partes interessadas, desde
que os processos relacionados possam ser afetados. Alm disso, a categorizao de
partes interessadas com base nos sistemas que suportam seus processos de negcios
pode ser til quando mudanas precisam ser feitas para os processos e sistemas.
Workshops de Requisitos (9.23): Durante os workshops de requisitos, o analista

de negcios pode perguntar aos participantes se eles podem sugerir outras
partes interessadas.
Anlise de Riscos (9.24): Riscos para a iniciativa podem resultar das atitudes de
partes interessadas ou da habilidade das principais partes interessadas de participar
da iniciativa.
Cenrios e Casos de Uso (9.26), e Histrias de Usurios (9.33): A identificao

dos papis das partes interessadas pode servir como um ponto de partida til para a
identificao de atores e papis.
Modelagem do Escopo (9.27): Modelos do Escopo devem mostrar partes interessadas

que esto fora do escopo da soluo, mas que iro interagir com ela de alguma forma.
Pesquisa/Questionrio (9.31): til para identificar caractersticas compartilhadas

de um grupo de partes interessadas.
.2 Matriz RACI
A matriz RACI descreve os papis daqueles envolvidos nas atividades de anlise de
negcios. Ela descreve partes interessadas como tendo uma ou mais das seguintes
responsabilidades para uma dada tarefa ou entrega:
[R]esponsvel faz o trabalho
[A]cusvel o tomador de deciso (apenas um)
[C]onsultado deve ser consultado antes do trabalho e fornece entrada(s)
[I]nformado significa que eles devem ser notificados do resultado
Um exemplo de uma Matriz RACI pode ser vista abaixo:
Figura 2-4: Exemplo de Matriz RACI

Processo de Solicitao de Mudana RACI Processo de Solicitao de Mudana RACI
Patrocinador Executivo A Analista de Banco de dados (DBA) C
Analista de Negcios R Analista de Infraestrutura C
Gerente de Projetos C Arquiteto do Negcio R
Desenvolvedor C Arquiteto da Informao C
Testador I Dono da Soluo C
Instrutor I Usurio Final I
Arquiteto da Aplicao C Especialista no Assunto C
Modelador de Dados C R, C, I
Outras partes interessadas
(varia)

.3 Mapa das Partes Interessadas

Mapas das partes interessadas so diagramas visuais que descrevem o
relacionamento das partes interessadas com a soluo e entre elas. H muitas
formas de mapas das partes interessadas, mas duas comuns incluem:
Uma matriz mapeando o nvel de influncia das partes interessadas versus o

nvel de interesse da parte interessada.
Um diagrama cebola indicando o quo envolvida a parte interessada est com

a soluo (quais partes interessadas iro interagir diretamente com a soluo
ou participar em um processo de negcios que faz parte da organizao e quais
esto fora da organizao).
Mapas de partes interessadas frequentemente incluem linhas de comunicao entre

Figura 2-5: Matriz de Partes Interessadas

Alto
Trabalhar prximo Parte

Influncia da Parte Interessada
Assegurar que a Parte Interessada Interessada para garantir que ela

permanea satisfeita. esteja de acordo e apoie as
mudanas.
Manter informada; provvel que

Monitorar se a influncia ou o
a Parte Interessada esteja muito
interesse da Parte Interessada
preocupada e possa se sentir
no se altera.
ansiosa sobre a falta de controle.
Baixo
Baixo Impacto sobre a Parte Interessada Alto
Figura 2-6: Diagrama Cebola das Partes Interessadas

Clientes, fornecedores,
reguladores e outros.
Partes Interessadas Externas Afetadas
Patrocinadores, executivos,
especialista no assunto e
Organizao ou Corporao outras pessoas que interagem
com o grupo afetado.
Unidade
Usurio final, help desk e
Organizacional Afetada
outros, cujo trabalho muda
quando a soluo entregue.
Entrega da
Soluo
Equipe de projeto e outros
diretamente envolvidos com
a criao da soluo.

Planejamento e Monitoramento da Anlise de Negcios Planejar Atividades da Anlise de Negcios

Especialista no Assunto: Pode ser capaz de recomendar outros especialistas em
negcios para auxiliar na definio dos requisitos.
Especialista de Implementao: Pode ser capaz de identificar e recomendar as

Gerente de Projeto: Pode ser capaz de identificar e recomendar as partes

interessadas. No contexto de um projeto com um gerente de projeto designado, a
responsabilidade pela identificao das partes interessadas e de gesto deve ser
compartilhada com o gerente do projeto. O analista de negcios e gerente de projeto
devem colaborar na execuo dessa tarefa. O gerente de projeto responsvel
por garantir que a equipe do projeto rena os compromissos assumidos para as
partes interessadas, gerir a atribuio das partes interessadas para as tarefas do
projeto e sua participao na execuo do projeto, assegurando que as mudanas
que impactam o projeto sejam adequadamente geridas e aprovadas. O analista do
negcio tambm ajudar o gerente de projeto na definio de quais membros da
equipe do projeto devem ser envolvidos na elaborao, reviso ou aprovao de
entregas da anlise de negcios.
Testador: Pode ser capaz de identiticar e recomendar as partes interessadas.
Regulador: Pode exigir que representantes das partes interessadas ou grupos

especficos sejam envolvidos no processo.
Patrocinador: Pode ser capaz de identificar o domnio de especialistas no assunto

para ajudar com a definio de requisitos.
2.2.7 Sada
Lista de Partes Interessadas, Papis e Responsabilidades: Esta pode incluir
informaes como:
Lista de papis requisitados;
Nome e cargo das partes interessadas;
Categoria das partes interessadas;
Localizao das partes interessadas;
Necessidades especiais;
Nmero de indivduos interessados neste papel;
Descrio da influncia e interesse das partes interessadas;
Documentao dos nveis de autoridade das partes interessadas.
2.3 Planejar Atividades da Anlise de Negcios

2.3.1 Propsito
Determinar as atividades que devem ser executadas e as entregas que devem
ser produzidas, estimar o esforo requerido para desempenhar aquele trabalho
e identificar as ferramentas de gesto necessrias para medir o progresso das
atividades e entregas.

Planejar Atividades da Anlise de Negcios Planejamento e Monitoramento da Anlise de Negcios
2.3.2 Descrio
O analista de negcios determina quais atividades so requeridas para uma dada
iniciativa, como aquelas atividades sero realizadas, o esforo de trabalho envolvido
e uma estimativa de quanto tempo as atividades iro tomar. Esta tarefa inclui
atividades para:
Identificar as entregas da anlise de negcios;
Determinar o escopo do trabalho das atividades de anlise de negcios;
Determinar quais atividades o analista de negcios ir executar e quando;
Desenvolver estimativas para o trabalho de anlise de negcios.
As atividades que so executadas e como elas so executadas determinaro a

qualidade e e o cumprimento dos prazos das entregas da anlise de negcios e,
em ltima instncia, da soluo. O(s) plano(s) de anlise de negcios identifica(m)
e agenda(m) as atividades e recursos necessrios para produzir um conjunto de
requisitos claro e conciso que apoiem o desenvolvimento da soluo.
Esta atividade de planejamento ir tipicamente ocorrer mais de uma vez em uma

dada iniciativa ou projeto, j que os planos frequentemente devem ser atualizados
para se referir s condies de negcios alteradas, questes encontradas pelo analista
de negcios ou outros membros da equipe, lies aprendidas atravs do desempenho
das atividades de anlise de negcios ou outras circunstncias alteradas.
Uma maneira de acomodar a mudana em uma iniciativa maior planejar em uma

base incremental ou de forma cclica. Essa abordagem de planejamento cria um plano
de alto nvel para o longo prazo e planos detalhados para atuar em atividades de
curto prazo, com a compreenso de que os planos de longo prazo mudaro conforme
mais informao torne-se disponvel. Uma alternativa usada em metodologias
orientadas mudana seguir um processo bem definido e limitado no tempo para
o desenvolvimento de requisitos e limitar cada iterao para o trabalho que pode
ser completo no perodo alocado. Um roadmap de longo prazo pode ser usado para
definir expectativas, mas os contedos do roadmap so constantemente revisados
conforme prioridades mudam.
2.3.3 Entrada
Abordagem da anlise de negcios: Define o ciclo de vida, entregas, modelos e tarefas
que devem ser includas. Abordagens orientadas ao planejamento buscam definir
requisitos o quanto antes possvel para reduzir a incerteza, enquanto abordagens
orientadas mudana incentivam que os requisitos sejam definidos prximo da
implementao. Essas diferenas iro levar a diferentes entregas e identificao
de tarefas, como tambm diferentes sequncias e dependncias entre as tarefas. A
abordagem ir tambm determinar como o processo de planejamento desempenhado.
Avaliao do Desempenho da Anlise de Negcios: O analista de negcios deve

usar experincias prvias na iniciativa atual, ou em outras, para determinar o
esforo envolvido no desempenho do trabalho de anlise de negcios.
Ativos de Processos Organizacionais: Os padres organizacionais e ativos de

processos locais podem impor determinadas entregas. Lies aprendidas em
iniciativas prvias, bem como de anlise de negcios atualmente em andamento,
podem ser usadas para o desenvolvimento dos planos da anlise de negcios.

Lista de Partes Interessadas, Papis e Responsabilidades: Partes interessadas

iro apresentar comportamentos e preferncias individuais que podem precisar
ser atendidas. Por exemplo, uma principal parte interessada pode preferir utilizar
mapas de processos, o que pode influenciar o planejamento das tarefas da anlise
de negcios relacionado a esta parte interessada. Outra parte interessada pode
possuir alguma experincia utilizando uma tecnologia em particular e ser favorvel
a sua escolha no projeto atual, o que tambm pode influenciar as entregas, tarefas e
estimativas da anlise de negcios. Compreender os seus papis e responsabilidades
no projeto ir auxiliar a determinar o quanto aquelas preferncias iro moldar o
plano. Alm disto, dever ser reservado um tempo para trabalho junto s partes
interessadas para elicitar e analisar requisitos , assim como dever ser reservado um
tempo para trabalho com as partes interessadas com poder de deciso para aprovar
requisitos. O papel de cada parte interessada deve ser compreendido para que as
atividades apropriadas possam ser agendadas e o tempo necessrio alocado.
Figura 2-7: Diagrama de Entrada/Sada de Planejar Atividades da Anlise de Negcios

Entradas
2.1 2.6 2.2
Abordagem da Avaliao do Ativos de Processos Lista de Partes

Anlise de Desempenho da Organizacionais Interessadas,
Negcios Anlise de Papis e
Negcios Responsabilidade
2.3
Planejar Atividades
da Anlise de
Negcios
2.3
Plano(s) da
Anlise de
Negcios
Tarefas que usam esta sada Tarefas gerenciadas por esta sada
2.4 2.5 Gerenciamento e
Planejar o Processo Planejar a Comunicao de
Elicitao
de Gerenciamento Comunicao da Requisitos
de Requisitos Anlise de Negcios + +
2.6
Anlise de
Gerenciar o Anlise Corporativa
Requisitos
Desempenho da + +
Anlise de Negcios
Avaliao e Validao
da Soluo
+

2.3.4 Elementos
.1 Distribuio geogrfica das partes interessadas
O analista de negcios deve considerar a localizao fsica das principais partes
interessadas no projeto. Alguns projetos tero partes interessadas localizadas em
uma nica localidade, enquanto outros tero algumas das suas principais partes
interessadas dispersas em um grande territrio. Os projetos que se enquadram no
segundo caso podero envolver uma complexidade maior que ter um impacto sobre
as estimativas de algumas atividades e tarefas no projeto. As partes interessadas
podem estar agrupadas ou dispersas.
Agrupadas: Todas as principais partes interessadas esto localizadas na mesma

rea geogrfica. No h consideraes especiais de planejamento relacionadas
localizao para o analista de negcios envolvido nesses projetos.
Dispersas: Estes projetos mais complexos envolvem a existncia de algumas das

principais partes interessadas localizadas em diferentes regies geogrficas ou
mesmo em diferentes pases. Os fatores de distncia, possveis diferenas de fuso
horrio, cultura e de idioma aumentam a complexidade da anlise de negcios e
iro requerer esforo para identificar e contabilizar essas diferenas e como elas iro
afetar o planejamento dos requisitos e o desenvolvimento/seleo da soluo, testes
e implementao. Se as partes interessadas esto dispersas, pode ser necessrio ter
mais teleconferncias ou videoconferncias do que reunies presenciais.
Outra situao comum envolve um projeto com desenvolvimento terceirizado

no qual a equipe de desenvolvimento est fisicamente localizada a muitos fusos
horrios de diferena. Este tipo de situao, por exemplo, ser levada em conta
durante o planejamento da anlise de negcios e pode ser melhor atendida com
uma documentao de requisitos e critrios de aceite mais detalhados e sesses de
reviso mais frequentes.
.2 Tipo de projeto ou iniciativa

O tipo de projeto ou iniciativa para qual o analista de negcios foi designado pode
ter um impacto significante nas atividades que precisam ser desempenhadas. Por
exemplo, em um projeto para a compra de um novo pacote de software, o trabalho
ser diferente do de um esforo para o desenvolvimento de um novo processo de
negcio. Diferentes tipos de iniciativas de anlise de negcios incluem, mas no
esto limitadas a:
Estudos de viabilidade;
Melhorias em processos;
Mudanas organizacionais;
Desenvolvimento interno de novo software;
Desenvolvimento terceirizado de novo software;
Manuteno ou aperfeioamento de software;
Seleo de um pacote de software.

.3 Entregas da Anlise de Negcios

Uma lista de entregas til como uma base para a identificao das atividades.
Mtodos para a identificao de entregas incluem, mas no esto limitados a:
Entrevistas ou sesses facilitadas junto s principais partes interessadas;
Reviso da documentao de projetos;
Reviso dos ativos de processos organizacionais, como metodologias e modelos

que podem ditar quais entregas so requeridas.
Uma organizao pode possuir um conjunto padro de entregas, ou mltiplos conjuntos

so utilizados para suportar diferentes metodologias aprovadas. A decomposio das
entregas pode tambm depender das tcnicas selecionadas pelo analista de negcios
e pode incluir entregas como questes de entrevistas, ata de reunies, diagramas e
descries de casos de uso e modelos de processos atuais e futuros. A abordagem da
anlise de negcios frequentemente impe a utilizao de certas tcnicas. A maior parte
dos mtodos geis assume que histrias de usurios sero usadas para documentar os
requisitos das partes interessadas e uma iniciativa de BPM (Business Process Management/
Gerenciamento de Processos de Negcios) ir requerer modelagem de processos.
Frequentemente, tcnicas adicionais podem ser selecionadas em uma base ad

hoc durante a execuo da anlise de negcios conforme o analista de negcios
encontra situaes nas quais elas so mais apropriadas. Por exemplo, o analista de
negcios pode decidir elicitar requisitos utilizando um workshop de requisitos e,
ento, determinar naquele workshop que uma parte interessada especfica possui
requisitos adicionais que sero mais bem identificados atravs de uma entrevista ou
da observao da parte interessada durante a execuo do seu trabalho.
Entregas iro frequentemente tomar a forma de um pacote de requisitos, como

descrito em Preparar o Pacote de Requisitos (4.4). A seleo e o formato dos pacotes
de requisitos costumam ser impostos pela abordagem da anlise de negcios.
.4 Determinar as Atividades da Anlise de Negcios

Uma ferramenta importante na definio do escopo do trabalho e no desenvolvimento
de estimativas a Estrutura Analtica do Projeto (EAP). A EAP decompe o escopo
do projeto em partes menores, criando uma hierarquia de trabalho. Uma EAP pode
decompor o projeto em iteraes, liberaes ou fases, quebrar entregas em pacotes
de trabalho ou decompor atividades em tarefas menores.
Pacotes de trabalho incluem ao menos uma e usualmente muitas atividades

que podem ser posteriormente decompostas em tarefas ainda menores. Essa
decomposio de atividades e tarefas cria a Lista de Atividades.
A Lista de Atividades pode ser criada atravs de diferentes maneiras, como:
Selecionando cada entrega, atribuindo as atividades necessrias para completar

a entrega e quebrando cada atividade em tarefas;
Dividindo o projeto em fases, iteraes, incrementos ou liberaes, identificando

as entregas para cada diviso e adicionando atividades e tarefas em
conformidade;
Utilizando um projeto similar anterior como esboo e expandi-lo com tarefas

detalhadas exclusivas para a fase de anlise de negcios do projeto atual.

Os elementos identificados para cada atividade e tarefa podem incluir:
Um nico nmero para identificar cada tarefa especfica;
Descrio da atividade rotulada com um verbo e um substantivo e a descrio

detalhada das tarefas que compe cada atividade. Por exemplo, uma atividade
poderia ser rotulada Atualizar o Documento de Requisitos.
Alm disto, pode incluir outras informaes, tais como:
Suposies: Para cada tarefa podem existir fatores ou condies que so tomadas
como verdadeiras. O analista de negcios pode documentar esses fatores e onde as
estimativas presentes sero desenvolvidas utilizando essas suposies.
Dependncias: Identificar relacionamentos lgicos, como quais atividades devem

ser completadas antes que tarefas subsequentes possam ser iniciadas.
Marcos: Representam eventos significativos no progresso de um projeto. Os marcos

so usados para medir o progresso do projeto e comparar o progresso atual com
estimativas anteriores. Marcos podem ser usados como momentos para celebrar a
finalizao, uma entrega principal ou apenas uma seo do trabalho do projeto. Um
exemplo de marco principal a aprovao formal do documento de requisitos pelas
partes interessadas e pelo patrocinador.
2.3.5 Tcnicas
Estimativa (9.10): Uma variedade de tcnicas de estimativas pode ser usada para
produzir uma avaliao global da quantidade de trabalho necessria de anlise de
negcios requerida. Em alguns casos, mltiplas tcnicas podem ser empregadas
para que se validem mutuamente. Estimativas so normalmente desenvolvidas
em conjunto com o gerente do projeto e outros membros da equipe e fazem uso da
metodologia organizacional e de modelos para o desenvolvimento de estimativas.
Decomposio funcional (9.12): A decomposio das tarefas do projeto (utilizando

uma estrutura analtica do projeto) ou produto (utilizando uma estrutura analtica
da soluo) pode ser empregada para facilitar uma compreenso do trabalho em um
nvel suficiente de detalhe para permitir a estimativa das tarefas.
Anlise de Riscos (9.24): Identificar riscos que possam impactar no(s) plano(s) da
anlise de negcios.
2.3.6 Partes interessadas

Todas as partes interessadas listadas aqui podem potencialmente participar na
verificao e validao das entregas da anlise de negcios.
Cliente, Especialista no Assunto, Usurio Final e Fornecedor: O Especialista

no Assunto ser provavelmente uma das principais fontes de requisitos e a sua
disponibilidade crtica durante as atividades de planejamento. A sua compreenso
das tcnicas de anlise de negcios pode formatar a seleo das tcnicas ou requerer
que o analista de negcios dedique algum tempo para auxili-lo na compreenso de
como os requisitos so definidos. Clientes e fornecedores podem ser especialmente
difceis de agendar de forma eficaz.
Especialista em Implementao da Soluo: O Especialista em Implementao

da Soluo pode participar nas atividades de anlise de negcios no intuito de
facilitar a compreenso das necessidades das partes interessadas. Eles iro precisar

Planejamento e Monitoramento da Anlise de Negcios Planejar a Comunicao da Anlise de Negcios
conhecer em qual forma e quando as entregas sero produzidas como entradas para
o planejamento das suas prprias atividades.
Suporte Operacional: Pode utilizar as entregas da anlise de negcios como base

para planejamento das atividades de suporte operacional ou desenvolvimento da
documentao apropriada.
Gerente do Projeto: Em um projeto, o plano da anlise de negcios integrado como

um componente do plano geral do projeto. O gerente do projeto deve participar do
planejamento da anlise de negcios e responsvel por garantir que aqueles planos
esto integrados com o trabalho desempenhado pelas demais pessoas do projeto.
Alm disto, o escopo do trabalho de anlise de negcios gerenciado como parte do
escopo geral do projeto e mudanas quele escopo de trabalho (por exemplo, como
novas partes interessadas so identificadas ou requisitos do negcio mudam) podem
requerer a aprovao de uma mudana no escopo do projeto. O gerente do projeto
tambm ir desempenhar um papel-chave na identificao dos recursos para a
execuo das tarefas, agendamento de atividades e desenvolvimento de estimativas
de custos.
Testador: Precisar saber em qual formato e quando as entregas sero produzidas

como entradas para o planejamento das suas prprias atividades.
Patrocinador: Deve participar da aprovao das entregas da anlise de negcios.
2.3.7 Sada
Plano(s) da Anlise de Negcios: O(s) plano(s) da anlise de negcios pode(m)
incluir informaes como a descrio do escopo do trabalho, a Estrutura Analtica
do Projeto das entregas, uma Lista de Atividades e estimativas para cada atividade
e tarefa. Ele deve tambm descrever quando e como o plano deve ser alterado em
resposta a mudanas nas condies. O nvel de detalhe associado ao(s) plano(s)
determinado pela abordagem da anlise de negcios e pela metodologia geral.
Nota: Todas as tarefas em todas as outras reas de conhecimento possuem os planos

da anlise de negcios como uma entrada implcita. O(s) plano(s) determina(m)
quando e como cada tarefa executada.
2.4 Planejar a Comunicao da Anlise de Negcios

2.4.1 Propsito
Um plano de comunicaes da anlise de negcios descreve a estrutura proposta
e o cronograma das comunicaes relativas s atividades de anlise de negcios.
Registra e organiza as atividades para prover uma base para o estabelecimento de
expectativas para o trabalho de anlise de negcio, reunies, revises estruturadas
e outras comunicaes.
2.4.2 Descrio
Planejar as comunicaes da anlise de negcios inclui determinar a melhor
forma de receber, distribuir, acessar, atualizar e escalonar informaes das partes
interessadas do projeto e determinar a melhor forma de se comunicar com cada
uma delas.
Requisitos podem ser apresentados em vrios formatos. Essa tarefa descreve

o trabalho requerido para decidir qual(is) formato(s) (so) apropriado(s) para
uma iniciativa em particular e suas partes interessadas. Os requisitos devem ser

Planejar a Comunicao da Anlise de Negcios Planejamento e Monitoramento da Anlise de Negcios
apresentados em formatos que sejam compreensveis para o revisor: devem ser

claros, concisos, precisos e estar no nvel apropriado de detalhamento.
Consideraes para o plano de comunicaes da anlise de negcios incluem:
o que precisa ser comunicado;
qual o mtodo adequado para a entrega;
quem o pblico apropriado;
e quando a comunicao deve ocorrer.
Necessidades das partes interessadas e restries relevantes para a comunicao

incluem:
Localizao fsica e fuso horrio das partes interessadas;
Abordagem da comunicao com a parte interessada;
Que tipos de comunicaes sero necessrios (ex.: posicionamento,

anormalidades, problemas e suas resolues, riscos, resultados de reunies,
pendncias, etc);
Que tipos de requisitos sero elicitados (de negcio, das partes interessadas, de
soluo ou de transio, de alto nvel versus detalhados) e a melhor forma de
elicit-los (veja a rea de Conhecimento Elicitao para opes);
Qual a melhor forma de comunicar as concluses/pacotes de requisitos,

incluindo nvel de autoridade (autoridade de aprovao, autoridade de veto ou
apenas de reviso);
Restries na disponibilidade de tempo e recursos.
2.4.3 Entradas
Abordagem da Anlise de Negcios: Pode incluir padres e modelos usados para
a comunicao e expectativas a respeito de quando e como as comunicaes devem
ocorrer.
Plano(s) da Anlise de Negcios: Determina quando o trabalho ser desempenhado,

as entregas que sero produzidas e quais precisaro ser comunicadas.
Ativos dos Processos Organizacionais: Podem incluir um conjunto definido de

modelos para uso na comunicao da anlise de negcios, incluindo formatos de
apresentaes, modelos de documentos de requisitos, entre outros.
Lista de Partes Interessadas, Papis e Responsabilidades: Usada para identificar

as partes interessadas que requerem informaes referentes ao trabalho de anlise
de negcios, determina quando as informaes devem ser fornecidas e como se
espera que a parte interessada faa uso dessas informaes.

Figura 2-8: Diagrama de Entrada/Sada de Planejar Comunicao da Anlise de Negcios

Entradas
2.1 2.3 2.2
Abordagem Plano(s) da Ativos de Lista de Partes

da Anlise de Anlise de Processos Interessadas, Papis e
Negcios Negcios Organizacionais Responsabilidade
2.4
Planejar a
Comunicao da
Anlise de Negcios
2.4
Plano de
Comunicao da
Anlise de Negcios
4.4 4.5
Preparar Pacote de Comunicar
Requisitos Requisitos
2.4.4 Elementos
.1 Geografia
As comunicaes necessrias para um time que se encontra em um mesmo
local sero diferentes das comunicaes necessrias para um projeto com partes
interessadas dispersas. Por exemplo, mais difcil realizar rpidas reunies dirias
da equipe quando os participantes vivem em diferentes fusos horrios, quando a
tecnologia no est acessvel e onde muitas entregas complexas, com interfaces
complexas, esto sendo desenvolvidas simultaneamente em diferentes localidades.
.2 Cultura
Diversidade cultural tambm deve ser levada em conta quando planejar
comunicaes. Consideraes culturais so importantes independentemente
de onde os membros da equipe esto localizados. Alm das bvias barreiras da
linguagem, pode haver diferenas mais sutis que devem ser planejadas, incluindo:
Relacionamento com o tempo. Algumas culturas veem os prazos como

comprometimentos firmes, enquanto outras podem v-los como uma meta que
deve ser balanceada em relao a outras preocupaes e interesses.

Planejar a Comunicao da Anlise de Negcios Planejamento e Monitoramento da Anlise de Negcios
Relacionamento com a finalizao de tarefas. Algumas culturas finalizam

tarefas porque esto comprometidas com as atividades planejadas. Outras
completam tarefas primeiramente quando confiana e relacionamento humano
tiverem sido construdos.
Relacionamento com os contratos. Algumas culturas acreditam na letra da lei,

outras no esprito do contrato. Essa diferena pode emergir durante a criao de
solicitaes de propostas, por exemplo.
Relacionamento com a autoridade formal e informal. Algumas culturas preferem

uma estrutura de poder centralizado, onde decises so tomadas por um
pequeno grupo, enquanto outras preferem envolver todas as partes interessadas
afetadas na aprovao das decises.
O uso de modelos seguindo notao padronizada pode auxiliar na superao das

barreiras de linguagem, atravs da eliminao de muitas descries textuais.
.3 Tipo de Projeto
Diferentes projetos exigiro diferentes entregas e o volume de documentao necessria
em um pacote de requisitos vai variar dependendo do projeto. Alguns exemplos so:
Projeto de desenvolvimento de um novo software customizado e produzido dentro

da organizao. Neste cenrio, todos os requisitos devem ser includos.
Upgrade da tecnologia ou infraestrutura de um sistema em uso. Neste cenrio,

apenas os requisitos tcnicos podem ser necessrios no pacote.
Mudanas em um processo de negcio ou novos dados para um aplicativo existente.

Neste cenrio, o processo e requisitos de dados, regras de negcios, requisitos
funcionais e tcnicos sero necessrios.
Aquisio de um pacote de software. Este tipo de projeto provavelmente ir requerer

uma RFP (Solicitao de Proposta Request For Proposal em ingls) e o pacote dever
incluir requisitos do negcio, requisitos tcnicos, requisitos funcionais limitados e
outras especificaes do fornecedor.
Iteraes de desenvolvimento de software geis, breves e focadas. Estes projetos

podem no especificar, ou especificar com pouca formalidade, a documentao
de requisitos. Quadros brancos, flipcharts e histrias do usurio podem suprir as
necessidades. Metodologias geis focam na criao da documentao mnima
necessria para a entrega dos requisitos e muitas equipes geis preferiro
documentar a soluo aps ela ter sido entregue.
.4 Freqncia da comunicao
Investiga a frequncia requerida por vrias partes interessadas para cada tipo de
comunicao. Note que a frequncia dos reportes pode variar de parte interessada
para parte interessada. Por exemplo, a frequncia dos reportes do estado da anlise
de negcios pode ser quinzenal para o patrocinador, semanal para o especialista no
assunto e quinzenal para os parceiros tcnicos.
.5 Formalidade das Comunicaes

Planejar as comunicaes requer levar em considerao o nvel de formalidade
necessrio. Ele pode variar de parte interessada para parte interessada, de fase
do projeto para fase do projeto, no trabalho dentro de uma fase de projeto e nas
apresentaes dos requisitos.

A comunicao tende a ser mais formal sob as seguintes circunstncias:
O projeto extraordinariamente grande (segundo os padres da organizao)

e ser entregue em fases. O nvel de formalidade das comunicaes tende a
crescer conforme cresce a escala do projeto. Isso deve-se tipicamente a mais
partes interessadas envolvidas e mais comunicao ser necessria.
O domnio envolvido muito complexo. Note que o domnio afetado pelo projeto
pode ultrapassar fronteiras departamentais dentro da organizao. Por exemplo,
o domnio de recrutamento de colaboradores para a engenharia poderia
envolver a engenharia, recursos humanos, folha de pagamento, marketing e
departamentos de administrao de benefcios. Esses grupos sero as principais
partes interessadas para o projeto e as entregas.
A tecnologia empregada, caso houver, ser nova, ou nova para a organizao.
O projeto considerado de misso crtica, sendo que est diretamente ligado a

objetivos estratgicos.
O patrocinador executivo e/ou principais partes interessadas requerem

formalidade.
Os requisitos podem ser submetidos reviso regulatria.
Os requisitos sero apresentados a fornecedores em uma FRQ/RFI/RFP.
2.4.5 Tcnicas
Veja Preparar Pacote de Requisitos (4.4) e Comunicar Requisitos (4.5) para informao
adicional. Tcnicas de comunicao so descritas em Habilidades de Comunicao (8.4).
Revises Estruturadas (9.30): Uma das abordagens mais comuns para a

comunicao de requisitos. O tempo destinado para a conduo de cada reviso
estruturada e para discutir os assuntos levantados durante a reviso estruturada
deve ser includo no plano.

Cliente ou fornecedor: Grandes clientes de uma organizao ou fornecedores dessa
organizao (particularmente clientes institucionais) podem precisar ser informados
a respeito de mudanas planejadas com a devida antecipao sua implementao.
Especialista no Assunto: Pode ser envolvido na reviso e aprovao. Tende a

focar em questes de interesse particular ou em reas nas quais especialista.
Especialistas no Assunto frequentemente possuem influncia sobre os aprovadores,
mesmo se a sua aprovao no for formalmente requerida.
Usurio Final: Pode ser envolvido na reviso e aprovao. Pode tambm possuir
influncia considervel sobre os aprovadores, mesmo se a sua aprovao no for
formalmente requerida.
Especialista em implementao da soluo: Pode ser envolvido na reviso e

aprovao.
Suporte Operacional: Pode ser envolvido na reviso e aprovao. Focar

primeiramente nos requisitos que suportam a soluo.

Planejar o Processo de Gerenciamento de Requisitos Planejamento e Monitoramento da Anlise de Negcios
Gerente do Projeto: Em um projeto, o plano de comunicao da anlise de negcios

ser geralmente integrado dentro do plano de comunicaes geral do projeto.
Em projetos menores, o plano pode ser muito breve e pode no ser documentado
formalmente. Em projetos grandes e complexos e em projetos com muitas partes
interessadas, ele pode ser includo como uma parte da documentao de iniciao
do projeto e uma parte essencial do plano geral de comunicao do projeto.
Testador: Ir se envolver primeiramente na verificao e validao dos requisitos.
Regulador: Reguladores podem requerer que requisitos, decises e outras

informaes referentes execuo dos processos da anlise de negcios, ou da
definio da soluo, sejam retidos e estejam disponveis para a sua reviso.
Patrocinador: Necessidades de comunicao para o patrocinador tendem a focar

nos requisitos do negcio, requisitos de partes interessadas e da soluo em alto nvel.
2.4.7 Sada
Plano de Comunicao da Anlise de Negcios: Descreve como, quando e porque
o analista de negcios trabalhar diretamente com as partes interessadas. Os
componentes podem incluir:
Os requisitos para comunicao das atividades da anlise de negcios com as

partes interessadas;
Formato, contedo, meio e nvel de detalhamento;
Responsabilidade pela coleta, distribuio, acesso e atualizao da informao.
2.5 Planejar o Processo de Gerenciamento de Requisitos

2.5.1 Propsito
Definir o processo que ser utilizado para aprovar requisitos de implementao e
gerenciar mudanas no escopo da soluo ou dos requisitos.
2.5.2 Descrio
Esta tarefa determina o processo de gerenciamento apropriado para uma iniciativa
em particular. Isso inclui determinar o processo para mudanas nos requisitos,
quais partes interessadas precisam aprovar a mudana, quem ser consultado e
informado das mudanas e, por extenso, quem no precisa ser envolvido. A tarefa
tambm inclui a avaliao das necessidades de rastreabilidade dos requisitos e a
determinao de quais atributos dos requisitos sero capturados.
2.5.3 Entrada
Abordagem da Anlise de Negcios: A abordagem selecionada pode incluir a
definio de um processo apropriado de gerenciamento dos requisitos.
Plano(s) da Anlise de Negcios: O(s) plano(s) da anlise de negcios define(m)

quais entregas sero produzidas e quando. Entregas no podem ser gerenciadas at
serem criadas.
Ativos de Processos Organizacionais: Podem existir modelos ou processos

padronizados para o gerenciamento de requisitos dentro da organizao. O analista

Planejamento e Monitoramento da Anlise de Negcios Planejar o Processo de Gerenciamento de Requisitos
de negcios deve ser um conhecedor da abordagem da organizao em relao

definio dos requisitos, uma vez que ela ir influenciar fortemente os passos
do processo, tarefas e entregas requeridas ou esperadas durante as atividades de
planejamento e monitoramento dos requisitos.
Figura 2-9: Diagrama de Entrada/Sada de Planejar o Processo de Gerenciamento de Requisitos

Entradas
2.1 2.3
Abordagem Plano(s) da Ativos de

da Anlise de Anlise de Processos
Negcios Negcios Organizacionais
2.5
Planejar o Processo
de Gerenciamento
de Requisitos
2.5
Plano de
Gerenciamento
de Requisitos
2.6 4.1
3.2
Gerenciar o Gerenciar o Escopo e
Conduzir Atividades
Desempenho da os Requisitos da
de Elicitao
Anlise de Negcios Soluo
4.2
Gerenciar 6.1
Rastreabilidade dos Priorizar Requisitos
Requisitos
2.5.4 Elementos
.1 Repositrio
Um repositrio de requisitos um mtodo de armazenamento de requisitos, incluindo
aqueles em desenvolvimento, aqueles sob reviso e os requisitos aprovados. Repositrios

podem incluir quadros brancos, documentos de editores de textos, diagramas e

modelos, wikis, ferramentas e aplicaes de gerenciamento de requisitos, ou qualquer
outra forma de registro de informao que permita que os requisitos possuam uma
nica origem e estejam disponveis para todas as partes interessadas relevantes,
enquanto forem necessrios. Todos os requisitos aprovados devem ser encontrados
em um repositrio (em oposio ao uso de ferramentas como e-mail, que podem no
alcanar todas as partes interessadas relevantes e podem no ser conservadas) e as
partes interessadas precisam ser capazes de localizar os requisitos naquele repositrio.
A sistemtica para adicionar, alterar e excluir requisitos deve ser consistente e

claramente compreendida pela equipe. Padres de nomenclatura para arquivos ou
componentes auxiliaro na categorizao e manuteno dos requisitos.
.2 Rastreabilidade
Determinar se e como rastrear os requisitos com base na complexidade do domnio,
no nmero de vises dos requisitos que sero produzidas, nos impactos potenciais de
risco e em uma compreenso dos custos e benefcios envolvidos. Rastrear requisitos
adiciona uma ateno considervel ao trabalho de anlise de negcios e deve ser
efetuado correta e consistentemente para possuir valor.
Veja Gerenciar Rastreabilidade dos Requisitos (4.2) para informao adicional.
.3 Selecionar Atributos dos Requisitos

Os atributos dos requisitos proveem informao a respeito dos requisitos, como
a fonte do requisito, a importncia do requisito e outros metadados. Atributos
auxiliam no gerenciamento contnuo dos requisitos ao longo do ciclo de vida do
projeto. Eles precisam ser planejados e determinados junto com os requisitos, mas
no constituem em si parte da definio da soluo.
Os atributos permitem que a equipe de requisitos associe informaes a requisitos

individuais ou grupos de requisitos relacionados e facilitam o processo de anlise de
requisitos, expressando informaes como quais requisitos devem adicionar risco ao
projeto ou requerem anlise adicional. A informao documentada pelos atributos
auxilia a equipe a fazer trocas eficazes e eficientes entre requisitos, identificar partes
interessadas afetadas por potenciais mudanas e compreender o impacto de uma
mudana proposta.
Alguns atributos de requisitos frequentemente utilizados incluem:
Referncia absoluta. um identificador numrico (preferencialmente) ou textual

exclusivo. A referncia no alterada ou reutilizada caso o requisito seja movido,
modificado ou excludo.
Autor do requisito. Se o requisito for considerado ambguo, o autor pode ser

consultado para esclarecimentos.
Complexidade. Indica quo difcil ser a implementao dos requisitos. Ela

frequentemente indicada atravs de escalas qualitativas com base em nmero
de interfaces, complexidade de processos essenciais, ou a quantidade e natureza
dos recursos requeridos.
Propriedade. Indica o indivduo ou grupo que precisa do requisito, ou que ser o

dono do negcio aps o projeto ser liberado no ambiente alvo.

Prioridade. Indica quais requisitos precisam ser implementados primeiro. Veja

abaixo discusso a respeito da priorizao e gerenciamento de requisitos.
Riscos. Associados ao atendimento, ou no, dos requisitos.
Fonte do requisito. Todo requisito deve ser originado de uma fonte que possui
autoridade para definir este conjunto particular de requisitos. A fonte deve
ser consultada se o requisito for alterado, ou se mais informao referente ao
requisito, ou necessidade que direcionou o requisito, tiver que ser obtida.
Estabilidade. usada para indicar o quo maduro o requisito . Ela usada para
determinar se o requisito firme o suficiente para que se possa trabalhar sobre
ele. Note que a presena de grande nmero de requisitos instveis no ncleo do
projeto pode indicar um risco significativo sua continuao.
Estado do requisito, indicando se ele est proposto, aceito, verificado, adiado,

cancelado ou implementado.
Urgncia indica quo cedo o requisito necessrio. S especificada de forma

separada da prioridade quando existe um prazo limite para a implementao.
Atributos adicionais podem incluir informaes como custo, alocao de

recursos, nmero de reviso, rastreado da origem e rastreado ao destino.
.4 Processo de Priorizao de Requisitos

Nem todos os requisitos entregam o mesmo valor para as partes interessadas. A
priorizao foca esforo na determinao de quais requisitos devem ser investigados
antes, com base no risco associado a eles, o custo para entreg-los, os benefcios que
eles iro produzir, entre outros fatores. Linhas do tempo, dependncias, restries
de recursos e outros fatores influenciam em como os requisitos so priorizados.
Planejar o processo de priorizao dos requisitos auxilia a garantir que as partes
interessadas determinam e compreendem como os requisitos sero priorizados ao
longo e ao final do esforo da anlise de negcios.
Formalidade. A formalidade e o rigor da priorizao dos requisitos so determinados

parcialmente pela metodologia escolhida e pelas caractersticas do projeto em
si. As diferenas situar-se-o no nvel de detalhe, na quantidade de formalidade
da estrutura no processo de priorizao (ex.: encontros formais versus conversas
informais) e na quantidade de documentao necessria para suportar o processo
de priorizao.
Estabelecimento do Processo e Tcnica. O processo para planejar como a priorizao dos

requisitos acontecer precisa incluir qual(is) tcnica(s) de priorizao ser(o) usada(s).
Planejar a Participao. O analista de negcios, junto ao gerente do projeto e ao

patrocinador devem trabalhar em conjunto para determinar os participantes
necessrios para o processo de priorizao.
Quem convidar e quem responsvel pelos convites dependem das normas

organizacionais e melhores prticas. Uma vez que patrocinadores so, em ltima
instncia, responsabilizados pela efetividade da soluo e pelas grandes decises
do projeto, eles precisam ser convidados a participar da discusso, mesmo quando
eles delegam a participao para especialistas no assunto. Outra principal parte
interessada o gerente do projeto, cujo plano dependente de quais requisitos
sero liberados e quando. Os convites dependem das metodologias, normas

organizacionais e engajamento do patrocinador. Quando existirem muitos fatores

limitantes, convide participantes de acordo com eles.
.5 Gerenciamento da Mudana
Algumas consideraes ao planejar o gerenciamento das mudanas so:
Determinar o processo de requisio de mudanas. O processo pode, mas no

obrigado a estabelecer nveis de autorizao para a aprovao de mudanas. Por
exemplo, pode ser decidido que se uma mudana, quando estimada, tomar menos
do que uma determinada quantidade de tempo ou dinheiro, o requisitante e o
gerente do projeto podero aprov-la. Caso o limite seja ultrapassado a aprovao
dever vir do patrocinador.
Determinar quem ir autorizar as mudanas. A atividade de planejamento precisa

incluir a designao de quem poder aprovar mudanas, uma vez aprovados os
requisitos. Mtodos orientados ao planejamento geralmente possuem um comit
formal de controle de mudanas (CCM), ou Autoridade de Mudana, que considera
a mudana requisitada e prov um julgamento inicial dos mritos dessa requisio.
O comit de controle de mudanas pode ser formado por diferentes quantidades
de pessoas oriundas de diferentes posies. Ele pode ou no incluir o patrocinador,
o gerente do projeto, o analista de negcios, o especialista no assunto ou outros
grupos. Mtodos orientados mudana tendem a permitir que a equipe do projeto
ou um nico proprietrio do produto tenha controle direto sobre as mudanas.
Anlise do Impacto. Especificar quem ir executar a anlise dos impactos, como

processos de negcio, requisitos de informao, interfaces de sistemas e hardware,
outros produtos de software, outros requisitos, estratgias e planos de testes, para
mencionar alguns.
Planejar a redao da requisio. importante estabelecer no incio das atividades

de anlise de negcios a expectativa de que, apesar da documentao necessria
para requisitar mudanas depende da metodologia e do projeto, a redao da
requisio deve ser clara. A mudana requisitada deve ser expressa em termos no-
ambguos. Ainda assim ser necessrio discutir a natureza da requisio com o
requisitante e outras partes interessadas.
O processo dos requisitos precisa enumerar a natureza dos componentes dentro de

uma requisio de mudana. Esses devem incluir:
Estimativas de custo e tempo da mudana
Para cada item, produto de trabalho ou produto tcnico afetado, uma breve
avaliao do custo esperado da mudana deve ser estimada. Como uma
questo de boa prtica, a reusabilidade levar a melhorias no processo de
mudana, atravs da limitao da extenso e escopo das mudanas em
outros componentes. A meta deve ser garantir resposta mudana, no
levantando objees e impedimentos ilimitados ao processo de mudana.
A estimativa fornecer uma viso integrada dos custos, recursos necessrios,

prazo para implementao e quaisquer outras dependncias.
Benefcios e riscos da mudana
Como a mudana se alinha ao projeto e aos objetivos do negcio para

auxiliar na garantia de que todas as mudanas adicionam valor ao negcio.

Uma vez que mesmo mudanas que parecem favorveis envolvem

consequncias no planejadas, a requisio deve incluir uma anlise bem
estruturada da mudana (escrita ou verbal), declaraes dos riscos esperados,
incluindo tanto influncias positivas quanto negativas aos objetivos do projeto.
Os benefcios considerados devem incluir no apenas os financeiros, mas
tambm os aspectos tcnicos das caractersticas dos produtos, influncias ao
escopo do projeto, tempo, custo, qualidade, recursos e o business case.
Curso de ao recomendado para a mudana
O curso de ao para a mudana deve ser explicado com a compreenso

dos benefcios e riscos da seo anterior. Alguns cursos alternativos podem
ser considerados, incluindo aqueles recomendados pelo requisitante e
por outras partes interessadas. Ponderando os benefcios, riscos e outros
critrios para cada opo, o tomador de deciso designado pelo processo
de aprovao pode fazer uma escolha que servir da melhor forma s
necessidades do projeto.
As vrias opes consideradas e o raciocnio por trs da opo selecionada

devem ser registrados.
O curso de ao recomendado deve ser suficientemente completo para

permitir uma coordenao clara das partes afetadas pela mudana. Para
mudanas maiores, este curso de ao deve ser um subprojeto dentro do
contexto geral do projeto, incluindo elementos que precisam ser inseridos
no plano geral do projeto.
Atualizaes no plano de comunicaes e no mtodo para a comunicao da

mudana para as partes interessadas afetadas.
As disciplinas de gerenciamento de configurao e rastreabilidade devem

estabelecer linhas de base do produto e prticas de controle de verso que iro
identificar claramente qual linha de base ser afetada pela mudana.
Coordenar a Priorizao da Mudana. A prioridade da mudana proposta deve

ser estabelecida em relao a outros interesses concorrentes dentro da fase atual
do projeto. O requisitante deve fornecer uma prioridade como descrito na seo
acima. Os tomadores de deciso do projeto tero que considerar a prioridade, como
tambm qualquer risco potencial referente ao adiamento da implementao, para
um momento posterior.
Mtodos orientados mudana

Metodologias orientadas mudana (em particular, mtodos geis de
desenvolvimento de software) tipicamente no possuem um processo de
gerenciamento de mudana separado do processo de priorizao dos requisitos.
Todos os requisitos, incluindo novos e alterados so registrados no backlog do
produto e priorizados. No incio de cada iterao, os requisitos com maior prioridade
so selecionados do backlog e estimados, e essas estimativas so usadas como
entrada para determinar se o requisito ser implementado naquela iterao.
.6 Adaptando Processo de Gerenciamento dos Requisitos

Um processo de gerenciamento de requisitos de uma organizao pode precisar
ser adaptado para atender s necessidades de uma iniciativa ou projeto especfico.
Fatores na adaptao do processo incluem:

Cultura organizacional. Em organizaes onde a cultura no suporta a

formalidade, mas onde a informalidade pe em risco o produto final, ser
necessrio trabalhar junto s partes interessadas para negociar um processo
apropriado.
Preferncias das partes interessadas. Algumas partes interessadas podem

requerer mais ou menos formalidade. Um patrocinador pode, por exemplo,
querer uma aprovao formal, mas no querer um processo documentado para
a elicitao de requisitos. Como mencionado anteriormente, ser necessrio
recomendar a abordagem mais apropriada para lidar com as mudanas,
apontando os riscos e impactos quando necessrio.
Complexidade do projeto, fase do projeto ou produto (produto, servio

ou resultado) sendo entregue. Processos formais para gerenciamento de
configurao e gerenciamento de mudanas so mais provavelmente usados
para:
Projetos que possuem muitas interfaces, muitos impactos ao negcio e/ou

impactos aos sistemas, ou que afetam diferentes reas funcionais.
Produtos construdos com muitos componentes e subcomponentes que

possuem interfaces complexas sero usados por uma variedade inumervel
de partes interessadas, ou possuem outras complexidades.
Maturidade organizacional. Organizaes menos maduras tendem a no desejar

investir tempo ou dinheiro na criao de um processo de definio de requisitos
e pode haver uma resistncia total ideia deste processo.
Disponibilidade dos recursos necessrios para apoiar o esforo de criao de tal

processo uma considerao importante. Grupos internos, como o escritrio
de gerenciamento de projetos (PMO), e recursos externos, como firmas de
consultoria ou mesmo fornecedores, podem ser capazes de incrementar os
recursos organizacionais.
2.5.5 Tcnicas
Anlise de Deciso (9.8): Pode ser usada para avaliar o possvel valor entregue por
uma mudana e avaliar reas de incerteza.
Rastreamento de Problemas (9.20): usado para rastrear possveis mudanas e

para garantir que uma deciso ser alcanada.
Anlise de Riscos (9.24): Usada para identificar possveis riscos associados com o
processo de gerenciamento das mudanas e riscos possveis associados ao fazer, ou
no, a mudana.

Especialista no Assunto: Consultado com o intuito de determinar a importncia
dos requisitos e para levantar o valor das requisies de mudana.
Usurio Final: Consultado com o intuito de determinar a importncia dos requisitos

e para levantar o valor das requisies de mudana.
Especialista em implementao da soluo: Consultado com o intuito de determinar

a dificuldade da implementao de um requisito ou de uma mudana proposta.

Planejamento e Monitoramento da Anlise de Negcios Gerenciar o Desempenho da Anlise de Negcios
Suporte Operacional: Informado a respeito das mudanas nos requisitos para

garantir que a soluo pode operar eficazmente.
Gerente do Projeto: Responsvel por gerenciar as mudanas no escopo do

projeto e responsvel pela entrega desse escopo. Mudanas na soluo e no
escopo dos requisitos provavelmente impactaro o escopo do projeto. Da mesma
forma, mudanas no escopo do projeto provavelmente impactaro o escopo da
soluo e dos requisitos. Grande parte dos projetos utiliza um nico processo de
gerenciamento das mudanas para lidar com ambos e para descrever os impactos
soluo e ao escopo do projeto em uma nica requisio de mudana. Isso ir
requerer o envolvimento do gerente do projeto nesta tarefa e a concordncia da
pessoa responsvel pelo processo de gerenciamento das mudanas.
Testador: Informado das mudanas nos requisitos para garantir que os planos de
testes so eficazes.
Patrocinador: Acionvel pelo escopo da soluo, deve aprovar a priorizao dos

requisitos e as mudanas nos requisitos.
2.5.7 Sada
Plano de Gerenciamento dos Requisitos. Um plano de gerenciamento dos requisitos
descreve:
A abordagem a ser adotada para a estrutura de rastreabilidade;
A definio dos atributos dos requisitos a serem utilizados;
O processo de priorizao dos requisitos;
O processo de gerenciamento das mudanas nos requisitos, incluindo como as

mudanas sero requisitadas, analisadas, aprovadas e implementadas.
2.6 Gerenciar o Desempenho da Anlise de Negcios

2.6.1 Propsito
Gerenciar o desempenho das atividades da anlise de negcios para garantir que
elas so executadas to eficazmente quanto possvel.
2.6.2 Descrio
Esta tarefa cobre a determinao de quais mtricas sero usadas para medir o
trabalho executado pelo analista de negcios. Isso inclui: como rastrear, avaliar e
reportar a qualidade do trabalho, e tomar aes para corrigir quaisquer problemas
que possam surgir. Ela pode alimentar o desenvolvimento de futuros planos de
anlise de negcios. As mtricas selecionadas so definidas nos ativos de processos
organizacionais ou nos planos de anlise de negcios.
Esta tarefa tambm descreve como os ativos dos processos organizacionais que
governam as atividades de anlise de negcio so gerenciados e atualizados.

Gerenciar o Desempenho da Anlise de Negcios Planejamento e Monitoramento da Anlise de Negcios
Figura 2-10: Diagrama de Entrada/Sada de Gerenciar o Desempenho da Anlise de Negcios
Entradas
* 2.3 2.5
Mtricas de Plano(s) da Padres de Plano de

Desempenho da Anlise de Desempenho Gerenciamento
Anlise de Negcios Negcios Organizacional de Requisitos
2.6
Gerenciar o
Desempenho da
Anlise de Negcios
2.6 2.6
Avaliao do Ativos de
Desempenho Processos da
da Anlise de Anlise de
Negcios Negcios
Tarefas que usam esta sada Sada usada tambm por

2.3 Ativos de
Planejar Atividades Processos
da Anlise de Organizacionais
Negcios +
2.6.3 Entrada
Mtricas de Desempenho da Anlise de Negcios: Medidas reais de desempenho
so capturadas, analisadas e tornam-se a base para a tomada de aes corretivas ou
preventivas. A captura das mtricas reais de desempenho um processo que ocorre
ao longo do esforo de anlise de negcios e implicitamente uma sada potencial de
cada tarefa de anlise de negcios.
Plano(s) de Anlise de Negcios: Esse plano descreve as entregas , atividades, tarefas

e estimativas para todo o trabalho de anlise de negcios. Estar em conformidade a
esses planos pode ser a mtrica primria para a avaliao do desempenho.
Padres de Desempenho Organizacional: Podem incluir mtricas impostas de

desempenho ou expectativas para o trabalho de anlise de negcios.

Planejamento e Monitoramento da Anlise de Negcios Gerenciar o Desempenho da Anlise de Negcios
Plano de Gerenciamento dos Requisitos: O plano de gerenciamento dos requisitos

pode tambm estabelecer expectativas da frequncia de mudana dos requisitos e
do trabalho envolvido no gerenciamento daquela mudana.
2.6.4 Elementos
.1 Medidas de Desempenho
Medidas de desempenho so usadas para estabelecer expectativas em relao ao que
constitui o trabalho efetivo de anlise de negcios no contexto de uma organizao
ou iniciativa particular. Medidas de desempenho podem ser baseadas nos prazos de
entrega determinados no plano da anlise de negcios, mtricas como a frequncia
das mudanas nos requisitos ou o nmero de ciclos de reviso necessrios, ou o
feedback qualitativo das partes interessadas ou dos pares do analista de negcios.
Medidas de desempenho apropriadas devem permitir que o analista de negcios
determine quando os problemas que podem afetar o desempenho da anlise de
negcios e de outras atividades esto ocorrendo, ou identificar as oportunidades
para melhoria.
.2 Relatrios de Desempenho
Relatrios podem ser escritos em um formato que permita o arquivamento e
rastreamento, informais e verbais, baseados nas necessidades do projeto. Alguns
relatrios podem ser feitos formal e oralmente, como apresentaes para vrios
nveis de partes interessadas e de gerncia.
.3 Ao Preventiva e Corretiva
O analista de negcios deve avaliar as medidas de desempenho para determinar
onde esto ocorrendo problemas na execuo da anlise de negcios ou onde
existem oportunidades para a melhoria do processo da anlise de negcios. Uma vez
que essa avaliao estiver completa, o analista de negcios deve acionar as partes
interessadas para identificar aes preventivas ou corretivas. Aes preventivas ou
corretivas tendem a resultar em mudanas nos planos de anlise de negcios.
2.6.5 Tcnicas
.1 Tcnicas Gerais
Entrevistas (9.14): Partes interessadas podem ser entrevistadas para efetuar
avaliaes do desempenho da anlise de negcios.
Processos de Lies Aprendidas (9.15): Auxilia a identificar mudanas aos

processos de anlise de negcios e entregas que podem ser incorporadas ao
trabalho futuro.
Mtricas e Indicadores-Chave de Desempenho (9.16): Podem ser usados para

determinar quais mtricas so apropriadas para avaliar o desempenho da anlise
de negcios e como elas podem ser rastreadas.
Rastreamento de Problemas (9.20): Pode ser usado para rastrear problemas que
ocorrem durante a anlise de negcios para posterior resoluo.
Modelagem de Processos (9.21): Pode ser usada para definir os processos da

anlise de negcios e para compreender como aperfeioar esses processos para
reduzir problemas relacionados transferncia de responsabilidades, melhorar os
tempos de ciclo ou alterar como o trabalho da anlise de negcios desempenhado
para apoiar melhorias em processos seguintes.

Gerenciar o Desempenho da Anlise de Negcios Planejamento e Monitoramento da Anlise de Negcios
Anlise da Causa-Raiz (9.25): Podem auxiliar na identificao de causas implcitas

de falhas ou dificuldades na realizao do trabalho da anlise de negcios.
Pesquisa/Questionrio (9.31): Pode ser usado para reunir feedback de grande

nmero de partes interessadas.
.2 Anlise de Varincia
O propsito dessa tcnica analisar discrepncias entre o desempenho planejado
e o realizado, determinar a magnitude dessas discrepncias e recomendar aes
preventivas e corretivas quando necessrias. Variaes podem estar relacionadas
ao planejado versus o realizado nas estimativas, custos, escopo, expectativas do
produto, ou em quaisquer medidas que foram estabelecidas durante o processo de
planejamento.
Quando variaes entre o trabalho real e o plano forem encontradas, a anlise da

variao mede a magnitude dessa variao. A anlise da variao tambm inclui o
estudo das causas da variao para determinar se aes corretivas ou preventivas
so necessrias para alinhar o trabalho da anlise de negcios aos seus planos.

Especialista no Assunto e Usurio Final: Devem ser informados do desempenho
da anlise de negcios no intuito de estabelecer expectativas em relao ao seu
envolvimento.
Especialista em implementao da soluo, suporte operacional e testador:

Dependente do desempenho efetivo das atividades da anlise de negcios para
desempenhar o seu papel. Deve ser consultado durante a avaliao das atividades.
Gerente do Projeto: O gerente do projeto responsvel pelo seu sucesso e deve ser
mantido informado a respeito do estado atual do trabalho de anlise de negcios. Se
potenciais problemas ou oportunidades de melhoria forem identificados, o gerente
do projeto deve ser consultado antes que as mudanas sejam implementadas para
avaliar se essas mudanas traro impacto ao projeto. O gerente do projeto tambm
pode entregar relatrios a respeito do desempenho da anlise de negcios para o
patrocinador e para outras partes interessadas.
Patrocinador: Pode requisitar relatrios do desempenho da anlise de negcios

para dar ateno aos problemas assim que so identificados. Um gestor da anlise
de negcios tambm pode patrocinar iniciativas para aperfeioar o desempenho das
atividades da anlise de negcios.
2.6.7 Sada
Avaliao de Desempenho de Anlise de Negcios: Inclui a comparao entre
o desempenho planejado e realizado, a compreenso da causa-raiz de variaes
do plano e outras informaes para auxiliar na compreeso do nvel de esforo
necessrio para completar o trabalho de anlise de negcios.
Ativos de Processos de Anlise de Negcios: Quando a anlise do desempenho

do trabalho da anlise de negcios leva a resultados menos que satisfatrios, til
revisar no apenas os resultados em si, mas tambm os processos que os produziram.
Esta anlise dos processos frequentemente resulta em recomendaes para a
melhoria do processo de anlise de negcios. O processo e os modelos de entrega
revisados devem ser analisados e documentados, e lies aprendidas devem ser
registradas. Eles podem ser incorporados aos ativos de processos organizacionais.

Elicitao
Captulo trs
A Elicitao dos requisitos uma tarefa-chave da anlise de negcios. essencial que
os requisitos sejam completos, claros, corretos e consistentes, porque eles servem
como pilares da soluo para as necessidades do negcio. Tirar proveito dos meios
consagrados para elicitar requisitos auxiliar a atingir essas metas de qualidade.
Defini-se elicitao como:
1. Elucidar ou trazer tona (algo latente ou com potencial)
2. Tornar visvel ou extrair (como informao ou como resposta)
Essas definies ressaltam a necessidade de engajar ativamente as partes

interessadas na definio dos requisitos.
Este captulo inclui detalhes para a elicitao de requisitos: do negcio,

das partes interessadas, da soluo e de transio. O analista de negcios deve
compreender as tcnicas comumente usadas para elicitar requisitos, ser capaz de
selecionar a(s) tcnica(s) apropriada(s) para uma dada situao e ser conhecedor das
tarefas necessrias para preparar, executar e completar cada tcnica.
Elicitar requisitos no uma atividade isolada ou segmentada. Normalmente,

requisitos so definidos ao longo das fases de elicitao, anlise, verificao e
validao. Por exemplo, requisitos podem ser elicitados em entrevistas ou workshops
de requisitos. Posteriormente, quando aqueles requisitos so usados para construir
e verificar modelos, podem ser encontrados gaps (lacunas) nos requisitos; o que
requerer elicitar os detalhes dos requisitos anteriormente identificados.
Uma combinao de tcnicas de elicitao normalmente utilizada para examinar

e definir os requisitos de forma completa. Uma variedade de fatores (o domnio do
negcio, a cultura e o ambiente corporativo, as habilidades do analista e as entregas
de requisitos que sero criados) define quais tcnicas devero ser usadas.
Figura 3-1: Tcnicas de Elicitao Geralmente Aceitas e Sinnimos

Tcnica de Elicitao Sinnimo
Brainstorming (9.3)
Anlise de Documentos (9.9) Reviso de documentao existente
Grupos Focais (9.11)
Anlise de Interface (9.13) Anlise de Interface Externa
Entrevistas (9.14)
Observao (9.18) Job Shadowing
Storyboarding, fluxo de navegao, prototipao
Prototipao (9.22)
em papel, fluxos de tela
Workshops de Requisitos (9.23) Workshop de Elicitao, Workshop Facilitado
Pesquisa / Questionrio (9.31)

Preparar a Elicitao Elicitao
As entregas da elicitao dependem das tcnicas usadas, por exemplo: notas de

entrevistas, respostas a pesquisas, termos do glossrio, entre outros.
esperado que em algum momento durante a elicitao exista material

suficientemente elicitado junto aos especialistas do negcio, o que permitir iniciar
as atividades de anlise. Os resultados combinados de todas as tcnicas de elicitao
usadas serviro como entrada para construir os modelos analticos selecionados.
Requisitos ausentes, incompletos ou incorretos iro, em um processo ideal, ser
identificados durante as atividades de anlise, requerendo uma elicitao adicional.
Nota: o desempenho de todas as atividades de elicitao governado pelos planos

da anlise de negcios (veja 2.3) sendo que o desempenho das mtricas da anlise de
negcios deve ser rastreado (veja 2.6).
Figura 3-2: Diagrama de Entrada/Sada da Elicitao
Entradas
Sadas
5.5 5.1 Tarefas
Business Case Necessidade do Ativos de 3.2 3.1
3.2
Negcio Processos 3.1
Conduzir a Atividade
Organizacionais Preparar a Elicitao
de Elicitao Resultados da Recursos
Elicitao Agendados
2.5 5.4 2.2 3.3 3.4

3.3,
Documentar os Confirmar 3.1
3.4
Plano de Escopo da Lista de Partes Resultados da Resultados da
Gerenciamento Soluo Interessadas, Elicitao Elicitao Preocupaes Materiais de
de Requisitos Papis e das Partes Apoio
Responsabilida Interessadas
de
3.1 Preparar a Elicitao

3.1.1 Propsito
Garantir que todos os recursos necessrios estejam organizados e agendados para a
conduo das atividades de elicitao.
3.1.2 Descrio
Construo de um cronograma detalhado para uma atividade particular de
elicitao, definio de atividades especficas e datas planejadas.
3.1.3 Entrada
Necessidade do Negcio: Necessria para garantir que o analista de negcios
compreenda qual informao deve ser elicitada junto s partes interessadas. Esta
entrada usada ao longo da elicitao dos requisitos do negcio (com exceo da
necessidade do negcio em si).
Escopo da Soluo e Business Case: Necessrios para garantir que o analista

de negcios compreenda qual informao deve ser elicitada junto s partes
interessadas. Estas entradas so usadas no levantamento dos requisitos: das partes
interessadas, da soluo e de transio.
Lista de Partes Interessadas, Papis e Atribuio de Responsabilidades: Usada

para identificar as partes interessadas que devem participar nas atividades de
elicitao.

Elicitao Preparar a Elicitao
Figura 3-3: Diagrama de Entrada/Sada de Preparar a Elicitao

Entradas
5.5 5.1 5.4 2.2
Business Case Necessidade do Escopo da Lista de Partes

(veja o texto) Negcio Soluo Interessadas,
(veja o texto) (veja o Papis e
texto) Responsabilidade
3.1
Preparar a Elicitao
3.1 3.1
Recursos Materiais de
Agendados Apoio
Tarefas que usam estas sadas

3.2
de Elicitao
3.1.4 Elementos
Esclarecer o escopo especfico da tcnica de elicitao escolhida e agrupar todos
os materiais de apoio necessrios;
Agendar todos os recursos (pessoas, instalaes, equipamento);
Notificar as partes apropriadas do plano.
Para elicitao baseada em eventos (brainstorming, grupo focal, entrevista,

observao, prototipagem, workshops de requisitos), regras bsicas devem ser
estabelecidas. O acordo alcanado junto s partes interessadas em relao forma
e freqncia do feedback durante o processo de elicitao como tambm em relao
ao mecanismo de verificao e aprovao dos resultados elicitados.
3.1.5 Tcnicas
Informao adicional sobre o desempenho desta tarefa pode ser encontrada na
descrio das tcnicas relevantes.

Conduzir a Atividade de Elicitao Elicitao
Brainstorming (9.3)
Anlise Documental (9.9)
Anlise de Interfaces (9.13)
Entrevistas (9.14)
Observao (9.18)
Prototipagem (9.22)
Workshops de Requisitos (9.23)
Pesquisa/Questionrio (9.31)

Todas as partes interessadas: Dependendo dos requisitos da atividade de
elicitao, qualquer parte interessada pode ser um participante.
Gerente do Projeto: O gerente do projeto auxiliar garantindo que os recursos

necessrios esto disponveis.
3.1.7 Sada
Recursos Agendados: Isso inclui os participantes, o local no qual a atividade de
elicitao ocorrer e quaisquer outros recursos que possam ser necessrios.
Materiais de Apoio: Quaisquer materiais necessrios para auxiliar na explicao

das tcnicas usadas ou na sua execuo.
3.2 Conduzir a Atividade de Elicitao

3.2.1 Propsito
Se reunir com parte(s) interessada(s) para elicitar informao referente s suas
necessidades.
3.2.2 Descrio
O evento de elicitao acontece (brainstorming, grupos focais, entrevistas,
observao, prototipagem, workshops de requisitos), ou a elicitao executada
(anlise documental, anlise de interfaces) ou distribuda (pesquisas,
questionrios).
3.2.3 Entrada
Necessidade do Negcio: Necessria para garantir que o analista de negcios
compreenda qual informao deve ser elicitada junto s partes interessadas. Esta
entrada usada ao longo da elicitao dos requisitos do negcio (com exceo da
necessidade do negcio em si).
Ativos de Processos Organizacionais: Podem incluir modelos ou processos para

estas atividades.

Elicitao Conduzir a Atividade de Elicitao
Plano de Gerenciamento dos Requisitos: Determina qual informao precisa ser

registrada e rastreada como um resultado da atividade. Em particular, muitos atributos
dos requisitos podem ser elicitados e capturados enquanto se executa essa tarefa.
Recursos Agendados: As partes interessadas relevantes, localizao e outros

recursos devem estar disponveis.
Escopo da Soluo e Business Case: so necessrios para garantir que o analista

de negcios compreenda qual informao deve ser elicitada junto s partes
interessadas. Estas entradas so usadas na elicitao dos requisitos: das partes
interessadas, da soluo e de transio.
Materiais de Apoio: Quadros brancos, flipcharts, documentos e outros materiais

devem estar disponveis enquanto a atividade conduzida.
Figura 3-4: Diagrama de Entrada/Sada de Conduzir Atividade de Elicitao

Entradas
5.5 5.1
Business Case Necessidade do Ativos de

(veja o texto) Negcio Processos
(veja o texto) Organizacionais
2.5 3.1 5.4 3.1
Plano de Recursos Escopo da Materiais de

Gerenciamento Agendados Soluo Apoio
de Requisitos (veja o texto)
3.2
de Elicitao
3.2
Resultados da
Elicitao
3.3
Documentar os
Resultados da
Elicitao

Conduzir a Atividade de Elicitao Elicitao
3.2.4 Elementos
Rastrear requisitos: Durante o levantamento dos requisitos importante evitar o
desvio do escopo. Rastrear os requisitos at as metas/objetivos do negcio auxilia na
validao de quais requisitos devem ser includos.
Capturar os atributos dos requisitos: Documentar os atributos dos requisitos

durante a elicitao, como a sua origem, valor e prioridade, auxiliar no
gerenciamento de cada requisito ao longo do seu ciclo de vida.
Mtricas: Acompanhar os participantes da elicitao e o tempo real investido na

elicitao dos requisitos proveem uma base para planejamento futuro.
Para tcnicas de elicitao baseadas em eventos, o levantamento dos requisitos

altamente dependente do conhecimento das partes interessadas, do seu desejo de
participar na definio dos requisitos e na habilidade do grupo em atingir o consenso.
importante que todas as partes interessadas definidas sejam ouvidas durante a elicitao
dos requisitos. Pode ser necessrio um esclarecimento e possivelmente uma redefinio
futura dos requisitos para englobar as perspectivas de todas as partes interessadas.
3.2.5 Tcnicas
Dicionrio de dados e Glossrio (9.5): Um glossrio de negcios um ativo
essencial para todas as tcnicas de elicitao. O glossrio deve conter principais
termos do domnio, acompanhados das suas definies de negcio.
Tcnicas Gerais:
Informao adicional sobre os elementos nicos para conduzir cada tcnica em

particular pode ser encontrada na descrio das tcnicas abaixo.
Brainstorming (9.3)
Anlise Documental (9.9)
Anlise de Interface (9.13)
Entrevistas (9.14)
Observao (9.18)
Prototipagem (9.22)
Workshops de Requisito (9.23)
Pesquisa/Questionrio (9.31)

Cliente, Especialista no assunto, Usurio Final, Fornecedor e Patrocinador:
Podem participar nessa tarefa como uma fonte de requisitos.
Especialista na Implementao da Soluo, Suporte Operacional, Gerente

do Projeto, Fornecedor e Testador: Podem participar para aumentar a sua
compreenso das necessidades das partes interessadas e para auxiliar as partes
interessadas na compreenso das trocas que a equipe do projeto enfrenta.

Elicitao Documentar os Resultados da Elicitao
Regulador: Pode participar diretamente (como uma fonte de requisitos) e pode

tambm impor que um processo especfico seja seguido ou que certos registros
sejam mantidos.
3.2.7 Sada
Resultados da elicitao: Pode incluir documentao apropriada para a tcnica e
coletar a informao provida pela parte interessada.
3.3 Documentar os Resultados da Elicitao

3.3.1 Propsito
Registrar as informaes providas pelas partes interessadas para o uso na anlise.
3.3.2 Descrio
Para um evento de elicitao (brainstorming, grupos focais, entrevistas, observao,
prototipagem, workshops de requisitos), um sumrio da sada do evento, incluindo
incidentes, produzido.
3.3.3 Entrada
Resultados da Elicitao: Inclui a informao provida pelas partes interessadas
que ser registrada e estruturada.
3.3.4 Elementos
A documentao pode assumir diferentes formatos, incluindo:
Documentos escritos descrevendo os resultados, como atas de reunies;
Registros visuais ou em udio;
Quadros brancos (tanto reais quanto virtuais), onde as notas so mantidas at

elas serem transferidas para outro meio.
A tcnica usada para elicitao, como tambm a abordagem da anlise de negcios,

ir determinar quais tipos de documentao so possveis e desejados.
3.3.5 Tcnicas
Brainstorming (9.3): A atividade geralmente produz a documentao necessria.
Anlise Documental (9.9): Um reporte das informaes encontradas deve ser

produzido.
Grupos Focais (9.11): Os resultados de um grupo focal so reunidos e sumarizados.
Anlise de Interface (9.13): Um reporte das informaes encontradas deve ser

produzido.
Entrevistas (9.14): Resultados da entrevista so documentados.
Observao (9.18): Resultados da observao so documentados.
Rastreamento de Problemas (9.20): Elicitao pode produzir incidentes que

precisam ser rastreados para resoluo.

Documentar os Resultados da Elicitao Elicitao
Prototipagem (9.22): Os resultados da elicitao podem sofrer anlise diretamente,

sem a necessidade de um passo intermedirio destinado a document-los.
Workshops de Requisitos (9.23): Os resultados da elicitao podem sofrer anlise

diretamente, sem a necessidade de um passo intermedirio destinado a document-los.
Pesquisa/Questionrio (9.31): Os resultados de uma pesquisa so reunidos e

sumarizados.
Figura 3-5: Diagrama de Entrada/Sada de Documentar os Resultados da Elicitao

Entradas
3.2
Resultados da
Elicitao
3.3
Documentar os
Resultados da
Elicitao
3.3 3.3
Requisitos Preocupaes
[Declarados] das Partes
Interessadas
Tarefas que usam esta sada Tarefas que usam esta sada
3.4 5.1 3.4

5.5
Confirmar Definir a Confirmar os
Definir o Business
Resultados da Necessidade do Resultados da
Case
Elicitao Negcio Elicitao
6.3 6.5 7.3

6.1
Especificar e Definir Suposies e Avaliar a Prontido
Priorizar Requisitos
Modelar Requisitos Restries Organizacional
7.4
Definir Requisitos de
Transio

Analista de Negcios: Outras partes interessadas no precisam participar dessa
tarefa.
3.3.7 Sada
Requisitos [declarados]: Descritos a partir da perspectiva da parte interessada.
Requisitos declarados descrevem a necessidade da parte interessada, a partir da sua
perspectiva.
Preocupaes das Partes Interessadas: Incluem questes identificadas pela parte

interessada, riscos, suposies, restries e outras informaes relevantes.

Elicitao Confirmar Resultados da Elicitao
3.4 Confirmar Resultados da Elicitao

3.4.1 Propsito
Validar se os requisitos declarados esto de acordo com a compreenso do problema
e das necessidades da parte interessada.
3.4.2 Descrio
Algumas tcnicas de elicitao beneficiam-se da reviso das sadas documentadas
junto s partes interessadas para garantir que a compreenso do analista esteja
alinhada aos desejos ou intenes reais da parte interessada.
3.4.3 Entrada
Requisitos [declarados, No-confirmados]: Representam a compreenso do
analista de negcios das intenes da parte interessada.
Preocupaes da Parte Interessada [No-confirmadas]: Representam a

compreenso do analista de negcios das questes identificadas pela parte
interessada, riscos, suposies, restries e outras informaes relevantes que
podem ser utilizadas na anlise de negcios.
3.4.4 Elementos
Refere-se descrio da tcnica relevante para aspectos nicos da confirmao de
resultados das tcnicas de entrevista e de observao.
3.4.5 Tcnicas
Entrevistas (9.14)
Observao (9.18)

Qualquer parte interessada que tenha participado de outras tarefas de elicitao
pode participar desta tarefa.
3.4.7 Sada
Requisitos [Declarados, Confirmados]: Idntico aos Requisitos [Declarados] para
todos os propsitos prticos, incluindo o uso como entrada em outras tarefas.
Preocupaes da Parte Interessada [Confirmadas]: Idntico s Preocupaes das

Partes Interessadas para todos os propsitos prticos, incluindo o uso como entrada
para outras tarefas.

Confirmar Resultados da Elicitao Elicitao
Figura 3-6: Diagrama de Entrada/Sada

de Confirmar Resultados da Elicitao
Entradas
3.3 3.3
Requisitos Preocupaes das

[Declarados, No Partes Interessadas
confirmados] [No Confirmadas]
3.4
Confirmar
Resultados da
Elicitao
3.4 3.4
Requisitos Preocupaes das

[Declarados, Partes Interessadas
Confirmados] [Confirmadas]
Tarefas que usam esta sada Tarefas que usam esta sada
(veja o texto) (veja o texto)
5.1 5.5 6.5

Definir a 6.1 Definir o Business Definir Suposies e
Necessidade do Priorizar Requisitos Case Restries
Negcio
7.3
6.3 7.4
Avaliar a Prontido
Especificar e Definir Requisitos de
Organizacional
Modelar Requisitos Transio

Gerenciamento e Comunicao dos Requisitos
Captulo quatro
A rea de conhecimento Gerenciamento e Comunicao dos Requisitos descreve as atividades
e consideraes para gerenciar e expressar requisitos para um pblico amplo e diverso.
Estas tarefas so executadas para garantir que todas as partes interessadas tenham um
entendimento compartilhado da natureza de uma soluo e para assegurar que aquelas
partes interessadas, com autoridade de aprovao, estejam de acordo quanto aos requisitos
que a soluo deva atender.
A comunicao dos requisitos ajuda a levar as partes interessadas a um entendimento

comum dos requisitos. Como as partes interessadas representam pessoas de diversas
origens e reas profissionais, esta comunicao ao mesmo tempo desafiadora e crtica para
o sucesso de qualquer iniciativa. Isso envolve determinar que conjuntos de requisitos so
relevantes para um determinado grupo de partes interessadas e apresent-los de maneira
apropriada para esse pblico.
O gerenciamento dos requisitos ajuda a entender os efeitos de mudanas e as ligaes entre

os objetivos e metas dos negcios com a soluo que de fato construda e entregue. A longo
prazo, tambm assegura que o conhecimento e o entendimento da organizao, alcanados
durante a anlise do negcio, estejam disponveis para uso futuro.
Nota: o desempenho de todas as atividades de gerenciamento e comunicao dos requisitos

governado pelo plano da anlise de negcios (ver 2.3) e a mtrica de desempenho da anlise
de negcios deve ser acompanhada (ver 2.6).
Figura 4-1: Diagrama de Entrada/Sada do Gerenciamento e Comunicao de Requisitos

Entradas
Sadas
2.4 *
Tarefas 4.1 4.5
Plano de Ativos de Requisitos 4.1 4.2
Comunicao Processos Gerenciar o Escopo e Gerenciar Requisitos Requisitos
da Anlise de Organizacionais os Requisitos da Rastreabilidade dos [Aprovados] [Comunicados]
Negcios Soluo Requisitos
2.5 6.2 5.4 4.3 4.4 4.3 4.2

Manter Requisitos Preparar o Pacote de
Plano de Estrutura de Escopo da para Reutilizao Requisitos Requisitos Requisitos
Gerenciamento Requisitos Soluo [Mantidos e [Rastreados]
de Requisitos Reusveis]
4.5
2.2 Comunicar 4.4
Requisitos
Lista de Partes Pacotes de
Interessadas, Papis e Requisitos
Responsabilidade
4.1 Gerenciar o Escopo e os Requisitos da Soluo

4.1.1 Propsito
Obter e manter consenso entre as principais partes interessadas acerca do escopo genrico
da soluo e os requisitos que sero implementados.

Gerenciar o Escopo e os Requisitos da Soluo Gerenciamento e Comunicao dos Requisitos
4.1.2 Descrio
Esta tarefa envolve assegurar a aprovao dos requisitos pelas partes interessadas
com autoridade competente para tal e o gerenciamento de questes que surjam
durante a elicitao e a anlise. A aprovao dos requisitos pode ser solicitada ao
trmino de uma fase de projeto ou em vrios outros pontos intermedirios dentro do
processo de anlise de negcios.
Aps aprovao dos requisitos, uma linha de base pode ser gerada. Qualquer
alterao nos requisitos aps a gerao da linha de base, se alteraes forem
permitidas, envolve o uso de um processo de controle de mudanas e subsequente
aprovao. medida que requisitos so refinados ou modificados como resultado
de novas informaes, as mudanas tambm so mapeadas.
O escopo da soluo necessrio como base para o gerenciamento de requisitos

e usado para determinar se um requisito proposto apoia as metas e os objetivos
do negcio. Se a necessidade do negcio mudar durante o ciclo de vida de uma
iniciativa, o escopo da soluo tambm dever ser modificado. Mudanas no escopo
da soluo podem tambm levar a mudanas em requisitos previamente aprovados,
que podem no apoiar o escopo revisado.
Abordagens orientadas mudana tipicamente no fazem uso de um processo

formal de controle de mudanas, na medida em que os requisitos so priorizados e
selecionados para implantao no incio de cada iterao e nenhuma mudana nos
requisitos ocorre durante uma iterao.
4.1.3 Entrada
Plano de Gerenciamento de Requisitos: Define o processo a ser seguido no
gerenciamento do escopo da soluo e dos requisitos.
Escopo da Soluo: Os requisitos devem apoiar o escopo da soluo para serem

aprovados, a no ser que o escopo da soluo seja modificado. O escopo da soluo
tambm um requisito passvel de ser gerencivel. Mudanas em outros requisitos
do negcio geralmente no esto includas no processo normal de gerenciamento de
mudanas de um projeto, j que elas so externas ao escopo do projeto.
Responsabilidades, Papis e Lista de Partes Interessadas: Define quem, dentre

as partes interessadas, est envolvido em revisar e aprovar os requisitos.
Requisitos das partes interessadas, da soluo ou de transio [Comunicados

ou Rastreados]: Requisitos podem ser gerenciados em qualquer momento de
seu ciclo de vida (declarados, especificados e modelados, verificados, validados,
etc.), embora a aprovao pelas partes interessadas esteja normalmente restrita
a requisitos que tenham sido verificados e validados. Requisitos devem ser
comunicados para serem gerenciados, uma vez que as partes interessadas no
podem consentir com requisitos dos quais no estejam cientes. Requisitos tambm
podem ser gerenciados se puderem ser rastreados a requisitos que j tenham
sido aprovados, j que aqueles requisitos so a base para determinar se outros se
enquadram dentro do escopo da soluo.

Gerenciamento e Comunicao dos Requisitos Gerenciar o Escopo e os Requisitos da Soluo
Figura 4-2: Diagrama de Entrada/Sada de Gerenciar o Escopo e os Requisitos da Soluo

Entradas
4.2,
2.5 5.4 2.2
4.5
Plano de Escopo da Lista de Partes Requisitos das partes interessadas,

Gerenciamento Soluo Interessadas, Papis da soluo ou de transio
de Requisitos e Responsabilidade [Comunicados ou Rastreados]
4.1
Gerenciar o Escopo e
os Requisitos da
Soluo
4.1
Requisitos
[Aprovados]
4.3
7.1
Manter os 7.2
Avaliar a Soluo
Requisitos para Alocar Requisitos
Proposta
Reutilizao
4.1.4 Elementos
.1 Gerenciamento do Escopo da Soluo
Todos os requisitos das solues e das partes interessadas devem ser avaliados para
assegurar que estejam dentro do escopo da soluo. As partes interessadas vo
identificar, com frequncia, necessidades adicionais que a soluo pode ser capaz de
atender. Entretanto, se esses requisitos adicionais forem invlidos (isto , no esto
alinhados com os requisitos do negcio aprovados) ou se eles no se enquadram dentro
do escopo da soluo, o analista de negcios dever agir para resolver esse conflito. Isto
pode ser feito corrigindo os requisitos do negcio e o escopo da soluo, ou chegando a
um entendimento de que o requisito proposto no se enquadra no escopo da iniciativa.
.2 Gerenciamento de Conflitos e Questes

medida que requisitos so desenvolvidos e revisados, frequentemente surgem
conflitos. Um conflito pode vir de partes interessadas de diferentes reas vendo
os mesmos requisitos de diferentes perspectivas. Tambm podem ser fruto de
prioridades conflitantes. Requisitos inconsistentes no podem ser resolvidos por
uma nica soluo, portanto, qualquer inconsistncia deve ser resolvida.
Para resolver a questo, facilite a comunicao entre as partes interessadas que

esto em conflito por causa do requisito. Conflitos podem ser resolvidos em

Gerenciar o Escopo e os Requisitos da Soluo Gerenciamento e Comunicao dos Requisitos
encontros formais entre as partes interessadas afetadas, atravs de pesquisa,

resoluo por um terceiro, ou ainda por outros mtodos apropriados. Conflitos
que afetem os requisitos precisam ser resolvidos antes que a aprovao formal seja
dada queles requisitos.
.3 Apresentando Requisitos para Reviso

Determine como os requisitos sero apresentados para as vrias partes interessadas
e se as apresentaes sero formais ou informais. Uma apresentao formal pode ser
uma especificao dos requisitos do sistema por escrito ou uma reviso estruturada
com vrios nveis de partes interessadas, incluindo sumrios executivos, assim como
um modelo estruturado contendo todos os diagramas associados, texto de apoio,
atributos detalhados e informao de reviso. Um requisito pode ser apresentado
informalmente em um e-mail, uma nota, ou verbalmente.
Avalie os requisitos, o pblico, e os ativos de processos organizacionais para

determinar o nvel de formalidade apropriado para a comunicao da anlise
de negcios. Geralmente, quanto mais formal a comunicao, mais tempo ser
necessrio para se preparar para as reunies, revises, para apresentaes,
preparaes ou pacotes de requisitos, etc. Comunicaes menos formais podem
resultar em falta de informaes relevantes s partes interessadas, ou em uma maior
ambiguidade nos requisitos.
Ao apresentar requisitos para reviso e aprovao necessrio que haja formalidade

o suficiente para apoiar a metodologia e garantir que as partes interessadas iro
rev-los, entend-los e aprov-los.
.4 Aprovao
Garanta que a(s) parte(s) interessada(s) responsvel(eis) por aprovar os requisitos os
compreendem e os aceitam. A aprovao de partes interessadas pode ser necessria
para o resultado de outras tarefas da anlise de negcios, incluindo alocao de
requisitos, resolues de problemas propostos e outras decises. A aprovao pode
ser obtida por uma parcela das partes interessadas, individualmente, ou em grupo.
Um registro da deciso pode ser mantido. Um registro da deciso pode incluir a

deciso tomada (incluir, ou no, o requisito, ou modificar o escopo), a razo para
esta deciso e as partes envolvidas.
4.1.5 Tcnicas
.1 Tcnicas Gerais
Rastreamento de Problemas (9.20): Permite ao analista de negcios gerenciar
quaisquer questes identificadas pelas partes interessadas relacionadas aos
requisitos e garantir que tais questes sejam resolvidas.
.2 Estabelecimento da Linha de Base

Uma vez que os requisitos so aprovados, eles podem ser estabelecidos como linha de
base, significando que todas as alteraes futuras sero registradas e acompanhadas
e que o estado atual poder ser comparado ao estado desta linha de base. Mudanas
subsequentes aos requisitos devem seguir o processo de controle de mudanas.
medida que mudanas so aprovadas, o plano de gerenciamento dos requisitos

pode exigir que a verso da linha de base dos requisitos seja mantida conjuntamente
com os requisitos alterados, assim como as descries das mudanas, as pessoas que
as executaram e suas razes.

Gerenciamento e Comunicao dos Requisitos Gerenciar o Escopo e os Requisitos da Soluo
.3 Aprovao
A aprovao dos requisitos formaliza o acordo entre as partes interessadas de que o
contedo e a apresentao dos requisitos documentados so precisos e completos.
Uma aprovao formal da documentao dos requisitos pode ser exigida por razes
legais ou de regulamentos da organizao.
A obteno da aprovao dos requisitos tipicamente envolve revises finais dos

mesmos, face face com cada parte interessada com autoridade para aprov-los.
Ao fim de cada reviso, solicitado parte interessada a formalmente aprovar a
documentao dos requisitos revisada. Esta aprovao pode ser verbal ou registrada
fsica ou eletronicamente.
Se uma parte interessada tem autoridade para aprovar apenas um subconjunto dos
requisitos, uma lista com os requisitos especficos que esto sendo aprovados por
esta parte, e uma complementar com os requisitos sobre os quais no tem poder de
aprovao (mas sobre os quais explicitamente no tem objeo), deve ser preparada.
Sob tais circunstncias, incumbncia do analista de negcios assegurar que cada
requisito individualmente seja explicitamente aprovado por pelo menos uma parte
interessada que tenha poder para faz-lo.

Especialista no assunto: Pode estar envolvido na reviso e aprovao dos
requisitos, conforme definido pela designao dos papis e responsabilidade das
Especialista em Implementao da Soluo: Provavelmente tambm estar

envolvido neste processo para garantir que os requisitos possam ser implementados.
Gerente do Projeto: O gerente do projeto responsvel e acionvel pelo escopo

do projeto. Ele deve estar envolvido na avaliao do escopo da soluo para definir
o escopo do projeto e precisa estar envolvido na reviso de qualquer mudana no
escopo da soluo pelas mesmas razes. Ademais, se um requisito proposto no for
aceito pelas principais partes interessadas, o gerente do projeto dever gerenciar o
risco associado ao projeto (alterando o escopo do projeto, expandindo a questo, ou
atravs de outra resposta apropriada).
Patrocinador: O business case, o escopo da soluo ou do produto e todos os

requisitos devem ser revistos e aprovados pelo(s) patrocinador(es) de acordo com a
autoridade de aprovao declarada no plano de gerenciamento de requisitos.
4.1.7 Sada
Requisitos [Aprovados]: Requisitos com os quais as partes interessadas concordam
e prontos para uso em subsequentes anlises de negcios ou esforos de implantao.

Gerenciar Rastreabilidade dos Requisitos Gerenciamento e Comunicao dos Requisitos
4.2 Gerenciar Rastreabilidade dos Requisitos

4.2.1 Propsito
Criar e manter relacionamentos entre objetivos de negcios, requisitos, outras
entregas da equipe e componentes da soluo para apoiar a anlise de negcios ou
outras atividades.
4.2.2 Descrio
Requisitos se relacionam a outros requisitos, aos componentes de soluo e a
outros artefatos, como casos de teste. Rastrear um requisito refere-se habilidade
de olhar para um requisito e para os outros itens com os quais ele se relaciona. A
rastreabilidade vincula requisitos de negcios s partes interessadas e requisitos de
soluo a outros artefatos produzidos pela equipe e aos componentes de soluo.
A rastreabilidade de requisitos identifica e documenta a linhagem de cada requisito,

incluindo sua rastreabilidade retroativa (derivao), sua rastreabilidade posterior
(alocao) e seu relacionamento com outros requisitos. A rastreabilidade utilizada
para assegurar a conformidade da soluo aos requisitos e para auxiliar no
gerenciamento do escopo e da mudana, gerenciamento de risco, gerenciamento de
tempo, gerenciamento de custos e gerenciamento de comunicao. Tambm usada
para detectar funcionalidades ausentes ou para identificar se alguma funcionalidade
implementada no suportada por um requisito em particular.
O rastreamento pode ser feito no nvel individual do requisito, nos nveis de

modelo ou pacotes de trabalho, ou no nvel de recurso, conforme apropriado.
A meta do rastreamento garantir que os requisitos (e, em ltimo caso,
componentes de soluo) estejam associados a um objetivo do negcio.
Rastreamento de requisitos d suporte s anlises de impacto, gerenciamento de
mudanas e alocao de requisitos.
Requisitos individuais quase sempre possuem dependncias inerentes e inter-

relacionamentos.
H diversas razes para a criao desses relacionamentos:
Anlise de Impacto. Quando um requisito modificado, o analista de

negcios pode facilmente rever todos os requisitos e componentes de software
relacionados para compreender o impacto da mudana.
Cobertura de Requisitos. Quando os objetivos do negcio so rastreados a

requisitos detalhados como regras de negcios, elementos de dados e casos de
uso, fica claro como eles sero alcanados. Cada objetivo de negcio pode ser
revisto para se ter certeza de que ser abordado pelos componentes de soluo
apropriados. Se um objetivo de negcio no estiver vinculado a nada, porque
no foi analisado nem includo na soluo. Informaes adicionais podem ser
encontradas em Avaliar Soluo Proposta (7.1).
Alocao de requisitos. Veja Alocar Requisitos (7.2).
4.2.3 Entrada
Requisitos: Todos os requisitos tm potencial para serem rastreados a outros
requisitos e todas as partes interessadas, e requisitos de soluo devem ser
rastreveis a um requisito do negcio.

Gerenciamento e Comunicao dos Requisitos Gerenciar Rastreabilidade dos Requisitos
Plano de Gerenciamento de Requisitos: Define como e se a rastreabilidade est

sendo executada, as ferramentas que sero usadas para apoi-la e os processos que
sero usados para gerenci-la.
Figura 4-3: Diagrama de Entrada/Sada de Gerenciar Rastreabilidade dos Requisitos
Entradas
* 2.5
Requisitos Plano de
Gerenciamento
de Requisitos
4.2
Gerenciar
Rastreabilidade dos
Requisitos
4.2
Requisitos
[Rastreados]
4.1
Gerenciar o Escopo e
os Requisitos da
Soluo
4.2.4 Elementos
.1 Relacionamentos
Aps examinar e organizar o conjunto de requisitos, registre as dependncias
e relacionamentos para cada um dos requisitos. Conhecer as dependncias e os
relacionamentos entre os requisitos ajuda a determinar a sequncia na qual cada
requisito dever ser direcionado. Relacionamentos comuns incluem:
Necessidade: Este relacionamento existe quando s fizer sentido implementar

um determinado requisito se um outro, com o qual este se relaciona, tambm for
implementado. Este relacionamento pode ser unidirecional ou bidirecional.
Esforo: Este relacionamento existe quando a implementao de um requisito fica

mais fcil se um outro relacionado a este seja tambm implementado.

Gerenciar Rastreabilidade dos Requisitos Gerenciamento e Comunicao dos Requisitos
Subconjunto: Quando o requisito o resultado decomposto de outro requisito.
Cobertura: Quando o requisito inclui totalmente outro requisito. Este um caso

especial de subconjunto, onde o requisito de maior nvel a soma dos subrequisitos.
Valor: Quando a incluso de um requisito afeta a necessidade de um requisito

relacionado (aumentando-a ou diminuindo-a). Isto pode ocorrer porque o requisito
relacionado s necessrio se o primeiro requisito for implementado, ou porque
apenas um dos requisitos deve ser implementado (por exemplo, ao discutir dois
recursos que tm potencial para suprir um requisito do negcio).
.2 Anlise de Impacto
A anlise de impacto executada para averiguar ou avaliar o impacto de uma
mudana. A rastreabilidade uma ferramenta til para realizar uma anlise de
impacto. Quando um requisito muda, seus relacionamentos com outros requisitos
ou componentes de sistema podem ser revistos. Cada requisito ou componente
relacionado pode tambm sofrer mudanas para suportar o novo requisito. Esses
componentes tambm podem ser rastreados a seus componentes relacionados e
estes componentes revisados para mudanas necessrias. Conhecer o impacto de
uma mudana auxilia os tomadores de decises do negcio a avaliar as suas opes
com base em fatos.
.3 Sistema de Gerenciamento de Configurao

Uma ferramenta especializada de gerenciamento de requisitos geralmente
necessria para rastrear um nmero grande de requisitos.
4.2.5 Tcnicas
.1 Matriz de Cobertura
Uma matriz de cobertura uma tabela ou matriz usada para gerenciar
rastreamentos. tipicamente utilizada quando h relativamente poucos requisitos
ou quando o rastreamento for limitado a requisitos de alto nvel (ex.: recursos ou
modelos).

Especialista em Implementao da Soluo: Deve ser capaz de vincular os
requisitos aos componentes de soluo que iro implementar.
Gerente do Projeto: Rastreabilidade d suporte ao gerenciamento de mudanas do

projeto.
Testador: Os testadores precisam entender como e quando os requisitos so

implementados ao criar planos de testes e casos de testes, e poder rastrear casos de
testes aos requisitos.
4.2.7 Sada
Requisitos [Rastreados]: Requisitos rastreados tm relacionamentos claramente
definidos com outros requisitos no escopo da soluo, de tal forma que
relativamente fcil identificar os efeitos de uma mudana em outros requisitos.

Gerenciamento e Comunicao dos Requisitos Manter Requisitos para Reutilizao
4.3 Manter Requisitos para Reutilizao

4.3.1 Propsito
Gerenciar o conhecimento sobre os requisitos aps sua implementao.
4.3.2 Descrio
Identificar requisitos que so candidatos a uso de longo prazo pela organizao.
Estes podem incluir requisitos que uma organizao deve atender frequentemente,
assim como requisitos que so implementados como parte de uma soluo.
Para reutilizar requisitos, estes precisam estar claramente nomeados e definidos

e estar facilmente disponveis para outros analistas. Esses requisitos podem ser
armazenados em um repositrio e uma pessoa deve ser designada para gerenciar
esse repositrio. Quando um requisito existente precisa ser modificado, ele pode ser
acessado do repositrio para reso.
A manuteno dos requisitos pode facilitar a anlise de impacto de novas mudanas

propostas ao negcio, reduzir tempo e esforo de anlise, auxiliar na manuteno
de solues previamente implementadas e apoiar outras atividades, incluindo
treinamento, governana corporativa e adequao a padres.
Figura 4-4: Diagrama de Entrada/Sada de Manter Requisitos para Reutilizao

Entradas
*
Ativos de Requisitos
Processos
Organizacionais
4.3
Manter Requisitos
para Reutilizao
4.3
Requisitos
[Mantidos e
Reusveis]
Sada usada tambm por

Arquitetura Iniciativas Futuras
Corporativa
+ +

Manter Requisitos para Reutilizao Gerenciamento e Comunicao dos Requisitos
4.3.3 Entrada
Ativos de Processos Organizacionais: So padres definidos de como e quando os
requisitos devem ser mantidos para reso.
Requisitos: Requisitos podem ser mantidos para reso enquanto descreverem

informaes que sejam de uso para a empresa alm do tempo de vida de uma
iniciativa. Requisitos sero candidatos para manuteno, somente se descreverem o
estado real e atual da organizao.
4.3.4 Elementos
.1 Requisitos Recorrentes
Requisitos recorrentes so aqueles que uma unidade organizacional tem que atender
regularmente. Estes podem incluir obrigaes contratuais, padres de qualidade,
acordos de nvel de servio, regras de negcio, processos de negcio ou requisitos
que descrevam os produtos do trabalho que o grupo realiza.
.2 Requisitos Atendidos
Mesmo que um requisito j tenha sido atendido, ainda ser um requisito enquanto a
parte interessada precisar dele. Manter esses requisitos ajuda a executar melhorias
no produto e futuras mudanas no sistema. Requisitos existentes tambm podem
ser usados em projetos de negcios relacionados.
4.3.5 Tcnicas
Nenhuma.

Analista de Negcios: Requisitos reusveis muito provavelmente sero usados por
um analista de negcios diferente do autor em algum momento futuro. Pode ser
necessrio revisar e atualizar a documentao dos requisitos para garantir que seja
autoexplanatria.
Especialista no assunto: Requisitos recorrentes provavelmente so referidos pelos

especialistas no assunto com maior regularidade para assegurar que os produtos do
trabalho os atendam.
Especialista em Implementao da Soluo: Esses requisitos geralmente so teis

para uma variedade de propsitos, incluindo desenvolvimento de testes de regresso
e anlise de impacto de melhorias.
4.3.7 Sada
Requisitos [Mantidos e Reusveis]: A sada desta tarefa so requisitos que so
expressos de uma forma que os tornem aplicveis para uso a longo prazo pela
organizao (mesmo na ausncia das partes interessadas que originalmente
definiram os requisitos). Eles podem se tornar ativos de processos organizacionais
ou serem usados em futuras iniciativas ou projetos. Em alguns casos, um requisito
que no foi aprovado ou implementado pode ser mantido para uma possvel
iniciativa futura.

Gerenciamento e Comunicao dos Requisitos Preparar o Pacote de Requisitos
4.4 Preparar o Pacote de Requisitos

4.4.1 Propsito
Selecionar e estruturar um conjunto de requisitos de uma forma apropriada
para assegurar que os requisitos sejam efetivamente comunicados, entendidos e
utilizveis por um grupo ou grupos de partes interessadas.
4.4.2 Descrio
Requisitos devem ser apresentados em formatos que sejam compreensveis pelas
partes interessadas. Esta tarefa descreve o trabalho necessrio para decidir quais
formatos so apropriados para um projeto em particular e suas partes interessadas.
Eles devem ser claros, concisos, precisos e apresentar o nvel apropriado de

detalhamento. A documentao de requisitos deve ser criada apenas na extenso
necessria para assegurar claro entendimento pela equipe.
Pacotes de requisitos devem ser preparados por vrias razes, incluindo, mas
no limitado, a avaliao antecipada da qualidade e planejamento, verificao de
possveis alternativas, aprovaes e revises formais, entradas no design da soluo,
conformidade a obrigaes regulatrias e contratuais, e manuteno para reso.
A meta principal de desenvolver um pacote de requisitos transmitir informaes de

uma forma clara e compreensvel. Para ajudar a decidir como apresentar requisitos,
faa perguntas como estas:
Quo detalhados os requerimentos precisam ser?
Que informao importante comunicar? Qual o nvel apropriado de detalhes a

incluir?
O que a parte interessada especfica ir entender baseada no tipo de audincia por

ela representada e no estilo de comunicao e aprendizado preferido daquela parte
interessada?
O formato e a apresentao do pacote de requisitos, e os requisitos contidos no

pacote, so apropriados para o tipo de pblico que precisa revis-los?
Como o pacote de requisitos apoia as fases prvias e subsequentes (ex.: teste,

implementao) ou atividades e entregas do projeto?
Uma m interpretao dos requisitos afeta negativamente a implementao da

soluo. Leva a retrabalho e custos excessivos, especialmente se as deficincias
forem descobertas em etapas tardias do processo.
Possveis formatos para pacotes de requisitos so:
Documentao Formal: Documentao formal geralmente baseada em um

padro (modelo) usado pela organizao, tal como um Documento de Viso ou
Especificao de Requisitos de Softwares.
Apresentao: Proporciona uma viso geral de alto nvel da funcionalidade

entregue pela soluo.

Preparar o Pacote de Requisitos Gerenciamento e Comunicao dos Requisitos
Modelos: Os requisitos podem ser apresentados apenas na forma de um modelo,

como um mapa de processo, ou capturados num quadro branco.
4.4.3 Entrada
Plano de Comunicao de Anlise de Negcios: Tipicamente descreve os grupos
de partes interessadas, suas necessidades de comunicao, e define se um nico ou
vrios pacotes de requisitos so necessrios. O plano de comunicao de anlise
de negcios tambm vai definir o nvel de formalidade que apropriado para os
requisitos.
Ativos de Processos Organizacionais: Possibilitam incluir modelos que podem ser

usados para empacotar requisitos.
Requisitos: O analista de negcios precisa entender quais requisitos sero includos

neste pacote. Requisitos podem ser empacotados em qualquer momento de seu ciclo
de vida.
Estrutura de Requisitos: Um pacote deve conter um conjunto consistente, coeso e

coerente de requisitos.
Figura 4-5: Diagrama de Entrada/Sada de Preparar o Pacote de Requisitos

Entradas
2.4 * 6.2
Plano de Ativos de Requisitos Estrutura de

Comunicao Processos Requisitos
da AN Organizacionais
4.4
Preparar o Pacote de
Requisitos
4.4
Pacotes de
Requisitos

4.5
Comunicar
Requisitos

4.4.4 Elementos
.1 Produtos intermedirios e Entregas
Um produto intermedirio um documento, ou coleo de notas ou diagramas,
usado pelo analista de negcios durante o processo de desenvolvimento dos
requisitos. O produto intermedirio pode, ou no, tornar-se uma entrega, embora
durante diferentes fases do processo de elicitao o analista de negcios possa
ter que compartilhar essa informao com as partes interessadas para esclarecer
requisitos, elicitar requisitos adicionais, ou avaliar a viabilidade da abordagem da
soluo. Podem ser exemplos de produtos do trabalho:
Agendas e atas de reunio;
Perguntas e anotaes de entrevistas;
Anotaes e agendas de sees de facilitao;
Registro de questes;
Plano de trabalho, relatrios de status;
Apresentaes utilizadas durante o projeto;
Matrizes de rastreabilidade.
Entregas
Uma entrega uma sada especfica do processo de anlise de negcios que o
analista de negcios concordou em produzir. Uma entrega de requisitos usada
como base para o desenho e implementao da soluo. O analista de negcios deve
entender a diferena entre estes dois conceitos e usar as entregas como mecanismos
de comunicao. O analista de negcios avaliar as necessidades do pblico,
determinar o nvel de detalhe que precisa ser comunicado e decidir quais entregas
incluir em cada pacote de apresentao.
.2 Formato
Dependendo do tipo do requisito, a tcnica de apresentao pode variar e formatos
especficos podem ter sido selecionados durante o desenvolvimento do plano de
comunicao de anlise de negcios. Provavelmente haver a combinao de vrios
formatos em um pacote de requisitos. Considere a melhor forma de combinar
e apresentar os materiais, de forma a que eles transmitam uma mensagem coesa
e efetiva para um ou mais pblicos que participaro do processo de reviso de
requisitos. Isso pode resultar em criar mais de um pacote de requisitos para o
mesmo projeto.
Considere cuidadosamente quais os tipos de informao que devem ser includos

em um pacote de requisitos e que o contedo pode variar entre diferentes projetos.
O formato mais adequado aquele que melhor comunicar o contedo especfico
do requisito. Cada organizao pode ter padres que o analista de negcios seja
obrigado a seguir e a equipe do projeto utilizar as tcnicas apropriadas para seu
projeto. Geralmente, cada organizao tambm possui um conjunto aprovado de
ferramentas que so usadas para documentao.
Se o pacote criado com a inteno de se obter aprovao formal, a documentao

de requisitos dever estar finalizada para que se prepare o pacote de requisitos.

Preparar o Pacote de Requisitos Gerenciamento e Comunicao dos Requisitos
Consideraes Adicionais Para Documentao de Requisitos

Cada pacote de requisitos pode possuir uma tabela de contedos (ndice) realando
o que est includo no pacote. O agrupamento de requisitos em categorias deve ser
claramente identificado no ndice para facilitar a navegao. Tambm pode incluir
um registro de reviso para documentar mudanas entre verses e ajudar partes
interessadas a verificar se possuem a verso mais recente.
4.4.5 Tcnicas
.1 Documentao de Requisitos
Requisitos frequentemente so capturados em um documento formal. Existem
muitos modelos comumente usados para a documentao de requisitos.
Apesar da seleo dos modelos de documentos estar sujeita abordagem da
anlise de negcios escolhida, alguns dos tipos de documentos de requisitos
mais comuns incluem:
Documento de Requisitos de Negcios (nota: muitos modelos de Documentos

de Requisitos de Negcios tambm incluem requisitos das partes interessadas);
Roadmap do produto;
Especificao dos Requisitos do Software/Sistema;
Especificao de Requisitos Suplementar;
Documento de Viso.
.2 Requisitos Para Seleo do Fornecedor

Se a equipe de soluo acreditar que uma soluo em potencial oferecida por
terceiros, o analista de negcios pode capturar os requisitos na forma de uma RFI
(Request for Information - Solicitao de Informao), RFQ (Request for Quatation
- Solicitao de Cotao), or RFP (Request for Proposal - Solicitao de Proposta).
Enquanto estes termos so s vezes utilizados como intercambiveis, a inteno

que eles reflitam diferentes nveis de formalidade no processo de seleo de
fornecedores. O agente de compras da empresa, seu departamento legal ou de
aquisies geralmente o dono deste processo.
Um RFI geralmente utilizado quando a organizao emitente est aberta para

vrias alternativas de solues e est procurando informaes para avaliar
possveis opes;
Uma RFQ ou RFP usada quando a organizao emitente compreende a

natureza das opes de soluo disponveis e est procura de um vendedor
que possa implementar uma opo. Uma RFQ geralmente segue um processo de
reviso e seleo menos formal que uma RFP.
A equipe da soluo deve considerar cuidadosamente como cada soluo, de

cada fornecedor, ser avaliada. Com frequncia as partes interessadas podem
se impressionar com uma demonstrao do produto, quando este de fato no
atinge a necessidade do negcio.
Analistas de negcios devem desenvolver critrios de avaliao baseados nos

requisitos do negcio antes de ver os produtos disponveis. Em particular, uma RFP
tipicamente inclui uma descrio dos critrios e processos de seleo. Os critrios

de avaliao utilizados podem ser baseados no custo da implementao ou no custo

total de propriedade. Uma medio objetiva (critrio de pesagem) de quo bem a
soluo proposta cumpre os requisitos tambm pode ser includa.
Ao desenvolver as perguntas da RFP, evite usar perguntas fechadas (aquelas que

requerem apenas respostas curtas). A meta estimular o fornecedor a prover
informaes extensivas a respeito dos produtos ou servios oferecidos.
A maior parte das RPFs consiste de vrias sees ou componentes. Exemplos

incluem:
Requisitos das partes interessadas e do negcio para o problema/soluo

especfico;
Descrio da arquitetura ou estratgia do negcio;
Limitaes/restries do ambiente tcnico;
Requisitos legais, regulatrios ou governamentais.
O fornecedor pode ser solicitado a submeter informaes especficas. Exemplos

incluem:
Custo da soluo ou custo total de propriedade;
Alinhamento com a estratgia global do negcio;
Suporte, qualidade, desempenho e arquitetura da soluo;
Extensibilidade e habilidade da soluo para integrar com outras aplicaes;
Sustentabilidade, e/ou perfil e reputao do fornecedor.

Especialistas no Assunto e Usurios Finais: Precisam de requisitos escritos
em terminologia familiar e fcil de entender e revisar. Eles devem entender
completamente cada requisito, j que este o grupo que ser mais afetado pela
soluo implementada. Este grupo se preocupar principalmente em como os
processos operacionais so afetados pela implementao do projeto e estar
interessado em garantir que os requisitos providos por eles, para o analista de
negcios durante o processo de levantamento de requisitos, sejam cumpridos.
Especialista em implementao da soluo: Precisam compreender os requisitos

gerais do projeto e focaro em requisitos que eles usam para projetar a soluo.
Clientes externos e fornecedores precisaro de requisitos tcnicos detalhados de
interface para construir os protocolos de rede e segurana apropriados, de acordo
com as polticas da empresa.
Gerentes de Projetos: Incluem entregas (envolvendo pacotes de requisitos

especficos) no plano do projeto e tipicamente os rastreiam como marcos para aferir
o progresso do projeto. A entrega age como um contrato para o projeto, definindo
o trabalho por todos acordado. A entrega torna-se um ativo do projeto porque
representa uma sada do projeto.
Reguladores: Podem ter requisitos especficos legais, contratuais ou de governana

sobre o que est incluso em um documento de requisitos.

Comunicar Requisitos Gerenciamento e Comunicao dos Requisitos
Patrocinadores (e outros gerentes de nvel executivo): Frequentemente querem

sumrios e requisitos de alto nvel. Sua meta principal entender que a soluo
atingir o retorno das expectativas do investimento de acordo com seu plano
de negcios e minimizar o tempo necessrio para que eles tomem uma deciso
efetiva. O escopo do projeto pode ser suficiente, incluindo a avaliao do ROI
(Retorno sobre Investimento), os benefcios do negcio, o custo do projeto e as
metas de datas de implementao.
Testadores: Focam na compreenso dos fatores crticos de sucesso do projeto

baseados nas necessidades dos usurios de negcio. Devem adquirir uma completa
compreenso dos requisitos funcionais e no-funcionais para construir uma
estratgia de teste efetiva.
4.4.7 Sada
Pacote de Requisitos: O resultado desta tarefa um documento de requisitos,
apresentao ou pacote de requisitos, pronto para ser revisado pelas partes
interessadas. Um pacote pode conter todos os requisitos do projeto ou ser quebrado
em diversos pacotes menores.
4.5 Comunicar Requisitos

4.5.1 Propsito
Comunicar requisitos fundamental para levar as partes interessadas a uma
compreenso comum dos requisitos.
4.5.2 Descrio
Comunicar requisitos inclui conversas, anotaes, documentos, apresentaes e
discusses. Comunicao concisa, apropriada e efetiva requer que o analista de negcios
possua um conjunto significativo de habilidades tanto interpessoais (comunicao),
quanto tcnicas (ex.: requisitos). Ver Habilidades de Comunicao (8.4).
4.5.3 Entrada
Plano de Comunicao da Anlise de Negcios: Define qual informao deve
ser comunicada, quais partes interessadas devem receb-la, quando e como a
comunicao deve ocorrer.
Requisitos: Qualquer requisito pode ser comunicado.
Pacote de requisitos: Requisitos podem ser comunicados sem estarem em um

pacote de requisitos, mas se um pacote foi montado, deve ser distribudo, revisto e
seu contedo deve ser comunicado s partes interessadas.
4.5.4 Elementos
.1 Comunicao Geral
A comunicao de requisitos executada iterativamente e em conjuno com a
maior parte das tarefas das demais reas de conhecimento.
Nem toda a comunicao pode ou deve ser planejada e a comunicao informal de

requisitos provavelmente ser necessria durante o desempenho de muitas tarefas
de anlise. Em muitos casos, comunicao de requisitos pode levar elicitao de
requisitos adicionais.

Gerenciamento e Comunicao dos Requisitos Comunicar Requisitos
Figura 4-6: Diagrama de Entrada/Sada de Comunicar Requisitos

Entradas
2.4 * 4.4
Plano de Requisitos Pacote de

Comunicao Requisitos
da Anlise de
Negcios
4.5
Comunicar
Requisitos
4.5
Requisitos
[Comunicados]

4.1
Gerenciar o Escopo e os
Requisitos da Soluo
Tarefas da Anlise Corporativa: Informao de business case e de escopo de

soluo comunicada.
Tarefas da Elicitao: Cada tcnica de elicitao requer habilidades de

comunicao especficas.
Teste de anlise de requisitos: requisitos so refinados, modificados, clareados e

finalizados atravs de uma comunicao eficaz.
Tarefas da Avaliao e Validao da Soluo: Avaliaes da soluo, alocao de

requisitos para componentes da soluo, prontido organizacional e requisitos de
transio devem ser todos comunicados.
.2 Apresentaes
Antes de fazer qualquer apresentao de requisitos para uma plateia, determine
um formato apropriado para a apresentao. A formalidade da apresentao
dirigida pelo objetivo da comunicao e pelas necessidades da plateia. Por exemplo,
o analista de negcios pode ser requisitado a apresentar pontos-chave utilizando
slides e material impresso. Isto pode ser necessrio ao apresentar para membros

Comunicar Requisitos Gerenciamento e Comunicao dos Requisitos
seniores que no estejam envolvidos ativamente com o desenvolvimento do projeto,

mas que precisam entender os requisitos em um nvel mais alto.
Uma apresentao pode ser usada:
Para assegurar que os padres de qualidade interna do projeto tenham sido

respeitados;
Para assegurar alinhamento com outras reas de processo de negcios no

mesmo projeto;
Para obter aceitao do negcio e aprovao;
Para obter aprovao da equipe de entrega;
Para obter aprovao da equipe de testes;
Como um precursor para entrega (ex.: examinar as opes de soluo com uma
equipe de entrega);
Para priorizar um conjunto de requisitos antes de proceder para o prxima

etapa do projeto;
Para tomar decises a respeito do escopo do projeto.
Apresentao Formal
Apresentaes formais tipicamente disseminam informaes em um formato bem
organizado e estruturado. Os membros da plateia podem receber material de apoio
antes ou durante a apresentao. A participao e perguntas da plateia podem ser
encorajadas.
Apresentao Informal
Uma apresentao informal pode ser usada:
Como uma checagem informal da situao dos requisitos (ex.: completude,

correo, impacto em outras reas);
Para comunicar requisitos equipe de entrega ou equipe de testes para

assegurar que no haja ambiguidades;
Para comunicar requisitos a reas de negcios afetadas (aquelas que no tm

poder de assinatura, mas que precisam conhecer as mudanas);
Para comunicar requisitos a outras equipes de projetos como um exerccio de

facilitao para aumentar a clareza dos requisitos. Por exemplo, ao aproximar
usurios e equipes tcnicas, uma compreenso comum pode ser alcanada
sobre a relevncia/importncia de requisitos individuais, assim como da
exequibilidade de entregar requisitos individuais.

Gerenciamento e Comunicao dos Requisitos Comunicar Requisitos
4.5.5 Tcnicas
Workshops de Requisitos (9.23): Requisitos podem ser apresentados como parte
de um workshop de requisitos para familiarizar todas as partes com o escopo da
soluo existente e os requisitos atuais.
Revises Estruturadas (9.24): Geralmente comea com uma reviso dos requisitos
a serem discutidos.

Todas.
4.5.7 Sada
Requisitos Comunicados: As partes interessadas devem entender quais so os
requisitos e a sua situao atual.

Anlise Corporativa
Captulo CINCO
A rea de Conhecimento Anlise Corporativa descreve as atividades de anlise de
negcios necessrias para identificar uma necessidade do negcio, problema ou
oportunidade, definir a natureza de uma soluo que atende a essa necessidade e
justificar o investimento necessrio para a entrega dessa soluo. Sadas da anlise
corporativa proveem contexto para a anlise de requisitos e identificao da soluo
para uma dada iniciativa ou planejamento de longo prazo. A anlise corporativa
frequentemente o ponto de partida para o incio de um novo projeto e contnua
conforme mudanas ocorram e mais informaes tornem-se disponveis. atravs
das atividades da anlise corporativa que os requisitos do negcio so identificados
e documentados.
Ela descreve as atividades de anlise de negcios que so empregadas nas

organizaes para:
Analisar a situao do negcio, no intuito de compreender completamente os

problemas e oportunidades do negcio;
Avaliar as capacidades da corporao, no intuito de compreender a mudana

necessria para atender s necessidades do negcio e atingir metas estratgicas;
Determinar a abordagem de soluo de negcio mais apropriada;
Definir o escopo da soluo e desenvolver o Business Case para uma soluo

proposta;
Definir e documentar os requisitos do negcio (incluindo a necessidade do

negcio, capacidades requeridas, escopo da soluo e business case).
Nota: O desempenho de todas as atividades da Anlise Corporativa governado

pelos planos da anlise de negcios (veja 2.3), sendo que as mtricas de desempenho
da anlise de negcios devem ser registradas (veja 2.6).
Figura 5-1: Diagrama de Entrada/Sada da Anlise Corporativa

Entradas
Sadas
6.4 Tarefas
5.1 5.2 5.5 5.1
Suposies e Metas e Arquitetura Definir a Avaliar Gaps
Restries Objetivos do Corporativa Necessidade do (Lacunas) de Business Case Necessidade de
Negcio Negcio Capacidades Negcio
3.3 7.6 5.3 5.2 5.3

5.4
Determinar a
Definir o Escopo da
Ativos de Requisitos Avaliao do Abordagem da Capacidades Abordagem de
Soluo
Processos [Declarados] Desempenho Soluo Requeridas Soluo
Organizacionais da Soluo
3.3 5.5 5.4
Definir o Business
Preocupaes Case Escopo da
das Partes Soluo
Interessadas

Definir a Necessidade do Negcio Anlise Corporativa
5.1 Definir a Necessidade do Negcio

5.1.1 Propsito
Identificar e definir porque uma mudana nas capacidades, ou sistemas
organizacionais, necessria.
5.1.2 Descrio
A definio da necessidade do negcio frequentemente o passo mais crtico de
qualquer esforo de anlise de negcios. A necessidade do negcio define o problema
para o qual o analista de negcios est tentando encontrar uma soluo. A maneira
como a necessidade do negcio definida determina quais solues alternativas
sero consideradas, quais partes interessadas sero consultadas e quais abordagens
de soluo sero avaliadas.
Figura 5-2: Diagrama de Entrada/Sada de Definir a Necessidade do Negcio

Entradas
3.3
Metas e Requisitos
Objetivos do [Declarados]
Negcio
5.1
Definir a
Necessidade do
Negcio
5.1
Necessidade do
Negcio
2.2
2.1
Conduzir a Anlise 3.1
Planejar a
das Partes Preparar a Elicitao
Abordagem da AN
Interessadas
5.2 5.3
3.2
Avaliar Gaps Determinar a
Conduzir Atividade
(Lacunas) de Abordagem da
de Elicitao
Capacidades Soluo
5.4 5.5
6.1
Definir o Business Definir o Escopo da
Case Soluo
Gerenciamento e
6.5 Comunicao de
Verificar Requisitos Requisitos
+

Anlise Corporativa Definir a Necessidade do Negcio
Uma questo encontrada na organizao, como uma reclamao de um cliente, a

perda de receita ou uma nova oportunidade de mercado, geralmente desencadeia
a avaliao de uma necessidade do negcio. comum organizaes agirem para
resolver a questo sem a investigao da necessidade implcita do negcio. O analista
de negcios deve questionar as suposies e restries que esto geralmente ocultas
sob a declarao da questo para garantir que o problema correto esteja sendo
resolvido e que o maior nmero de solues alternativas esteja sendo considerado.
Novas necessidades do negcio podem ser geradas de diferentes formas:
De cima para baixo a necessidade de atingir uma meta estratgica
De baixo para cima um problema com a situao atual de um processo, funo

ou sistema.
Da mdia gerncia um gerente precisa de informao adicional para tomar

decises importantes ou deve executar funes adicionais para atender aos
objetivos do negcio.
De direcionadores externos direcionados por uma demanda de cliente ou pela

competio no mercado.
5.1.3 Entrada
Metas e Objetivos do Negcio: Objetivos e metas do negcio geralmente precisam
ser refinados, com o intuito de definir a necessidade do negcio. Em alguns casos,
a meta ou objetivo pode ser exploratrio a necessidade do negcio pode ser a de
compreender se uma metodologia ou modelo de negcio funciona.
Requisitos [Declarados]: Elicitao pode ser executada no intuito de auxiliar as

partes interessadas a definir suas necessidades percebidas. Garanta que elas reflitam
verdadeiros requisitos do negcio e no descries de solues.
5.1.4 Elementos
.1 Metas e Objetivos do Negcio
Metas e objetivos do negcio descrevem os fins que a organizao est procurando
atingir. Metas e objetivos podem estar relacionados a mudanas que a organizao
deseja alcanar ou condies atuais que ela deseja manter.
Metas so declaraes contnuas e qualitativas, de longo prazo, de um estado

ou condio que a organizao est buscando estabelecer ou manter. Metas de
alto nvel podem ser decompostas para distribuir a estratgia geral entre reas de
foco distintas que podem levar aos resultados desejados, tais como uma crescente
satisfao do cliente, excelncia operacional e/ou crescimento do negcio. reas de
foco so geralmente descritas em declaraes breves. Por exemplo, uma meta pode ser
Aumentar a parcela de clientes altamente lucrativos e ento ser refinada no objetivo
Aumentar a parcela de clientes altamente lucrativos atravs de fuses e aquisies.
Conforme as metas so analisadas, elas so convertidas em objetivos mais

descritivos, granulares e especficos e vinculadas s medidas que tornem possveis
avaliar se esses objetivos foram alcanados. Um teste comum para verificar os
objetivos garantir que eles so SMART (espertos):
eSpecficos Descrevendo algo que possui um resultado observvel
Mensurveis Rastreando e medindo o resultado

Definir a Necessidade do Negcio Anlise Corporativa
Alcanveis Testando a viabilidade do esforo
Relevantes Em alinhamento com a viso, misso e principais metas da

organizao
Temporais O objetivo possui um prazo definido que consistente com a

necessidade do negcio
.2 Problema ou Oportunidade do Negcio

No intuito de definir a necessidade do negcio, uma questo deve ser investigada
para garantir que ela , de fato, uma oportunidade para melhoria, se for resolvida.
Fatores que o analista de negcio deve considerar incluem:
Impactos adversos que o problema est causando dentro da organizao e a

quantificao desses impactos (ex.: potencial perda de receitas, ineficincias,
clientes insatisfeitos, baixa moral entre os colaboradores);
Benefcios esperados de uma soluo em potencial (ex.: maiores receitas, reduo

dos custos, maior participao no mercado);
O quo rpido o problema poderia ser potencialmente resolvido ou a

oportunidade poderia ser adotada e o custo de no se fazer nada;
A causa implcita do problema.
.3 O Resultado Desejado
Um resultado desejado no uma soluo. Ele descreve os benefcios do negcio
que resultaro do atendimento necessidade do negcio e do estado final desejado
pelas partes interessadas. Solues propostas devem ser avaliadas em relao aos
resultados desejados para garantir que elas podem entregar aqueles produtos.
Exemplos incluem:
Criar uma nova capacidade como em um novo produto ou servio, atuando sobre
uma desvantagem competitiva ou criando uma nova vantagem competitiva;
Aumentar as receitas atravs do aumento nas vendas ou da reduo dos custos;
Aumentar a satisfao dos clientes;
Aumentar a satisfao dos colaboradores;
Ajustar-se a novas regulamentaes;
Aumentar a segurana;
Reduzir o tempo de entrega de um produto ou servio.
Resultados desejados devem enderear um problema ou oportunidade e apoiar as

metas e objetivos do negcio.
5.1.5 Tcnicas
Benchmarking (9.2): Compreender o que organizaes concorrentes e parceiros
esto fazendo permite que a organizao permanea em um nvel comparvel de
servio ou identifique oportunidades para aumentar a eficincia.

Anlise Corporativa Avaliar Gaps (Lacunas) de Capacidades
Brainstorming (9.3): Gera insights e opes.
Anlise das Regras de Negcios (9.4): Identifica mudanas nas polticas que guiam
a organizao na direo de atingir suas metas e objetivos.
Grupos Focais (9.11): Para identificar e discutir problemas.
Decomposio Funcional (9.12): Converter metas do negcio em objetivos e medidas

atingveis.
Anlise da Causa-Raiz (9.25): Determinar a causa implcita de um problema.

Cliente ou Fornecedor: Uma necessidade do negcio pode surgir de aes ou
necessidades de um cliente ou fornecedor. Novas oportunidades frequentemente
surgem quando uma necessidade no atendida de um cliente identificada.
Especialista no Assunto e Usurio Final: Quem provavelmente tm a percepo

mais direta dos problemas e das limitaes que existem em sistemas atuais e os seus
efeitos.
Especialista na Implementao da Soluo: Pode perceber as capacidades

atualmente presentes, ou facilmente adicionveis, dos sistemas atuais que podem
oferecer novas oportunidades.
Regulador: Pode impor novos requisitos regulatrios ou de governana para a

organizao.
Patrocinador: Um patrocinador deve ser identificado dentro da organizao e

responsvel por garantir que a necessidade do negcio ser atendida e pode autorizar
as aes para atend-la.
5.1.7 Sada
Necessidade do Negcio: Uma necessidade do negcio descreve um problema que
a organizao est enfrentando, ou que pode vir a enfrentar, ou uma oportunidade
que no foi aproveitada, e o resultado desejado. A necessidade do negcio vai guiar a
identificao e definio de possveis solues.
5.2 Avaliar Gaps (Lacunas) de Capacidades

5.2.1 Propsito
Identificar as novas capacidades requeridas pela corporao para atender
necessidade do negcio.
5.2.2 Descrio
Levantar as capacidades atuais da corporao e identificar os gaps (lacunas) que a
impedem de atender s necessidades do negcio e alcanar os resultados desejados.
Determinar se possvel para a organizao atender necessidade do negcio
utilizando a estrutura, pessoas, processos e tecnologia atuais. Se a organizao pode
atender necessidade do negcio com as suas capacidades existentes, a mudana
resultante tende a ser relativamente pequena.
Entretanto, se as capacidades existentes so inadequadas, provavelmente ser

necessrio lanar um projeto para desenvolver aquela capacidade. Mudanas podem

Avaliar Gaps (Lacunas) de Capacidades Anlise Corporativa
ser necessrias em cada componente da organizao, incluindo (mas no limitado

a): processos do negcio, funes, linhas de negcios, estruturas organizacionais,
competncias da equipe, conhecimento e habilidades, treinamento, instalaes,
ferramentas de escritrio, localizaes fsicas da organizao, dados e informao,
aplicativos de sistemas e/ou infraestrutura de tecnologia.
Figura 5-3: Diagrama de Entrada/Sada de Avaliar Gaps (Lacunas) de Capacidades

Entradas
5.1 7.6
Necessidade do Arquitetura Avaliao do

Negcio Corporativa Desempenho
da Soluo
5.2
Avaliar Gaps
(Lacunas) de
Capacidades
5.2
Capacidades
Requeridas
5.3
5.4
Determinar a
Definir o Escopo da
Abordagem da
Soluo
Soluo
Gerenciamento e
6.1 6.5
Comunicao
Priorizar Verificar
de Requisitos
+
5.2.3 Entrada
Necessidade do Negcio: Capacidades so avaliadas em relao necessidade do
negcio para identificar gaps (lacunas).
Arquitetura Corporativa: A arquitetura corporativa define as capacidades atuais

de uma organizao.
Avaliao do Desempenho da Soluo: Identifica deficincias, problemas ou

limitaes de uma soluo existente. Em alguns casos, uma soluo pode possuir

Anlise Corporativa Avaliar Gaps (Lacunas) de Capacidades
capacidades que uma organizao no est utilizando (ocorre frequentemente com

uma soluo empacotada ou com servios terceirizados) que podem tambm ser
avaliadas em relao necessidade do negcio.
5.2.4 Elementos
.1 Anlise das Capacidades Atuais
Rene o mximo possvel de informao disponvel sobre a arquitetura corporativa
das reas da corporao afetadas pela necessidade do negcio. A meta compreender
o negcio da organizao e como a arquitetura do negcio e da tecnologia est
suportando aquele negcio. Se informaes adequadas no estiverem disponveis,
ser necessrio desenvolver os modelos e outras informaes descritivas sobre a
rea da corporao que est sob reviso. Uma vez que as capacidades da corporao
esto totalmente descritas, elas devem ser avaliadas em relao aos objetivos
desejados para determinar se a organizao possui atualmente a capacidade de
atender necessidade do negcio.
.2 Avaliao dos Requisitos de Novas Capacidades

Se as capacidades atuais so insuficientes para atender necessidade do negcio,
o analista de negcios deve identificar as capacidades que devem ser adicionadas.
O analista de negcios ir desenvolver modelos e outras informaes descritivas
sobre a viso futura e descrever o estado futuro da organizao. Uma comparao
entre o estado atual e o estado futuro desejado ir identificar gaps (lacunas) nas
capacidades organizacionais que precisam ser preenchidos para apoiar a viso do
negcio, estratgia, metas e objetivos.
Alguns exemplos de capacidades incluem:
Processos do negcio
Funcionalidades de um aplicativo de software
Tarefas que um usurio final deve executar
Eventos aos quais uma soluo deve ser capaz de responder
Produtos que uma organizao cria
Servios que uma organizao entrega
Metas que uma soluo ir permitir que as partes interessadas alcancem
.3 Suposies
Frequentemente ser difcil, ou impossvel, provar que a entrega de uma nova
capacidade atender a uma necessidade do negcio, mesmo nos casos em que parece
plausvel assumir que a nova capacidade ir trazer o efeito desejado. Essas suposies
devem ser identificadas e claramente compreendidas para que as decises apropriadas
possam ser tomadas, caso as suposies sejam posteriormente provadas invlidas.
5.2.5 Tcnicas
Anlise de Documentos (9.9): til para compreender o estado atual da corporao,
na medida em que este estado atual esteja documentado.
Anlise SWOT (9.32): Identificar como as capacidades e limitaes atuais (foras e

fraquezas) alinham-se versus os fatores influenciadores (oportunidades e ameaas).

Determinar a Abordagem da Soluo Anlise Corporativa

Cliente e Fornecedor: Clientes e Fornecedores podem ser impactados se o negcio
desenvolver ou alterar as suas capacidades. Eles podem tambm estar em posio
de desenvolver, eles mesmos, as capacidades no lugar de requerer que a organizao
mude no intuito de prov-las.
Especialista no Assunto, Usurio Final, Especialista em Implementao da

Soluo e Patrocinador: Iro prover informaes sobre as foras e fraquezas das
capacidades atuais.
5.2.7 Sada
Capacidades requeridas: Uma compreenso das capacidades atuais da organizao
e das novas capacidades (processos, pessoas, funcionalidades em um aplicativo, etc.)
que podem ser requeridas para atender necessidade do negcio.
5.3 Determinar a Abordagem da Soluo

5.3.1 Propsito
Determinar a abordagem de soluo mais vivel para atender necessidade do
negcio em um nvel de detalhe suficiente que permita definir o escopo da soluo e
preparar o business case.
5.3.2 Descrio
A abordagem da soluo descreve a abordagem geral que ser tomada para criar ou
adquirir novas capacidades requeridas para atender necessidade do negcio. Para
determinar a abordagem da soluo, necessrio identificar abordagens possveis,
determinar os meios atravs dos quais a soluo pode ser entregue (incluindo a
metodologia e o ciclo de vida a ser utilizado) e avaliar se a organizao capaz de
implementar e usar eficazmente uma soluo dessa natureza.
Algumas abordagens possveis incluem:
Utilizar capacidades adicionais de software/hardware existentes que j esto

disponveis dentro da organizao
Adquirir ou fazer leasing de software/hardware junto a um fornecedor
Desenhar e desenvolver software personalizado
Adicionar recursos ao negcio ou efetuar mudanas organizacionais
Mudar procedimentos/processos do negcio
Estabelecer parcerias com outras organizaes ou terceirizar trabalho com

fornecedores

Anlise Corporativa Determinar a Abordagem da Soluo
Figura 5-4: Diagrama de Entrada/Sada de Determinar a Abordagem da Soluo

Entradas
5.1 5.2
Necessidade do Ativos de Capacidades

Negcio Processos Requeridas
Organizacionais
5.3
Determinar a
Abordagem da
Soluo
5.3
Abordagem da
Soluo

5.4
Definir o Escopo da
Soluo
5.3.3 Entrada
Necessidade do Negcio: Solues possveis sero avaliadas em relao necessidade
do negcio para garantir que ela possa ser atendida pela abordagem selecionada.
Ativos de Processos Organizacionais: A organizao pode requerer que uma

abordagem especfica (como uma metodologia especfica) seja tomada para solues
de um determinado tipo.
Capacidades Requeridas: Identifica as novas capacidades que qualquer soluo

deve suportar.
5.3.4 Elementos
.1 Gerao de Alternativas
Identificar tantas opes em potencial quanto possvel para atender aos objetivos
do negcio e preencher os gaps (lacunas) identificados nas capacidades. A lista
de alternativas possveis deve incluir a opo de nada se fazer, como tambm a
investigao de opes que permitam que a organizao ganhe tempo.
Mesmo no existindo uma regra clara e absoluta para determinar se a quantidade

suficiente de alternativas foi investigada, alguns indicadores so:

Determinar a Abordagem da Soluo Anlise Corporativa
Ao menos uma das abordagens alternativas aceitvel do ponto de vista das

principais partes interessadas;
Ao menos algumas das abordagens so, de fato, diferentes entre si;
O esforo para investigar alternativas est produzindo cada vez menos retorno.
.2 Suposies e Restries
Suposies que podem afetar a soluo escolhida devem ser identificadas. Certas
solues podem ser descartadas por serem consideradas tecnicamente inviveis ou
de alto custo, enquanto outras abordagens podem ser consideradas de fcil execuo,
mais do que realmente so. Da mesma forma, a organizao pode ser impedida de
adquirir certas alternativas de soluo em virtude de razes contratuais ou porque
elas no se encaixam na infraestrutura da organizao. Suposies e restries
devem ser questionadas para garantir que elas so vlidas.
.3 Ranqueamento e Seleo de Abordagens

No intuito de avaliar uma abordagem, registre a informao disponvel e
analise a viabilidade operacional, econmica, tcnica, temporal, organizacional,
cultural, legal e mercadolgica. Capture informaes consistentes para cada
opo para facilitar a sua comparao e revise os resultados para garantir que
esto corretos e completos.
Em alguns casos, uma abordagem de uma soluo em particular pode se provar

como sendo evidentemente superior s alternativas. Se este no for o caso,
abordagens de soluo devem ser avaliadas e ranqueadas. Caso existam apenas
algumas diferenas crticas entre alternativas de solues, pode ser possvel criar
uma avaliao qualitativa dessas diferenas para apoiar a escolha. Para problemas
de deciso mais complexa, um sistema de pontuao deve ser usado com pesos
sendo atribudos a conjuntos de requisitos relacionados; pesos que reflitam a sua
importncia relativa para a organizao. Cada soluo pontuada e a soluo, ou as
solues, com a maior nota so investigadas com mais detalhe.
5.3.5 Tcnicas
.1 Tcnicas Gerais
Benchmarking (9.2): Identifica abordagens de soluo que se provaram efetivas em
outras organizaes.
Brainstorming (9.3): Usado como um mtodo para a gerao de alternativas.
Anlise Decisria (9.8): Ranqueia e seleciona possveis abordagens de soluo.
Estimativa (9.10): Desenvolve comparaes iniciais de custos entre as abordagens

de soluo possveis.
Anlise SWOT (9.23): Mtodo til para a comparao de abordagens possveis.
.2 Anlise de Viabilidade
Para esforos pequenos e relativamente diretos, a abordagem da soluo pode ser
determinada pelo analista de negcios sozinho ou junto a um pequeno time de
especialistas que examinaro as abordagens em uma sesso de trabalho informal.
Para iniciativas que envolvam mudanas maiores, que requerem investimentos
significativos, um estudo de viabilidade mais formal pode auxiliar na determinao
da alternativa de soluo mais vivel.

Anlise Corporativa Definir o Escopo da Soluo
Um estudo de viabilidade uma anlise preliminar das alternativas de soluo

ou opes para determinar se, e como, cada opo pode prover um benefcio de
negcio esperado para atender necessidade do negcio. Um estudo de viabilidade
pode enderear um problema do negcio a ser resolvido ou uma oportunidade de
negcio a ser explorada. Estudos de viabilidade formais usam dados confiveis e
aplicam estatsticas e pesquisas de mercado para identificar e analisar potenciais
alternativas de soluo.
A anlise de viabilidade uma parte integral da formulao de uma grande

transformao de negcio, tais como a reengenharia de um processo de negcio-
chave e da tecnologia que o suporta, uma nova linha de negcio, o aumento da
fatia de mercado atravs de aquisies, ou desenvolvimento de um novo produto ou
servio. Estudos abreviados podem ser conduzidos para iniciativas de mudanas
que requerem menores investimentos.

Cliente, Especialista no Assunto, Usurio Final e Fornecedor: Podem ser capazes
de sugerir abordagens e de identificar suposies e restries.
Especialista na Implementao da Soluo: Ser necessrio para avaliar a

viabilidade de possveis abordagens.
Patrocinador: Pode ser a fonte de restries s alternativas de soluo e ser

provavelmente chamado a aprovar a abordagem recomendada.
5.3.7 Sada
Abordagem da Soluo: Uma descrio da abordagem que ser tomada para
implementar um novo conjunto de capacidades. Abordagens de soluo descrevem
os tipos de componentes de soluo que sero entregues (novos processos, um novo
aplicativo de software, etc.) e podem tambm descrever a metodologia que ser
utilizada para entregar esses componentes.
5.4 Definir o Escopo da Soluo

5.4.1 Propsito
Definir quais novas capacidades um projeto ou iterao ir entregar.
5.4.2 Descrio
O propsito dessa tarefa conceituar a soluo recomendada em um nvel de
detalhes suficiente para permitir que as partes interessadas compreendam quais
novas capacidades de negcio uma iniciativa entregar. O escopo da soluo mudar
durante um projeto com base em mudanas no ambiente de negcios ou conforme o
escopo do projeto for alterado para atender ao oramento, tempo, qualidade e outras
restries. O escopo da soluo inclui:
O escopo da anlise (a unidade organizacional ou processo para o qual os

requisitos esto sendo desenvolvidos) que proveem o contexto no qual a soluo
implementada.
As capacidades suportadas por componentes da soluo, como processos do

negcio, unidades organizacionais e aplicativos de software.
As capacidades a serem suportadas por entregas ou iteraes individuais.

Definir o Escopo da Soluo Anlise Corporativa
As capacidades bsicas que so necessrias para que a organizao desenvolva

as capacidades requeridas para atender necessidade do negcio.
Nota: Esta tarefa descreve como os requisitos do negcio so alocados para

implementao por um projeto. Veja Alocar Requisitos (7.2) para uma discusso a
respeito de como os requisitos das partes interessadas e da soluo so alocadas aos
componentes e s entregas da soluo.
Figura 5-5: Diagrama de Entrada/Sada de Definir o Escopo da Soluo
Entradas
6.4 5.1 5.2 5.3
Suposies e Necessidade do Capacidades Abordagem

Restries Negcio Requeridas da Soluo
5.4
Definir o Escopo da
Soluo
5.4
Escopo da
Soluo

3.2 5.5
3.1
Conduzir a Atividade Definir o Business
Preparar a Elicitao
de Elicitao Case
6.1 6.2 6.5

Priorizar Requisitos Organizar Requisitos Verificar Requisitos
7.3 Gerenciamento e
7.2
Avaliar a Prontido Comunicao de
Alocar Requisitos
Organizacional Requisitos
+

Anlise Corporativa Definir o Escopo da Soluo
5.4.3 Entrada
Suposies e Restries: Suposies e restries relevantes podem incluir suposies
sobre como as partes interessadas iro responder a um novo produto ou servio, ou
a respeito da disponibilidade da tecnologia. Restries podem incluir limitaes em
relao ao que pode ser includo no escopo da soluo. Inclui qualquer limitao de
fundos ou cronograma, alm de padres, polticas e regulamentaes significativas
a serem seguidos e os dados de apoio requeridos.
Necessidade do Negcio: As metas, objetivos e resultados desejados pela organizao.
Capacidades Requeridas: Descreve como novas capacidades so requeridas para

atender necessidade do negcio e serve como base para o escopo da soluo.
Abordagem da Soluo: A abordagem geral tomada para a entrega das novas

capacidades requeridas pelo negcio ser usada na avaliao das opes para a
implementao dos componentes da soluo.
5.4.4 Elementos
.1 Definio do Escopo da Soluo
A soluo descrita no nvel das maiores funcionalidades e funes a serem
includas e das interaes que a soluo ter com pessoas e sistemas fora do seu
escopo. Declara os componentes includos e excludos do escopo da soluo.
Descreve as unidades de negcio que sero envolvidas, processos de negcio a serem
aperfeioados ou redesenhados, donos dos processos e sistemas de TI e outras
tecnologias que sero provavelmente afetadas.
.2 Abordagem de Implementao
A abordagem de implementao descreve como a abordagem de soluo escolhida
ir entregar o escopo da soluo. Por exemplo, se a abordagem de soluo envolve
a diviso do projeto proposto em liberaes que iro entregar subconjuntos teis
de funcionalidades para o negcio, a abordagem de implementao descrever
a funcionalidade em cada liberao e o cronograma esperado das entregas. Se a
abordagem de soluo envolver a terceirizao de processos-chave, a abordagem
de implementao definir quais processos so candidatos terceirizao ou
o processo que ser usado para identificar aqueles candidatos. A abordagem de
implementao pode decompor as entregas em liberaes especficas ou prover um
roadmap que indica o prazo dentro do qual cada capacidade pode ser esperada.
.3 Dependncias
Definir as principais dependncias de negcio e tcnicas que iro impor restries
ao esforo de entrega da soluo, incluindo dependncias que possam existir entre
os componentes da soluo.
5.4.5 Tcnicas
.1 Tcnicas Gerais
Decomposio Funcional (9.12): Para compreender o escopo do trabalho e quebrar
o escopo da soluo em produtos de trabalho e entregas menores.
Anlise de Interfaces (9.13): Descreve o escopo de trabalho requerido para a

integrao da nova soluo nos ambientes de negcios e tcnicos.
Modelagem de Escopo (9.27): Identifica fronteiras apropriadas para o escopo da

soluo.

Definir o Business Case Anlise Corporativa
Histrias do Usurio (9.33): Descrevem as partes interessadas e as metas que o

sistema suporta. Tambm podem ser usadas para definir o escopo da soluo.
.2 Declarao do Problema ou da Viso

Uma declarao do problema ou da viso declara a necessidade do negcio, identifica
as principais partes interessadas e descreve brevemente o impacto positivo que, ao
atender necessidade do negcio, a mesma ter sobre aquelas partes interessadas.
Figura 5-6: Exemplo de Declarao do Problema

O problema de Descreva o problema.
Afeta As Partes Interessadas afetadas pelo problema.
Cujo impacto Qual o impacto do problema sobre cada Parte Interessada.
Uma soluo bem sucedida

Listar alguns dos principais benefcios de uma boa soluo.
poderia

Especialista no Assunto: Participar na identificao das unidades organizacionais
afetadas, na modelagem do escopo das solues possveis e na determinao das
prioridades relativas das capacidades requeridas.
Especialista na Implementao da Soluo: Participar na alocao das

capacidades nos componentes da soluo e na determinao do tempo e esforo
necessrios para entregar novas capacidades.
Gerente do projeto: Pode auxiliar no desenvolvimento do escopo geral da soluo,

o qual ser usado como uma entrada para o Termo de Abertura do Projeto. O
gerente do projeto responsvel pela definio do escopo do projeto, que o
trabalho necessrio para a entrega do escopo da soluo ou de uma parcela dela. O
gerente do projeto assumir um papel importante na alocao de capacidades nos
componentes e ser primariamente responsvel pela determinao do tempo e do
esforo necessrio para entregar a capacidade.
Patrocinador: Participar no estabelecimento de prioridades e na aprovao do

escopo da soluo.
5.4.7 Sada
Escopo da Soluo: Define o que deve ser entregue a fim de atender a necessidade do
negcio, e o efeito da iniciativa de mudana proposta sobre o negcio e as operaes
e infra-estrutura de tecnologia.
5.5 Definir o Business Case

5.5.1 Propsito
Determinar se uma organizao pode justificar o investimento necessrio para
entregar uma soluo proposta.

Anlise Corporativa Definir o Business Case
5.5.2 Descrio
O business case descreve a justificativa para o projeto em termos de valor a ser
adicionado ao negcio como resultado da soluo implantada, em comparao ao
custo para desenvolver e operar a soluo. O business case pode tambm incluir
benefcios qualitativos e quantitativos, estimativas de custo e tempo at o ponto
de equilbrio, expectativas de lucros e oportunidades adicionais. O business case
pode apresentar os impactos esperados das aes sobre o fluxo de caixa ao longo do
tempo e os mtodos e o raciocnio usados para a quantificao dos benefcios e dos
custos. Ele fornece um framework para a demonstrao de como esperado que a
iniciativa atinja os objetivos do negcio. Alm disso, o business case lista as restries
associadas ao projeto proposto, junto a um oramento estimado e ao alinhamento
com as estratgias estabelecidas pela organizao.
Figura 5-7: Diagrama de Entrada/Sada de Definir o Business Case
Entradas
6.4 5.1 5.4 3.3
Suposies e Necessidade do Escopo da Preocupaes

Restries Negcio Soluo das Partes
Interessadas
5.5
Definir o Business
Case
5.5
Business Case

3.2
3.1 6.1
Preparar a Elicitao Priorizar Requisitos
de Elicitao
Gerenciamento e
6.5 6.6 Comunicao de
Verificar Requisitos Validar Requisitos Requisitos
+

Definir o Business Case Anlise Corporativa
5.5.3 Entrada
Suposies e Restries: Inclui suposies a respeito das receitas geradas ou retidas
pela soluo, ou melhorias no-financeiras que ela trar.
Necessidade do Negcio: Define o valor que uma soluo ir entregar organizao

e como ela se alinha s metas e objetivos do negcio.
Escopo da Soluo: Define as capacidades que sero implementadas, os mtodos

que sero usados para entreg-las e as reas da organizao que sero afetadas.
Preocupaes das Partes Interessadas: Podem incluir riscos ou questes que devem
ser levados em conta no business case.
5.5.4 Elementos
.1 Benefcios
Medir os benefcios da soluo recomendada em termos de ganhos qualitativos e
quantitativos para a corporao. Os benefcios devem ser quantificados sempre que
possvel. Os benefcios de uma natureza no-financeira (como moral elevada dos
colaboradores, maior flexibilidade na resposta a mudanas, maior satisfao dos
clientes ou reduo da exposio ao risco) so tambm importantes e adicionam
um valor significativo para a organizao, mesmo que eles devam ser avaliados
qualitativamente. Estimativas de benefcios devem ser rastreveis at as metas e aos
objetivos estratgicos.
.2 Custos
Estimar o custo lquido total da soluo. Isso requer que sejam feitas estimativas dos
maiores gastos do novo investimento, custos do desenvolvimento e implementao
da mudana, custos da oportunidade do no-investimento em outras opes, custos
relacionados mudana no trabalho e nas prticas da organizao, o custo total de
propriedade para suportar a nova soluo e custos consequentes arcados por outros.
.3 Avaliao do Risco
O propsito da avaliao inicial do risco determinar se a iniciativa proposta traz
mais risco do que a organizao est disposta a tolerar.
A avaliao inicial do risco foca primariamente nos riscos de viabilidade da soluo e

revisitada ao longo do projeto. A avaliao do risco deve considerar riscos tcnicos
(se uma tecnologia escolhida e fornecedores podem entregar as funcionalidades
requeridas), riscos financeiros (se os custos iro exceder nveis que tornam a soluo
vivel ou se os benefcios potenciais podem ser anulados) e riscos organizacionais e
de mudana nos negcios (se a organizao ir implantar as mudanas necessrias
para se beneficiar da nova soluo).
.4 Medio dos Resultados

O business case articula no apenas os custos e benefcios projetados a serem
realizados, mas tambm como esses custos e benefcios sero acessados e avaliados.
5.5.5 Tcnicas
Anlise de Deciso (9.8): Anlise de custo/benefcio compara os custos da
implementao de uma soluo versus os benefcios a serem ganhos. Anlise
financeira inclui o uso de modelos financeiros que estimam o valor de mercado de
um ativo organizacional.

Anlise Corporativa Definir o Business Case
Estimativa (9.10): Previso do tamanho do investimento necessrio para lanar e

operar a soluo proposta.
Mtricas e Indicadores-Chave de Desempenho (9.16): Avaliados para apoiar o

gerenciamento dos benefcios, medio e reportes, incluindo onde o realinhamento de
medies internas ou de sistemas necessrio para garantir que os comportamentos
que estamos buscando podem ser vistos, avaliados e compreendidos.
Anlise de Riscos (9.24): Usada para avaliar riscos potenciais que possam impactar
da soluo e os custos e benefcios associados a ela.
Anlise SWOT (9.32): Demonstra como a soluo auxiliar a organizao a

maximizar foras e a minimizar fraquezas.
Avaliao de Fornecedores (9.34): Se a aquisio ou terceirizao est sendo

considerada, uma avaliao do fornecedor pode ser executada como parte do
business case.

Patrocinador: Aprova o business case e autoriza o financiamento.
Especialista no Assunto: Auxilia na estimativa dos benefcios de negcio esperados

da nova iniciativa.
Especialista na Implementao da Soluo: Auxilia na estimativa de projees de

custos para a tecnologia necessria para suportar a nova soluo.
Gerente do Projeto: Participa no desenvolvimento das estimativas de tempo e custo

e pode desenvolver um plano de projeto preliminar ou estrutura analtica do projeto
junto equipe do projeto. O gerente do projeto usar o business case como uma
entrada para o termo de abertura do projeto.
5.5.7 Sada
Business Case: Apresenta as informaes necessrias para apoiar, ou no, a deciso
para investir e ir adiante com o projeto proposto.

Anlise de Requisitos
Captulo SEIS
A rea de Conhecimento Anlise de Requisitos descreve as tarefas e tcnicas utilizadas
por um analista de negcios para analisar requisitos declarados, no intuito de definir
as capacidades requeridas de uma soluo potencial para atender s necessidades das
partes interessadas. Ela contempla a definio dos requisitos das partes interessadas
que descrevem o que uma soluo deve ser capaz de fazer para atender s necessidades
de um ou mais grupos de partes interessadas, e a definio dos requisitos da soluo que
descrevem o comportamento dos componentes da soluo, suficientemente detalhados,
para permitir que eles sejam construdos. As tarefas desta rea de conhecimento so
aplicveis tanto aos requisitos das partes interessadas quanto da soluo.
Alm disso, a anlise de requisitos pode ser conduzida para desenvolver modelos do
estado atual de uma organizao. Esses modelos de domnio so teis na validao
do escopo da soluo junto s partes interessadas do negcio e tcnicas, para
analisar o estado atual de uma organizao e identificar oportunidades de melhoria,
ou para auxiliar as partes interessadas a compreender aquele estado atual.
Nota: O desempenho de todas as atividades de anlise de requisitos governado

pelos planos da anlise de negcios (veja 2.3) e as mtricas de desempenho da anlise
de negcios devem ser rastreadas (veja 2.6).
Figura 6-1: Diagrama de Entrada/Sada da Anlise de Requisitos
Entradas
5.5 5.1 * Tarefas Sadas

Business Case Necessidade do Requisitos 6.4 6.1
6.1 6.2 6.2
Negcio
Priorizar Requisitos Organizar Requisitos
3.3 Suposies e Estrutura de Requisitos
2.5
Restries Requisitos [Priorizados]
6.3 6.4
Ativos de Plano de Preocupaes Especificar e Definir Suposies e
Processos Gerenciamento das Partes Modelar Requisitos Restries 6.6 6.5 6.3
Organizacionais de Requisitos Interessadas
Requisitos Requisitos Requisitos das
6.5 6.6 [Validados] [Verificados] Partes
2.2 5.4 Verificar Requisitos Validar Requisitos Interessadas ou
da Soluo
Lista de Partes Escopo da
Interessadas, Papis Soluo
e Responsabilidade
6.1 Priorizar Requisitos

6.1.1 Propsito
A priorizao dos requisitos garante que os esforos de anlise e implementao
estejam focados nos requisitos mais crticos.
6.1.2 Descrio
A priorizao de requisitos um processo de deciso usado para determinar a
importncia relativa dos requisitos. A importncia dos requisitos pode ser baseada
no seu valor relativo, no risco, na dificuldade de implementao ou em qualquer
outro critrio.

Priorizar Requisitos Anlise de Requisitos
Essas prioridades so usadas para determinar quais requisitos devem ser alvos de
maior anlise e para determinar quais requisitos devem ser implementados primeiro.
Figura 6-2: Diagrama de Entrada/Sada de Priorizar Requisitos

Inputs
5.5 5.1 * 2.5 2.2
Business Necessidade Requisitos Plano de Lista de Partes

Case do Negcio Gerenciamento Interessadas, Papis e
de Requisitos Responsabilidade
6.1
6.1
Requisitos
[Priorizados]

7.1
7.2
Avaliar a Soluo
Alocar Requisitos
Proposta
Gerenciamento e
7.5 Comunicao de
Validar a Soluo Requisitos
+
6.1.3 Entrada
Business Case: O business case declara as principais metas e mtricas de sucesso
para um projeto ou organizao e as prioridades devem estar alinhadas a essas
metas e objetivos.
Necessidade do Negcio: Serve como uma alternativa ao business case caso este
no tenha sido definido.
Requisitos: Qualquer requisito pode ser priorizado a qualquer momento do seu ciclo
de vida. A priorizao de requisitos pede que os requisitos tenham sido declarados
pelas partes interessadas; contudo, os requisitos podem no ter sido analisados
completamente, ou no estarem na sua forma final.

Anlise de Requisitos Priorizar Requisitos
Plano de Gerenciamento de Requisitos: Define o processo que ser usado para a

priorizao de requisitos.
Lista de partes interessadas, Papis e Responsabilidades: A lista de partes

interessadas, contendo os seus nveis de autoridade e influncia, usada para
determinar quais partes interessadas precisam participar da priorizao.
6.1.4 Elementos
.1 Bases para priorizao
Os requisitos podem ser priorizados com base em diferentes critrios, incluindo:
Valor para o Negcio: Esta abordagem prioriza requisitos com base na anlise de
custo/benefcio do seu valor relativo para a organizao. Os requisitos de maior
valor sero marcados para serem desenvolvidos primeiro. Esta abordagem comum
no aperfeioamento de uma soluo existente que j atenda aos requisitos mnimos,
ou quando se pretende entregar a soluo de forma incremental.
Risco tcnico ou de negcio: Esta abordagem seleciona os requisitos que

representam maior risco de fracasso para o projeto. Estes requisitos so investigados
e implementados primeiro para garantir que, em caso de fracasso, a organizao
tenha-se investido o mnimo possvel at este ponto.
Dificuldade de Implementao: Esta abordagem seleciona os requisitos mais

fceis de implementar. Ela frequentemente utilizada durante um piloto de um novo
processo ou ferramenta, ou na ativao de uma soluo empacotada, uma vez que
permite que a equipe se familiarize com estes processos, ferramentas ou pacotes
enquanto trabalha em requisitos de baixo risco.
Probabilidade de Sucesso: Esta abordagem foca nos requisitos que tendem a

produzir sucesso rpido e relativamente garantido. Ela comum quando um projeto
controverso e sinais rpidos de progresso so necessrios para que a iniciativa
seja apoiada.
Conformidade legal ou poltica: Esta abordagem prioriza requisitos que devem ser
implementados no intuito de atender a demandas legais ou polticas impostas na
organizao que precedem requisitos de outras partes interessadas.
Relacionamento com Outros Requisitos: Um requisito pode no possuir alto valor

por si mesmo, mas pode apoiar outros requisitos de alta prioridade e, como tal, pode
ser candidato implementao priorizada.
Acordo entre as Partes Interessadas: Esta abordagem requer que as partes

interessadas entrem em consenso sobre quais requisitos so mais teis e valiosos.
Ela frequentemente utilizada em combinao com uma ou mais das abordagens
descritas acima.
Urgncia: Esta abordagem prioriza requisitos sensveis ao tempo.
.2 Desafios
Desafios na facilitao de uma sesso de priorizao de requisitos incluem:
Demandas no-Negociveis: As partes interessadas evitam escolhas difceis,

falham em reconhecer a necessidade de se fazer trocas ou desejam classificar todos
os requisitos com alta prioridade.

Priorizar Requisitos Anlise de Requisitos
Trocas no-Realistas: A equipe de desenvolvimento da soluo pode tentar,

intencionalmente ou no, influenciar o resultado do processo de priorizao
superestimando a dificuldade ou complexidade da implementao de certos requisitos.
6.1.5 Tcnicas
.1 Tcnicas Gerais
Anlise Decisria (9.8): Anlise decisria pode ser usada para identificar requisitos
de alto valor.
Anlise de Riscos (9.24): Requisitos considerados de alto risco podem ser

investigados ou implementados no incio pois, se estes riscos levarem o projeto ao
fracasso, a organizao ter investido o mnimo possvel at este ponto.
.2 Anlise MoSCoW
A anlise MoSCoW divide requisitos em quatro categorias: Deve (Must), Deveria
(Should), Poderia (Could) e No ir (Wont) descritas a seguir:
Deve: Descreve um requisito que deve ser atendido na soluo final para que a
mesma seja considerada um sucesso.
Deveria: Representa um item de alta prioridade que deveria ser includo na soluo,
caso possvel. Trata-se frequentemente de um requisito crtico que pode ser atendido
de outras formas se for estritamente necessrio.
Poderia: Descreve um requisito que considerado desejvel, mas no necessrio, e

que ser includo caso o tempo e os recursos permitam.
No ir: Representa um requisito que as partes interessadas concordaram em no

implementar em uma determinada entrega, mas que pode ser considerado no futuro.
.3 Prazo/Oramento fixo
Prazo ou oramento fixo prioriza requisitos para investigao e implementao
baseado na alocao de um recurso pr-definido. usada quando a abordagem da
soluo j foi determinada. Prazo fixo prioriza os requisitos baseado na quantidade
de trabalho que a equipe do projeto capaz de entregar em um perodo determinado
de tempo. Por outro lado, oramento fixo usado quando uma quantidade definida de
dinheiro alocada para a equipe do projeto. Esta abordagem mais frequentemente
usada quando um prazo deve ser atendido ou quando solues so otimizadas de
forma frequente e regular. Existem algumas abordagens para determinar quais
requisitos podem ser includos dentro de uma iterao de tempo fixo:
Todos dentro: Comece com todos os requisitos elegveis de acordo com o prazo
ou oramento atribudo. Remova os requisitos no intuito de atender s datas ou
limites oramentrios.
Todos fora: Comece adicionando o(s) requisito(s) de acordo com o prazo ou

oramento atribudo. Pare quando os prazos forem atingidos ou o limite do
oramento alcanado.
Seletivo: Comece identificando requisitos de alta prioridade adicionados ao

prazo ou oramento. Adicione mais requisitos no intuito de atingir a prazo ou o
limite oramentrio.

Anlise de Requisitos Organizar Requisitos
.4 Votao
Mtodos de votao alocam uma quantidade fixa de recursos (votos, dinheiro de
brinquedo ou outras fichas) para cada participante para que eles possam distribu-
los entre as funcionalidades ou requisitos propostos. Os requisitos que receberem
mais votos sero aqueles que sero investigados ou desenvolvidos primeiro.

Especialista no assunto: Especialistas no assunto podem ser convidados a
participar da priorizao dos requisitos para avaliar as necessidades do negcio e
negociar a sua importncia.
Especialista na Implementao da Soluo: Especialistas na implementao da

soluo podem ser solicitados a avaliar a complexidade relativa ou o risco associado
com a implementao de certos requisitos.
Gerente do Projeto: O gerente do projeto responsvel pela implementao da

soluo e utilizar a prioridade dos requisitos como entrada para o plano do projeto.
Patrocinador: Uma vez que os patrocinadores so, em ltima instncia,

responsveis pela soluo de negcio e pelas principais decises do projeto, eles
precisam ser convidados para participar da discusso.
6.1.7 Sada
Requisitos [Priorizados]: Um requisito priorizado possui um atributo que descreve
sua importncia relativa para as partes interessadas e para organizao. Ao
completar esta tarefa, cada requisito deve ter sua prioridade definida. As prioridades
podem ser definidas para um requisito ou um grupo de requisitos relacionados.
6.2 Organizar Requisitos

6.2.1 Propsito
O propsito de organizar requisitos criar um conjunto de vises dos requisitos
para a nova soluo do negcio que seja abrangente, completa, consistente e
compreendida pelas partes interessadas.
6.2.2 Descrio
Existem dois objetivos-chave na organizao de requisitos.
Compreender quais modelos so apropriados para o domnio do negcio e para

o escopo da soluo.
Identificar inter-relacionamentos e dependncias entre os modelos. Requisitos

sozinhos no so complexos; so os relacionamentos e interdependncias
entre requisitos que adicionam complexidade. Desta forma, os requisitos
organizados devem tambm descrever claramente os relacionamentos
inerentes entre os requisitos.
6.2.3 Entrada
Ativos de Processos Organizacionais: Descrevem as estruturas e tipos de
informaes a respeito dos requisitos que as partes interessadas esperam.
Requisitos [Declarados]: Requisitos so declarados de vrias formas como sada

das atividades de levantamento. Requisitos declarados so desejos expressados

Organizar Requisitos Anlise de Requisitos
pelas partes interessadas que devem ser analisados para garantir que reflitam
necessidades genunas.
Escopo da Soluo: Os modelos de requisitos selecionados devem ser capazes de

descrever de forma completa o escopo da soluo a partir de todas as perspectivas
necessrias.
Figura 6-3: Diagrama de Entrada/Sada de Organizar Requisitos
Entradas
* 5.4
Ativos de Requisitos Escopo da

Processos [Declarados] Soluo
Organizacionais
6.2
Organizar
Requisitos
6.2
Estrutura de
Requisitos

4.4 6.3
Preparar o Pacote de Especificar e Modelar
6.2.4 Elementos
As orientaes a seguir iro auxiliar a promover consistncia, repetibilidade e alto
nvel de qualidade:
Siga padres organizacionais que descrevem os tipos de requisitos que sero

consistentemente usados em projetos. Caso no haja padres, o analista de
negcios deve selecionar um conjunto apropriado de tcnicas.
Use definies simples e consistentes para cada um dos tipos de requisitos

descritos em linguagem natural, utilizando-se da terminologia de negcios que
prevalece na empresa.
Documente dependncias e inter-relacionamentos entre requisitos.
Produza um conjunto consistente de modelos para documentar os requisitos

conforme descrito em Especificar e Modelar Requisitos (6.3).

Anlise de Requisitos Organizar Requisitos
Os vrios nveis de abstrao e modelos usados no so mutuamente exclusivos.

Ser frequentemente benfica a criao de mltiplos modelos e perspectivas dos
requisitos no intuito de garantir a compreenso. Entretanto, cada requisito deve
aparecer em apenas um modelo para evitar desordem e contradies.
.1 Nveis de Abstrao
Os requisitos podem ser articulados em diferentes nveis de abstrao. Os requisitos
so frequentemente descritos como precisando dizer o que precisa ser feito e no
como faz-lo. Esta formulao pode ser problemtica, pois o fato de algo ser um
o que ou um como depende da perspectiva do pblico. Por exemplo, a deciso de
implementar um mecanismo de gerenciamento de processos de negcio pode ser o
que ns estamos fazendo (da perspectiva da equipe do projeto) e como ns estamos
melhorando nossa agilidade nos processos (da perspectiva do grupo de arquitetura
corporativa). Na prtica da anlise de negcios ns podemos distinguir o o que do
como compreendendo que nossa perspectiva da diferena entre esses termos precisa
ser alinhada com a perspectiva das partes interessadas do negcio.
Existem algumas estruturas formais para nveis de abstrao, incluindo aquelas

delineadas nos frameworks da arquitetura corporativa. Alternativamente, o analista
de negcios pode definir, de modo informal, um conjunto de requisitos como sendo
de nvel alto ou baixo, baseado no nvel de detalhe includo. Frequentemente,
requisitos tornam-se menos abstratos, conforme o analista de negcios define
requisitos do negcio, das partes interessadas e da soluo. Mas nem sempre toda
categoria de requisitos pode ser expressa em qualquer que seja o nvel de abstrao
apropriado para o pblico. As metodologias podem tambm determinar o nvel de
abstrao usado na definio de requisitos.
.2 Seleo de Modelos
O analista de negcios deve determinar quais tipos de modelos sero requeridos
para descrever o escopo da soluo e atender s necessidades de informao das
partes interessadas. Essas necessidades podem variar ao longo do tempo.
Modelos abstraem e simplificam a realidade. Nenhum modelo pode ser uma

descrio completa da realidade; o objetivo de desenvolver um modelo o de
simplificar a realidade de uma maneira que seja til. Cada modelo representa uma
viso diferente dentro da realidade do domnio do negcio. geralmente necessrio
desenvolver mltiplos modelos, usando diferentes tcnicas de modelagem para
analisar e documentar requisitos de forma completa.
Os modelos no possuem nenhuma hierarquia inerente uma anlise eficaz pode

potencialmente ser iniciada atravs de qualquer aspecto do modelo e se estender
para alcanar os demais. Por exemplo, a anlise de casos de uso pode comear
com metas ou eventos e capturar processos e regras relevantes. Gerenciamento de
Processos de Negcios (BPM) comea identificando processos e ento deriva papis,
eventos e regras desses processos.
Existem alguns conceitos gerais de modelagem que so relevantes para a anlise de

negcios:
Classes de Usurios, Perfis ou Papis. Esses modelos categorizam e descrevem as

pessoas que interagem diretamente com uma soluo. Cada papel agrupa pessoas
com necessidades, expectativas e metas similares. Cada papel tende a corresponder a
uma parte interessada e deve ser investigada como uma fonte de requisitos. Elas so
geralmente identificadas na ao de Conduzir a Anlise das Partes Interessadas (2.2)

Organizar Requisitos Anlise de Requisitos
e so usadas em diversos modelos de anlise, particularmente em Modelagem da

Organizao (9.19), Modelagem de processos (9.21) e Casos de uso (9.26).
Conceitos e Relacionamentos. Conceitos geralmente correspondem a algo do

mundo real, como um lugar, uma pessoa, uma coisa, uma organizao. Eles definem
os objetos, entidades ou fatos que so relevantes para o domnio do negcio e quais
relacionamentos eles possuem com outros conceitos. Modelagem de dados (9.7)
aborda os conceitos, alm de descrever os atributos relacionados a cada conceito.
Eventos. Uma requisio para que um sistema de negcio ou uma organizao

faa algo como, por exemplo, um cliente efetuando uma compra ou um gerente
solicitando um relatrio, pode ser descrita como um evento. Uma organizao deve
responder a um evento e na maioria dos casos um evento ir disparar ou afetar um
processo de negcio. Eventos podem ter sua origem fora da rea de negcios, dentro
dela ou ocorrer em momentos agendados. Eventos podem servir como a base para
a modelagem de escopo (9.27) e podem ser descritos em outros modelos, incluindo
modelagem de processos (9.21), diagramas de estados (9.29) e casos de uso (9.26).
Processos. Processos so uma sequncia de atividades repetveis, executadas dentro

de uma organizao. Processos podem ser simples (envolvendo uma pessoa e um
sistema) ou complexos (envolvendo muitas pessoas, departamentos, organizaes
e sistemas). Processos descrevem quem e o que deve estar envolvido na resposta
completa para um evento, ou como as pessoas na empresa colaboram para atingir
uma meta. Processos so normalmente descritos em modelagem de processos (9.21),
entretanto, informaes teis podem ser capturadas tambm em modelagem da
organizao (9.9), diagramas de estados (9.29) ou casos de uso (9.26).
Regras. Regras so usadas pela empresa para reforar metas e guiar tomadas de
deciso. Elas determinam quando a informao associada a uma entidade pode
mudar, quais valores da informao so vlidos, como as decises so tomadas
em um processo e quais so as prioridades da organizao. Regras de negcios
so normalmente descritas como tais, contudo elas podem estar inseridas em
modelagem de processos (9.21), diagramas de estados (9.29) ou casos de uso (9.26).
Escolha o conjunto de tcnicas de modelagem que atendam s necessidades de

informao das partes interessadas e que permitam a descrio de todos os cinco
conceitos para garantir uma cobertura total do domnio do negcio (assumindo-se
que esta cobertura total seja requerida).
6.2.5 Tcnicas
Anlise de Regras de Negcios (9.4): Regras de negcios podem estar separadas de
outros requisitos para implementao e gerenciamento em um mecanismo de regras
de negcio ou algo similar.
Diagramas de Fluxo de Dados (9.6): Apresenta como a informao flui atravs de

um sistema. Cada funo que modifica a informao deve ser decomposta em nveis
menores at que o sistema esteja suficientemente descrito.
Modelagem de Dados (9.7): Descreve os conceitos e relacionamentos relevantes

para a soluo ou domnio do negcio.
Decomposio Funcional (9.12): Decompe uma unidade organizacional, um

escopo de produto ou algo semelhante em componentes menores. Cada parte pode
ter os seus prprios conjuntos de requisitos.

Anlise de Requisitos Especificar e Modelar Requisitos
Modelagem da Organizao (9.19): Descreve as diversas unidades organizacionais,

partes interessadas e seus relacionamentos. Requisitos podem ser estruturados em
torno das necessidades de cada parte interessada ou grupo.
Modelagem de Processos (9.21): Requisitos podem ser organizados em torno de

processos relevantes. Os processos em si podem conter subprocessos e descrever
uma hierarquia indo do nvel mais alto, do processo de ponta a ponta, at as
atividades individuais de mais baixo nvel.
Cenrios e Casos de Uso (9.26): Descreve os requisitos que suportam as metas

individuais de cada ator ou a resposta para o evento disparador.
Modelagem do Escopo (9.27): Requisitos podem ser organizados com base nos
componentes aos quais eles esto relacionados.
Histrias do Usurio (9.33): Descreve os objetivos das partes interessadas que a

soluo ir suportar.

Especialista no Assunto, Usurio Final, Especialista na Implementao
da Soluo e Patrocinador: Afetados pelas tcnicas usadas para organizar os
requisitos, uma vez que eles precisam verific-los e valid-los. O analista de negcios
adapta a abordagem para atender s necessidades dos principais grupos de partes
interessadas e deve determinar quais modelos sero teis para cada um.
Gerente do Projeto: Utiliza o conjunto organizado de requisitos para verificar o

escopo da soluo e avaliar o trabalho que precisa ser feito no projeto.
6.2.7 Sada
Estrutura de Requisitos: A sada desta tarefa uma estrutura organizada de
requisitos e um conjunto documentado de relacionamentos entre eles. Esta
estrutura distinta do rastreamento que vincula requisitos relacionados; neste caso,
ela usada para que o analista e as partes interessadas saibam onde um requisito
especfico deve ser encontrado. Cada modelo ou conjunto de requisitos dentro da
estrutura deve possuir um escopo implcito claro, isto , deve ser claro para as partes
interessadas o que um modelo ir, ou no, descrever.
6.3 Especificar e Modelar Requisitos

6.3.1 Propsito
Analisar os desejos expressos pelas partes interessadas e/ou o estado atual da
organizao usando uma combinao de declaraes textuais, matrizes, diagramas
e modelos formais.
6.3.2 Descrio
Especificaes e modelos so criados para analisar o funcionamento de uma
organizao e para prover insights sobre oportunidades de melhoria. Eles tambm
apoiam outros objetivos, incluindo o desenvolvimento e implementao de solues,
facilitao da comunicao entre as partes interessadas, apoio a atividades de
treinamento e gerenciamento do conhecimento e garantia do atendimento a
contratos e regulamentos.
As especificidades desta tarefa so altamente dependentes das tcnicas usadas para

especificar e modelar requisitos.

Especificar e Modelar Requisitos Anlise de Requisitos
6.3.3 Entrada
Requisitos [Declarados]: Especificao ou modelagem de requisitos
desempenhada para estruturar e aperfeioar a compreenso das necessidades
expressadas pelas partes interessadas.
Estrutura de Requisitos: Define como o requisito se encaixa dentro do conjunto

geral de requisitos e quais outros conjuntos de requisitos podem incluir informaes
relacionadas.
Figura 6-4: Diagrama de Entrada/Sada de Especificar e Modelar Requisitos

Entradas
3.3 6.2
Requisitos Estrutura de
[Declarados] Requisitos
6.3
Especificar e Modelar
Requisitos
6.3
Requisitos
[Analisados]

6.5 Gerenciamento e
6.1 Verificar Requisitos Comunicao de
Priorizar Requisitos Requisitos
+
6.3.4 Elementos
.1 Texto
Um requisito textual deve descrever as capacidades da soluo, quaisquer condies
que devam existir para o requisito operar e quaisquer restries que possam impedir
que a soluo atenda ao requisito. Guias para a escrita de requisitos textuais incluem:
Expressar um e somente um requisito de cada vez.
Evitar clusulas condicionais complexas.
No assumir que o seu leitor possui conhecimento do domnio.

Anlise de Requisitos Especificar e Modelar Requisitos
Usar terminologia consistente.
Expressar requisitos como um verbo ou frase verbal.
Escrev-los em voz ativa, descrevendo claramente quem ou o qu responsvel

por atender ao requisito.
Usar terminologia familiar s partes interessadas que devem revisar ou usar o

requisito.
.2 Documentao em Matriz
Tabelas so a forma mais simples de uma matriz. Tabelas so usadas quando o
analista de negcios procura comunicar um conjunto de requisitos que possui uma
estrutura complexa, mas uniforme, que pode ser decomposta em elementos que se
aplicam a cada entrada na tabela.
Atributos dos requisitos e dicionrios de dados so geralmente expressos em forma

tabular. As matrizes so frequentemente usadas para rastreabilidade dos requisitos
entre si, dos requisitos aos casos de testes e para anlise de gaps (lacunas). As
matrizes so tambm utilizadas para a priorizao de requisitos atravs do seu
mapeamento em relao aos objetivos do projeto.
Uma matriz mais complexa ir tambm expressar informaes nas linhas da tabela.
No lugar de apresentar informao repetida, esta forma de matriz geralmente
voltada a indicar que dois elementos so relacionados de alguma maneira (por
exemplo, que um requisito afeta um elemento particular de dados).
.3 Modelos
Formatos de Modelagem
Um modelo qualquer representao simplificada de uma realidade complexa,
sendo til para a compreenso e tomada de deciso no contexto dessa realidade.
Modelos podem ser tanto textuais como grficos, ou uma combinao das duas
formas. Modelos grficos so frequentemente chamados de diagramas.
A escolha de quais modelos sero utilizados para um conjunto particular de

requisitos determinada pelo tipo de informao a ser comunicada como tambm
pelo pblico que ir consumir a informao. Os modelos podem:
Descrever uma situao ou definir um problema
Definir as fronteiras dos domnios e subdomnios do negcio e descrever os

componentes dentro de cada fronteira definida
Descrever processos de pensamento e fluxos de ao
Categorizar e criar hierarquias de itens
Apresentar componentes e seus relacionamentos
Apresentar a lgica do negcio
O fato de um diagrama ser, ou no, utilizado no lugar de uma descrio textual

frequentemente determinado pelo pblico da informao, como tambm pelo nvel
de detalhe em um modelo particular.

Especificar e Modelar Requisitos Anlise de Requisitos
Os modelos podem ser usados no somente para documentar requisitos na sua

forma final, mas tambm como uma ferramenta durante a execuo das atividades
de elicitao.
Notaes
Descrevem qualquer smbolo ou notao usada. Nos diagramas frequentemente
significa a incluso de uma legenda que auxilia na interpretao dos smbolos e/ou
cores utilizadas, ou a referncia a um padro externo.
Modelos Formais versus Modelos Informais

Um modelo formal segue uma semntica e uma iconografia - definidas dentro de
um padro para cada elemento do modelo. Um modelo formal pode frequentemente
transmitir uma grande quantidade de informao, mas algumas sutilezas do modelo
podem no ser propriamente transmitidas para um pblico no familiarizado com
a notao especfica.
Um modelo informal no possui uma definio de semntica formal, mas, por outro
lado, conecta elementos de forma significativa para o analista e para o pblico.
Embora o modelo possa ser menos expressivo, ele no requer treinamento especial
para ser interpretado.
.4 Capturar Atributos dos Requisitos

Conforme cada requisito ou conjunto de requisitos especificado e modelado,
os atributos relevantes que foram selecionados na ao de Planejar o Processo de
Gerenciamentos dos Requisitos (2.5) devem ser capturados.
.5 Oportunidades de Melhoria
Analistas devem trabalhar para identificar oportunidades de melhoria na operao
do negcio. Alguns exemplos comuns de oportunidades que um analista tende a
identificar incluem:
Automatizar ou Simplificar o Trabalho que as Pessoas Desempenham: Tarefas

relativamente simples, onde decises so tomadas com base em regras rigorosas e
inflexveis, so as principais candidatas para automao.
Melhorar o Acesso Informao: Prover maior quantidade de informao para a

equipe que interage diretamente ou indiretamente com clientes, reduzindo ento a
necessidade de especialistas. Tomadores de deciso podem no requerer este nvel
de detalhe, mas devem saber onde e com quem podem conseguir a informao, se
necessrio. Normalmente, tomadores de deciso precisam ser informados a respeito
do significado e relevncia dos dados adquiridos e usados pela equipe operacional.
Reduzir a Complexidade das Interfaces: Interfaces so necessrias sempre que o

trabalho transferido entre sistemas ou entre pessoas. Reduzir sua complexidade
pode aperfeioar a compreenso.
Aumentar a Consistncia do Comportamento: Trabalhadores diferentes podem

atuar em casos similares de formas bastante diversas, causando insatisfao e
frustrao dos clientes.
Eliminar Redundncia: Diferentes grupos de partes interessadas podem possuir

necessidades comuns que podem ser atendidas com uma mesma soluo, reduzindo
o custo de implementao.

Anlise de Requisitos Definir Suposies e Restries
6.3.5 Tcnicas
.1 Tcnicas Gerais
Tcnicas que podem ser usadas para especificar ou modelar requisitos incluem:
Definio dos Critrios de Aceite e de Avaliao (9.1)
Anlise de Regras de Negcios (9.4)
Dicionrio de Dados e Glossrio (9.5)
Diagramas de Fluxo de Dados (9.6)
Modelagem de Dados (9.7)
Decomposio Funcional (9.12)
Anlise de Interfaces (9.13)
Mtricas e Indicadores-Chave de Desempenho (9.16)
Anlise de Requisitos No-Funcionais (9.17)
Modelagem da Organizao (9.19)
Modelagem de Processos (9.21)
Prototipagem (9.22)
Cenrios e Casos de Uso (9.26)
Diagramas de Sequncia (9.28)
Diagramas de Estados (9.29)
Histrias de Usurios (9.33)

Qualquer Parte Interessada: O analista de negcios pode escolher desempenhar
sozinho esta tarefa e, ento, empacotar e comunicar separadamente os requisitos
para as partes interessadas para a sua reviso ou aprovao. O analista de negcios
pode ainda convidar algumas ou todas as partes interessadas a participar dessa
tarefa (dependendo de quais requisitos esto sendo analisados, a abordagem da
anlise de negcios, as preferncias do analista de negcios e outros fatores).
6.3.7 Sada
Requisitos [Analisados]: Requisitos modelados e especificados so produzidos
nessa tarefa.
6.4 Definir Suposies e Restries

6.4.1 Propsito
Identificar fatores, alm dos requisitos, que podem afetar quais solues so viveis.

Definir Suposies e Restries Anlise de Requisitos
6.4.2 Descrio
Suposies so fatores que se acredita serem verdadeiros, mas que no foram
confirmados. Suposies podem afetar todos os aspectos do projeto e trazer certo
grau de risco, caso no se comprovem verdadeiros. O analista de negcios identifica
e documenta suposies, tentativas de confirmar a acuidade das suposies e
identifica e gerencia os riscos relacionados habilidade de uma soluo atender
Restries so definidas como limitaes s solues possveis. O analista de negcios

responsvel por documentar quaisquer restries ou limitaes do desenho da
soluo, construo, testes, validao e implantao. Restries da soluo descrevem
aspectos do estado atual ou do estado futuro planejado que no podem ser mudados.
Elas no so requisitos, uma vez que no so implementadas de nenhuma forma pela
equipe do projeto. Restries so comunicadas equipe do projeto para inform-la
quais opes que normalmente poderiam ser consideradas e no esto disponveis.
Suposies e restries so geralmente documentadas com seus atributos (ex.: data

da identificao, dono, impacto, risco associado e outras informaes explanatrias),
sendo definidas e esclarecidas conforme os requisitos so compreendidos. Em muitos
casos, requisitos de baixo nvel podem ser dependentes e, portanto, rastreados a
partir da presena de uma suposio ou restrio. Dessa forma os requisitos podem
ser afetados caso a suposio se prove falsa ou a restrio seja alterada.
6.4.3 Entrada
Preocupaes das Partes Interessadas: Suposies e restries so identificadas
atravs da elicitao junto s partes interessadas.
6.44. Elementos
.1 Suposies
Uma suposio qualquer coisa na qual se acredita ser verdade, mas que no foi
verificada de fato. Suposies podem estar relacionadas a qualquer coisa no presente
ou no futuro. Suposies devem ser documentadas e, se alguma suposio for
provada como falsa, geralmente ir impactar o projeto de alguma forma. Portanto,
suposies so potenciais fontes de risco ao projeto. Suposies podem tambm
refletir uma compreenso de como os resultados desejados tendem a ser alcanados.
Por exemplo, as partes interessadas podem acreditar que os clientes respondero de
uma determinada forma a uma mudana na qual um produto entregue, mas pode
haver apenas indcios superficiais apoiando esta crena.
.2 Restries do Negcio
Restries do negcio descrevem limitaes s solues disponveis ou um aspecto
do estado atual que no pode ser mudado atravs da implantao da nova soluo.
Elas podem refletir restries oramentrias, de tempo, limites no nmero de
recursos disponveis, restries baseadas nas habilidades da equipe do projeto e
das partes interessadas, um requisito para que certas partes interessadas no sejam
afetadas pela implementao da soluo, ou qualquer outra restrio organizacional.
Restries precisam ser cuidadosamente examinadas para garantir que estejam
corretas e justificadas.
.3 Restries Tcnicas
Restries tcnicas incluem quaisquer decises de arquitetura tomadas que podem
impactar o desenho da soluo. Elas podem incluir linguagens de desenvolvimento,

Anlise de Requisitos Definir Suposies e Restries
plataformas de hardware e software, e aplicativos de software que devem ser

utilizados. Restries tcnicas podem tambm descrever restries como uso de
recursos, tamanhos e momentos das mensagens, tamanho do software, quantidade e
tamanhos mximos de arquivos, registros e elementos de dados. Restries tcnicas
incluem quaisquer padres de arquitetura corporativa que devam ser seguidos.
Restries tcnicas podem criar uma situao onde um requisito no possa ser
atendido usando a abordagem atual ou um componente da soluo. O analista de
negcios deve trabalhar com a equipe do projeto para identificar outras maneiras de
atender necessidade do negcio associada.
6.4.4 Tcnicas
Rastreamento de Problemas (9.20): Tanto suposies quanto restries so
frequentemente identificadas e gerenciadas usando atividades contnuas de
planejamento, monitoramento e gerenciamento de questes/riscos da equipe do projeto.
Anlise de Riscos (9.24): Avalia o risco (tanto positivo quanto negativo) de uma
suposio se provar invlida ou se uma restrio for removida.

Figura 6-5: Diagrama de Entrada/Sada de Definir Suposies e Restries
Entradas
3.3
Preocupaes das
Partes
Interessadas
6.4
Definir Suposies e
Restries
6.4
Suposies e
Restries
5.4 5.5
Definir o Escopo da Definir o Business
Soluo Case
7.1 Gerenciamento e
Avaliar a Soluo Comunicao de
Proposta Requisitos
+

Verificar Requisitos Anlise de Requisitos

Especialista em Implementao da Soluo: Deve levar em conta as suposies e
as restries ao desenhar uma soluo.
Gerente do Projeto: Deve avaliar suposies e restries para identificar riscos

potenciais que possam impactar a entrega do projeto e gerenciar restries de
cronograma, custos e recursos.
Todas as Partes Interessadas: A parte interessada responsvel pela definio de

uma suposio ou restrio em particular deve ser envolvida em qualquer discusso
que implique na sua mudana. Uma vez que suposies e restries podem afetar
e/ou se originar de qualquer parte interessada, todas devem estar envolvidas na
identificao das suposies ou restries.
6.4.6 Sada
Suposies e Restries: Suposies e restries iro limitar as potenciais
opes de soluo e tero as suas possveis mudanas monitoradas. Mesmo no
sendo tecnicamente consideradas como requisitos, elas podem ser gerenciadas
e comunicadas atravs da execuo das tarefas do Captulo 4: Gerenciamento e
Comunicao de Requisitos.
6.5 Verificar Requisitos

6.5.1 Propsito
A verificao de requisitos garante que as especificaes e modelos de requisitos
atendam ao padro necessrio de qualidade para permitir que sejam usados de
forma efetiva para guiar o trabalho futuro.
6.5.2 Descrio
Verificar requisitos garante que os mesmos foram definidos corretamente, isto ,
que eles possuem uma qualidade aceitvel. Requisitos que no atendem aos padres
de qualidade so defeituosos e devem ser revisados. A verificao de requisitos
constitui-se de uma checagem final executada pelo analista de negcios e principais
partes interessadas para determinar que os requisitos estejam:
Prontos para reviso e validao formal pelos clientes e usurios;
Provendo toda a informao necessria para o trabalho que ser realizado

baseado nos requisitos.
6.5.3 Entrada
Requisitos [Exceto os Declarados]: Qualquer requisito pode ser verificado
(incluindo os de negcio, das partes interessadas, da soluo e de transio). Verificao
uma checagem da qualidade executada, seguida da anlise de um requisito.
6.5.4 Elementos
O analista de negcios verifica se os requisitos foram especificados em declaraes
de requisitos bem escritas.
.1 Caractersticas da Qualidade dos Requisitos

Um requisito de alta qualidade apresenta, no mnimo, as seguintes caractersticas:

Anlise de Requisitos Verificar Requisitos
Figura 6-6: Diagrama de Entrada/Sada de Verificar Requisitos
Entradas
*
Requisitos
[Exceto os
Declarados]
6.5
Verificar Requisitos
6.5
Requisitos
[Verificados]

Gerenciamento e
Comunicao de 6.6
Requisitos Validar Requisitos
+
Coeso: Um conjunto coeso de requisitos est relacionado a apenas uma coisa, seja
ela um processo de negcio, regra de negcio, unidade organizacional, etc. Todos os
requisitos, em um conjunto ou modelo, devem apoiar o seu propsito e escopo geral.
Completude: O conjunto total de requisitos deve representar todos os requisitos

relevantes. Alm disso, todo requisito individual deve ser completo. Garantia de que
cada requisito seja autocontido, sem nenhuma informao faltante.
Consistncia: Garantia de que os requisitos individuais no conflitem entre si ou que

descrevam o mesmo requisito utilizando palavreado diferente. Alm disso, o nvel de
detalhes fornecido por cada requisito, em um conjunto ou modelo, deve ser o mesmo.
Correo: Defeitos nos requisitos levaro a defeitos na soluo resultante.
Viabilidade: Cada requisito deve ser implementvel dentro da infraestrutura

existente, dentro do oramento existente, prazo e recursos disponveis para a equipe
(ou o projeto deve desenvolver a capacidade para implementar o requisito). O analista
de negcios precisa trabalhar junto equipe do projeto para tomar essas decises.
Ajustabilidade/adaptao: Requisitos inter-relacionados devem ser mantidos

agrupados a fim de se tornem modificveis. Essa caracterstica demonstrada
atravs de uma estruturao lgica dos requisitos.
No Ambiguidade: Requisitos individuais nunca podem ser pouco claros. Um requisito

no pode permitir a formao de mltiplas e divergentes interpretaes vlidas.

Verificar Requisitos Anlise de Requisitos
Testabilidade: Deve haver uma forma de provar que um requisito foi atendido. Cada
requisito deve ser testvel isto , deve ser possvel desenhar um teste que possa ser
usado para determinar se uma soluo atendeu ao requisito, ou utilizar algum outro
meio de determinar o aceite, ou no, de uma soluo que atende ao requisito.
.2 Atividades de Verificao
Atividades de verificao so tipicamente desempenhadas iterativamente ao longo
do processo de anlise de requisitos. Atividades de verificao incluem:
Checar a completude dentro de cada modelo de requisitos. Por exemplo,

diagramas de fluxo de dados iro possuir todos os componentes e fluxos de
dados rotulados com suas respectivas setas indicando a direo.
Comparar cada modelo de requisitos preparado (textual ou grfico) com os demais

modelos de requisitos preparados. Checar elementos que so mencionados em um
modelo e que esto faltando em outros. Tambm checar se o mesmo componente
referenciado da mesma forma em todos os modelos por exemplo, uso de linguagem
consistente, ex.: cliente e consumidor. Resolver todas as discrepncias, corrigindo a
terminologia ou adicionando/removendo componentes, conforme necessrio.
Garantir que todas as variaes dos processos documentados foram

identificadas e documentadas. Dar ateno especial lgica de ramificao
bsica ex.: nenhum encontrado, um e apenas um encontrado, ou mais de
um encontrado.
Garantir que todos os gatilhos e resultados foram levados em considerao em

todas as variaes.
Garantir que a terminologia utilizada na expresso dos requisitos

compreensvel pelas partes interessadas e consistente com o uso dos termos
dentro da organizao.
Adicionar exemplos onde for apropriado para esclarecer e reforar o business case.
6.5.5 Tcnicas
.1 Tcnicas Gerais
Definio dos Critrios de Aceite e Avaliao (9.1): Garantir que os requisitos
esto declarados de forma suficientemente clara para a elaborao de um conjunto
de testes que podem provar que os requisitos foram atendidos.
Rastreamento de Problemas (9.20): Pode ser utilizado para garantir que quaisquer
problemas identificados durante a verificao estejam resolvidos.
Revises estruturadas (9.30): Utilizadas para identificar requisitos ambguos ou

no-claros na documentao de requisitos.
.2 Checklists
Checklists so teis como uma tcnica de controle da qualidade para a documentao
dos requisitos. Eles podem incluir um conjunto padro de elementos de qualidade
que o analista de negcios, ou outros revisores, usam para validar os requisitos, ou
ser desenvolvidos especificamente para capturar questes relacionadas ao projeto.
O propsito de um checklist garantir que itens entendidos como importantes pela
organizao ou pela equipe do projeto estejam includos na (s) entrega (s) final(is),
ou que os passos do processo que a organizao ou a equipe do projeto tenham

Anlise de Requisitos Validar Requisitos
determinado que devam ser seguidos foram abordados. Checklists podem tambm
ser desenvolvidos dentro do projeto para auxiliar na garantia da consistncia da
abordagem e resultados, particularmente em projetos grandes, onde mltiplas
equipes de subprojetos esto trabalhando.

Todas as Partes Interessadas: O analista de negcios, em conjunto com os
especialistas dos domnios tcnicos e do negcio, possui a responsabilidade primria
de determinar que esta tarefa foi completada. Outras partes interessadas podem
descobrir requisitos problemticos durante a comunicao dos requisitos. Portanto,
virtualmente, todas as partes interessadas do projeto esto envolvidas nesta tarefa.
6.5.7 Sada
Requisitos [Verificados]: Requisitos verificados so de qualidade suficiente para
permitir que o trabalho futuro, baseado nestes requisitos, seja executado.
6.6 Validar Requisitos

6.6.1 Propsito
O propsito da validao dos requisitos garantir que todos os requisitos entreguem
valor para o negcio, cumpram suas metas e objetivos e satisfaam a uma
necessidade de uma parte interessada.
Figura 6-7: Diagrama de Entrada/Sada de Validar Requisitos
Entradas
5.5 6.5
Business Case Requisitos das Partes

Interessadas, da Soluo
ou de Transio
[Verificados]
6.6
Validar Requisitos
6.6
Requisitos
[Validados]

Gerenciamento e
Comunicao de 7.5
Requisitos Validar a Soluo
+

Validar Requisitos Anlise de Requisitos
6.6.2 Descrio
Validao de requisitos um processo contnuo para garantir que os requisitos das partes
interessadas, da soluo e de transio, estejam alinhados aos requisitos do negcio.
Avaliar qual ser o resultado para a parte interessada quando a sua necessidade for
satisfeita pode ser til na validao dos requisitos. A implementao dos requisitos
como um todo deve ser suficiente para atingir o estado futuro desejado para clientes e
usurios. Em muitos casos, partes interessadas possuem necessidades e expectativas
diferentes ou conflitantes e que podem ser expostas atravs do processo de validao
para serem reconciliadas. Veja Gerenciar o Escopo e os Requisitos da Soluo (4.1).
6.6.3 Entrada
Business Case: O business case descreve os objetivos e medidas gerais do negcio
que se espera que a soluo entregue. Para ser vlido, um requisito deve contribuir
diretamente ou indiretamente para o business case. Outros requisitos do negcio,
incluindo a necessidade do negcio, capacidades requeridas e o escopo da soluo
podem tambm ser usados para validao.
Requisitos das Partes Interessadas, da Soluo ou de Transio [Verificados]:

Requisitos precisam estar verificados para que a validao seja completada. Caso
um requisito no possa ser verificado, ele no pode ser implementado com xito e,
ento, no pode atender a uma necessidade do negcio. Contudo, as atividades de
validao podem ser iniciadas antes que os requisitos estejam todos verificados.
6.6.4 Elementos
.1 Identificar Suposies
Em muitos casos pode no ser possvel provar que a implementao do requisito
resultar no benefcio desejado. Se uma organizao est lanando um produto ou
servio sem precedentes, pode ser necessrio criar suposies a respeito da resposta
dos clientes ou das partes interessadas, uma vez que no h experincias similares
nas quais se possa basear. Em outros casos, pode ser difcil ou impossvel provar que
um problema particular derive de uma causa-raiz identificada. Partes interessadas
podem ter assumido que certos benefcios iro resultar da implementao de um
requisito e essas suposies devem ser identificadas e definidas, de forma que os
riscos associados possam ser gerenciados. Veja Definir Suposies e Restries (6.4).
.2 Definir Critrios de Avaliao Mensurveis

Enquanto os benefcios previstos do negcio so definidos no business case, os
critrios de medio e processos de avaliao especficos podem no ter sido
includos. Seguindo a definio dos benefcios que iro resultar da implementao de
um requisito, necessrio definir o critrio de avaliao que ser usado para avaliar
quanto sucesso a mudana resultante teve, uma vez que a soluo seja implantada.
(Veja Mtricas e Indicadores Chave de Desempenho (9.16), para informaes sobre
a seleo dos critrios apropriados, e Avaliar o Desempenho da Soluo (7.6), para
detalhes sobre como essa avaliao realizada aps a implementao).
.3 Determinar o Valor para o Negcio

O business case, alm de definir o valor entregue por uma soluo que atenda ao seu
escopo, tambm possibilita avaliar requisitos ou funcionalidades individualmente para
determinar se os mesmos tambm entregam valor para o negcio. Especificar e Modelar
Requisitos (6.3) esboa algumas maneiras atravs das quais um requisito pode entregar
valor para o negcio. Um requisito que no entrega valor direto ou indireto para uma
parte interessada um forte candidato eliminao. O valor no precisa ser monetrio.

Anlise de Requisitos Validar Requisitos
Valor para o negcio pode ser entregue atravs de requisitos que apoiam a conformidade
com regulamentos ou outros padres, alinhamento junto a padres e polticas internas
da organizao ou que aumentam a satisfao das partes interessadas, mesmo se essas
coisas no possurem um benefcio financeiro direto mensurvel.
.4 Determinar Dependncias para a Realizao dos Benefcios

Nem todos os requisitos contribuem diretamente para o resultado final desejado
pela organizao e descrito no business case. Veja Gerenciar a Rastreabilidade dos
Requisitos (4.2) para os tipos de relacionamentos que podem existir.
.5 Avaliar o Alinhamento com o Business Case e com o Custo da Oportunidade

Um requisito pode ter valor para uma parte interessada e ainda assim no ser uma parte
desejvel de uma soluo. Um requisito que no est alinhado ao business case deve
ser definido e aprovado em um business case parte, ou considerado para remoo do
escopo da soluo. Em ltima anlise, cada requisito deve ser rastrevel at os objetivos
no business case e deve tambm minimizar o custo da oportunidade da implementao.
No nvel do projeto, o custo da oportunidade refere-se aos benefcios que poderiam ser
atingidos com um investimento alternativo no lugar do investimento que est sendo
feito. Em outras palavras, o custo do que voc no pode fazer, ou ter, porque decidiu
investir neste projeto ao invs de investir em outro. Este conceito pode tambm ser
aplicado a decises feitas dentro de um projeto. Por exemplo, se uma equipe de projeto
investe tempo e energia implementando uma funcionalidade em uma aplicao de
software, este esforo no pode ser aplicado em testes adicionais, treinamento para
os usurios, resoluo de bugs ou outro trabalho do projeto. Este trabalho perdido
representa o custo da oportunidade da deciso. O custo da oportunidade de qualquer
deciso igual ao valor do melhor uso alternativo desses recursos.
6.6.5 Tcnicas
Definio dos Critrios de Aceite e Avaliao (9.1): Critrios de aceite so as
mtricas de qualidade que devem ser cumpridas para conquistar a aceitao pelas
Mtricas e Indicadores-Chave de Desempenho (9.16): Usadas para selecionar medidas

apropriadas de desempenho para uma soluo, componente de soluo ou requisito.
Prototipao (9.22): Prototipao dos componentes do produto usada para

conseguir o de acordo do usurio em relao soluo proposta.
Anlise de Riscos (9.24): Anlise de riscos pode ser usada para identificar cenrios
possveis que alterariam o valor entregue por um requisito.
Revises Estruturadas (9.30): Reunies de reviso so conduzidas para confirmar

se as partes interessadas concordam que as suas necessidades foram atendidas.

Todas as Partes Interessadas: Virtualmente todas as partes interessadas so
envolvidas ou impactadas pelas atividades de validao.
6.6.7 Sadas
Requisitos [Validados]: Requisitos validados so aqueles que podem demonstrar
que entregam valor para as partes interessadas e que esto alinhados com as metas
e objetivos do negcio. Se um requisito no pode ser validado, ele no beneficia a
organizao, no se enquadra no escopo da soluo, ou ambos.

Avaliao e Validao da Soluo
Captulo SETE
A rea de Conhecimento Avaliao e Validao da Soluo descreve as tarefas que so
executadas para garantir que as solues encontradas atendam necessidade do negcio
e para facilitar o sucesso em sua implementao. Essas atividades podem ser executadas
para avaliar e validar processos de negcio, estruturas organizacionais, acordos de
terceirizao, aplicaes de software e quaisquer outros componentes da soluo.
A anlise de negcio desempenha um papel vital na garantia de que o processo

de reviso, seleo e desenho da soluo realizado de uma forma que maximize
o valor entregue para as partes interessadas. O analista de negcio conhece o
ambiente do negcio e pode avaliar como cada soluo proposta poderia afetar
esse ambiente. O analista de negcio responsvel por garantir que as partes
interessadas compreendam totalmente os requisitos da soluo e que as decises de
implementao estejam alinhadas com os requisitos relevantes.
Nota: a execuo de todas as atividades de avaliao e validao da soluo

dirigida pelos planos da anlise de negcio (veja 2.3) e mtricas de desempenho da
anlise de negcio devem ser rastreadas (veja 2.6).
Figura 7-1: Diagrama de Entrada/Sada da Avaliao e Validao da Soluo

Entradas Sadas
6.4 * 7.1 7.5 7.5

Tarefas
Suposies e Arquitetura Requisitos Avaliao da Defeitos Aes de
7.1 Mitigao
Restries Corporativa 7.2 Soluo Identificados
Avaliar a Soluo
Alocar Requisitos Proposta
Proposta
7.3 7.2 7.4
7.3 7.4
Soluo Alternativa(s) Mtricas de Avaliar a Prontido Definir Requisitos de
Avaliao da Requisitos Requisitos de
[Construda, de Soluo Desempenho Organizacional Transio
Prontido [Alocados] Transio
Desenvolvida ou da Soluo Organizacional
Desenhada] 7.6
7.5
Avaliar o Desempenho da
Validar a Soluo
5.4 3.3 Soluo 7.6 7.5
Escopo da Preocupaes Avaliao do Avaliao da

Soluo das Partes Desempenho da Validao
Interessadas Soluo Soluo
7.1 Avaliar Soluo Proposta

7.1.1 Propsito
Avaliar as solues propostas a fim de determinar o quanto elas atendem aos
requisitos das partes interessadas e da soluo.
7.1.2 Descrio
A avaliao da soluo pode ser executada com uma nica soluo ou comparar
vrias solues propostas.

Avaliar Soluo Proposta Avaliao e Validao da Soluo
Na avaliao de uma nica soluo, o analista de negcio determina se a soluo

entrega valor de negcio suficiente para justificar sua implementao. Isso ser mais
comum quando uma soluo customizada tiver sido criada para atender a uma
necessidade especfica do negcio.
Figura 7-2: Diagrama de Entrada/Sada de Avaliar a Soluo Proposta

Entradas
6.4 4.1,
6.1
Suposies e Requisitos Alternativa

Restries [Priorizados e (s) de
Aprovados] Soluo
7.1
Avaliar a Soluo
Proposta
7.1
Avaliao da
Soluo
Proposta
Tarefas que usam

esta sada
Seleo ou
Desenho da
Soluo
+
Na avaliao de vrias solues alternativas, o analista de negcio possui a meta

adicional de procurar determinar qual soluo entrega o maior valor de negcio.
Isso requer a compreenso das vantagens e desvantagens de cada alternativa.
7.1.3 Entrada
Suposies e Restries: Suposies podem levar ao favorecimento de certas
solues, enquanto restries podem limitar as opes de solues disponveis.
Requisitos [Priorizados e Aprovados]: As prioridades relativas dos requisitos

permitem anlises para identificar as escolhas que atendem aos requisitos mais
importantes. Os requisitos devem estar aprovados para que esta deciso seja tomada.
Alternativa(s) de Soluo: Informaes a respeito de cada soluo proposta devem

estar disponveis. A informao deve possuir um formato que facilite a comparao
efetiva entre as opes disponveis.

Avaliao e Validao da Soluo Avaliar Soluo Proposta
7.1.4 Elementos
.1 Ranqueamento das Opes de Solues
Quando h relativamente poucos critrios envolvidos, pode ser mais produtivo focar-
se naqueles critrios nos quais existam diferenas substanciais entre as alternativas
de soluo. Essas diferenas constituem, por sua vez, a base para a deciso.
Para problemas de deciso mais complexos, um sistema de pontuao pode ser

usado, com conjuntos de requisitos relacionados com pesos atribudos que reflitam
a sua importncia relativa para a organizao. Cada soluo pontuada e a soluo,
ou solues, com melhor nota so ento investigadas em maior detalhe.
.2 Identificao de Capacidades Potenciais Adicionais
Algumas vezes as alternativas de soluo oferecero capacidades (potenciais ou
existentes) para a organizao que esto acima ou aqum daquelas identificadas
nos requisitos ou no business case original. Em muitos casos, essas capacidades
no trazem valor imediato para a organizao, mas possuem o potencial de
gerar valor futuro, uma vez que a soluo pode apoiar o desenvolvimento ou
implementao rpidos daquelas capacidades, caso elas sejam requeridas (por
exemplo, uma aplicativo de software pode possuir recursos que a organizao
planeja utilizar futuramente).
7.1.5 Tcnicas
Definio dos Critrios de Aceite e de Avaliao (9.1): Os requisitos devem ser
expressados na forma de critrios de aceite para torn-los mais teis para a avaliao
das solues propostas.
Anlise Decisria (9.8): Mtodos de anlise decisria apoiam diretamente a

avaliao e o ranqueamento das alternativas de soluo.
Avaliao de Fornecedores (9.34): Quando uma alternativa est sendo provida

de forma parcial ou completa por uma terceira parte, a avaliao da soluo deve
ser combinada com uma avaliao do fornecedor para garantir que todas as partes
sero capazes de desenvolver e manter um relacionamento de trabalho saudvel.

Especialistas no Assunto: Podem prover feedback durante o processo de seleo ou
participar na avaliao das opes.
Especialista em Implementao da Soluo: Coleta informao de especialistas

com conhecimentos especficos sobre as alternativas de soluo consideradas. A
interoperabilidade com as necessidades da arquitetura organizacional deve ser
considerada.
Suporte Operacional: Fornece informao sobre restries tcnicas que podem

limitar as solues que podem ser implementadas.
Gerente do Projeto: Precisar planejar e gerenciar o processo de seleo.
Fornecedor: Prover informaes sobre a funcionalidade associada a uma

alternativa de soluo em particular.
Patrocinador: Aprova o investimento de recursos para adquirir ou desenvolver uma

soluo e aprova a recomendao final.

Alocar Requisitos Avaliao e Validao da Soluo
7.1.7 Sada
Avaliao da Soluo Proposta: Avalia o valor entregue por cada soluo proposta.
Caso haja vrias solues disponveis, uma recomendao sobre a melhor soluo
deve ser feita. Caso nenhuma soluo entregue valor suficiente para justificar a sua
implementao, uma recomendao para abandono da iniciativa deve ser dada.
7.2 Alocar Requisitos

7.2.1 Propsito
Alocar os requisitos das partes interessadas e da soluo entre os componentes da
soluo e liberaes no intuito de maximizar o possvel valor para o negcio, dadas
as opes e alternativas geradas pela equipe de desenho.
7.2.2 Descrio
A alocao de requisitos o processo de distribuio dos requisitos das partes
interessadas e da soluo nos componentes da soluo e em liberaes. A alocao
apoiada pela avaliao das trocas existentes entre as alternativas, no intuito de
maximizar os benefcios e minimizar os custos. O valor de uma soluo para o
negcio muda, dependendo de como os requisitos so implementados e quando a
soluo se torna disponvel para as partes interessadas. O objetivo da alocao
maximizar este valor.
Figura 7-3: Diagrama de Entrada/Sada de Alocar Requisitos

Entradas
4.1, 5.4
6.1
Requisitos Soluo Escopo da

[Priorizados e [Desenhada] Soluo
Aprovados]
7.2
Alocar Requisitos
7.2
Requisitos
[Alocados]
Tarefas Usadas nesta Sada Sada usada tambm por
Gerenciamento e Seleo ou Desenho da

Comunicao de Requisitos Soluo
+ +

Avaliao e Validao da Soluo Alocar Requisitos
Os requisitos podem ser distribudos entre unidades organizacionais, funes,

pessoas e software, componentes de aplicativos de software ou liberaes de uma
soluo. A alocao de requisitos inicia-se tipicamente no incio do ciclo de vida
do projeto (to cedo quanto possa ser determinada a abordagem da soluo) e ir
continuar a ser desempenhada at que todos os requisitos vlidos estejam alocados.
A alocao tipicamente continua ao longo do desenho e construo de uma soluo.
7.2.3 Entrada
Requisitos [Priorizados e Aprovados]: Alocao dos requisitos pode ser
desempenhada com requisitos em qualquer estgio (ex.: declarados, analisados,
verificados, validados), contudo, para que a tarefa seja considerada completa,
necessrio que os requisitos tenham sido aprovados.
Soluo [Desenhada]: O desenho da soluo deve possuir um conjunto

definido de componentes e os custos e os esforos associados entrega daqueles
componentes devem ter sido estimados. Compensaes (Tradeoffs) podem ento
ser feitas entre a funcionalidade alocada a cada componente e o custo associado
ao seu desenvolvimento.
Escopo da Soluo: O escopo da soluo aloca os requisitos do negcio aos

componentes e s liberaes. Os requisitos das partes interessadas e da soluo
associados devem atender quela alocao, ou o escopo da soluo dever ser revisado.
7.2.4 Elementos
.1 Componentes da Soluo
A maioria das solues de negcio (com exceo de pequenas mudanas ou
melhorias em uma soluo existente) ser composta de mltiplos componentes.
Cada componente implementa um subconjunto dos requisitos. A alocao de
requisitos aos componentes da soluo ser um acionador primrio do custo para
implementar a soluo e os benefcios gerados por ela.
Os componentes da soluo podem incluir:
Polticas e regras de negcio
Processos de negcio a serem executados e gerenciados
Pessoas que operam e mantm a soluo, incluindo as funes e

responsabilidades dos seus cargos
Aplicativos de software e componentes de aplicativos usados na soluo
Estrutura da organizao, incluindo interaes entre a organizao, seus

clientes e fornecedores
Durante o desenho da soluo, pode se tornar necessrio revisitar a alocao inicial

de funcionalidade entre os componentes como definida no escopo da soluo,
conforme se compreende melhor o custo da implementao de cada componente e
para determinar quais alocaes possuem a melhor relao custo/benefcio.
Conforme os custos e esforos so compreendidos para cada componente da soluo,

o analista de negcio precisar avaliar se a alocao representa as escolhas mais
eficientes entre as opes de entrega. As consideraes tendem a incluir:

Alocar Requisitos Avaliao e Validao da Soluo
Recursos disponveis: Os fornecedores sero confrontados com limitaes em

relao quantidade de requisitos que eles podem implementar com base nos
recursos alocados. Em alguns casos, o analista de negcio pode ser capaz de
desenvolver um business case que justifique investimento adicional.
Restries soluo: Requisitos regulatrios ou decises de negcio podem

requerer que certos requisitos sejam tratados manual ou automaticamente, ou
que certos requisitos devam ser priorizados em relao aos demais.
Dependncias entre requisitos: Algumas capacidades podem em si prover

valor limitado para a organizao, mas precisam ser entregues para apoiar
outros requisitos que, por sua vez, possuem alto valor.
.2 Planejamento das Entregas

Facilita as decises em relao a quais requisitos sero includos em cada liberao/
fase/iterao do projeto. Existem muitos fatores que orientaro essas decises tais
como o oramento geral do projeto, a necessidade de implementar uma soluo
ou partes da soluo at uma certa data, limitaes de recursos, agendamento
de treinamento e a habilidade do negcio de absorver mudanas dentro de um
perodo definido. Garantir que todas as partes compreendem as consequncias para
a organizao com base no cronograma planejado de liberaes e identificar as
capacidades da soluo que entregaro o maior benefcio para o negcio.
Podem existir restries ou polticas organizacionais que devem ser atendidas em

qualquer implementao, incluindo restries como perodos de congelamento
para implementao, polticas gerais da companhia e quaisquer atividades contidas
nas fases. Analistas de negcio auxiliam no planejamento da cronometragem da
implementao dentro de um ciclo do negcio, no intuito de causar o mnimo de
impacto negativo sobre as atividades do negcio.
7.2.5 Tcnicas
Definio dos critrios de Aceite e Avaliao (9.1):
Um conjunto mnimo de critrios de aceite precisa ser atingido para uma liberao
em particular.
Anlise das Regras de Negcio (9.4): Regras de negcio podem ser gerenciadas e
monitoradas por pessoas ou automatizadas por um aplicativo de software.
Anlise Decisria (9.8): Pode ser usada para estimar o valor associado com
diferentes decises de alocao e otimizar essas decises.
Decomposio Funcional (9.12): Pode ser usada para decompor o escopo da

soluo em componentes menores para alocao.
Modelagem de Processos (9.21): Atividades no modelo do processo podem ser

alocadas para diferentes papis ou terceirizados com um fornecedor. Pode ser
desenvolvida uma soluo que apoia alguns subprocessos ou atividades de forma
incremental.
Cenrios e Casos de Uso (9.26): Fluxos alternativos podem ser separados do caso de
uso base e ser includos em uma extenso para serem movidos para uma liberao
posterior.

Avaliao e Validao da Soluo Avaliar a Prontido Organizacional

Clientes e Fornecedores: Sero afetados por como e quando os requisitos so
implementados e podem precisar ser consultados a respeito de, ou concordar com,
as decises da alocao.
Especialistas no Assunto: Podem ter recomendaes a respeito do conjunto de

requisitos a ser alocados a um componente da soluo ou a uma liberao.
Usurio Final: Pode requerer que um conjunto mnimo definido de requisitos seja
implementado antes que a liberao seja aceita. Se os requisitos so realocados
a um processo manual, a carga de trabalho adicional pode afetar seriamente o
desempenho do seu trabalho e a sua satisfao. Usurios finais podem possuir
preocupaes a respeito da frequncia da mudana que eles esto preparados para
aceitar e precisaro estar a par das realocaes.
Especialista em Implementao da Soluo: Ser responsvel pelo desenho

e construo de alguns, ou todos, componentes da soluo e pela estimativa do
trabalho necessrio. Far recomendaes a respeito da alocao dos requisitos e pode
assumir a propriedade sobre a alocao, se a deciso em relao a uma alocao em
particular no possuir nenhum impacto significativo sobre a capacidade da soluo
em atender aos requisitos das partes interessadas e da soluo. Em particular, a
alocao dos requisitos entre componentes individuais do aplicativo de software
usualmente de responsabilidade de um arquiteto do sistema ou desenvolvedor.
Suporte operacional: Ser afetado pela alocao de requisitos a componentes e

liberaes e precisa estar a par de quando e onde os requisitos sero alocados.
Gerente de Projeto: responsvel pelo trabalho desenvolvido pelo equipe de projeto

e precisar participar da alocao de requisitos a fim de gerenciar o escopo do
projeto e o trabalho. Pode precisar solicitar realocao a fim de reduzir o trabalho
do projeto ou solicitar ajustes no escopo ou oramento do projeto.
Testador: responsvel por verificar liberaes e componentes de soluo e precisar,

portanto, conhecer como os requisitos tm sido alocados.
Patrocinador: responsvel por bancar o projeto e, portanto, requisitado para

aprovar a alocao de requisitos aos componentes e liberaes com base na
recomendao do analista de negcio e da equipe de projeto.
7.2.7 Sada
Requisitos [Alocados]: Requisitos alocados so associados a um componente de
soluo que vai implement-los
7.3 Avaliar a Prontido Organizacional

7.3.1 Propsito
Avaliar se a organizao est pronta para fazer uso efetivo de uma nova soluo.
7.3.2 Descrio
Uma avaliao da prontido organizacional descreve o efeito que uma nova soluo
ter sobre uma organizao e se ela est preparada para a mudana organizacional
que a implementao da soluo produzir. A comunicao efetiva dos impactos
da soluo auxilia na implementao das prticas necessrias de gerenciamento

Avaliar a Prontido Organizacional Avaliao e Validao da Soluo
da mudana organizacional e na identificao dos requisitos de treinamento para a

implementao da soluo.
No intuito de identificar impactos, o analista deve compreender quais mudanas

ocorrero na rea de negcio, infraestrutura tcnica ou processos e como elas
afetaro outras unidades de negcio ou operaes.
Figura 7-4: Diagrama de Entrada/Sada de Avaliar a Prontido Organizacional
Entradas
5.4 3.3
Arquitetura Soluo Escopo da Preocupaes das

Corporativa [Desenhada] Soluo Partes Interessadas
7.3
Avaliar a Prontido
Organizacional
7.3
Avaliao da
Prontido
Organizacional
Definir Requisitos
de Transio
7.3.3 Entrada
Arquitetura Corporativa: Descreve o estado atual da corporao, incluindo
estrutura organizacional, processos de negcio, sistemas, informao, etc.
Escopo da Soluo: Usado para determinar quais componentes da arquitetura do

negcio so afetados.
Soluo [Desenhada]: Usada no lugar do escopo da soluo, se estiver disponvel.
Preocupaes das Partes Interessadas: Usadas para avaliar problemas ou

incidentes potenciais.

Avaliao e Validao da Soluo Avaliar a Prontido Organizacional
7.3.4 Elementos
.1 Avaliao Cultural
Determinar se os grupos de partes interessadas desejam genuinamente que a
mudana seja bem-sucedida. Avaliar as crenas, atitudes e sentimentos comuns
aos principais grupos de partes interessadas e o desejo daqueles grupos de
partes interessadas de aceitar a mudana. Determinar se as partes interessadas
compreendem as razes pelas quais uma nova soluo est sendo implementada,
se elas veem a soluo como algo que ser benfico e se elas compreendem as razes
pelas quais uma nova soluo requerida.
.2 Avaliao Operacional ou Tcnica

Determinar se a organizao capaz de tirar vantagem das capacidades providas
pela nova soluo e avaliar se as partes interessadas esto preparadas para fazer
uso da nova soluo. Determinar se o treinamento foi realizado, se novas polticas
e procedimentos foram definidos, se sistemas de TI requeridos para apoi-los esto
disponveis e se a soluo capaz de desempenhar em um nvel requerido.
.3 Anlise do Impacto nas Partes Interessadas

Compreender como a mudana afetar um grupo particular de partes interessadas.
Algumas consideraes na anlise de impacto incluem:
Funes: Quais processos envolvem a parte interessada e quais aplicativos so

utilizados pela parte interessada?
Localizao: As partes interessadas esto localizadas em um nico local ou em

uma equipe distribuda? Caso elas estejam distribudas, a mudana afetar as suas
comunicaes?
Tarefas: Quais tarefas so desempenhadas por pessoas associadas a quais grupos

de partes interessadas? A mudana alterar a maneira como essas tarefas so
desempenhadas, ou afetar os nveis de habilidades requeridos para desempenh-
las? As partes interessadas tero mais ou menos flexibilidade no desempenho das
suas tarefas?
Preocupaes: Quais so os requisitos de usabilidade, as preferncias e o

nvel de proficincia deste grupo em relao s interaes com os sistemas
computadorizados? Elas tornar-se-o mais ou menos exigentes? Algum membro do
grupo est em risco de perder seu emprego? As mudanas afetaro a sua satisfao
no trabalho?
7.3.5 Tcnicas
.1 Tcnicas Gerais
Definio de Critrios de Aceite e Avaliao (9.1): Critrios de aceite da soluo
devem refletir nveis de desempenho que permitiriam organizao ter confiana
nas solues que atendam queles critrios.
Diagramas de Fluxos de Dados (9.6) e Modelos de Processos (9.21): til para

identificar as atividades suscetveis de mudar com a implementao de uma nova
soluo e as partes interessadas que desempenharam essas atividades.
Grupos Focais (9.11), Entrevistas (9.14) e Pesquisa/Questionrio (9.31): Podem

auxiliar na identificao das preocupaes ou questes das partes interessadas.

Avaliar a Prontido Organizacional Avaliao e Validao da Soluo
Modelagem da Organizao (9.19): Usada para identificar partes interessadas ou

grupos de partes interessadas que podem ser impactados pela nova soluo.
Rastreamento de Problemas (9.20): Usado para garantir que questes identificadas

pela avaliao da prontido organizacional sejam resolvidas.
Anlise de Risco (9.24): Usada para avaliar problemas potenciais que so

identificados durante a avaliao da prontido organizacional, determinar quais
dos possveis problemas so os mais importantes para se lidar e desenvolver uma
estratgia de mitigao.
Anlise SWOT (9.32): Usada para avaliar estratgias desenvolvidas para responder
a questes identificadas.
.2 Anlise do Campo de Fora

Anlise do campo de fora um mtodo grfico para a demonstrao das foras que
apoiam e se opem a uma mudana. Ela envolve a identificao das foras que apoiam
e se opem a uma mudana, desenhando-as como lados opostos de uma linha e ento
estimando o nvel de cada fora, no intuito de avaliar qual conjunto de foras mais
intenso. Uma vez completada a anlise, o prximo passo procurar por maneiras de
reforar as foras que apoiam o resultado desejado ou criar novas foras.
Figura 7-5: Diagrama de Anlise de Campo de Foras

Potncia da Foras de Apoio Foras de Oposio Potncia da
Fora Mudana Mudana Fora
5 Fora de Apoio 1 Fora de Oposio 1 3

Proposta de
Alterao do
Sistema de
Negcio
2 Fora de Apoio 2 Fora de Oposio 2 1
Total: 7 Total: 4

Especialistas no Assunto: Proveem informao sobre os impactos provveis para
as partes interessadas e as capacidades da corporao.
Especialista em Implementao da Soluo: Fornece informaes sobre as

habilidades e capacidades necessrias para operar a nova soluo com sucesso.
Existem diversos especialistas em implementao da soluo que podem ter um
efeito significante na habilidade de uma organizao para implementar a mudana,
incluindo, mas no limitado a:
Especialistas em Gesto da Mudana Organizacional auxiliam organizaes na

comunicao da mudana para suas partes interessadas e na criao de apoio
entre as partes interessadas para a mudana.

Avaliao e Validao da Soluo Definir Requisitos de Transio
Especialistas em Usabilidade auxiliam na avaliao e no desenho dos aplicativos

de software que so mais fceis de compreender e utilizar.
Especialistas em Treinamento auxiliam na criao de um plano de treinamento

para auxiliar as partes interessadas a desenvolver habilidades que elas precisam
para utilizar efetivamente a nova soluo.
Suporte Operacional: Proveem informaes sobre a sua habilidade de apoiar a

operao da soluo. Precisar compreender a natureza da soluo no intuito de ser
capaz de apoi-la.
Gerente do Projeto: Requer a avaliao da prontido organizacional para

determinar se trabalho adicional de projeto requerido para uma implementao
bem-sucedida da soluo. Um plano de implementao deve ser criado para delinear
os passos a serem tomados e a ordem na qual eles devem ser executados para resolver
quaisquer questes identificadas na avaliao da prontido organizacional.
Patrocinador: Autoriza e lidera aes para resolver problemas identificados na

avaliao da prontido organizacional.
7.3.7 Sada
Avaliao da Prontido Organizacional: Descreve se as partes interessadas esto
preparadas para aceitar a mudana associada a uma soluo e so capazes de us-la
efetivamente. Pode levar a revises no escopo da soluo ou do projeto.
7.4 Definir Requisitos de Transio

7.4.1 Propsito
Definir requisitos para capacidades necessrias para a transio entre uma soluo
existente e a nova soluo.
7.4.2 Descrio
Na maioria dos casos, uma soluo implementada em uma corporao para
aperfeioar ou substituir uma soluo existente. Durante o perodo de transio (o
tempo no qual ambas solues, a nova e a existente, esto operacionais), a corporao
pode precisar operar as solues em paralelo, transferir informaes entre a soluo
nova e a antiga, conduzir treinamentos para capacitar partes interessadas para
operar efetivamente a nova soluo e assim por diante. Alm do desenvolvimento em
si, a equipe de implementao tende a ter que desenvolver capacidades adicionais
para apoiar essa transio.
Essas capacidades so requisitos, uma vez que as partes interessadas precisam

ser capazes de fazer essa transio com sucesso contudo, elas so diferentes por
natureza de outros tipos de requisitos, uma vez que elas no podem ser definidas at
que a soluo tenha sido desenhada. Esses requisitos tambm possuem um ciclo de
vida diferente dos outros tipos de requisitos, pois eles se mantm relevantes somente
durante o perodo de transio entre solues.
Os requisitos de transio so elicitados, analisados, gerenciados e comunicados

atravs da realizao das mesmas tarefas utilizadas para outros requisitos. A
diferena no est nos mtodos para defini-los, mas nas entradas, na natureza dos
requisitos de transio e no fato de que eles deixam de ser relevantes assim que a
soluo existente desativada.

Definir Requisitos de Transio Avaliao e Validao da Soluo
Naqueles casos em que no h soluo existente e a nova soluo est adicionando uma
capacidade completamente nova corporao (ao invs de estender ou aperfeioar
uma capacidade existente), os requisitos de transio no precisam ser analisados.
Figura 7-6: Diagrama de Entrada/Sada de Definir Requisitos de Transio
Entradas
7.3 3.3
Avaliao da Requisitos Soluo [Em Soluo

Prontido [Declarados] Operao] [Desenhada]
Organizacional
7.4
Definir Requisitos
de Transio
7.4
Requisitos de
Transio

Gerenciamento e
6.1 6.5 Comunicao de
Priorizar Requisitos Verificar Requisitos Requisitos
+
7.4.3 Entrada
Avaliao da Prontido Organizacional: Usada para identificar reas nas quais
a organizao precisa adicionar novas capacidades para gerenciar e operar a nova
soluo.
Requisitos [Declarados]: As partes interessadas identificaro a informao e os

processos que elas precisam durante a transio.
Soluo [Em Operao]: A soluo em operao (ou existente) ser investigada para
compreender o que precisa ser transferido para a nova soluo. Pode ser necessrio
elicitar uma descrio das capacidades da soluo e desempenhar algumas
tarefas de anlise, no intuito de garantir que as capacidades atuais so totalmente
compreendidas.
Soluo [Desenhada]: O desenho da nova soluo deve estar suficientemente

definido para permitir que as maiores diferenas sejam identificadas.

Avaliao e Validao da Soluo Definir Requisitos de Transio
7.4.4 Elementos
Examinar a soluo atualmente em uso para identificar particularidades que esto
implementadas de forma substancialmente diferente na nova soluo, informaes
que precisam ser transferidas para a nova soluo e outras reas de mudana
significativa. Fontes provveis de requisitos de transio incluem:
.1 Dados
Os dados e metadados gerenciados pelo sistema antigo precisam ser avaliados
para determinar o arquivamento da informao ou a sua transferncia para a nova
soluo. Regras para a converso dessas informaes devero ser desenvolvidas e
regras de negcio podem precisar ser definidas para garantir que a nova soluo
interprete os dados convertidos corretamente.
.2 Trabalho Contnuo
provvel que um trabalho esteja sendo feito na verso antiga da soluo, no momento
em que a nova verso implementada. Opes para o gerenciamento deste trabalho
podem incluir a finalizao do trabalho existente na soluo atual, iniciando o novo
trabalho na nova soluo, suspendendo o processamento do novo trabalho por um
perodo de tempo ou convertendo todo o trabalho no momento da implementao.
.3 Mudana Organizacional
O analista de negcio pode estar envolvido no desenvolvimento de um processo para o
gerenciamento do lado humano das mudanas relacionado soluo. O gerenciamento
de mudanas organizacionais geralmente refere-se a um processo e a um conjunto
de ferramentas para o gerenciamento da mudana em um nvel organizacional.
O analista de negcio pode auxiliar no desenvolvimento de recomendaes de
mudanas na estrutura organizacional ou no pessoal, uma vez que as funes de
trabalho podem mudar significantemente como resultado da automao do trabalho.
Novas informaes podem ser disponibilizadas para as partes interessadas e novas
habilidades podem ser necessrias para a operao da soluo.
7.4.5 Tcnicas
Anlise de Regras de Negcio (9.4): Regras de negcio adicionais podem ser
definidas para auxiliar na migrao dos dados, ou para gerenciar o trabalho migrado
da soluo existente (j que possvel que diferentes regras sejam aplicadas,
dependendo de quando o trabalho foi realizado).
Diagramas de Fluxos de Dados (9.6), Modelagem de Processos (9.21) e

Modelagem da Organizao (9.19): Eles podem ser analisados para identificar as
diferenas entre solues novas e existentes.
Modelagem de Dados (9.7): Modelos de dados fsicos para as solues existentes e

novas sero comparados para permitir o mapeamento entre as duas.

Cliente: Pode ser afetado negativamente durante a transio com base na
transferncia de trabalho em execuo, ou informao incorretamente transferida.
Especialistas no Assunto: Provero informao sobre a soluo existente e

auxiliaro na verificao e validao dos requisitos de transio.
Usurio Final: Se a soluo existente e a nova esto ambas em uso por um perodo,
ele precisar saber como coorden-las.

Validar a Soluo Avaliao e Validao da Soluo
Especialista em Implementao da Soluo: Ser a fonte de muitos requisitos de

transio.
Suporte Operacional: Pode precisar operar duas solues simultaneamente.
Gerente do Projeto: Precisar planejar o trabalho necessrio para implementar os

requisitos de transio. Isso pode afetar o escopo do projeto.
Regulador: Pode requerer que os registros dos requisitos de transio e dos

processos sejam retidos para reviso de longo prazo e observncia aos regulamentos.
Testador: Verificar se a transio foi realizada corretamente, incluindo o

desenvolvimento dos planos de teste.
Patrocinador: Dever ser informado sobre os potenciais efeitos da transio sobre

os custos e benefcios da nova soluo.
7.4.7 Sada
Requisitos de Transio: Requisitos de transio descrevem capacidades que
devem ser desenvolvidas para que uma organizao faa a transio bem-sucedida
entre solues. Os requisitos de transio so analisados por essa tarefa e devem
ainda ser verificados, validados, gerenciados e comunicados.
7.5 Validar a Soluo

7.5.1 Propsito
Garantir que a soluo atende necessidade do negcio e determinar a resposta
mais apropriada para os defeitos identificados.
7.5.2 Descrio
A validao da soluo requerida para garantir que uma soluo entregue atende
continuamente s necessidades do negcio . Os problemas que so identificados atravs
da validao da soluo sero reportados e priorizados para resoluo. Quando um
problema identificado na soluo (isto , uma falha em atender a uma necessidade
de uma parte interessada tenha sido o requisito bem especificado ou no) o analista
de negcio ser capaz de auxiliar a equipe na determinao da ao mais apropriada.
7.5.3 Entrada
Soluo [Construda]: A validao s pode ser desempenhada sobre uma soluo
que existe de fato. A soluo pode, ou no, estar em uso pela corporao.
Requisitos [Priorizados e Validados]: As prioridades so necessrias para determinar

quais requisitos so candidatos a critrios de aceite. Os requisitos so usados para
determinar se as sadas da soluo encontram-se dentro de parmetros aceitveis.
7.5.4 Elementos
.1 Investigar Sadas Defeituosas da Soluo
Identificar defeitos em uma soluo ou componente da soluo procurando casos
nos quais as sadas da soluo esto abaixo de um nvel aceitvel de qualidade.
necessrio definir o que considerado como sendo uma sada defeituosa. Por
exemplo, um requisito pode ser considerado defeituoso se for alterado mais de uma
vez antes da sua implementao, ou se ele for rejeitado pelos revisores depois de uma
segunda rodada de revises. Quando puder ser constatado que uma soluo est

Avaliao e Validao da Soluo Validar a Soluo
produzindo consistentemente sadas defeituosas, a anlise da causa-raiz deve ser

executada, no intuito de identificar a causa do problema.
Alguns componentes de solues (aplicativos de software sendo o exemplo mais

provvel) podem requerer um especialista em implementao da soluo para
investigar a causa-raiz dos problemas.
.2 Avaliar Defeitos e Incidentes

Os defeitos identificados so revisados para avaliar o efeito que eles tero sobre a
operao da organizao. Isso requer a determinao da severidade do defeito,
a probabilidade da ocorrncia do defeito, a severidade do impacto no negcio e a
capacidade do negcio em absorver o impacto dos defeitos. O analista de negcio
pode ser requisitado a identificar quais defeitos devem ser resolvidos, quais podem
ser mitigados atravs de solues paliativas, ou outras abordagens, e quais podem
ser aceitos at que existam recursos para trat-los.
Caso um defeito no possa ser resolvido em um prazo aceitvel na perspectiva do

negcio (pela sua complexidade, quando a causa no pode ser identificada, porque
no possui prioridade suficiente ou qualquer outra razo) e as partes interessadas no
puderem aceitar o defeito, o analista de negcio precisa investigar opes para mitigao
dos efeitos. Elas podem incluir verificaes adicionais de controle de qualidade, novos
processos manuais, remoo de suporte para certos casos de exceo ou outras medidas.
Figura 7-7: Diagrama de Entrada/Sada de Validar a Soluo
Entradas
4.1,
6.6
Requisitos Soluo
[Priorizados e [Construda]
Validados]
7.5
Validar a Soluo
7.5 7.5 7.5
Defeitos Mitigao Avaliao da

Identificados Validao
Soluo
Tarefas que usam esta sada Sadas usadas tambm

7.6 Sadaspor
usadas
Avaliar o Desempenho da tambm por
Soluo +

Validar a Soluo Avaliao e Validao da Soluo
7.5.5 Tcnicas
Definio de Critrios de Aceite e Avaliao (9.1): Determinar o conjunto de
requisitos que a soluo deve atender para ser considerada vlida.
Rastreamento de Problemas (9.20): Usado para rastrear defeitos identificados

para garantir que eles sejam resolvidos.
Anlise de Causa-Raiz (9.25): Usada para garantir que a razo implcita de um

defeito seja identificada, ao invs de simplesmente corrigir a sada (que pode ser um
sintoma de um problema implcito mais profundo).

Especialistas no Assunto: Prover entradas para o desenvolvimento dos critrios
de aceite e avaliao.
Usurio Final: Pode auxiliar no desenvolvimento dos critrios de aceite e avaliao

e participar no teste de aceite.
Especialista em Implementao da Soluo: Apoiar o processo de validao,

investigar defeito, corrigir defeitos identificados e participar na priorizao do
defeito e no processo de resoluo.
Suporte Operacional: Apoiar a implantao das resolues dos defeitos.
Gerente do Projeto: Responsvel pela coordenao do trabalho entre as partes

envolvidas no processo de validao.
Testador: Responsvel pela verificao da soluo (isto , verificar se a soluo

comporta-se de acordo com os seus requisitos). Testadores desenvolvero e
executaro testes para identificar defeitos que precisam ser avaliados e validados
pelo analista de negcio. Planos de testes podem ser revisados para garantir
que o conjunto planejado de atividades de teste ser suficiente para assegurar
organizao que a soluo possui conformidade com os requisitos.
Regulador: Pode revisar os resultados do teste de aceite e requerer que registros

referentes ao processo e aos resultados sejam mantidos.
Patrocinador: O patrocinador (ou algum designado por ele) precisa aceitar a

soluo.
7.5.7 Sada
Defeitos Identificados: Problemas conhecidos existentes em uma soluo.
Aes de Mitigao: Passos que podem ser tomados, ou processos que podem ser
seguidos para reduzir ou eliminar o efeito que um defeito identificado possui sobre
uma parte interessada ou sobre um grupo de partes interessadas.
Avaliao da Validao da Soluo: Uma avaliao da capacidade da soluo em

atender necessidade do negcio dentro de um nvel aceitvel de qualidade.

Avaliao e Validao da Soluo Avaliar o Desempenho da Soluo
7.6 Avaliar o Desempenho da Soluo

7.6.1 Propsito
Avaliar solues em funcionamento para compreender o valor que elas entregam e
identificar oportunidades de melhoria.
7.6.2 Descrio
Avaliao da soluo envolve a investigao de como uma soluo usada de fato
aps a sua implantao e a avaliao do efeito que ela teve, tanto positivo quanto
negativo. Ela pode ser denominada avaliao ps-implementao quando executada
imediatamente aps a finalizao de um projeto.
As solues podem ser adaptadas e modificadas diretamente pelos usurios finais,

incluindo paliativos manuais, registros de informao adicional e adoo de
polticas e procedimentos informais para resolver problemas que ocorreram ou para
permitir novos usos para a soluo. No intuito de avaliar corretamente a soluo,
tambm necessrio compreender quando, onde e porque isso ocorreu e avaliar o
benefcio que essas mudanas trouxeram para a organizao.
Figura 7-8: Diagrama de Entrada/Sada de Avaliar o Desempenho da Soluo

Entradas
* 7.5
Requisitos de Defeitos Soluo [Em Mtricas de

Negcios Identificados operao] Desempenho
da Soluo
7.6
Avaliar o Desempenho da
Soluo
7.6
Avaliao do
Desempenho da
Soluo

5.2
Avaliar Gaps (Lacunas) de
Capacidades
7.6.3 Entradas
Requisitos de Negcio: O desempenho da soluo ser medido em relao aos
requisitos do negcio. Sem requisitos do negcio claros impossvel avaliar o
desempenho da soluo efetivamente, uma vez que no existem metas definidas que
ela supostamente deve atender.

Avaliar o Desempenho da Soluo Avaliao e Validao da Soluo
Defeitos Identificados: Quaisquer defeitos conhecidos devem ser considerados na

avaliao da qualidade da soluo.
Mtricas de Desempenho da Soluo: Elas representam os critrios pelos quais o

desempenho da soluo avaliado. Elas podem ser quantitativas (medidas de tempo,
volume, receita, erros encontrados ou outras informaes para as quais nmeros
esto disponveis) ou qualitativas (satisfao do usurio ou do cliente, recomendaes
ou outras medidas que resumem as opinies das partes interessadas).
Soluo [Em Operao]: Essa tarefa no pode ser desempenhada at que a soluo
esteja em uso.
7.6.4 Elementos
.1 Compreender o Valor Entregue pela Soluo
Reunir as mtricas atuais que descrevem o desempenho da soluo. Aplicativos podem
reportar automaticamente algumas ou todas as mtricas definidas, mas onde elas no o
fazem, ser necessrio reunir informaes de desempenho qualitativas e quantitativas.
Desempenho significativamente acima ou abaixo das metas podem ser investigados
para identificar a causa-raiz do problema ou determinar uma resposta apropriada.
Se a causa raiz do problema para o desempenho abaixo do esperado for um fator

que est potencialmente sob o controle da empresa, abord-la pode tornar-se uma
Desempenho significativamente acima do esperado pode indicar que os recursos

dedicados soluo podem ser usados em outro lugar, ou que o valor da soluo para
o negcio foi subestimado. provvel que existam lies que possam ser aprendidas
e aplicadas posteriormente.
.2 Validar as Mtricas da Soluo

Em alguns casos, o desempenho de uma soluo ser considerado excelente, com base
nas mtricas de desempenho definidas para aquela soluo, mas as metas e objetivos de
negcio, aos quais aquelas mtricas deveriam estar alinhadas, no esto sendo atingidos.
Um esforo de anlise para identificar e definir mtricas mais apropriadas, incluindo a
modificao da soluo para coletar e reportar essas mtricas pode ser necessrio.
.3 Substituio ou Eliminao da Soluo

Eventualmente, ser necessrio considerar a substituio de uma soluo ou de
um componente da soluo. Isso pode ocorrer porque um sistema de TI ou outro
componente de tecnologia tenha alcanado o final da sua vida til, servios esto sendo
assumidos pela organizao ou sendo terceirizados, a soluo no est preenchendo
as metas do negcio definidas para ela ou por qualquer outra razo. Questes que
podem influenciar uma deciso de substituio ou eliminao podem incluir:
Custo Contnuo versus Investimento Inicial: comum para a soluo existente

ter custos crescentes ao longo do tempo enquanto alternativas possuem um custo
de investimento mais alto, contudo, com custos menores de manuteno.
Custo da Oportunidade: O custo da oportunidade representa o valor potencial

que poderia ser realizado ao se perseguir cursos alternativos de ao. A substituio
de uma soluo existente tende a no produzir retornos altos de investimentos
no incio (por replicar capacidades existentes, pelo menos inicialmente, ao invs
de criar muitas mais). Uma vez que o esforo para desenvolver uma substituio
ir retirar recursos de outras iniciativas, a organizao pode estar considerando
os benefcios potenciais dessas iniciativas que precisam ser levados em conta
Avaliao e Validao da Soluo Avaliar o Desempenho da Soluo
para determinar se eles so maiores do que o benefcio de uma substituio (esta

geralmente no uma considerao quando uma eliminao considerada).
Necessidade: A maioria dos componentes de soluo possui um tempo de

vida limitado (devido obsolescncia, mudanas nas condies do mercado e
outras causas). Aps certo ponto no ciclo de vida, ser impossvel manter um
componente existente.
Custo incorrido: Custo incorrido descreve o dinheiro e esforo j dedicados a uma

iniciativa. O impacto psicolgico de custos incorridos pode tornar difcil para partes
interessadas avaliarem objetivamente o raciocnio para substituio ou eliminao,
conforme elas ficam relutantes em desperdiar o esforo ou dinheiro j investido.
Uma vez que este investimento no pode ser recuperado, ele efetivamente
irrelevante na considerao de aes futuras. Decises deveriam ser baseadas no
investimento futuro requerido e os benefcios futuros que podem ser ganhos.
7.6.5 Tcnicas
Anlise Decisria (9.8): Uma anlise custo/benefcio tipicamente usada para
determinar o impacto financeiro da soluo sobre a organizao. J que so
crticos, importante garantir que os custos no-financeiros (incluindo o custo da
oportunidade) e os benefcios so avaliados.
Grupos Focais (9.11): teis para ganhar uma compreenso qualitativa detalhada do
valor de uma soluo para um grupo de partes interessadas. Eles podem ser usados
para descobrir novas informaes alm do escopo das mtricas previamente definidas.
Observao (9.18): Pode revelar usos ou problemas que no esto sendo reportados.
Pesquisa/Questionrio (9.31): Permite a coleta de informaes qualitativas

e quantitativas de grande nmero de partes interessadas. Se uma pesquisa
apropriadamente desenhada e respondida por uma amostra estatisticamente
significativa e representativa da populao das partes interessadas, ela pode refletir
com acurcia as opinies da populao inteira. As pesquisas no so especialmente
efetivas no levantamento de informaes inesperadas.

Cliente, Especialistas no Assunto e Fornecedor: Podem fazer recomendaes
para melhorias.
Usurio Final: Responsvel pela operao no dia-a-dia da soluo e uma grande

fonte de informao a respeito de problemas ou defeitos.
Suporte Operacional: Ser envolvido no monitoramento do desempenho e da

efetividade da soluo e dos seus componentes.
Regulador: Pode possuir requisitos a respeito do desempenho de uma soluo que

devem ser atendidos continuamente.
Patrocinador: A pessoa responsvel pela operao da soluo que, desde a

perspectiva do negcio, ser responsvel por decidir se a avaliao da soluo
garante o incio de uma iniciativa de mudana.
7.6.7 Sada
Avaliao do Desempenho da Soluo: Descreve como a soluo est
desempenhando em relao s metas e objetivos do negcio.

Competncias Fundamentais
Captulo OITO
A rea de Conhecimento Competncias Fundamentais apresenta uma descrio dos
comportamentos, caractersticas, conhecimentos e qualidades que apoiam a prtica
da anlise de negcios.
As competncias fundamentais no so, evidentemente, exclusivas da profisso de

anlise de negcios. Elas so descritas aqui para garantir que os leitores estejam
a par da gama de habilidades fundamentais necessrias e para fornecer uma base
para que eles possam investigar mais a fundo as habilidades e conhecimentos que os
tornaro analistas de negcios flexveis e habilidosos.
8.1 Pensamento Analtico e Resoluo de Problemas

8.1.1 Pensamento Criativo
.1 Propsito
Analistas de negcios devem ser eficazes na gerao de novas ideias quando determinam
abordagem para a soluo de problemas ou para a gerao de solues alternativas.
.2 Definio
Pensamento criativo envolve no s a gerao de novas ideias e conceitos, como
tambm novas associaes entre ideias e conceitos existentes. Isso exige inovao
e adaptabilidade situao. Alm da identificao e sugesto de alternativas, o
analista de negcios pode conseguir promover o pensamento criativo entre os
demais, fazendo as perguntas certas e desafiando suposies.
.3 Medidas de Eficcia
Sinais de pensamento criativo bem sucedido incluem:
Sucesso na gerao e avaliao de novas ideias.
Aplicao de novas ideias soluo de problemas existentes.
Disposio das partes interessadas para aceitar novas abordagens.
8.1.2 Tomada de Deciso

.1 Propsito
Analistas de negcios devem compreender os critrios envolvidos na tomada de
uma deciso, devem tomar decises de forma eficaz e tambm devem dar suporte
apropriado para que outros tomem as melhores decises.
.2 Definio
Uma deciso necessria toda vez que preciso selecionar uma alternativa ou
abordagem entre duas ou mais opes. Anlise de deciso inclui reunir informaes
relevantes para uma deciso, decompor a informao relevante, comparar opes
similares e no similares e identificar a opo mais desejvel. Analistas de negcios
devem estar cientes das armadilhas que podem impedir algum ou um grupo de

Pensamento Analtico e Resoluo de Problemas Competncias Fundamentais
tomar uma deciso bem embasada, incluindo a tendncia de se aceitar a primeira

ideia a respeito de um problema, o efeito do custo perdido e a tendncia de se dar
mais valor s evidncias que confirmam impresses existentes.
Sinais de decises bem embasadas incluem:
Confiana dos envolvidos de que a deciso tomada correta.
Novas informaes ou alternativas que levam uma deciso a ser repensada

so genuinamente novas e no informaes antigas que por algum motivo no
foram consideradas anteriormente.
As decises realmente tratam do problema em questo.
Durante a tomada de decises, o impacto de incertezas e de novas informaes

pode ser avaliado de forma eficaz.
8.1.3 Aprendizado
.1 Propsito
Analistas de negcios devem aprender o domnio do negcio, entender como o
negcio funciona e depois devem compreender como todo este aprendizado ser
utilizado para trazer benefcios organizao.
.2 Definio
Aprender o processo de adquirir conhecimento ou habilidades. Para aprender a
respeito de um domnio, necessrio passar por vrios estgios, desde a aquisio
inicial e o aprendizado dos fatos em si (atravs da compreenso dos seus significados),
at a aplicao do conhecimento no dia-a-dia e, por fim, a anlise, sntese e avaliao.
Um analista de negcios deve ser capaz de descrever o seu nvel de compreenso
do domnio do negcio e deve ser capaz de aplicar este nvel de compreenso
para determinar quais atividades de anlise devem ser desempenhadas em uma
determinada situao. Quando o aprendizado sobre um domnio atinge o ponto em
que a anlise est completa, o analista de negcios deve ser capaz de sintetizar a
informao para identificar oportunidades de criar novas solues e avaliar essas
solues para garantir que elas sejam eficazes.
Sinais do aprendizado bem sucedido incluem:
Concordncia entre as partes interessadas de que o resultado da anlise modela

o domnio de forma eficaz e o descreve de forma completa.
Identificao de problemas relacionados ao domnio ou a reas que compem o

domnio.
Rpida absoro de novas informaes ou de novos domnios.
8.1.4 Resoluo de Problemas

.1 Propsito
Analistas de negcios devem definir e solucionar problemas de forma eficaz,
garantindo que o problema real foi compreendido e que as solues realmente atuam
sobre o problema.

Competncias Fundamentais Pensamento Analtico e Resoluo de Problemas
.2 Definio
Para definir um problema, necessrio garantir que a natureza do problema
claramente compreendida por todas as partes e que questes implcitas tornem-
se visveis. Conflitos entre metas e objetivos das partes interessadas precisam
ser articulados e discutidos. Pr-suposies devem ser identificadas e testadas.
Os objetivos que sero alcanados quando o problema for solucionado devem ser
claramente especificados e solues alternativas devem ser desenvolvidas. Solues
alternativas so avaliadas em relao aos objetivos para identificar as vantagens e
desvantagens de cada soluo e para determinar a melhor soluo. O analista de
negcios deve conhecer vrias tcnicas para resoluo de problemas.
Sinais de resoluo de problemas bem sucedida incluem:
Confiana dos participantes no processo de resoluo do problema de que a

soluo selecionada a correta.
Novas opes de solues podem ser avaliadas eficazmente usando uma

estrutura para resoluo de problemas.
Solues selecionadas atendem aos objetivos definidos e resolvem o problema real.
O processo de resoluo de problemas evita a tomada de decises com base

em noes pr-concebidas, no ambiente poltico da organizao ou em outras
armadilhas que podem causar a seleo de uma soluo no-tima.
8.1.5 Pensamento Sistmico

.1 Propsito
Analistas de negcios devem compreender de forma eficaz como pessoas, processos
e tecnologia de uma organizao interagem, formando relacionamentos e padres,
criando um sistema.
.2 Definio
A teoria dos sistemas e o pensamento sistmico sugerem que um sistema ter
propriedades, comportamentos e caractersticas que emergem da interao entre
os componentes do sistema e que no so previsveis atravs da compreenso
de cada componente isoladamente. No contexto da teoria dos sistemas, o termo
sistema muito mais abrangente do que um sistema automatizado de informao
(aplicativos de software) ele tambm inclui as pessoas envolvidas e a interao
entre elas, as foras externas que afetam o seu comportamento e todos os elementos
e fatores relevantes.
Sinais do uso eficaz do pensamento sistmico incluem:
Compreenso de como uma mudana em um componente afeta o sistema como

um todo.
Identificao das iteraes de feedback de reforo e compensao.
Compreenso de como os sistemas se adaptam s presses e mudanas externas.

Caractersticas Comportamentais Competncias Fundamentais
8.2 Caractersticas Comportamentais

8.2.1 tica
.1 Propsito
Um analista de negcios deve ser capaz de se comportar ticamente para conquistar
a confiana e o respeito das partes interessadas e ser capaz de reconhecer quando
uma soluo proposta ou um requisito pode envolver dilemas ticos.
.2 Definio
tica requer compreenso do comportamento moral e imoral, dos padres que
devem governar o comportamento de uma pessoa e disposio para garantir que
este comportamento seja moral ou atenda aos padres. Analistas de negcios
precisam considerar o impacto que uma soluo proposta ter sobre todas as
partes interessadas e trabalhar para garantir que todas as partes sejam tratadas de
forma justa. Tratamento justo no requer que o resultado seja benfico para uma
parte interessada especfica, mas requer que: todas as partes interessadas afetadas
compreendam as razes da deciso, que elas no estejam sendo enganadas a
respeito do resultado e que as decises sejam tomadas tendo em mente os interesses
da organizao. O analista de negcios deve ser capaz de identificar um dilema tico
e entender como tais dilemas podem ser solucionados.
Sinais de comportamento tico incluem:
Decises tomadas considerando os interesses de todas as partes interessadas.
Razes para uma deciso claramente articuladas e compreendidas.
Comunicao imediata e total sobre potenciais conflitos de interesse.
Honestidade em relao a habilidades, desempenho de trabalho e aceitao de

responsabilidade por falhas e erros.
8.2.2 Organizao Pessoal

.1 Propsito
Habilidades de organizao pessoal auxiliam o analista de negcios no
gerenciamento eficaz de tarefas e de informaes.
.2 Definio
Organizao pessoal envolve a habilidade de prontamente encontrar arquivos ou
informaes, administrar o tempo, gerenciar tarefas e tratar prioridades de forma
apropriada. Informaes devem ser armazenadas ou arquivadas de forma que
permita ao analista de negcios recuper-las posteriormente. Gerenciamento eficaz
do tempo requer priorizao eficaz, eliminao da procrastinao e clareza de
metas e expectativas. Tcnicas como planos de ao, listas de atividades e definio
de prioridades esto entre as abordagens utilizadas para o gerenciamento efetivo
do tempo.
Sinais de organizao pessoal incluem:
Habilidade do analista de negcios em encontrar informaes.

Competncias Fundamentais Conhecimento de Negcios
Finalizao de tarefas dentro do tempo previsto.
Eficincia na finalizao do trabalho.
Habilidade de identificar facilmente todo o trabalho ainda por fazer e a situao

em que se encontra cada atividade.
8.2.3 Confiabilidade
.1 Propsito
Conquistar a confiana das principais partes interessadas necessrio para garantir
que o analista de negcios consiga levantar requisitos relacionados a assuntos
delicados e para garantir que recomendaes sejam avaliadas apropriadamente.
.2 Definio
Um analista de negcios digno de confiana deve demonstrar constantemente s partes
interessadas que merece esta confiana e que est preocupado com os interesses das
partes envolvidas. As partes interessadas devem acreditar que o analista de negcios se
comporta de forma tica para que a anlise de negcios possa ocorrer de forma eficaz e,
assim, evitar a falta de confiana gerada por interesses em se manter o status quo ou pelo
simples medo da mudana. Confiabilidade requer que o analista de negcios preocupe-se
com as reais necessidades e no com os desejos das partes interessadas, e que o analista
de negcios trate honestamente de problemas ou conflitos quando eles ocorrerem.
Sinais de confiabilidade incluem:
Partes interessadas envolvendo o analista de negcios na tomada de decises.
Aceitao pelas partes interessadas das recomendaes do analista de negcios.
Disposio das partes interessadas para discutir assuntos difceis ou

controversos com o analista de negcios.
Disposio das partes interessadas para apoiar ou defender o analista de

negcios quando ocorrem problemas.
8.3 Conhecimento de Negcios

8.3.1 Princpios e Prticas de Negcios
.1 Propsito
Analistas de negcios precisam compreender princpios fundamentais e melhores
prticas de negcios para garantir que sero incorporados ou apoiados por uma soluo.
.2 Definio
Os princpios de negcios so as caractersticas comuns a todas as organizaes com
propsitos e estruturas similares, estando elas, ou no, dentro da mesma indstria.
Quase todas as organizaes precisam de determinadas funes ou capacidades
para que possam operar. reas de negcios dentro do mesmo setor de mercado ou
at em outros setores frequentemente possuem um conjunto de processos de negcio
e sistemas relacionados. reas funcionais comuns incluem:
Recursos Humanos
Finanas

Conhecimento de Negcios Competncias Fundamentais
Tecnologia da Informao
Gerenciamento da Cadeia de Suprimentos
Apesar destas reas possuirem processos em comum, eles podem tambm variar
consideravelmente dependendo da indstria e tamanho da organizao (ex.:
Recursos Humanos sero guiados por diferentes influncias culturais e regulatrias,
mas existem similaridades universais em funes tais como: encontrar, reter,
aconselhar, compensar e demitir colaboradores). Outras reas, como por exemplo a
Produo, tendem a possuir demandas fundamentalmente diferentes, dependendo
do setor de mercado (ex.: agricultura versus desenvolvimento de software). A
compreenso de como outras organizaes resolveram desafios similares pode ser
til na identificao de potenciais solues.
Sinais de conhecimento em relao aos princpios e prticas de negcios incluem:
Compreenso dos ambientes de negcios, operaes, processos e prticas

relacionadas a:
Conceitos, princpios, atividades e prticas comuns sobre gerenciamento de

negcios e tomada de decises.
Estruturas organizacionais, cargos e atividades de trabalho comuns ou tpicas.
Funes e operaes complexas.
Compreenso de frameworks regulatrios, de aderncia (compliance) e de

governana.
Compreenso de questes relacionadas auditoria e segurana.
8.3.2 Conhecimento de Mercado

.1 Propsito
Analistas de negcios devem conhecer o mercado no qual a sua organizao atua
para que possam compreender novos desafios trazidos por movimentos competitivos
e quais solues se provaram eficazes em outros lugares.
.2 Definio
Conhecimento de mercado a compreenso das foras competitivas que moldam um
determinado setor de mercado. Isso requer que o analista de negcios compreenda
os vrios segmentos de consumidores que o mercado atende e as caractersticas
demogrficas, ou outras caractersticas comuns a cada segmento. Uma compreenso
das tendncias que impactam o mercado ajudar a identificar os requisitos de negcio.
Concorrentes faro mudanas em seus produtos e suas operaes em resposta a
essas mudanas, e o analista de negcios pode precisar recomendar mudanas a uma
iniciativa em andamento para responder ao de um concorrente.
Sinais de um conhecimento eficaz de mercado ou de um determinado setor do
mercado incluem:
Compreenso de assuntos relacionados ao mercado e manter-se a par do que

acontece no mercado.

Competncias Fundamentais Conhecimento de Negcios
Habilidade de identificar as principais tendncias que moldam o mercado.
Conhecimento dos principais concorrentes e parceiros da organizao.
Conhecimento dos principais segmentos de consumidores.
Conhecimento dos produtos mais comuns e dos tipos de produtos.
Conhecimento das fontes de informao a respeito de um determinado setor de

mercado, incluindo associaes ou publicaes relevantes.
Compreenso de documentos de processos e outros recursos especficos a um

determinado setor do mercado.
Compreenso dos processos e metodologias padro do mercado.
Compreenso do ambiente regulatrio de determinado setor de mercado.
8.3.3 Conhecimento da Organizao

.1 Propsito
A anlise de negcios significativamente auxiliada pela compreenso da
organizao para a qual est sendo desempenhada.
.2 Definio
O conhecimento da organizao a compreenso da arquitetura do negcio. Isso
inclui a compreenso do modelo de negcio da organizao (como a organizao gera
lucro ou atinge suas metas), a estrutura organizacional atual, os relacionamentos
existentes entre as unidades de negcio e as pessoas que cumprem a funo das
principais partes interessadas. Compreender uma organizao requer entender os
meios informais de comunicao e autoridade que costumam existir em paralelo
aos formais e o ambiente poltico interno que governa ou influencia as decises.
Sinais do conhecimento do analista de negcios em relao organizao incluem:
Compreenso da terminologia ou dos jarges utilizados na organizao.
Compreenso dos produtos ou servios oferecidos pela organizao.
Habilidade para identificar especialistas em diferentes assuntos dentro da

organizao.
Compreenso dos relacionamentos e ambiente poltico da organizao.
8.3.4 Conhecimento da Soluo

.1 Propsito
Analistas de negcios podem usar o seu conhecimento de solues existentes para
identificar os meios mais eficazes para a implementao de uma mudana.
.2 Definio
Analistas de negcios frequentemente trabalham em projetos que envolvem
aperfeioamento de uma soluo existente ou a aquisio de uma soluo
disponvel no mercado, ao invs do desenvolvimento de solues customizadas. Em
tais circunstncias, provvel que o mtodo de implementao escolhido impacte

Habilidades de Comunicao Competncias Fundamentais
significativamente no tempo e esforo necessrios para a implementao. Um

analista de negcios que conhece a soluo em questo ser capaz de identificar
e recomendar mudanas que podem ser implementadas mais facilmente, mas
que provero benefcios concretos. Familiaridade com uma variedade de
fornecedores ou de solues disponveis no mercado pode auxiliar na identificao
de potenciais alternativas.
Sinais do conhecimento til de solues incluem:
Tempo ou custo reduzidos para a implantao de uma mudana requerida.
Tempo mais curto de anlise de requisitos e/ou desenho da soluo.
Compreenso de quando uma mudana maior justificada com base no

benefcio para o negcio.
Compreenso de como capacidades adicionais presentes em uma soluo, mas

no utilizadas atualmente, podem ser aplicadas para prover valor ao negcio.
8.4 Habilidades de Comunicao

8.4.1 Comunicaes Verbais
.1 Propsito
Habilidades de comunicao verbal permitem que o analista de negcios expresse
ideias de forma eficaz e apropriada para o pblico alvo.
.2 Definio
Habilidades de comunicao verbal so usadas para expressar oralmente ideias,
informaes ou outras questes. Comunicaes verbais so um rico canal que
permite uma eficiente transferncia de informao, incluindo emoes e outras
informaes no-verbais. Habilidades eficazes de comunicao verbal incluem
tanto a habilidade de se fazer compreender quanto a habilidade de ouvir ativamente,
o que garante a compreenso do que dito pelos outros. O analista de negcios
deve compreender como o tom de voz pode influenciar o ouvinte positiva ou
negativamente. A comunicao verbal mais eficiente quando a informao sendo
comunicada ser usada no curto prazo.
Habilidades eficazes de comunicao verbal podem ser demonstradas atravs de:
Parafrasear (repetir em seguida) de forma eficaz as frases ditas para garantir o

entendimento das mesmas.
Facilitao eficaz de reunies, garantindo o seu sucesso atravs de preparao

antecipada e coordenao durante a reunio.
Desenvolvimento e execuo de apresentaes impactantes atravs do

posicionamento apropriado do contedo e dos objetivos (ex.: tom positivo versus
tom negativo).
Habilidade de comunicar a criticidade ou urgncia de uma situao de maneira

calma e racional em conjunto com solues propostas.

Competncias Fundamentais Habilidades de Comunicao
8.4.2 Ensino
.1 Propsito
Habilidade para ensinar faz com que analistas de negcios possam comunicar
requisitos e questes a serem resolvidas de forma eficaz e garantir que a informao
comunicada ser compreendida e retida.
.2 Definio
Ensinar requer uma compreenso de como as pessoas aprendem e a habilidade
de usar esta compreenso para que o aprendizado acontea de forma eficaz. A
comunicao eficaz de requisitos requer habilidade para ensinar, uma vez que
frequentemente o analista de negcios deve educar os especialistas a respeito do
contexto no qual uma soluo ser implantada. Um analista de negcios deve
conhecer os diferentes estilos de aprendizado, incluindo:
Aprendiz visual (quem aprende mais facilmente atravs da apresentao de

guias e modelos visuais).
Aprendiz auditivo (quem aprende mais facilmente atravs da comunicao

verbal e linguagem escrita).
Aprendiz sinestsico (quem aprende mais facilmente executando algo).
O analista de negcios deve compreender como diferentes estilos de aprendizado

influenciam a forma de comunicao dos requisitos. O analista de negcios pode
tambm ensinar s partes interessadas como utilizar tcnicas de anlise, permitindo
que participem mais e de forma mais direta no processo de anlise. Ensino eficaz
tambm requer uma compreenso dos mtodos utilizados para confirmar que um
aluno aprendeu e que pode aplicar esse aprendizado.
Habilidades eficazes de ensino podem ser demonstradas atravs da:
Verificao de que os alunos adquiriram informaes a eles repassadas.
Capacidade dos alunos de utilizarem as novas habilidades ou de demonstrarem

os novos conhecimentos.
8.4.3 Comunicaes Escritas

.1 Propsito
Habilidades de comunicao escrita so necessrias para que os analistas de
negcios documentem resultados da elicitao e outras informaes quando
registro ou armazenamento de mdio a longo prazo so necessrios.
.2 Definio
Comunicao escrita envolve o uso de smbolos para comunicar informao. Isso
inclui a habilidade de escrever de forma eficaz para vrios contextos e pblicos. A
comunicao escrita necessria quando a informao ser usada em um momento
ou local diferente do momento ou local onde ela foi criada. A comunicao escrita
eficaz requer que o analista de negcios possua um amplo vocabulrio, compreenso
de gramtica e estilo e tambm de quais expresses ou termos sero mais facilmente
compreendidos pelo pblico alvo. As comunicaes escritas tornam possvel o
registro de uma grande quantidade de informaes, porm frequentemente
desafiador garantir que o texto escrito seja corretamente compreendido.

Habilidades de Interao Competncias Fundamentais
Habilidades de comunicao escrita eficazes podem ser demonstradas atravs de:
Habilidade de ajustar o estilo de escrita s necessidades do pblico alvo.
Uso apropriado de gramtica e estilo.
Escolha apropriada de palavras.
Habilidade do leitor de parafrasear o que leu e descrever o contedo da

comunicao escrita.
8.5 Habilidades de Interao

8.5.1 Facilitao e Negociao
.1 Propsito
Analistas de negcios facilitam interaes entre partes interessadas no intuito de
auxili-las a solucionar desacordos relacionados prioridade e natureza dos requisitos.
.2 Definio
Facilitao a habilidade de moderar discusses entre um grupo para permitir que
todos os participantes articulem os seus pontos de vista de forma eficaz a respeito
do tpico em discusso e garantir que os participantes reconheam e apreciem os
diferentes pontos de vista que forem articulados. Em muitos casos, uma discusso
facilitada de forma eficaz levar os participantes a reconhecer que eles possuem
vises diferentes a respeito do tpico em discusso. O analista de negcios pode
ser chamado para apoiar a negociao entre as partes, com o objetivo de resolver
as diferenas da melhor maneira possvel. O analista de negcios deve ser capaz de
identificar os verdadeiros interesses de cada parte, de distinguir entre os verdadeiros
interesses e o que foi abertamente declarado, e auxiliar as partes a identificar
solues que satisfaam seus verdadeiros interesses.
Habilidades eficazes de facilitao e de negociao so demonstradas atravs de:
Garantia de que todos os participantes em uma discusso compreendem

corretamente as posies uns dos outros.
Utilizao de habilidades e ferramentas de gerenciamento de reunies (incluindo

pautas e atas de reunio para manter as discusses focadas e organizadas).
Preveno de que discusses sejam desviadas para tpicos irrelevantes.
Identificao de reas de comum acordo.
Uso efetivo de diferentes estilos de negociao.
Habilidade para identificar questes importantes.
Compreenso e considerao dos interesses, motivaes e objetivos de todas as

partes.
Encorajamento das partes interessadas em alcanar de forma regular resultados

ganha-ganha.

Competncias Fundamentais Habilidades de Interao
Compreenso de implicaes polticas em conflitos e negociao de uma

maneira politicamente sensvel.
Compreenso do impacto do tempo e do momento nas negociaes.
8.5.2 Liderana e Influncia

.1 Propsito
Analistas de negcios precisam ser eficazes em papis de liderana formal e
informal para guiar outros na investigao dos requisitos e para encorajar as partes
interessadas a apoiarem uma mudana necessria.
.2 Definio
A responsabilidade do analista de negcios em definir e comunicar requisitos
o colocar numa funo de liderana em qualquer grupo ou equipe de projeto,
havendo ou no pessoas subordinadas diretamente a ele.
Liderana envolve motivar pessoas a agir de maneira que as permita trabalharem

juntas para atingir metas e objetivos em comum. O analista de negcios deve
compreender as necessidades e capacidades de cada membro da equipe e de cada
parte interessada e como estas necessidades e capacidades podem ser efetivamente
canalizadas para alcanar os objetivos em comum. Liderana eficaz requer, portanto,
que o analista de negcios seja capaz de definir uma viso do estado futuro desejado
que motive as pessoas a trabalhar e que ele possua as habilidades interpessoais
necessrias para encoraj-las nesse sentido.
Habilidades de liderana e de influncia eficazes so demonstradas atravs de:
Reduo de resistncia s mudanas necessrias.
Demonstrao por parte dos membros da equipe e das partes interessadas de

sua disposio para deixar de lado objetivos pessoais quando necessrio.
Articulao de uma viso clara e inspiradora do estado futuro desejado.
8.5.3 Trabalho em Equipe

.1 Propsito
Analistas de negcios devem ser capazes de trabalhar com outras pessoas e
apoiar o trabalho de outros membros da equipe para que as solues possam ser
implementadas de forma eficaz.
.2 Definio
Analistas de negcios geralmente trabalham como parte de uma equipe
juntamente com outros analistas de negcios, gerentes de projetos, outras partes
interessadas e especialistas na implementao de solues. Os relacionamentos
entre integrantes de uma equipe so uma parcela importante do sucesso de
qualquer projeto ou organizao.
Existem vrios modelos de desenvolvimento de equipes que tentam explicar

como equipes se formam e funcionam. Esses modelos descrevem o progresso de
uma equipe e o que normalmente acontece em vrios estgios do ciclo de vida da
equipe. Reconhecer o estgio do progresso da equipe pode diminuir o estresse
no desenvolvimento do relacionamento da equipe, permitindo que os membros

Aplicativos de Software Competncias Fundamentais
reconheam certos comportamentos como normais, esperados e como parte

de um estgio a ser trabalhado. As comunicaes e a confiana podem tambm
ser aperfeioadas atravs da compreenso e conscincia dos seguintes aspectos:
definio de regras para a equipe, tomada de decises pela equipe, liderana formal
e informal, e papis de gerenciamento.
Conflitos nas equipes so comuns. Se gerenciados corretamente, a resoluo

de um conflito pode at beneficiar a equipe. Os tipos bsicos de conflitos so os
emocionais e os cognitivos. Conflitos emocionais emanam das interaes pessoais,
enquanto conflitos cognitivos so baseados em divergncias sobre questes de
valor ou impacto no projeto ou organizao. A resoluo de conflitos cognitivos
requer que a equipe reveja as premissas, suposies, observaes e expectativas dos
membros. Resolver tais problemas pode ter um efeito benfico, reforando as bases
para anlise e soluo. Muitas situaes de conflito envolvem elementos tanto
emocionais quanto cognitivos.
Habilidades de trabalho em equipe eficazes so demonstradas atravs de:
Ambiente de trabalho colaborativo e encorajador.
Resoluo eficaz de conflitos.
Desenvolvimento da confiana entre os membros da equipe.
Apoio da equipe para alcanar objetivos comuns.
Senso compartilhado de propriedade das metas da equipe.
8.6 Aplicativos de Software

8.6.1 Aplicativos de Uso Geral
.1 Propsito
Analistas de negcios utilizam aplicativos de uso geral para documentar e rastrear
requisitos.
.2 Definio
Estes aplicativos geralmente incluem trs componentes: processamento de
texto, planilhas e softwares de apresentao. Os documentos produzidos por
essas ferramentas so basicamente a forma como informaes so armazenadas
e distribudas em muitas organizaes. Analistas de negcios precisam ser
proficientes no uso de ferramentas genricas, mesmo onde ferramentas mais
especializadas estiverem disponveis. Elas possuem a vantagem de serem de baixo
custo ou at mesmo gratuitas. Alm disso, quase todas as partes interessadas tm
acesso a elas.
Processadores de texto so usados para desenvolver e manter documentos

de requisitos. Eles permitem um bom nvel de controle sobre a formatao da
apresentao do documento. Modelos padro para documentao de requisitos
esto disponveis para processadores de texto. A maior parte das ferramentas de
processamento de texto possui a capacidade limitada de rastrear mudanas e de
registrar comentrios e no so desenhadas para autoria colaborativa.

Competncias Fundamentais Aplicativos de Software
Planilhas so utilizadas para manter listas (como requisitos, funcionalidades, aes,

questes ou defeitos). Planilhas so a melhor escolha para a captura e manipulao
de dados numricos atravs de algoritmos rudimentares. Elas podem tambm
ser usadas para apoiar a anlise decisria e so muito eficientes na sumarizao
de cenrios complexos. Planilhas tambm apoiam o rastreamento limitado de
mudanas e podem ser compartilhadas entre mltiplos usurios como ocorre com
um documento de processamento de texto.
Softwares de apresentao so usados para apoiar treinamento ou para introduzir

tpicos para a discusso entre partes interessadas. Enquanto alguns desses
aplicativos podem ser usados de forma muito limitada para capturar requisitos
ou para simular prottipos de baixa fidelidade, o seu propsito primrio apoiar a
estruturao e entrega de informaes verbais.
Ferramentas de colaborao e gesto do conhecimento so usadas para apoiar

a captura do conhecimento distribudo atravs da organizao e torn-lo mais
acessvel. Elas permitem que documentos estejam disponveis para toda uma equipe
e facilitam a colaborao para a gerao e manuteno de documentos. Permitem
tambm que muitos usurios trabalhem num documento de forma simultnea e
geralmente suportam comentrios e discusso a respeito dos documentos e seus
contedos. Essas ferramentas podem ser repositrios de documentos (integradas
aos aplicativos de edio de documentos), wikis (que permitem a fcil criao e
vnculos entre pginas da web), fruns de discusso ou outras ferramentas baseadas
na web. Seu custo varia muito.
Ferramentas de comunicao, como e-mail e aplicativos de mensagens instantneas

so usadas para a comunicao com partes interessadas que esto localizadas
remotamente, que no podem responder a perguntas imediatamente, ou que
precisam que as informaes sejam registradas ou armazenadas para uso futuro.
Ferramentas de comunicao geralmente so muito fceis de usar e quase todas
as partes interessadas tm acesso a esse tipo de aplicativo. Contudo, elas no so
eficazes para armazenamento de longo prazo ou reteno de informao. O seu
uso primrio d-se na facilitao da comunicao distncia, em tempo real ou de
forma assncrona.
Sinais de habilidade com aplicativos de uso geral incluem:
Habilidade de aplicar o conhecimento de uma ferramenta a outras ferramentas

similares.
Capacidade de identificar as melhores ferramentas disponveis no mercado e

descrever como elas podem ser utilizadas em uma determinada situao.
Compreender e ser capaz de usar a maior parte das funcionalidades da

ferramenta.
Capacidade de usar as ferramentas para completar atividades referentes aos

requisitos mais rapidamente do que seria possvel sem elas.
Capacidade de rastrear mudanas aos requisitos realizadas atravs das

ferramentas.

Aplicativos de Software Competncias Fundamentais
8.6.2 Aplicativos Especializados

.1 Propsito
Analistas de negcios usam ferramentas de modelagem para apoiar o
desenvolvimento de modelos formais e em alguns casos tambm para a validao e
implementao de modelos.
.2 Definio
Ferramentas de diagramao facilitam o desenho e a rpida documentao de um
modelo, tipicamente provendo exemplos ou templates que seguem uma notao
particular. Elas geralmente no impem ou verificam a utilizao de um padro de
notao ou fazem isso de forma limitada. Ferramentas de diagramao geralmente
tm baixo custo e so relativamente fceis de usar. Os diagramas gerados podem ser
integrados a um documento de texto.
Ferramentas de modelagem facilitam a converso de um modelo em algo executvel,

seja atravs da utilizao de um mecanismo para a execuo do modelo ou atravs
da gerao automtica de cdigo de software que pode ser aperfeioado por um
desenvolvedor. A ferramenta normalmente verifica o uso de notao especfica. Entre
as ferramentas de modelagem que geram modelos executveis esto os sistemas de
gerenciamento de processos de negcios (que permitem que o aplicativo execute
os modelos de processos) e os sistemas de gerenciamento de regras de negcios
(que permitem a imposio das regras de negcios capturadas). Ferramentas de
modelagem tm custo mdio ou alto e frequentemente requerem treinamento
especializado para o seu uso.
Ferramentas de gerenciamento de requisitos so usadas para controlar mudanas,

rastrear requisitos, gerenciar a configurao de requisitos e para gerenciar artefatos
relacionados a requisitos. Algumas ferramentas so tambm capazes de vincular
requisitos ao cdigo de software. Elas so desenhadas para garantir que sejam
registrados os motivos para qualquer mudana nos requisitos e para rapidamente
identificar quaisquer impactos provenientes dessas mudanas. Elas so de mdio ou
alto custo e frequentemente requerem treinamento especializado. Ferramentas de
gerenciamento de requisitos so mais comumente utilizadas por equipes grandes e/
ou geograficamente dispersas.
Sinais de habilidade com aplicativos especializados incluem:
Habilidade de aplicar o conhecimento de uma ferramenta a outras ferramentas

similares.
Capacidade de identificar as melhores ferramentas disponveis no mercado e

descrever como elas podem ser utilizadas em uma determinada situao.
Compreender e ser capaz de usar a maior parte das funcionalidades da

ferramenta.
Capacidade de usar as ferramentas para completar as atividades referentes aos

requisitos mais rapidamente do que sem elas.
Capacidade de rastrear mudanas nos requisitos realizadas atravs das

ferramentas.

Tcnicas
Captulo NOVE
O captulo de Tcnicas oferece uma viso geral de alto nvel das tcnicas referenciadas
nas reas de conhecimento do Guia BABOK. As tcnicas alteram a forma com a
qual uma tarefa da anlise de negcios desempenhada ou descrevem uma forma
especfica de sada que uma tarefa pode assumir.
As tcnicas listadas aqui so apenas um subconjunto das tcnicas usadas pelos

praticantes da anlise de negcios. As listadas aqui so aplicveis a situaes e
domnios do negcio suficientemente diferentes e tm sido adotadas por uma
parcela significante de praticantes de anlise de negcios de forma que se espera
que um generalista habilidoso esteja familiarizado com a existncia e propsito da
tcnica. Analistas de negcios que se especializam em uma metodologia ou domnio
do negcio em particular precisam compreender um conjunto menor de tcnicas
com maior profundidade ou podem ter que desenvolver expertise em tcnicas no
descritas aqui.
Em alguns casos, ns agrupamos um conjunto de tcnicas conceitualmente similares

dentro de um nico item. Isso foi feito para indicar que qualquer uma das tcnicas
que esto listadas naquele item (ou mesmo variaes que no esto especificamente
mencionadas) podem ser teis para aquele propsito. Enquanto existem certamente
importantes diferenas tericas e prticas entre essas variaes, a maior parte dos
praticantes vai achar que a expertise em apenas uma delas suficiente dentro de
qualquer ambiente em particular.
9.1 Definio dos Critrios de Aceite e Avaliao

9.1.1 Propsito
Definir os requisitos que devem ser atendidos para que a soluo seja considerada
aceitvel pelas partes interessadas.
9.1.2 Descrio
Determinar quais requisitos podem ser efetivamente mais usados como critrios de
aceite ou avaliao.
Critrios de aceite descrevem o conjunto mnimo de requisitos que devem

ser atendidos para que valha a pena que uma soluo em particular seja
implementada.
Critrios de avaliao so o conjunto de requisitos que ser usado para escolher

entre mltiplas solues.
Tanto critrios de aceite quanto de avaliao podem ser usados para determinar se
uma soluo ou componente de soluo pode ser considerado objetivamente como
atendendo a um requisito. Critrios de aceite so tipicamente usados quando apenas
uma soluo possvel est sendo avaliada e so geralmente expressos como aprovado
ou reprovado. Critrios de avaliao so usados para comparar mltiplas solues
ou componentes de solues e seguem um espectro de possveis notas.

Benchmarking Tcnicas
9.1.3 Elementos
.1 Testabilidade
Os critrios de aceite e avaliao, ainda mais do que outros requisitos, devem ser
expressos em uma forma testvel. Isso pode exigir que sejam detalhados em uma
forma atmica para que casos de teste possam ser escritos para testar a soluo em
funo dos critrios.
.2 Determinar ranqueamento e pontuao

Ranqueamento o processo de determinar a ordem de importncia para todos os
requisitos, como descrito em Priorizar requisitos (6.1). A tcnica MoSCoW til para este
propsito. Um critrio Deve ter um que remover a soluo proposta de considerao
caso no atendido. Nveis mais baixos de prioridade recebero ranking mais baixo.
Pontuao o processo de determinar o quo bem uma soluo atende um requisito.

Uma escala deve ser estabelecida para pontuar cada requisito e mltiplos nveis
possveis de pontuao definidos.
Em ambos os casos, as partes interessadas devem concordar no somente com os

critrios, mas tambm com a avaliao da soluo em relao a eles.
9.1.4 Consideraes de uso

.1 Vantagens
Metodologias geis podem requerer que todos os requisitos sejam expressos em
critrios de aceite testveis.
Critrios de aceite so tambm necessrios quando os requisitos expressam

obrigaes contratuais.
.2 Desvantagens
Critrios de aceite e avaliao podem expressar obrigaes contratuais de forma
que seja difcil a mudana, tanto por razes legais, quanto polticas.
9.2 Benchmarking
9.2.1 Propsito
Os estudos de benchmarking so realizados para comparar as foras e as fraquezas
de uma organizao em relao aos seus pares e concorrentes.
9.2.2 Descrio
Os estudos de benchmarking so conduzidos para comparar prticas
organizacionais com as melhores prticas que existem nas empresas concorrentes,
no governo ou na indstria. O objetivo dos estudos de benchmarking determinar
como as companhias alcanam seus nveis superiores de performance e usam
essa informao para desenhar projetos para melhorar as operaes da empresa.
Benchmarking normalmente focado em estratgias, operaes e processos.
9.2.3 Elementos
O benchmarking requer que o analista de negcios:
Identifique a rea a ser estudada
Identifique as organizaes que so lderes no setor

Tcnicas Brainstorming
Conduza uma pesquisa nas organizaes selecionadas para compreender as

suas prticas
Organize visitas s melhores organizaes
Desenvolva uma proposta de projeto para implementar as melhores prticas

.1 Vantagens
O benchmarking oferece para as organizaes informaes sobre novos e diferentes
mtodos, ideias e ferramentas para melhorar o desempenho organizacional.
.2 Desvantagens
O benchmarking consome tempo. Alm disso, as organizaes podem no ter
o conhecimento necessrio para conduzir a anlise e adquirir ou interpretar
informaes teis competitivas.
Uma vez que envolve a avaliao de solues que funcionaram em outros lugares,
com o objetivo de reproduzi-las, o benchmarking no pode produzir solues
inovadoras ou solues que produziro uma vantagem competitiva sustentvel.
9.3 Brainstorming
9.3.1 Propsito
O brainstorming uma excelente forma de fomentar pensamento criativo acerca de
um problema. O alvo do brainstorming produzir numerosas novas ideias e derivar
delas temas para anlise futura.
9.3.2 Descrio
O brainstorming uma tcnica dedicada a produzir um conjunto amplo ou diverso
de opes. O brainstorming auxilia na resposta a questes especficas como (mas
no limitado a):
Quais opes esto disponveis para atuar sobre a questo em mos?
Quais fatores esto impedindo o grupo de avanar com uma abordagem ou

opo?
O que poderia estar causando um atraso na atividade A?
O que o grupo pode fazer para resolver o problema B?
O brainstorming funciona atravs do foco em um tpico ou problema e, ento,

levantando vrias solues possveis para ele. Esta tcnica melhor aplicada em
grupo porque se alimenta da experincia e criatividade de todos os seus membros.
Na ausncia de um grupo, uma pessoa poderia fazer brainstorming sozinha
para desencadear suas prprias ideias novas. Para despertar a criatividade, os
participantes so encorajados a usar novas formas de olhar as coisas e fazer
associaes livres em qualquer direo.
Quando facilitado de forma correta, o brainstorming pode ser divertido, envolvente

e produtivo.

Brainstorming Tcnicas
9.3.3 Elementos
.1 Preparao
Desenvolver uma definio clara e concisa da rea de interesse.
Determinar um limite de tempo para o grupo gerar ideias; quanto maior for o
grupo, mais tempo necessrio.
Identificar o facilitador e os participantes da sesso. Procure por participantes

(o ideal entre 6 e 8) que representam amplo conhecimento e experincia em
relao ao tpico.
Definir as expectativas junto aos participantes e conseguir com que eles se

envolvam com o processo.
Estabelecer critrios para avaliao e ranqueamento das ideias.
.2 Sesso
Compartilhe novas ideias sem nenhuma discusso, criticismo ou avaliao.
Registre visivelmente todas as ideias.
Encoraje os participantes a serem criativos, compartilhar ideias exageradas e

construir sobre as ideias dos demais.
No limite o nmero de ideias, uma vez que o objetivo elicitar tantas quantas o
perodo de tempo permitir.
.3 Fechamento
Uma vez que o limite de tempo alcanado, usando os critrios de avaliao pr-
determinados, discuta e avalie as ideias.
Crie uma lista condensada de ideias, combine ideias quando apropriado e

elimine duplicatas.
Ordene as ideias. Distribua a lista final de ideias s partes apropriadas.

.1 Vantagens
Habilidade de elicitar muitas ideias em um curto perodo de tempo.
Ambiente livre de julgamentos permite pensamento criativo.
Pode ser til durante um workshop para reduzir a tenso entre os participantes.
.2 Desvantagens
Dependente da criatividade ou disposio dos participantes. Polticas
organizacionais ou interpessoais tambm podem limitar a participao.
Participantes devem concordar em evitar debater as ideias surgidas durante o

brainstorming.

Tcnicas Anlise de regras de negcio
9.4 Anlise de regras de negcio

9.4.1 Propsito
Definir as regras que governam as decises em uma organizao e que definem,
restringem ou possibilitam as operaes organizacionais.
9.4.2 Descrio
Polticas e regras direcionam e restringem a organizao e a sua operao.
Uma poltica do negcio uma diretiva no-acionvel que apoia um objetivo do
negcio. Uma regra de negcio uma diretiva especfica, acionvel e testvel
que est sob o controle de uma organizao e que apoia uma poltica do negcio.
Regras particularmente complexas, ou regras com uma quantidade razovel
de dependncias inter-relacionadas, podem ser expressas como uma tabela de
deciso ou como uma rvore de deciso, como descrito em Anlise de deciso (9.8).
Um conjunto de princpios bsicos guia o analista de negcios quando so declaradas

ou gerenciadas as regras de negcio. As regras de negcio devem ser:
Declaradas em terminologia apropriada para permitir que especialistas no

assunto validem as regras;
Documentadas independentemente de como elas sero impostas;
Declaradas em nvel atmico e em formato declarativo;
Separadas dos processos que a regra apoia ou restringe;
Mantidas de forma que permita que a organizao monitore e adapte as regras

conforme as polticas do negcio mudam.
9.4.3 Elementos
Regras de negcio requerem um glossrio definido de termos e uma compreenso
de como os relacionamentos entre elas, conhecidos como um modelo de termos
e fatos (ver Dicionrio de dados e glossrio (9.5) e Modelagem de dados (9.7) para
mais informaes). No intuito de garantir que elas so independentes de qualquer
implementao, as regras no devem depender de nenhuma informao adicional,
ou incluir suposies sobre como elas sero impostas.
.1 Regras operativas
Regras operativas so regras que a organizao escolhe para impor como uma
questo de poltica. Elas so destinadas a guiar as aes das pessoas que trabalham
dentro da organizao. Elas podem obrigar as pessoas a tomar certas aes, evitar
que as pessoas tomem certas aes ou prescrever condies sob as quais uma
ao deva ser tomada. Por definio, deve ser possvel para as pessoas violar uma
regra operativa, mesmo quando no h circunstncias sob as quais a organizao
aprovaria este ato. Um exemplo de regra operativa :
Um pedido no deve ser tirado quando o endereo de cobrana fornecido pelo cliente
no corresponder com o endereo registrado na companhia do carto de crdito.
Uma vez que possvel violar uma regra operativa, uma anlise posterior pode ser
conduzida para determinar quais tipos de sanes devem ser impostas quando uma
regra violada, permitir que uma regra seja desconsiderada (antes ou depois do fato)

Dicionrio de dados e glossrio Tcnicas
ou as circunstncias nas quais uma exceo regra apropriada. Isso pode levar
definio de regras adicionais.
.2 Regras estruturais
Regras estruturais so destinadas a auxiliar na determinao de quando algo ,
ou no, verdadeiro, ou quando as coisas se encaixam dentro de uma categoria
especfica. Elas so expressas como regras porque elas descrevem categorizaes
que podem mudar ao longo do tempo. Uma vez que elas estruturam o conhecimento
da organizao, e no o comportamento das pessoas, elas no podem ser violadas
(porm, podem ser mal aplicadas). Um exemplo de regra estrutural :
Um pedido deve ter relacionado um e apenas um mtodo de pagamento.

.1 Foras
Definir e estruturar claramente as regras permite que as organizaes faam mudanas
poltica sem alterar processos. O impacto das mudanas s regras de negcio pode
ser avaliado mais facilmente quando elas so documentadas separadamente dos
processos que elas detalham, ou dos meios usados para impor as regras.
.2 Fraquezas
Organizaes podem produzir longas listas de regras de negcio. Regras de negcio
podem contradizer umas s outras ou produzir resultados imprevistos quando
combinadas. Pode ser tambm importante questionar regras de negcio existentes
em relao sua contnua relevncia em relao a modos atuais ou projetados de
operaes e estrutura organizacionais.
9.5 Dicionrio de dados e glossrio

9.5.1 Propsito
Um dicionrio de dados ou glossrio define os principais termos e dados relevantes
para um domnio do negcio.
9.5.2 Descrio
Dicionrios de dados e glossrios so usados para identificar formalmente e definir
toda a terminologia usada pela organizao ou unidade organizacional. Por exemplo,
uma unidade organizacional pode diferenciar entre cliente e consumidor, onde um
cliente uma parte com a qual o negcio possui um acordo de servio, enquanto
um consumidor pode possuir um relacionamento muito mais casual e baseado em
transaes com o negcio. Em uma organizao de sade, como um hospital, o termo
paciente pode ser usado como definio nica, no lugar de cliente ou consumidor.
9.5.3 Elementos
.1 Glossrio
Um glossrio documenta termos nicos para o domnio. Ele criado para garantir
que todas as partes interessadas compreendam o que se pretende dizer quando
certa palavra empregada. Um glossrio consiste de um termo relevante e uma
nica definio para cada domnio, como tambm apelidos de referncia cruzada.
.2 Dicionrio de dados
Dicionrios de dados incluem definies-padro para elementos de dados, seus
significados e valores permitidos. Um dicionrio de dados contm definies de

Tcnicas Diagramas de fluxos de dados
cada elemento primitivo de dados e indica como esses elementos se combinam em

elementos compostos de dados.
Elementos de dados primitivos

As seguintes informaes devem ser registradas a respeito de cada elemento de
dados no dicionrio de dados:
Nome: um nico nome para cada elemento de dados, que ser referenciado pelos
elementos de dados compostos.
Apelidos: Nomes alternativos para o elemento de dados usados pelas diferentes

Valores/Significados: uma lista de valores para o elemento de dados. Isso pode

ser expresso como uma lista enumerada ou como uma descrio dos formatos
permitidos para o dado (incluindo informaes como o nmero de caracteres).
Se os valores so abreviados, haver uma explicao do significado.
Descrio: A definio do elemento de dados no contexto da soluo.
Elementos de dados compostos
Dados compostos so montados a partir de elementos de dados primitivos.

Estruturas compostas incluem:
Sequncias: mostram dados primitivos em ordem. Os elementos primitivos

devem ocorrer em uma ordem especfica.
Repeties: mostram que um ou mais elementos primitivos de dados devem

ocorrer mltiplas vezes no elemento composto.
Elementos opcionais: podem ou no ocorrer em uma instncia particular do

elemento de dados.

Um dicionrio de dados ou glossrio til para garantir que todas as partes
interessadas concordam com o formato e contedo de informaes relevantes.
Capturar essas definies em um nico modelo garante que esses termos sero
usados consistentemente.
9.6 Diagramas de fluxos de dados

9.6.1 Propsito
Apresentar como a informao inserida, processada, armazenada e retirada de
um sistema.
9.6.2 Descrio
O Diagrama de Fluxo de Dados (DFD) fornece uma representao visual de como a
informao movida atravs do sistema. Ele mostra:
As entidades externas que fornecem dados para, ou recebem dados de, um

sistema;
Os processos do sistema que transformam os dados;

Diagramas de fluxos de dados Tcnicas
Os depsitos de dados nos quais os dados so colecionados por algum perodo

de tempo;
Os fluxos de dados atravs dos quais os dados se movem entre entidades

externas, processos e depsitos de dados.
9.6.3 Elementos
.1 Entidades externas
Uma entidade externa uma fonte ou destino de dados. Ela representada como um
retngulo rotulado.
.2 Depsito de dados
Um depsito de dados representa a localizao onde um dado no est se movendo
ou sendo transformado, mas est sendo armazenado passivamente para uso futuro.
Depsitos de dados so representados como um rtulo entre duas linhas paralelas
ou um retngulo rotulado com um quadrado.
.3 Processo de dados
Um processo de dados um processo que transforma os dados de alguma forma,
seja combinando, convertendo, filtrando os dados, ou outra atividade do gnero.
Um asterisco dentro do processo usado para identificar processos de dados que
possuem modelos de decomposio. Processos so representados como um crculo
ou retngulo arredondado com um rtulo. O rtulo padro utiliza uma estrutura de
verbo-objeto.
.4 Fluxo de dados
Um fluxo de dados identifica onde os dados esto sendo movidos entre um
processo de dados e uma entidade externa, um depsito de dados ou outro
processo de dados. O nome do fluxo deve ser um substantivo que identifica os
dados sendo movidos. Ele pode ser especificado mais detalhadamente como fluxos
de resultado, de controle e de atualizao. Fluxos de dados so representados por
uma linha simples bipartida, com uma seta. As linhas devem ser rotuladas com
uma descrio dos dados sendo movidos.

Diagramas de Fluxo de Dados so usados como parte de uma abordagem de anlise
estruturada. Eles podem ser usados para compreender o alcance dos dados dentro
do domnio. Eles so tipicamente usados aps a criao de um diagrama de contexto
e como um pr-requisito ou atividade concorrente da modelagem de dados.
.1 Pontos Fortes
Pode ser usada como tcnica de descoberta de processos e dados, ou como uma
tcnica para a verificao de uma Decomposio funcional (9.12) ou Modelo de
dados (9.7) que j tenha sido completado.
A maior parte dos usurios considerar esses diagramas fceis de compreender.
Geralmente considerado uma entrega til para os desenvolvedores em um

ambiente de programao estruturada.
.2 Pontos fracos
DFDs no podem apresentar facilmente quem responsvel por desempenhar o
trabalho. Eles no podem mostrar caminhos alternativos para o mesmo processo.

Tcnicas Modelagem de dados
Figura 9-1: Diagrama de Fluxo de Dados (Notao de Gane-Sarson)

1 2
Pacote de Pacote de
Dados de
Verbo Verbo Dados de
Entrada do Substantivado Sada para
Diagrama Pai Substantivado Diagrama Pai
(Entrada de Frase Nominal Frase Nominal (Sada de
Sistema 1) Processo 1 Processo 2 Sistema 1)
Pacote de
Entrada de Dados
Pacote de Sada
de Dados
Depsito
de Dados
Figura 9-2: Diagrama de Fluxo de Dados (Notao de Yourdon)
Sada de Dados Depsito de

Entrada de Dados
Entidade Dados
Externa
Processameto
de Dados
9.7 Modelagem de dados

9.7.1 Propsito
O propsito de um modelo de dados descrever os conceitos relevantes de um
domnio, os relacionamentos entre esses conceitos e as informaes associadas a eles.
9.7.2 Descrio
Um modelo de dados normalmente toma a forma de um diagrama, apoiado por descries
textuais. Ele representa visualmente os tipos de pessoas, lugares, coisas e conceitos que
so importantes para o negcio, os atributos associados a eles e os relacionamentos
significativos entre eles. Modelos de dados so frequentemente apoiados por um
Dicionrio de dados e Glossrio (9.5) e pela Anlise de Regras de Negcio (9.4).
Os dois tipos de modelos de dados mais utilizados so o Diagrama de Entidade-

Relacionamento (DER) e o Diagrama de Classes, contudo, outras notaes de
modelagem mantm-se em uso. A notao utilizada frequentemente determinada
pela plataforma de tecnologia da organizao. Geralmente DERs so preferidos quando
o modelo for usado como base para um banco de dados relacional, enquanto diagramas
de classes so preferidos para apoiar o desenvolvimento orientado a objetos. Analistas
de negcios que tero de usar esses modelos devem compreender as caractersticas
especficas de cada tipo de modelo de dados eles servem para propsitos similares,
mas tm algumas importantes diferenas conceituais que surgem na prtica.

Modelagem de dados Tcnicas
9.7.3 Elementos
Modelo lgico de dados descreve as informaes relevantes para uma organizao.
Modelo lgico de dados de alto nvel pode focar somente nas descries das
entidades, atributos e relacionamentos de maior importncia. Modelo lgicos de
dados detalhado comunica descries abrangentes de todas as entidades, atributos
e relacionamentos. Modelo fsico de dados descreve como os dados so armazenados
e gerenciados em um aplicativo de software.
.1 Conceito
Um conceito algo de significncia para o domnio que est sendo descrito, de cujos
dados a a organizao necessita.
Cada tipo de conceito deve ter um identificador nico (um tipo de atributo) que
diferencia entre instncias reais do conceito. Conceitos so referenciados como
entidades em DERs e como classes em um diagrama de classes.
.2 Atributos
Um atributo define uma determinada parte da informao associada a um conceito
o quanto de informao pode ser capturada nele, os valores permitidos e o tipo de
informao que ele representa.
Figura 9-3: Diagrama Entidade-Relacionamento (Notao P de Galinha)

Cada entidade mostrada O identificador nico da
como um retngulo com o entidade apresentado abaixo
nome da entidade do nome da entidade
relacionamento da
Entidade 1 esquerda para a direita Entidade 2
Identificador nico Identificador nico
relacionamento da direita
Atributo Atributo
para a esquerda
Entidade 3 Entidade 4
Identificador nico Identificador nico
Atributo 1 Chave Estrangeira
Atributo 2 Atributo
Relacionamentos so
Os atributos da entidade indicados por uma linha, com
esto listados abaixo do smbolos nas pontas para
identificador nico mostrar cardinalidade
Cardinalidade
Entidade Entidade Entidade Entidade

Qualquer nmero Zero ou Um Somente Um Qualquer nmero
(zero a muitos) de um a muitos

Tcnicas Modelagem de dados
Nome: um nico nome para o atributo. Outros nomes usados pelas partes
interessadas podem ser capturados como aliases.
Valores/Significados: uma lista de valores aceitveis para o atributo. Isso pode

ser expresso como uma lista enumerada ou como uma descrio dos formatos
permitidos para o dado (incluindo informaes como o nmero de caracteres). Se os
valores so abreviados, haver uma explicao do significado.
Descrio: A definio do atributo no contexto da soluo.
.3 Relacionamento
Relacionamentos so associaes significativas do negcio entre conceitos. O
exemplo mostra os relacionamentos entre o Analista de Negcios e o Requisito
como uma linha rotulada. Os rtulos explicam a natureza do relacionamento sob a
perspectiva de cada entidade.
Os relacionamentos definem como a informao usada na operao do negcio

e indicam os vnculos importantes que precisam ser gerenciados e mantidos
na soluo. Os relacionamentos podem tambm indicar a cardinalidade ou
multiplicidade do relacionamento (ex.: o nmero de relacionamentos permitidos
ou requeridos).
.4 Metadado
Os metadados so definidos como dados a respeito de dados. Os metadados
descrevem o contexto, uso e validade da informao de negcio e geralmente
usado para determinar quando e porque uma informao armazenada em um
sistema foi alterada.
Figura 9-4: Diagrama de Classes (UML)

O nome da classe listado aqui. Pode Os relacionamentos so
opcionalmente ter um esteretipo que indicados por uma linha que
define propriedades adicionais. tambm pode mostrar a
multiplicidade.
<<Esteretipo>>
Classe 1 Classe 2
Atributo 1: Atributo 1
Tipo de Dados 1 0..* Atributo 2
Atributo 2: Atributo 3
Tipo de Dados Atributo 4
Operao 1
Operao 2
Operao 3 Os atributos da classe so
listados em uma caixa abaixo do
nome. Operaes so listadas
abaixo dos atributos.
Multiplicidade
* X X..Y 1..*
Classe Classe Classe Classe
Qualquer nmero Deve ser Qualquer nmero Qualquer nmero
(zero a muitos) exatamente X de X a Y de um a muitos

Anlise de deciso Tcnicas

.1 Vantagens
Modelos de dados oferecem a flexibilidade em diferentes nveis de descrio. Eles
fornecem uma abordagem consistente de modelagem que apoia a transio entre
planejamento, anlise, desenho e implementao.
Uma vez que possuem uma forte base em conceitos matemticos, modelos de dados
so suportados por regras rigorosas de correo (exatido) e integridade. Isso
incentiva a acuidade no desenvolvimento dos modelos.
.2 Desvantagens
Modelos de dados podem ser complexos e eles lidam com conceitos que podem no
ser familiares para pessoas sem um histrico dentro da Tecnologia da Informao.
Se no forem apresentados corretamente, pode ser difcil para os usurios entend-
los e relacionar-se com eles. Termos e definies podem variar o uso em diferentes
unidades ou domnios organizacionais.
9.8 Anlise de deciso

9.8.1 Propsito
Apoiar a tomada de deciso em situaes complexas, difceis e incertas.
9.8.2 Descrio
A Anlise de Deciso uma abordagem de tomada de deciso que examina e modela
as possveis consequncias de diferentes decises. A anlise de deciso auxilia na
tomada de uma deciso otimizada sob condies de incerteza. A incerteza pode
existir por causa de fatores desconhecidos que so relevantes para o problema de
deciso, porque existem muitos fatores inter-relacionados para considerar, por
causa de perspectivas conflitantes de uma situao, ou por causa de escolha entre
diferentes opes disponveis.
Uma tomada de deciso eficaz requer que o analista compreenda:
Os valores, metas e objetivos que so relevantes para o problema de deciso;
A natureza da deciso que deve ser tomada;
As reas de incertezas que afetam a deciso;
E as consequncias de cada deciso possvel.
As tarefas da rea de conhecimento Anlise Corporativa descrevem muito do que

necessrio para estruturar efetivamente um problema de deciso. Esta tcnica
descreve as ferramentas especficas usadas para analisar resultados, incerteza e
escolhas. A anlise de deciso pode envolver o uso de modelos muito complexos e
aplicativos de software especializados.
9.8.3 Elementos
.1 Sadas
A anlise de deciso geralmente requer que o analista de negcios utilize alguma
forma de modelo matemtico para avaliar os possveis resultados.

Tcnicas Anlise de deciso
Anlise Financeira
Os modelos financeiros estimam o valor de mercado de um ativo organizacional,
como por exemplo, o valor de uma nova soluo ou aquisio do negcio.
As tcnicas de avaliaes financeiras comumente utilizadas incluem:
Fluxo de caixa descontado: valor futuro em uma data especfica;
Valor presente lquido: viso futura dos custos e benefcios convertidos em

valores de hoje;
Taxa de retorno interno: a taxa de juros (ou desconto), quando o valor presente
lquido igual a zero;
Taxa mdia de retorno: estimativa da taxa de retorno de um investimento;
Payback Prazo de recuperao do investimento: a quantidade de tempo

que um investimento leva para pagar a si mesmo;
Anlise de custo-benefcio: quantificao dos custos e benefcios para uma

nova soluo proposta.
Resultados no-financeiros
Nem todos os resultados de uma deciso podem ser expressos em termos financeiros.
Contudo, uma anlise de deciso eficaz ainda requer que os resultados sejam
diretamente comparveis. Em alguns casos, haver uma mtrica que aplicvel
(defeitos por mil, percentual de tempo disponvel, qualificao da satisfao do
consumidor). Quando no houver, uma pontuao relativa dos possveis resultados
ter que ser determinada.
.2 Incerteza
A incerteza torna-se relevante para um problema de deciso quando impossvel
saber qual resultado ir ocorrer. Isso pode se dar por falta de informao, ou porque
o resultado depende de como os demais respondem. Um mtodo comum para
lidar com a incerteza nos problemas de deciso calcular o valor esperado dos
resultados. Isso envolve estimar a chance percentual de ocorrer cada resultado e
ento multiplic-la pelo valor numrico associado ao resultado.
Uma rvore de deciso um mtodo de avaliar o resultado preferido quando existem

muitas fontes de incerteza.
.3 Escolhas
As escolhas tornam-se relevantes sempre que um problema de deciso envolver
objetivos mltiplos e, possivelmente, conflitantes. Uma vez que mais de um objetivo
relevante, no suficiente simplesmente encontrar o valor mximo de uma varivel
(como no benefcio financeiro para a organizao). Quando so feitas escolhas,
mtodos efetivos incluem:
Eliminao das alternativas dominadas. Uma alternativa dominada qualquer

opo que claramente inferior a alguma outra opo. Se uma opo igual,
ou pior, do que alguma outra opo quando pontuada em relao aos objetivos,
a outra opo pode ser considerada como dominante. Em alguns casos, uma
opo pode tambm ser dominada se ela oferece apenas pequenas vantagens,
mas possui desvantagens significativas.

Anlise de deciso Tcnicas
Ranqueamento dos objetivos em uma escala similar. Um mtodo de converso

de ranqueamentos para uma escala similar a pontuao proporcional. Usando
este mtodo, o melhor resultado pontuado como 100, o pior como 0 e todos
os demais resultados so pontuados com base em onde eles situam-se entre
essas duas pontuaes. Se os resultados ento receberem pesos baseados na sua
importncia relativa, uma pontuao pode ser atribuda para cada resultado e a
melhor alternativa designada, usando uma rvore de deciso.
Figura 9-5: rvore de Deciso

Possibilidade ou Fim
Evento Incerto
Resultado,
2.1.1 Cenrio A
Probabilidade
Deciso
2.1 Deciso A
Resultado,
2.1.2 Cenrio B
Probabilidade
Deciso a ser tomada
Resultado,
2.2 Deciso B
Probabilidade

.1 Vantagens
A anlise de deciso fornece uma tcnica eficaz para determinar o valor
esperado de um cenrio alternativo para a organizao.
Usar tcnicas consistentes de justificativa financeira em todos os business cases

fornece aos tomadores de deciso medidas quantitativas sobre as quais podem
tomar decises de investimentos em projetos.
A anlise de deciso pode forar as partes interessadas a avaliar honestamente a

importncia que elas depositam em cada uma das diferentes alternativas.
.2 Desvantagens
A anlise de deciso requer habilidades e conhecimentos especializados,
incluindo conhecimento matemtico, noo de probabilidades e conceitos
similares.
Os resultados da anlise de deciso podem ser tratados como mais precisos

do que eles realmente so, se os tomadores de deciso no compreenderem as
limitaes do modelo e as suposies por trs dele.
Os tomadores de deciso podem estar relutantes em revisar decises quando

surgem novas informaes nas reas de incerteza que poderiam afetar na
escolha da opo tima.

Tcnicas Anlise de documentos
9.9 Anlise de documentos

9.9.1 Propsito
A anlise de documentos uma forma de elicitao de requisitos atravs do estudo da
documentao disponvel das solues existentes e comparveis, e da identificao
de informaes relevantes.
9.9.2 Descrio
A anlise de documentos pode incluir anlise de planos de negcio, estudos de
mercado, contratos, requisies de propostas, declaraes de trabalho, memorandos,
orientaes existentes, procedimentos, guias de treinamentos, literatura a respeito
de produtos concorrentes, revises comparativas publicadas de produtos, reportes
de problemas, registros de sugestes de clientes, especificaes de sistemas
existentes, entre outros. A identificao e consulta a todas as fontes de requisitos
resultaro em uma cobertura aperfeioada dos requisitos, assumindo-se que a
documentao esteja atualizada.
A anlise de documentos utilizada quando o objetivo for coletar detalhes das

solues existentes, incluindo regras de negcio, entidades e atributos que devem
ser includos em uma nova soluo ou devem ser atualizados na soluo atual. Esta
tcnica tambm aplica-se em situaes onde os especialistas na rea da soluo
existente no se encontram mais na organizao, ou no estaro disponveis ao
longo da durao do processo de elicitao.
9.9.3 Elementos
.1 Preparao
Avalie quais documentaes existentes sobre o negcio e sistemas so relevantes,
disponveis e apropriadas para o estudo.
.2 Reviso documental
Estude o material e identifique detalhes relevantes do negcio.
Documente detalhes do negcio, como tambm perguntas para

acompanhamento junto aos especialistas da rea.
.3 Fechamento
Revise e confirme os detalhes selecionados junto aos especialistas da rea.
Organize a informao na forma de requisitos.
Obtenha as respostas para as perguntas de acompanhamento.

.1 Vantagens
No iniciar a partir de uma folha em branco.
Utilizar materiais existentes para descobrir e/ou confirmar requisitos.
Um meio de verificar os requisitos de outras tcnicas de elicitao como

entrevistas, observao passiva, pesquisas ou grupos focais.
.2 Desvantagens
Limitado perspectiva as-is (como ).

Estimativa Tcnicas
A documentao existente pode no estar atualizada ou no ser mais vlida.
Pode consumir muito tempo e transformar-se em um processo tedioso a

localizao de informaes relevantes.
9.10 Estimativa
9.10.1 Propsito
Tcnicas de estimativas preveem custos e esforos envolvidos na busca do progresso
de uma atividade.
9.10.2 Descrio
As tcnicas de estimativa so usadas para desenvolver uma melhor compreenso
da possvel dimenso dos custos e esforos associados com qualquer iniciativa. A
estimativa utilizada quando impossvel determinar o custo exato. A estimativa
no pode e no deve eliminar a incerteza, ou melhor, o propsito da estimativa
alcanar uma avaliao razovel dos provveis custos e esforos requeridos.
Quanto menos informao estiver disponvel para o responsvel pela estimativa,

maior ser a dimenso de incerteza. As estimativas devem ser revisitadas conforme
novas informaes tornarem-se disponveis. Muitas tcnicas de estimativa apoiam-
se em registros histricos da organizao para suporte o desenvolvimento das
estimativas atuais. As estimativas devem incluir uma avaliao da dimenso da
incerteza associada a elas.
9.10.3 Elementos
.1 Estimativa anloga
Uso de um projeto similar como base para o desenvolvimento de estimativas do
projeto atual. Esta tcnica utilizada quando pouco conhecido. A estimativa
anloga frequentemente usada para desenvolver uma estimativa de ordem
de grandeza (ROM rough order of magnitude), e tambm conhecida como
estimativa top-down. Geralmente utilizada no incio do projeto, ou de uma
fase do projeto, e as estimativas mais detalhadas so realizadas conforme mais
informaes tornam-se disponveis.
.2 Estimativa paramtrica
Uso de parmetros multiplicados por um nmero de horas. Para que a estimativa
paramtrica possa ser utilizvel, necessria a disponibilidade de um histrico em
quantidade suficiente para ser utilizado como base de comparao. Com este tipo
de estimativa, o analista de negcios j realizou trabalho suficiente para determinar
quais parmetros podem ser usados e quantos eles sero. Por exemplo, o analista
de negcios determina que sejam desenvolvidos dez casos de uso e tambm possui
um histrico que indica que o tempo total consumido para cada caso de uso ser de
20 horas. Usando esta tcnica, o analista de negcios pode multiplicar 10 x 20 para
conseguir um total de 200 horas.
Existe uma quantidade razovel de mtodos bem definidos para estimativa

paramtrica para desenvolvimento de software, como COCOMO II, pontos de
funo, pontos de casos de uso e story points.
.3 Estimativa bottom-up
Utilizando esta tcnica o analista de negcios coleta as entregas, atividades, tarefas e
estimativas de todas as partes interessadas e as rene para conseguir um total de todas

Tcnicas Estimativa
as atividades e tarefas. Uma vez que mais fcil estimar itens pequenos do que grandes,
a estimativa bottom-up pode produzir estimativas mais acuradas e defensveis.
.4 Forma cclica
Esta uma tcnica que envolve o refinamento das estimativas. Estima os detalhes
das atividades na iterao ou incremento atual e prov uma estimativa anloga
para todo o escopo do trabalho. Na aproximao do final da iterao, as estimativas
para a prxima iterao podem ser realizadas e a estimativa inicial para todas as
atividades refinada.
.5 Estimativa de Trs Pontos

Utiliza cenrios para:
O cenrio mais otimista, ou cenrio feliz;
O cenrio mais pessimista, ou pior cenrio;
A estimativa mais provvel.
Note que a estimativa mais provvel no uma mdia do cenrio otimista e

pessimista. Ela requer um conhecimento profundo da situao. Sob as circunstncias
corretas, o cenrio mais otimista pode tambm ser o mais provvel.
.6 Anlise histrica
Utiliza a histria como base para a estimativa. similar estimativa anloga,
porm no usada apenas na estimativa top-down, mas tambm para as tarefas
detalhadas. Estimativas histricas demandam que registros de projetos anteriores
sejam mantidos formalmente em um repositrio, ou informalmente em uma
documentao individual de projeto.
.7 Avaliao de especialista
A estimativa se apoia na experincia daqueles que desempenharam o trabalho no
passado. Esses especialistas podem ser internos ou externos equipe do projeto, ou
organizao.
.8 Estimativa Delphi
Esta tcnica utiliza uma combinao de avaliao de especialista e histrico.
Existem algumas variaes deste processo, mas todas elas incluem as estimativas
individuais e o compartilhamento dessas estimativas com especialistas de forma
recorrente at que se atinja o consenso. Uma mdia das trs estimativas usada.
Algumas vezes a mdia obtida pela soma da otimista, da pessimista e quatro vezes
da mais provvel, dividido por seis.

.1 Vantagens
As estimativas podem auxiliar as partes interessadas a tomar as melhores decises
baseadas em uma compreenso aperfeioada dos resultados provveis de uma
iniciativa.
.2 Desvantagens
As partes interessadas frequentemente tratam as estimativas como compromissos e
esperam que uma vez que uma estimativa seja fornecida, a equipe que implementar
a soluo ir atender ao tempo e custo estimados.

Grupos focais Tcnicas
Frequentemente as estimativas so intencionalmente, ou no, alteradas para

atender aos desejos de partes interessadas mais influentes, porque os responsveis
pela estimativa ou demais envolvidos esto preocupados que as estimativas mais
altas levem o projeto a ser rejeitado ou demonstrar falta de engajamento.
9.11 Grupos focais

9.11.1 Propsito
Um grupo focal uma forma para elicitar ideias e atitudes a respeito de um produto,
servio ou oportunidade especficos em um ambiente de grupo interativo. Os
participantes compartilham suas impresses, preferncias e necessidades, guiados
por um moderador.
9.11.2 Descrio
Um grupo focal composto de indivduos pr-qualificados cujo objetivo discutir e
comentar um tpico. Esta uma oportunidade para os indivduos compartilharem
suas prprias perspectivas e as discutirem em um formato de grupo. Isso pode levar
os participantes a reavaliar suas prprias perspectivas sob a tica das experincias
dos demais. Um moderador treinado gerencia o trabalho preliminar, facilita a sesso
e produz o relatrio. Observadores podem registrar ou monitorar o grupo focal, mas
no podem participar.
Uma vez que esta tcnica de elicitao considerada uma forma de pesquisa
qualitativa, os resultados da sesso so analisados e comunicados como temas e
perspectivas, e no como descobertas numricas. O relatrio pode tambm incluir
citaes selecionadas para apoiar os temas.
Um grupo focal tradicional se rene dentro da mesma sala. Um grupo focal on-line
permite que os membros estejam localizados remotamente, participando atravs de
uma conexo de rede. Cada abordagem possui seus prs e contras em termos de
logsticas e despesas.
Um grupo focal pode ser utilizado durante qualquer estado do ciclo de vida:
exploratrio, em desenvolvimento, pronto para lanar ou em produo. Se o tpico
do grupo um produto em desenvolvimento, as ideias do grupo so analisadas em
relao aos requisitos declarados. Isso pode resultar na atualizao dos requisitos
existentes ou na descoberta de novos requisitos. Se o tpico for um produto completo
que est pronto para ser lanado, o relatrio do grupo pode influenciar em como
posicionar o produto no mercado. Se o tpico um produto em produo, o relatrio
pode prover direcionamento para as revises para a prxima entrega de requisitos.
Um grupo focal pode tambm servir como um meio de avaliar a satisfao dos
clientes, com um produto ou servio.
O trabalho de um grupo focal pode ser similar quele feito em uma sesso de
brainstorming. Uma diferena que o grupo focal tipicamente mais estruturado.
Outra diferena que o objetivo de um brainstorming procurar ideias abrangentes,
criativas e at mesmo exageradas.
9.11.3 Elementos
.1 Preparao
Recrutar Participantes
Um grupo focal tipicamente possui entre 6 e 12 participantes. Pode ser necessrio
convidar indivduos adicionais no intuito de permitir que aqueles que no podem

Tcnicas Grupos focais
participar da sesso devido aos conflitos nas agendas, emergncias ou outras razes,
o faam. Se muitas pessoas precisarem participar, pode ser necessrio organizar
mais de um grupo focal.
O tpico do grupo focal ir influenciar quem deve ser recrutado. Se o tpico for um
novo produto, provvel que usurios existentes (experientes e novos) devam ser
includos. Existem prs e contras que devem ser considerados quando utilizada uma
composio homognea versus uma composio heterognea.
Homognea indivduos com caractersticas similares. Ateno: Perspectivas

diferentes no sero compartilhadas. Possvel soluo: conduzir sesses
separadas para diferentes grupos homogneos para coletar perspectivas diferentes.
Heterognea indivduos que diferem em histricos e/ou perspectivas.

Ateno: indivduos podem se auto-censurar se no se sentirem confortveis
com os histricos e opinies dos demais, resultando em uma baixa qualidade
dos dados coletados.
Designar o moderador e registrador

O moderador deve ter experincia na facilitao de grupos. Perfis tpicos incluem a
habilidade de:
promover a discusso
fazer perguntas abertas (aquelas que requerem ou promovem uma resposta

estendida)
facilitar interaes entre membros do grupo
engajar todos os membros
manter o foco nas sesses
permanecer neutro
ser adaptvel e flexvel
Criar o guia de discusso

O guia de discusso inclui metas/objetivos da sesso e entre cinco e seis perguntas
abertas.
Reservar local e servios

Selecionar o local para a sesso. Garantir suporte tcnico para transcrever a sesso
e, se utilizados, equipamentos de gravao audiovisual.
.2 Realizar a sesso de grupo focal

O moderador guia a discusso do grupo, segue um script pr-planejado de questes
especficas e garante que os objetivos sejam alcanados. Contudo, a discusso do
grupo deve parecer fluente e relativamente no estruturada para os participantes.
Uma sesso dura tipicamente entre uma e duas horas. O registrador captura os
comentrios do grupo.
.3 Produzir o relatrio
O moderador analisa e documenta os pontos onde h, ou no, consenso entre os
participantes e os sintetiza em temas.

Decomposio funcional Tcnicas

.1 Vantagens
Habilidade em elicitar dados de um grupo de pessoas em uma nica sesso
poupa tempo e custo quando comparada a entrevistas individuais com o mesmo
nmero de pessoas.
Efetivo para compreender as atitudes, experincias e desejos das pessoas.
Discusso ativa e a habilidade de fazer outras perguntas criam um ambiente

onde os participantes podem considerar suas vises pessoais em relao s
outras perspectivas.
.2 Desvantagens
Na organizao do grupo, os participantes podem estar preocupados com
questes de confiana, ou podem estar indispostos a discutir tpicos sensveis
ou pessoais.
Os dados coletados (o que as pessoas dizem) podem no ser consistentes com o

modo com o qual as pessoas realmente se comportam.
Se o grupo for muito homogneo as respostas podem no representar o conjunto

completo de requisitos.
Um moderador habilidoso necessrio para gerenciar as interaes e discusses

do grupo.
Pode ser difcil agendar o grupo todo para a mesma data e hora.
Se a meta do grupo focal for elicitar ideias sobre um produto novo ou em

mudana, um grupo focal no uma forma efetiva de avaliao da usabilidade.
9.12 Decomposio funcional

9.12.1 Propsito
Decompor processos, reas funcionais ou entregas em partes que os compem e
permitir que cada parte seja analisada de forma independente.
9.12.2 Descrio
A decomposio funcional envolve a quebra de um grande problema em
funcionalidades ou entregas menores. A principal meta da decomposio funcional
garantir que o problema seja separado em subproblemas que so os mais
independentes possveis para que o trabalho possa ser designado para grupos
diferentes. Isso fornece a habilidade de escalar e gerenciar projetos maiores.
9.12.3 Elementos
A decomposio funcional identifica as funes de alto nvel de uma organizao,
ou soluo, e ento quebra aquelas funes em pedaos menores, como em sub-
processos e atividades, recursos e assim por diante.
Quando decompondo uma funo organizacional, os modelos comeam com uma

funo de alto nvel, correspondendo a uma unidade organizacional e continuam

Tcnicas Decomposio funcional
Figura 9-6: Diagrama de Decomposio Funcional

Funo
Subfuno 1 Subfuno 2
Processo Processo Processo Processo Processo Processo Processo

1.1 1.2 1.3 2.1 2.2 2.3 2.4
Atividade Atividade Processo

1.1.1 1.2.1 2.1.1
Atividade Atividade Processo

1.1.2 1.2.2 2.2.2
Atividade
1.1.3
avanando at sub-funes, representando os processos conduzidos por aquela

unidade e, abaixo destes sub-processos, atividades individuais (os nomes para cada
nvel so apenas convenes e no implicam que a decomposio deva parar quando
o quarto nvel for alcanado). Isso pode ser representado por um diagrama de
hierarquia, um diagrama de rvore ou na numerao de cada sub-funo. Cada
funo completamente formada pelas sub-funes abaixo dela. O processo de
decomposio funcional continua at que uma sub-funo no possa ser quebrada
em duas ou mais funes de nvel menor.
Um processo similar pode ser conduzido para o trabalho envolvido em um projeto.

Esta decomposio (conhecida como Estrutura Analtica do Projeto ou EAP) quebra
o escopo do projeto em fases, pacotes de trabalho e entregas. A decomposio pode
tambm ser feita para descrever um produto ou processo.

.1 Vantagens
Cria um modelo conceitual do trabalho que precisa ser completado para entregar
a nova soluo do negcio.
Fornece para todas as partes interessadas uma viso consistente do escopo do

esforo.
Auxilia a estimativa, uma vez que as estimativas podem ser feitas para menores
subconjuntos do todo e, por sua vez, mais facilmente compreensveis.
.2 Desvantagens
No h forma de garantir que todos os componentes foram capturados.
Decompor um problema sem uma compreenso completa do relacionamento

entre as partes do problema pode criar uma estrutura inapropriada que impede
a anlise.

Anlise de interface Tcnicas
9.13 Anlise de interface

9.13.1 Propsito
Identificar interfaces entre solues e/ou componentes da soluo e definir requisitos
que descrevem como elas iro interagir.
9.13.2 Descrio
Uma interface uma conexo entre dois componentes. A maior parte das aplicaes
de software requer uma ou mais interfaces. Os tipos de interface incluem:
Interfaces do usurio, incluindo usurios humanos interagindo diretamente

com o sistema, como tambm relatrios fornecidos para o usurio.
Interfaces para e de aplicativos externos
Interfaces para e de dispositivos de hardware
A anlise de interface auxilia a clarear as fronteiras entre os aplicativos. Ela distingue

qual aplicativo fornece funcionalidades especficas junto das necessidades de
entrada e sada de dados. Fazendo uma separao clara e cuidadosa dos requisitos
para cada aplicativo durante a definio dos requisitos compartilhados de interface,
uma base para a interoperabilidade bem sucedida estabelecida.
Identificando quais interfaces so necessrias para apoiar um aplicativo define o

terreno para elicitar uma grande variedade de requisitos. Uma identificao prvia
das interfaces traz tona e confirma as partes interessadas que interfaceiam e
fornece um modelo para anlises subsequentes dos requisitos detalhados para cada
interface. A anlise de interface certamente necessria para que uma soluo ou um
componente de soluo, mas tambm pode ser til para uma soluo no-software,
como na definio de requisitos para entregas que sero produzidos por terceiros.
9.13.3 Elementos
.1 Preparar para a identificao das interfaces
Revisar a documentao atual em busca de quaisquer indicaes de requisitos de
interfaces. Por exemplo, um Diagrama de Contexto, como descrito em Modelagem do
escopo (9.27) pode fornecer uma visualizao efetiva das interfaces para e de partes
externas.
.2 Conduzir a identificao das interfaces

Para cada parte interessada ou sistema que interage com o sistema, identificar todas
as interfaces necessrias.
Para cada interface:
Descrever o propsito da interface.
Avaliar qual tipo de interface pode ser apropriado: interface do usurio,

interface sistema-a-sistema, e/ou interfaces com dispositivos externos de
hardware.
Elicitar detalhes de alto nvel sobre a interface, dependendo do seu tipo:
Para uma interface onde o usurio atua diretamente junto ao aplicativo, ver
Prototipao.

Tcnicas Entrevistas
Para uma interface sistema-a-sistema ou uma interface com um dispositivo externo

de hardware, delinear o contedo e o nome dos eventos relativos.
.3 Definir interfaces
Requisitos para uma interface so primariamente focados na descrio das entradas
e sadas daquela interface, quaisquer regras de validao que governam aquelas
entradas e sadas e eventos que podem disparar interaes. Pode haver grande nmero
de possveis tipos de interaes que podem ser individualmente especificadas.

.1 Vantagens
Identificao antecipada das interfaces fornece uma viso de alto nvel da
interoperabilidade para planejar:
Impacto na data de entrega. Sabendo que interfaces so necessrias, como

tambm a sua complexidade antecipada e necessidades de testes permitem
um planejamento de projeto mais acurado e potenciais economias em tempo
e custo.
A colaborao com outros sistemas ou projetos. Se a interface comunica-se

com um sistema, produto ou dispositivo existente e a interface j existe, pode
no ser facilmente altervel. Se a interface for nova, ento a propriedade,
desenvolvimento e testes da interface devem ser abordados para ambos
aplicativos. Quando o caso, elicitar e analisar os requisitos de interface ir
provavelmente requerer negociao e cooperao entre aqueles responsveis por
ambas os aplicativos.
Especificao das interfaces deve prevenir dificuldades na integrao de

mltiplos componentes.
.2 Desvantagens
No fornece insights sobre outros aspectos da soluo, uma vez que a anlise no
avalia os componentes internos.
9.14 Entrevistas
9.14.1 Propsito
Uma entrevista uma abordagem sistemtica desenhada para elicitar informaes
junto a uma pessoa ou a um grupo de pessoas de maneira formal ou informal atravs
de uma conversa com um entrevistado, na qual so feitas perguntas relevantes e as
respostas so documentadas.
9.14.2 Descrio
Em uma entrevista, o entrevistador faz perguntas formalou informalmente a uma
parte interessada para obter respostas que iro ser usadas para criar requisitos
formais. Entrevistas um a um so mais comuns. Em uma entrevista em grupo (com
mais de um entrevistado presente) o entrevistador deve se preocupar em elicitar
respostas de todos os presentes.
Para o propsito de elicitar requisitos, as entrevistas so de dois tipos bsicos:
Entrevista Estruturada: onde o entrevistador possui um conjunto pr-definido

de questes e procura respostas para elas.

Entrevistas Tcnicas
Entrevista No-Estruturada: onde, sem nenhuma questo pr-definida, o

entrevistador e o entrevistado discutem abertamente tpicos de interesse .
Entrevistas bem-sucedidas dependem de vrios fatores incluindo, mas no limitados a:
Nvel de compreenso do domnio pelo entrevistador.
Experincia do entrevistador na conduo das entrevistas.
Habilidade do entrevistador em documentar as discusses.
Prontido do entrevistado para fornecer informaes relevantes.
Grau de clareza na mente do entrevistado em relao ao que o negcio requer do

sistema em discusso.
Empatia (rapport) do entrevistador com o entrevistado.
9.14.3 Elementos
.1 Preparao para a entrevista
Definir o foco ou a meta da entrevista antes de proceder.
Identificar entrevistados em potencial

O analista de negcios considera as seguintes perguntas na identificao de quem
deve ser entrevistado:
Quem possui a informao mais autntica e atualizada sobre o assunto de

interesse?
Qual o seu interesse na iniciativa?
Qual a importncia relativa da informao mantida por uma pessoa em relao

mantida por outra pessoa? Esta informao til na anlise de comentrios
conflitantes entre entrevistas.
Desenhar a entrevista
O entrevistador pode precisar adaptar o formato da entrevista a cada entrevistado
identificado. A habilidade do entrevistado em participar e o resultado desejado
guiam o desenho da entrevista. Alm disso, os seguintes fatores so tambm
considerados:
O formato da entrevista, estruturada versus no-estruturada. No caso de uma

entrevista estruturada, os tipos de pergunta:
Perguntas fechadas: Perguntas que so usadas para elicitar uma resposta

nica como: sim, no, ou um nmero especfico. Exemplo: Quantas horas
levam para que um determinado processo seja concludo?
Perguntas abertas: Perguntas que so usadas para elicitar um dilogo ou

uma srie de passos e que no podem ser respondidas no estilo sim ou
no, pois necessitam de explicao. Exemplo: O que faz um processador de
solicitaes ao receber um formulrio de solicitao?
Organizao das perguntas: use uma ordem lgica ou uma ordem de

prioridade/significncia. Exemplos de ordem seriam de perguntas mais

Tcnicas Entrevistas
genricas para especficas, do incio para o fim, do detalhe para a sntese, etc.
A organizao efetiva baseada em fatores como o nvel de conhecimento do
entrevistado e o assunto da entrevista. O objetivo seguir uma ordem lgica,
em vez de ficar saltando entre diferentes assuntos durante as perguntas.
Localizao dos participantes: Uma entrevista pode ser conduzida

pessoalmente ou pelo telefone, conferncia web ou outros mtodos de
comunicao remota.
A hora e local da entrevista convenientes para o entrevistado.
Determinao da necessidade de um escriba e, se for o caso, incluir esta pessoa

no processo de agendamento. Determinao da necessidade da entrevista ser
gravada. Neste caso, discutir o propsito e o uso da gravao com o entrevistado.
Contatar entrevistados em potencial

O entrevistador contata os entrevistados selecionados e explica a eles porque sua
ajuda necessria. O propsito explicar o objetivo da entrevista para o entrevistado
em potencial.
.2 Conduo da entrevista
Abertura da entrevista: O entrevistador declara o propsito da entrevista,
atende quaisquer preocupaes iniciais levantadas pelo entrevistado e explica
que anotaes sero feitas e compartilhadas com o entrevistado ao final da
entrevista.
Durante a entrevista
O entrevistador mantm foco nas metas estabelecidas e perguntas pr-

definidas.
Todas as preocupaes levantadas pelo entrevistado so atendidas durante

a entrevista ou documentadas para dar seguimento ps-entrevista ou em
uma entrevista subsequente.
O entrevistador pratica escuta ativa para confirmar o que foi compreendido

da informao oferecida em vrios momentos ao longo da entrevista.
Fechamento da entrevista: O entrevistador pergunta para o entrevistado

se existem reas que tenham sido negligenciadas durante a sesso. Por fim,
o entrevistador sintetiza a sesso, relembra o entrevistado a respeito do
processo de reviso que ir acontecer em seguida e agradece ao entrevistado
pelo seu tempo.
.3 Seguimento ps-entrevista e confirmao

Depois do fim da entrevista, o entrevistador organiza as informaes e envia as
anotaes ao entrevistado para reviso. Documentar a discusso para reviso
permite que o entrevistado tenha uma viso de toda a informao no contexto
relacionado. Essa reviso pode apontar itens que esto incorretos ou faltando, devido
ao fato do entrevistador (ou escriba) t-los deixado escapar, ou porque o entrevistador
(ou escriba) os documentaram incorretamente, ou porque o entrevistado esqueceu-
se de discuti-los. Esta reviso no dedicada a avaliar se os requisitos so, ou no,
vlidos, nem se eles esto aprovados para incluso nas entregas, apenas se d para
determinar se a entrevista foi adequadamente documentada.

Processo de lies aprendidas Tcnicas

.1 Vantagens
Encoraja a participao e estabelece empatia (rapport) junto parte interessada.
Tcnica simples e direta que pode ser usada em diferentes situaes.
Permite que o entrevistador e o participante tenham discusses e explicaes

amplas sobre perguntas e respostas.
Permite a observao de aspectos no-verbais.
O entrevistador pode fazer perguntas de seguimento ou de sondagem para

confirmar a sua compreenso.
Mantm o foco atravs do uso de objetivos claros para a entrevista, com os quais
todos os participantes concordaram e que podem ser alcanados dentro do
tempo alocado.
Permite aos entrevistados expressar opinies de forma privada que relutariam

em expressar de forma pblica.
.2 Desvantagens
Entrevistas no so o meio ideal de se alcanar consenso entre um grupo de
Requer dedicao e envolvimento considerveis por parte dos participantes.
necessrio treinamento para conduzir entrevistas efetivas. Em particular,

entrevistas no-estruturadas requerem habilidades especiais, incluindo
facilitao/facilitao virtual e escuta ativa.
A profundidade das perguntas subsequentes depende do conhecimento do

entrevistador em relao ao domnio do negcio.
A transcrio e anlise dos dados da entrevista podem ser complexas e caras.
Com base no nvel de clareza da entrevista, a documentao resultante pode

estar sujeita interpretao do entrevistador.
Existe um risco de influenciar de forma no intencional o entrevistado.
9.15 Processo de lies aprendidas

9.15.1 Propsito
O propsito do processo de lies aprendidas compilar e documentar sucessos,
oportunidades de melhorias, falhas e recomendaes para aperfeioamento do
desempenho nos projetos futuros ou fases futuras de projetos.
9.15.2 Descrio
As sesses de lies aprendidas podem incluir qualquer formato de reunio ou
frum que funcione para as principais partes interessadas que forem identificadas
como participantes dessas sesses.

Tcnicas Mtricas e Indicadores-Chave de Desempenho
9.15.3 Elementos
As sesses podem incluir uma reviso de:
Atividades da anlise de negcios
Entregas da anlise de negcios
O produto final
O processo da anlise de negcios
Automao e tecnologias utilizadas ou no utilizadas
Questes ou preocupaes gerenciais
Como os ativos de processos organizacionais auxiliaram ou prejudicaram os

processos de anlise de negcios e de requisitos
Desempenho versus plano
Variaes
Causas razes das variaes
Se as variaes foram de rotina ou anomalias significativas
Ao corretiva e/ou preventiva recomendada, aprovada ou rejeitada e tomada.
As sesses de lies aprendidas podem acontecer como reunies formais, facilitadas

com agendas definidas e papis claros, sesses de trabalho formais ou informais, ou
como encontros informais, podendo incluir, ou no, uma celebrao.

.1 Vantagens
til para identificar oportunidades de melhoria de processos.
Pode auxiliar na construo do moral da equipe aps um perodo difcil.
.2 Desvantagens
Todos os participantes devem estar preparados para evitar o impulso de apontar
culpados durante a sesso, ou uma discusso honesta pode no ocorrer.
Os participantes podem relutar em documentar e discutir problemas.
Existe o risco de se tornar uma sesso de reclamaes na qual as oportunidades

de melhorias seriam negligenciadas.
9.16 Mtricas e Indicadores-Chave de Desempenho

9.16.1 Propsito
O propsito das mtricas e indicadores-chave de desempenho medir o desempenho
de solues, de componentes de solues e outras questes de interesse para as

Mtricas e Indicadores-Chave de Desempenho Tcnicas
9.16.2 Descrio
Uma mtrica um nvel quantificvel de um indicador que a organizao utiliza
para medir progresso. Um indicador identifica uma medida numrica especfica
que representa o grau de progresso para o alcance de uma meta, objetivo, sada,
atividade ou outra entrada. Um indicador-chave de desempenho aquele que mede
o progresso em relao a uma meta ou objetivo estratgico. O reporte o processo de
informar as partes interessadas a respeito das mtricas dos indicadores em formatos
e intervalos especificados.
As mtricas e os reportes so os principais componentes para o monitoramento

e a avaliao. O monitoramento um processo contnuo de coleta de dados para
determinar o quo bem uma soluo foi implementada em comparao com os
resultados esperados. A avaliao um julgamento sistemtico e objetivo de uma
soluo para determinar seu estado e sua eficcia no alcance dos objetivos ao longo
do tempo, e para identificar formas de aperfeioar a soluo para melhor alcanar os
objetivos. As maiores prioridades de um sistema de monitoramento e avaliao so
as metas e efeitos desejados de uma soluo, como tambm as entradas, atividades
e sadas.
9.16.3 Elementos
.1 Indicadores
Um indicador identifica uma medida numrica especfica para uma meta, impacto,
sada, atividade ou entrada. Cada fator de interesse possui pelo menos um indicador
para medi-lo de forma correta, mas alguns podem requerer vrios. Um bom
indicador possui cinco caractersticas:
Claro: preciso e no-ambguo
Relevante: apropriado para o fator
Econmico: disponvel por um custo razovel
Adequado: fornece base suficiente para avaliar desempenho
Quantificvel: pode ser validado de forma independente
Alm dessas caractersticas, os interesses da parte interessada tambm so

importantes. Certos indicadores podem ajudar ou melhorar o desempenho das
partes interessadas mais do que outros. Ao longo do tempo, fraquezas em alguns
indicadores podem ser identificadas e aperfeioadas.
Nem todos os fatores podem ser mensurados diretamente. Representantes indiretos

dos indicadores podem ser utilizados quando os dados no estiverem disponveis ou
no sejam viveis para coleta em intervalos regulares. Por exemplo, na ausncia de
uma pesquisa de satisfao do cliente, uma organizao pode utilizar a proporo
de todos os contratos renovados como um indicador.
Ao estabelecer um indicador, sua fonte, mtodo de coleta, o responsvel pela coleta

e o custo, a frequncia e a dificuldade na coleta precisam ser considerados. Fontes
secundrias de dados podem ser as mais econmicas e, contudo no atender s
caractersticas de um bom indicador. A pesquisa primria, como questionrios,
entrevistas ou observao direta pode ser necessria. O mtodo de coleta de
dados o principal direcionador do custo de um sistema de monitoramento,
avaliao e reporte.

Tcnicas Mtricas e Indicadores-Chave de Desempenho
.2 Mtricas
As mtricas so nveis quantificveis de indicadores que so medidos em um ponto
especfico no tempo. Uma mtrica alvo um objetivo a ser alcanado dentro de
um perodo especfico de tempo. Na definio de uma mtrica (geralmente uma)
para um indicador importante ter uma compreenso clara da linha de base do
ponto inicial, dos recursos que podem ser dedicados ao aperfeioamento dos fatores
cobertos pelo indicador e das questes e preocupaes polticas.
Uma mtrica pode ser um ponto especfico, um limite ou um intervalo. Um intervalo

pode ser til para um indicador novo. O limite de tempo para alcanar a mtrica
alvo pode ser plurianual, anual ou trimestral, ou ainda mais frequente, dependendo
da necessidade.
.3 Estrutura
O estabelecimento de um sistema de monitoramento e avaliao requer um
procedimento de coleta de dados, um procedimento de anlise de dados, um
procedimento de reporte e a coleta de dados de linha de base. O procedimento
de coleta de dados cobre unidades de anlise, procedimentos de amostragem,
instrumentos de coleta de dados a serem utilizados, frequncia da coleta e
responsabilidade pela coleta. O mtodo de anlise especifica os procedimentos
para a conduo da anlise e o consumidor dos dados, que pode ter interesses fortes
em relao a como essa anlise conduzida. O procedimento de reporte cobre os
modelos, destinatrios, frequncia e meios de comunicao. A informao de linha
de base so os dados providos imediatamente antes ou no incio de um perodo de
mensurao. A linha de base usada para aprender sobre o desempenho recente e
para mensurar o progresso daquele ponto em diante. Ela deve ser coletada para cada
indicador, analisada e reportada.
Existem trs fatores-chave para a avaliao da qualidade dos indicadores e suas

mtricas confiabilidade, validade e oportunidade. A confiabilidade representa
o quanto a abordagem de coleta de dados estvel e consistente ao longo do
tempo e espao. A validade representa o grau em que os dados so claros e
refletem uma medida direta do desempenho que a organizao precisa medir.
A oportunidade a adequao da frequncia e latncia dos dados necessidade
que os gestores possuem.
.4 Reportes
Geralmente, os reportes comparam a linha de base, mtricas atuais e mtricas
alvo entre si com clculos das diferenas apresentadas, tanto em termos absolutos,
quanto relativos. Na maior parte das situaes, tendncias so mais verossmeis e
importantes do que mtricas absolutas. Apresentaes visuais tendem a ser mais
efetivas do que tabelas, particularmente quando apoiadas por um texto qualitativo
para explicar os dados.

.1 Vantagens
O estabelecimento de um sistema de monitoramento e avaliao permite que as
partes interessadas compreendam o quanto uma soluo atende a um objetivo
e quo efetivas foram as entradas e as atividades para o desenvolvimento da
soluo (sada).
Os indicadores, mtricas e reportes tambm facilitam o alinhamento organizacional,

vinculando metas a objetivos, solues de suporte, tarefas fundamentais e recursos.

Anlise de Requisitos No-Funcionais Tcnicas
.2 Desvantagens
A coleta de uma quantidade excessiva de dados alm do necessrio resultar em
gastos desnecessrios na coleta, anlise e reporte. Tambm ir desviar a ateno
dos membros do projeto de outras responsabilidades. Em projetos geis, isso ser
particularmente relevante.
Um programa burocrtico de mtricas falha por coletar muitos dados sem a gerao de
reportes teis que permitiriam aes de resposta no tempo desejado. Os responsveis
pela coleta de dados das mtricas devem receber feedback para compreender como as
suas aes esto afetando a qualidade dos resultados do projeto.
Quando as mtricas so usadas para avaliar o desempenho, os indivduos sendo

medidos tendem a agir para incrementar o seu desempenho nessas mtricas, mesmo
quando isso leva a um desempenho inferior em outras atividades.
9.17 Anlise de Requisitos No-Funcionais

9.17.1 Propsito
O propsito dos requisitos no-funcionais descrever as qualidades requeridas para
um sistema, como sua usabilidade e caractersticas de desempenho. Eles completam a
documentao de requisitos funcionais que descrevem o comportamento do sistema.
9.17.2 Descrio
Os requisitos no-funcionais documentam as qualidades de um sistema que so
importante para:
a comunidade de usurios, como usabilidade, capacidade de aprendizado,

confiabilidade, etc.
a comunidade de desenvolvedores, como escalabilidade, manutenibilidade,

reusabilidade, etc.
Na prtica, o termo requisitos no-funcionais s se aplica quando se descreve

um aplicativo de software. Contudo, as diversas categorias de requisitos no-
funcionais podem ser aplicadas para outros componentes da soluo para os quais
os requisitos podem ser desenvolvidos. Por exemplo, requisitos de confiabilidade
para uma unidade organizacional podem incluir horas de disponibilidade de um
determinado servio e requisitos de eficincia do desempenho para um processo de
negcio podem incluir tempo de ciclo para lidar com uma requisio do cliente e
podem ser capturados em um acordo de nvel de servio (SLA). Nesses casos, um
termo alternativo como requisitos de qualidade de servio pode ser preferido.
9.17.3 Elementos
Os seguintes elementos geralmente so includos na descrio de requisitos no-
funcionais.
.1 Categoria
Requisitos no-funcionais so usualmente organizados em categorias. A
categorizao apoia a descoberta de requisitos no-funcionais fornecendo um
checklist de caractersticas a considerar quando se executa a elicitao de requisitos.
O esquema listado aqui tem como base a ISO 9126, mas outras categorizaes (como
FURPS+) podem tambm ser utilizadas.

Tcnicas Anlise de Requisitos No-Funcionais
Confiabilidade: O aplicativo de software est disponvel quando necessrio?

Requisitos de confiabilidade incluem a habilidade do aplicativo de manter-se
disponvel, recuperar-se de erros ou de falhas de interfaces.
Eficincia de desempenho: O aplicativo de software entrega nveis de desempenho

aceitveis dos recursos disponveis? Os requisitos de eficincia de desempenho
incluem o tempo necessrio para executar as atividades e os nveis de utilizao
de recursos.
Operabilidade: O aplicativo de software compreensvel pelos usurios? Os

requisitos de operabilidade incluem o quanto os usurios conseguem reconhecer
se um aplicativo ir atender as suas necessidades, a facilidade de aprendizado do
aplicativo e a sua usabilidade.
Segurana: O aplicativo previne mau uso intencional? Os requisitos de segurana

incluem a habilidade para garantir a confidencialidade apropriada da informao, a
integridade da informao armazenada no aplicativo, a habilidade de verificar quais
aes foram tomadas e por quem, e a habilidade de autenticar usurios.
Compatibilidade: O aplicativo pode operar efetivamente com outros aplicativos

no mesmo ambiente? Os requisitos de compatibilidade incluem requisitos para
a substituio correta de outro aplicativo, a habilidade de coexistir com outros
aplicativos e a habilidade de interagir com outros aplicativos.
Manutenibilidade: O aplicativo poder ser modificado de forma efetiva depois da

implementao para atender s novas necessidades? Requisitos de manutenibilidade
incluem a habilidade de alterar um componente sem afetar os demais, a habilidade
de reutilizar componentes, se o aplicativo pode ser testado com eficcia e seus
problemas podem ser propriamente diagnosticados, a facilidade de fazer mudanas
e a habilidade de implementar mudanas sem causar falhas inesperadas.
Portabilidade: O aplicativo pode ser instalado em outro ambiente? Os requisitos de

portabilidade incluem a facilidade de instalao e de desinstalao do aplicativo, os
tipos de diferentes ambientes nos quais pode rodar e a facilidade de migrao para
um novo ambiente.
.2 Medio
A definio de um requisito no-funcional deve incluir uma medida de sucesso
apropriada para que possa ser adequadamente testada. Alguns requisitos no-
funcionais podem parecer muito subjetivos (ex.: interface intuitiva), mas uma
reflexo cuidadosa geralmente pode encontrar uma medida de sucesso apropriada.
.3 Documentao
Os requisitos no-funcionais so tipicamente documentados textualmente usando
descries declarativas como:
Noventa por cento dos operadores devem ser capazes de utilizar todas as
funcionalidades do sistema aps um treinamento no superior a seis horas.
O sistema deve fornecer 90% das respostas em, no mximo, dois segundos.
Esta documentao apresentada como parte da documentao total de requisitos,

geralmente em uma seo ou documento separado.

Observao Tcnicas
9.17.4 Considerao de uso

.1 Vantagens
O sucesso no atendimento de requisitos no-funcionais ter uma forte influncia na
aceitao, ou no, do sistema pelos seus usurios.
.2 Desvantagens
Requisitos no-funcionais so geralmente mais difceis de definir que requisitos
funcionais. As expectativas em relao aos atributos de qualidade podem no ser
descritas e os usurios de um aplicativo podem consider-las difceis de articular.
Requisitos no-funcionais excessivamente rigorosos podem impactar

significativamente o custo de desenvolver um aplicativo de software.
9.18 Observao
9.18.1 Propsito
A observao uma forma de elicitar requisitos atravs da conduo de uma
avaliao do ambiente de trabalho da parte interessada. Esta tcnica apropriada
para documentar detalhes sobre processos atuais ou quando o projeto se destina a
melhorar ou alterar um processo atual.
9.18.2 Descrio
A observao baseia-se no estudo das pessoas na execuo das suas funes e s
vezes chamada de siga o mestre ( job shadowing ou following people around).
Por exemplo, algumas pessoas esto to habituadas com sua rotina de trabalho que
elas tm dificuldade de explicar o que fazem ou por qu. O observador pode precisar
assisti-los executando o seu trabalho para compreender o fluxo de trabalho. Em
certos projetos, importante compreender os processos atuais para melhor avaliar
as modificaes em processos que podem ser necessrias.
H duas abordagens bsicas da tcnica de observao:
Passiva/invisvel: Nesta abordagem, o observador acompanha o usurio

trabalhando na rotina do negcio e no faz perguntas. O observador registra o
que observado, mas permanece fora do caminho. O observador aguarda at
que o processo todo tenha sido completado antes de fazer qualquer pergunta. O
observador deve examinar o processo de negcios vrias vezes para garantir que
ele compreende como o processo funciona hoje e por que funciona desse jeito.
Ativa/visvel: Nessa abordagem, enquanto o observador analisa o processo

atual e toma notas, ele pode dialogar com o usurio. Quando o observador tem
perguntas como, a razo pela qual algo est sendo feito de tal maneira, ele faz a
pergunta imediatamente, mesmo se ela quebra a rotina do usurio.
Variaes da tcnica de observao:
Em alguns casos, o observador pode participar do trabalho real para obter

uma experincia prtica de como o processo de negcio funciona hoje. Este
procedimento seria limitado a uma atividade que uma pessoa no especializada
possa executar e cujos resultados no afetem negativamente o negcio.
O observador torna-se um aprendiz temporrio.

Tcnicas Observao
O observador assiste a demonstrao de como um processo e/ou tarefa

especficos so executados.
9.18.3 Elementos
.1 Preparar para a observao
Determinar qual amostragem de usurios (ex.: experientes e novatos, apenas
experientes) observar e quais atividades.
Preparar as perguntas que sero feitas durante ou depois da observao.
.2 Observar
O observador se apresenta para a pessoa a ser observada e:
Garante ao usurio que o seu trabalho no est sendo questionado. Ao contrrio,

a observao do trabalho e documentao resultante iro servir como entrada
para a anlise de requisitos.
Informa ao usurio que ele est presente apenas para estudar os seus
processos e vai evitar discutir solues futuras para eventuais problemas.
Explica para o usurio que ele pode interromper o processo de observao

a qualquer momento, caso acreditar que est interferindo no seu trabalho.
Sugere ao usurio que eles pensem em voz alta enquanto esto

trabalhando, como uma maneira de compartilhar suas intenes, desafios
e preocupaes.
Conduzir a observao.
Toma notas detalhadas.
Se estiver usando a abordagem de observao ativa, faz perguntas

investigativas sobre o por que determinados processos e tarefas esto sendo
executados da forma como esto.
.3 Fechamento Ps-Observao Documentao e Confirmao

Obter respostas para as perguntas originais, ou para novas perguntas que
surgiram durante as observaes.
Fornecer uma sntese das anotaes para o usurio, assim que possvel, para
reviso e esclarecimento.
Ao observar muitos usurios, compilar as anotaes em intervalos regulares

para identificar os pontos comuns e diferenas entre os usurios. Revisar as
descobertas junto ao grupo todo para garantir que os detalhes finais representem
o grupo todo, no apenas alguns usurios selecionados.

.1 Vantagens:
Fornece uma viso prtica e realista do negcio atravs da experincia mo na
massa de como os processos de negcio funcionam hoje.
Elicita detalhes da comunicao informal e a forma como as pessoas realmente

trabalham com o sistema, o que pode no estar documentado em outros lugares.

Modelagem Organizacional Tcnicas
.2 Desvantagens
Possvel apenas para processos existentes.
Pode consumir muito tempo.
Pode atrapalhar a pessoa sendo observada.
Situaes incomuns e excees que ocorrem com pouca frequncia podem no

ocorrer durante a observao.
Pode no funcionar bem se o processo atual envolver um alto nvel de atividade

intelectual ou outro trabalho que no seja de fcil observao.
9.19 Modelagem Organizacional

9.19.1 Propsito
A modelagem organizacional utilizada para descrever os papis, as
responsabilidades e hierarquia de reportes existentes em uma organizao,
alinhando essas estruturas com as metas da organizao.
9.19.2 Descrio
Um modelo organizacional define como uma organizao ou unidade organizacional
est estruturada. Unidades organizacionais trazem consigo um grupo de pessoas
destinadas a atingir um propsito ou meta em comum. Este propsito pode ser
funcional, significando que as pessoas em questo compartilham um conjunto
comum de habilidades e conhecimento, ou servem um mercado em particular.
Um modelo organizacional definir o escopo da unidade organizacional, os
relacionamentos formais entre as pessoas que fazem parte da unidade, os papis
que essas pessoas possuem e as interfaces entre uma unidade e demais unidades ou
9.19.3 Elementos
.1 Propsito e estrutura organizacional
Funes: Organizaes orientadas funo agrupam as pessoas com base em suas
habilidades ou reas de expertise compartilhadas. Elas so geralmente adotadas
para encorajar a padronizao do trabalho ou processos dentro da organizao.
Organizaes funcionais facilitam o gerenciamento de custos e reduzem a
duplicao do trabalho, mas tendem a desenvolver problemas transfuncionais ou de
coordenao (conhecidos informalmente como silos).
Mercados: O termo orientado ao mercado abriga um nmero de possveis formas

de organizar uma empresa, todas com base no servio a um segmento particular
de clientes, ao invs das habilidades ou expertises do funcionrio . Estruturas
orientadas ao mercado permitem que a organizao seja melhor orientada s
necessidades dos seus clientes, mas tendem a desenvolver inconsistncias na forma
como o trabalho desempenhado e a duplicar o trabalho em mltiplas divises.
Uma organizao orientada ao mercado pode ser organizada em torno de grupos
de clientes, reas geogrficas, projetos ou processos.
Matricial: Neste modelo existem diferentes gerentes para cada rea funcional
e para cada produto, servio ou grupo de clientes. Os colaboradores respondem a
um gerente de operao responsvel pelo desempenho de um tipo de trabalho e
por identificar oportunidades de eficincia no trabalho, e a um gerente de mercado

Tcnicas Modelagem Organizacional
(produto/servio/projeto/etc.) responsvel por gerenciar o produto, servio, etc., ao

longo de mltiplas reas funcionais.
.2 Papis
Uma unidade organizacional incluir um nmero suficiente de papis definidos.
Cada papel ir requerer um conjunto especfico de habilidades e conhecimento,
ter certas responsabilidades, ir desempenhar certos tipos de trabalho e ter
relacionamentos definidos junto a outros papis na organizao.
.3 Interfaces
Cada unidade organizacional ter interfaces com outras unidades organizacionais.
As interfaces podem ser na forma de pacotes de trabalho, que uma unidade recebe ou
entrega para outras unidades, comunicao com pessoas em outros papis e assim
por diante. Os pacotes de trabalho devem ter requisitos e padres de qualidade
acordados entre as partes interessadas afetadas. Esses requisitos, padres e
expectativas podem ser definidos formal ou informalmente e podem ser negociados
caso a caso, ou permitir flexibilidade em como so atendidos.
.4 Diagramas organizacionais
O diagrama fundamental usado na modelagem organizacional o organograma.
No existe um padro formal para definir organogramas, contudo, existem certas
convenes que a maior parte dos organogramas segue. Os organogramas apresentam:
Unidades organizacionais que representam pessoas, equipes, departamentos

ou divises, baseadas no nvel de abstrao do diagrama. Frequentemente um
diagrama ir agrupar unidades organizacionais, apresentando um conjunto de
pessoas, equipes e divises de nvel mais alto.
Linhas hierrquicas, as quais traam responsabilidades e controle entre

unidades organizacionais. Uma linha contnua tipicamente denota autoridade
direta, enquanto uma linha tracejada indica transferncia de informao
ou autoridade situacional. Linhas de hierarquia descrevem visualmente a
amplitude de controle de um gerente ou unidade organizacional em particular
(ou seja, o nmero de pessoas que um gerente responsvel por gerenciar).
Papis e pessoas. Um organograma pode apresentar os papis que existem em

uma organizao e as pessoas designadas a cada um destes papis.
Figura 9-7: Organograma
Nome do Titular da
Funo de Executivo
Nome do Titular da Nome do Titular da Nome do Titular da

Funo de Gerncia Funo de Gerncia Funo de Gerncia
Nome do Titular
Nome do Titular da Funo de Funcionrio
Nome do Titular da Funo de
da Funo de Funcionrio com
Vaga de Funo Gerncia da rea de Negcios (sem
relacionamento de subordinao Nome do Titular
funcionrios)
por linha pontilhada da Funo de Funcionrio

Rastreamento de problemas Tcnicas

.1 Vantagens
Modelos organizacionais so um dos poucos tipos de modelos que provavelmente
todas as organizaes j possuem definidos. Mesmo a mais simples das organizaes
deve definir as estruturas de reportes entre os membros das equipes, a fim de
coordenar o trabalho entre suas pessoas.
.2 Desvantagens
A limitao primria da modelagem organizacional no a tcnica em si, mas
as implicaes de incluir o redesenho organizacional no escopo de um projeto. O
redesenho organizacional tende a ser altamente polmico e requer apoio executivo
significativo para ser bem sucedido.
Um problema secundrio que linhas informais de autoridade e comunicao no

refletidas no diagrama provavelmente existem de fato dentro da organizao.
9.20 Rastreamento de problemas

9.20.1 Propsito
O rastreamento de problemas fornece uma abordagem organizada para rastreamento,
gerenciamento e resoluo de defeitos, questes, problemas e riscos ao longo das
atividades de anlise de negcios. O gerenciamento de questes importante para
que elas possam ser resolvidas em tempo hbil para garantir o sucesso.
9.20.2 Descrio
Os problemas podem incluir questes, perguntas, riscos, defeitos, conflitos ou
outras preocupaes que devem ser rastreadas at a resoluo. Um sistema de
rastreamento de problemas garante que as questes no sejam simplesmente
negligenciadas ou perdidas. Para cada problema, a ferramenta de rastreamento
pode incluir uma identificao do problema, atualizaes da situao, designao
de aes relacionadas que so solicitadas aos membros da equipe, monitoramento
das datas esperadas de resoluo, resultados da resoluo, aes e decises tomadas,
prioridade e impactos. A situao atual do problema deve ser comunicada para
todas as partes interessadas relevantes. O gerenciamento de problemas deve levar :
Resoluo de problemas em tempo hbil para eliminar impactos negativos.
Alocao de recursos para solucionar problemas.
Identificao das causas-razes dos problemas.
9.20.3 Elementos
.1 Registro dos problemas
Um registro de problemas deve conter algumas ou todas as informaes a seguir:
Descrio: Uma descrio clara e concisa do problema identificado.
Descoberto por: A pessoa que identificou o problema.
Data de identificao.
Impacto: As possveis consequncias, caso o problema no seja resolvido at a

data limite. O impacto pode ser avaliado, por exemplo, com base no cronograma,
custo ou escopo.

Tcnicas Rastreamento de problemas
Prioridade: Determinar a prioridade do problema, baseada na avaliao das partes

interessadas. Um exemplo de escala de prioridade : crtica, alta, mdia e baixa.
Data limite: At quando um problema deve ser solucionado para evitar as

consequncias.
Dono: Um membro da equipe que designado para gerenciar o problema

at o seu fechamento. O dono no deve ser obrigatoriamente a pessoa que
identificou o problema, ou as mesmas pessoas que tm aes designadas para
solucionar o problema.
Situao: A situao atual do problema. Exemplos de situaes que podem ser

usadas incluem: Aberto, Designado, Resolvido e Cancelado.
Ao necessria para solucionar: Detalhes de quais aes devem ser tomadas

para solucionar o problema. Podem ser mais de uma.
Responsvel pela ao: Pessoa designada para tomar uma ao especfica.
Data de concluso da ao: Pode ser uma data futura estimada ou uma data
passada real, caso o problema esteja encerrado.
Resultado: Os resultados da resoluo.
.2 Gerenciamento de problemas
O problema deve ser rastreado e gerenciado at que seja resolvido, ou que seja
determinado que nenhuma ao ser tomada. Uma reviso regular agendada
do reporte de problemas por todas as partes garante visibilidade e foco sobre os
problemas. Caso os problemas no possam ser solucionados em um perodo de
tempo razovel, pode ser necessrio escalar a questo.
.3 Mtricas
Um elemento adicional que pode ser til para medir como o projeto est se saindo em
relao resoluo de problemas decidir por um conjunto de Mtricas e Indicadores-
Chave de Desempenho (9.16) e ento medir e reportar. Exemplos de possveis KPIs so:
Nmero de problemas por situao e prioridade.
Ciclo de tempo para cada problema (nmero de dias entre a identificao e a

resoluo).

.1 Vantagens
O rastreamento dos problemas oferece um mtodo organizado para rastreamento
e soluo de riscos, questes e defeitos. Ele prov tambm um mecanismo para
comunicar os problemas para a equipe e auxilia a manter o foco sobre os problemas
em aberto at que eles sejam solucionados. A reviso regular dos problemas em
conjunto com a equipe auxilia tambm a manter o foco e garantir resoluo.
.2 Desvantagens
Nas situaes a seguir, o uso da tcnica possui os desafios:
Caso no ocorra priorizao e gerenciamento frequentes, a lista torna-se

desatualizada e irrelevante.

Modelagem de processos Tcnicas
Se principais membros da equipe no estiverem disponveis regularmente para

discutir a lista de problemas e determinar aes a serem tomadas, o processo de
resoluo pode ser muito lento ou mesmo inexistente.
Caso exista uma data limite para a entrega da soluo, o gerenciamento de

problemas torna-se secundrio, com menor prioridade. Frequentemente, a
anlise de causa-raiz dos problemas pode tomar mais tempo e recursos do que
existem disponveis.
9.21 Modelagem de processos

9.21.1 Propsito
Compreender como o trabalho que envolve mltiplos papis e departamentos
desempenhado dentro de uma organizao.
9.21.2 Descrio
Um processo descreve como mltiplas pessoas ou grupos colaboram ao longo de
um perodo de tempo para desempenhar um trabalho. Os processos envolvem um
nmero de atividades vinculadas por um fluxo de sequncia. Um processo repetvel
e pode possuir muitos caminhos para ser completo.
Um processo iniciado por um evento no domnio do negcio, como a venda de um

produto para um cliente, uma requisio de informao por um executivo snior ou
uma falha ao completar uma transao. Os eventos podem ser aes tomadas por
uma pessoa, regras que levam a aes a serem tomadas ou simplesmente a passagem
de um perodo de tempo. O modelo de processos pode envolver atividades manuais,
ser completamente automatizado ou uma combinao de ambos. O processo
finalizado quando o objetivo ou meta do processo completado.
Um modelo de processo uma representao visual do fluxo sequencial e controle

lgico de um conjunto de atividades ou aes relacionadas. A modelagem de
processos usada para obter uma representao grfica de um processo atual ou
futuro dentro de uma organizao. Um modelo pode ser usado no seu nvel mais
alto para obter compreenso geral do processo ou em baixo nvel como uma base
de simulao para que o processo seja feito da forma mais eficientemente possvel.
9.21.3 Elementos
Existem vrias notaes diferentes a serem aplicadas para descrever modelos
de processos. As mais comumente utilizadas so os diagramas de fluxo e os
diagramas de atividades da UML, contudo, o BPMN tem tido uma crescente adoo
recentemente. Os modelos de processos contm tipicamente alguns ou todos os
seguintes elementos-chave:
.1 Elementos de notao
Atividades: Os passos individuais ou partes de trabalho que devem ser completos
para executar o processo de negcio. Uma atividade pode ser uma simples tarefa
ou pode ser decomposta em um subprocesso (com suas prprias atividades, fluxo e
outros elementos de processo).
Decises: Bifurcaes onde o fluxo de trabalho segue para dois ou mais fluxos e
opcionalmente onde fluxos distintos agrupam-se. Uma deciso pode criar fluxos
mutuamente exclusivos ou paralelos.

Tcnicas Modelagem de processos
Figura 9-8: Fluxograma

Raia para o papel Raia para o papel
Inicio
O fluxo de trabalho
Tarefa 1 divide-se. As tarefas so
executadas em paralelo.
Tarefa 2A Tarefa 2B
Entrada/
Sada
Fluxo
funde-se
em uma Subprocesso
tarefa
Falso
Deciso Tarefa 3
Verdadeiro
Um subprocesso
incorpora um
Pare outro modelo
de processo
Raias so extraoficiais, mas so

uma extenso comum no padro
de fluxogramas.
Eventos: Os eventos ocorrem fora do escopo de um processo e podem ser o resultado

de aes tomadas, mensagens recebidas ou da passagem do tempo. Os eventos
podem criar, interromper ou finalizar processos.

Modelagem de processos Tcnicas
Figura 9-9: Diagrama de Atividades

Raia para o papel 1 Raia para o papel 2
Tarefa 1
O fluxo de trabalho
divide-se. As tarefas
so executadas em
paralelo.
Tarefa 2A Tarefa 2B
Fluxo funde-se
Tarefa (I/O)
Subprocesso
Deciso [falso] Tarefa 3
Um subprocesso
[verdadeiro]
incorpora um outro
modelo de
processo
Fluxo: Indica a direo da sequncia passo a passo do fluxo de trabalho. Em geral,

os diagramas so desenhados de cima para baixo ou na direo de leitura para
apresentar a passagem do tempo. O fluxo de processos pode se dividir para permitir
que atividades ocorram de forma simultnea para, em seguida, reunir-se novamente.
Papis: Os papis representam um tipo de pessoa ou grupo. As definies de papis

tipicamente so compatveis com aquelas definidas no Modelagem Organizacional (9.19).

Tcnicas Modelagem de processos
Raias e piscinas: As raias so seces verticais ou horizontais de um processo que

apresentam como as atividades so desempenhadas por um papel em particular.
Quando o fluxo de trabalho atravessa as fronteiras de uma raia, a responsabilidade
por aquele trabalho passa ento para outra pessoa ou grupo dentro da organizao.
Uma piscina representa uma fronteira organizacional. Ela pode incluir vrias raias.
Comumente um processo ir incluir uma piscina para o cliente e uma segunda
piscina para a organizao, contudo, possvel que um processo inclua qualquer
nmero de piscinas.
Pontos terminais: Os pontos terminais representam o incio ou fim de um processo,

ou de um fluxo de um processo. Um ponto terminal geralmente representa algum
tipo de evento que visvel para a organizao ou fora dela.
.2 Melhoria do processo
Existe um certo nmero de frameworks e metodologias que focam na melhoria de
processos, como Seis Sigma, Lean e um grande nmero de abordagens proprietrias de
BPM. Os mtodos para melhoria de processos incluem o mapeamento do fluxo de valor,
anlise e controle estatsticos, simulao de processos, benchmarking, frameworks de
processos e outros. Mudanas comuns nos processos para melhoria incluem:
A anlise de um processo para identificar e remover atividades que no

adicionam valor para uma parte interessada, quando possvel.
Reduo do tempo requerido para completar um processo (atravs da reduo

do tempo para desempenhar uma tarefa ou a espera entre tarefas).
Aperfeioamento das interfaces ou passagens de basto entre papis e unidades

organizacionais para remover erros.
Reduo ou eliminao de gargalos e backlogs.

.1 Vantagens
A maioria das partes interessadas est confortvel com os elementos bsicos e
conceitos por trs de um modelo de processo.
Os modelos de processos so efetivos ao apresentar como manipular grande

nmero de cenrios e ramificaes paralelas.
Os modelos de processos tendem a ter valor em si prprios, conforme so

usados pelas partes interessadas do negcio para treinamento e coordenao
de atividades.
.2 Desvantagens
Modelos de processos podem se tornar extremamente complexos se no
estruturados cuidadosamente. Processos complexos podem envolver
atividades e papis suficientes para faz-los quase impossveis para uma nica
pessoa compreender.
Problemas em um processo podem no ser sempre facilmente identificados

apenas olhando-se para o modelo. usualmente necessrio acionar as partes
interessadas diretamente para descobrir problemas que elas tenham encontrado
quando trabalhando sobre o processo.

Prototipagem Tcnicas
9.22 Prototipagem
9.22.1 Propsito
A prototipagem detalha os requisitos da interface do usurio e os integra aos outros
requisitos como casos de uso, cenrios, regras de dados e de negcio. As partes
interessadas frequentemente consideram a prototipagem como um meio concreto
de identificar, descrever e validar suas necessidades de interface.
9.22.2 Descrio
A prototipagem pode ser categorizada de duas formas:
Escopo funcional. Um prottipo horizontal modela uma viso superficial e

abrangente da funcionalidade do sistema. Ele normalmente no tem qualquer lgica
de negcio rodando por trs da visualizao. Um prottipo vertical modela uma
fatia profunda e limitada da funcionalidade completa do sistema.
Utilizao ao longo do ciclo de vida do desenvolvimento do sistema. Um prottipo

descartvel visa detectar e esclarecer rapidamente os requisitos de interface,
utilizando ferramentas simples, algumas vezes apenas papel e lpis. Como o nome
sugere, tal prottipo usualmente descartado quando o sistema final desenvolvido.
O foco est na funcionalidade que no facilmente elicitada por outras tcnicas, que
possui pontos de vista conflitantes ou que difcil de compreender. Um prottipo
Evolucionrio ou Funcional estende os requisitos iniciais de interface at um
sistema totalmente funcional e requer ferramentas ou linguagens de prototipagem
especializadas. Este prottipo produz um aplicativo de software funcional.
9.22.3 Elementos
.1 Preparar para a prototipagem
Determinar a abordagem da prototipagem: descartvel versus evolucionria/
funcional; vertical versus horizontal.
Identificar a funcionalidade a ser modelada.
.2 Prototipar
Construir o prottipo um processo iterativo. Os esforos iniciais esboam as vises
de alto nvel. As iteraes subsequentes adicionam detalhes, dependendo do escopo
funcional (horizontal versus vertical).
Ao prototipar um relatrio, a primeira iterao pode produzir uma lista de

requisitos de relatrio como atributos de dados, critrios de seleo e regras de
derivao para totalizao. Uma anlise mais aprofundada pode esboar um layout
detalhado do relatrio.
Ao prototipar uma interface que aparece em uma tela (seja em uma tela de
computador, ou em um dispositivo, como um telefone celular ou uma mquina
copiadora), um nmero de iteraes pode ser til. O foco inicial uma compreenso
completa do fluxo da interface. Adicionar detalhes quando apropriado para
o trabalho.
Um storyboard (tambm conhecido como Mapa de Dilogo, Hierarquia de

Dilogo ou Fluxo de Navegao) retrata os caminhos de navegao atravs dos
componentes da interface. A sua representao inclui a abstrao de cada tela
junto com as setas direcionais que indicam os fluxos de navegao permitidos.

Tcnicas Prototipagem
Prottipos de tela fornecem atributos de dados, critrios de seleo e regras de

negcio que as apoiam.
Um layout de tela, ou maquete, fornece uma representao grfica dos elementos.

Neste nvel de detalhe possvel aplicar qualquer padro organizacional ou
orientaes de estilo.
.3 Avaliar o prottipo
Para prottipos detalhados, verificar que os elementos lgicos da interface fazem
referncia aos requisitos do usurio, como processos, regras de dados e de negcio.
Validar que o prottipo representa as necessidades do usurio. Os cenrios so

eficientes para testar as interfaces.

.1 Vantagens
Apoia os usurios que se sentem mais confortveis e efetivos na articulao das
suas necessidades,utilizando imagens, uma vez que prototipagem os deixa ver
a interface futura do sistema.
Um prottipo permite a interao do usurio e feedback antecipado.
Um prottipo descartvel pode ser um meio barato para se descobrir e confirmar

rapidamente uma variedade de requisitos que vai alm da interface, tais como
processos e regras de dados e de negcio.
Um prottipo vertical pode demonstrar o que factvel com a tecnologia

existente e onde pode haver gaps de tecnologia.
Um prottipo evolucionrio/funcional fornece um veculo para os designers e

desenvolvedores aprenderem sobre as necessidades de interface dos usurios e
para envolver requisitos do sistema.
.2 Desvantagens
Dependendo da complexidade do sistema alvo, o uso de prototipagem para
elicitar requisitos pode tomar um tempo considervel se o processo se prender
pelo como ao invs de o que .
Suposies sobre a tecnologia subjacente podem ser necessrias para iniciar a

prototipagem.
Um prottipo pode levar os usurios a desenvolver expectativas no realistas

quanto ao desempenho do sistema entregue, data de entrega, caractersticas
de confiabilidade e usabilidade. Isso ocorre porque um prottipo elaborado e
detalhado pode se parecer muito com um sistema funcional.
Os usurios podem focar nas especificaes de design da soluo, ao invs

dos requisitos que a soluo deve atender. Isso pode, por sua vez, os limitar na
concepo da soluo. Os desenvolvedores podem acreditar que eles devem
entregar uma interface do usurio que atenda precisamente ao prottipo,
mesmo se a tecnologia e abordagens de interfaces superiores existirem.

Workshop de requisitos Tcnicas
9.23 Workshop de requisitos

9.23.1 Propsito
Um workshop de requisitos uma forma estruturada de capturar requisitos. Um
workshop pode ser utilizado para investigar, descobrir, definir, priorizar e atingir o
fechamento dos requisitos do sistema alvo.
Workshops bem executados so considerados a forma mais efetiva de entregar

prontamente os requisitos de alta qualidade. Eles podem promover confiana,
compreenso mtua e forte comunicao entre as partes interessadas do projeto e
time do projeto, e produzem entregas que estruturam e orientam a anlise futura.
9.23.2 Descrio
Um workshop de requisitos um evento altamente produtivo e focado, com
a participao das principais partes interessadas e especialistas no assunto,
cuidadosamente selecionados, para um perodo curto e intenso de trabalho
(tipicamente um ou alguns dias).
O workshop facilitado por um membro da equipe, ou de forma ideal, por um

facilitador experiente e neutro. Um escriba (tambm conhecido como registrador)
documenta os requisitos elicitados como tambm quaisquer questes importantes.
Um analista de negcios deve ser o facilitador ou o escriba nesses workshops.
Em situaes onde o analista de negcios um especialista no assunto, ele pode
servir como um dos participantes do workshop. Contudo, isso deve ser feito com
cautela, uma vez que pode confundir os demais em relao ao papel do analista
de negcios. Alm disso, pode haver suspeita de que o analista de negcio como
participante venha a influenciar a documentao dos requisitos, segundo seus
pontos de vista e prioridades.
Um workshop pode ser usado para gerar ideias para novos recursos ou produtos, para
chegar a um consenso sobre um tema ou para rever requisitos. Outros resultados so
muitas vezes requisitos detalhados, capturados em modelos.
9.23.3 Elementos
.1 Preparar para o workshop de requisitos
Esclarecer as necessidades das partes interessadas e o propsito do workshop.
Identificar partes interessadas crticas que devem participar do workshop.
Definir a agenda do workshop.
Determinar quais meios sero usados para documentar os resultados do

workshop.
Agendar a(s) sesso(es).
Organizar a logstica da sala e equipamentos, incluindo assentos, flipcharts,

projetores, etc.
Enviar material com antecedncia para preparar os participantes e aumentar a

produtividade na reunio.
Conduzir entrevistas pr-workshop com os participantes. No se tratam de

entrevistas completas de requistos. Em vez disto, elas focam em garantir que o

Tcnicas Workshop de requisitos
propsito do workshop de requisitos compreendido e alinhado s necessidades

de cada participante e para garantir que quaisquer necessidades de preparao
requerida para a sesso por aquela parte interessada compreendida.
Determinar o nmero de partes interessadas que deve participar do workshop.
.2 Conduzir o workshop de requisitos

Elicitar, analisar e documentar requisitos.
Obter consenso quanto a vises conflitantes.
Manter o foco atravs da validao frequente das atividades da sesso frente aos
objetivos declarados do workshop.
O facilitador tem a responsabilidade de:
Estabelecer um tom profissional e objetivo para a reunio.
Apresentar as metas e a agenda da reunio.
Impor disciplina, a estrutura e as regras bsicas para a reunio.
Gerenciar a reunio e manter a equipe nos trilhos.
Facilitar um processo de tomada de deciso e construir consenso, mas evitar

participao no contedo da discusso.
Garantir que todas as partes interessadas tenham suas opinies ouvidas.
Fazer as perguntas certas. Isso inclui analisar a informao que fornecida e

aprofundar com perguntas investigativas, se necessrio.
O papel do escriba documentar os requisitos no formato determinado antes do

workshop e acompanhar todos os itens ou questes que so deferidos durante a
prpria sesso.
.3 Fechamento ps-workshop de requisitos

Acompanhar quaisquer itens abertos de ao que foram registrados no
workshop.
Completar a documentao e distribuir para os participantes e para o

patrocinador.

.1 Vantagens
Um workshop de requisitos pode ser um meio de elicitar requisitos detalhados
em um perodo de tempo relativamente curto.
Um workshop de requisitos fornece meios para as partes interessadas

colaborarem, tomarem decises e atingirem a compreenso mtua dos
requisitos.
O custo de um workshop de requisitos , muitas vezes, inferior ao custo da

conduo de vrias entrevistas. Um workshop de requisitos permite que os
participantes trabalhem em conjunto para atingir um consenso. Esta pode ser

Anlise de riscos Tcnicas
uma abordagem mais barata e rpida do que a execuo de vrias entrevistas

de requisitos, uma vez que entrevistas podem levar a requisitos conflitantes e o
esforo necessrio para solucionar esses conflitos junto a todos os entrevistados
pode ser muito custoso.
O feedback imediato. A interpretao do facilitador dos requisitos fornecida

imediatamente para as partes interessadas e validada.
.2 Desvantagens
A disponibilidade das partes interessadas pode tornar difcil a programao do
workshop de requisitos.
O sucesso do workshop de requisitos altamente dependente da habilidade do

facilitador e do conhecimento dos participantes.
Workshops de requisitos que envolvem muitos participantes podem tornar o

processo lento. Por outro lado, coletar informaes de poucos participantes pode
levar a ignorar requisitos que so importantes para usurios, ou a especificar
requisitos que no representam as necessidades da maioria dos usurios.
9.24 Anlise de riscos

9.24.1 Propsito
Identificar e gerenciar reas de incerteza que podem impactar uma iniciativa,
soluo ou organizao.
9.24.2 Descrio
Um risco descreve uma ocorrncia ou evento incerto que pode ter um efeito na
capacidade do analista de negcios, equipe do projeto ou organizao de atingir
um objetivo. Os riscos so por natureza positivos ou negativos. A anlise de riscos
envolve uma compreenso dos nveis de tolerncia a risco da organizao, avaliao
dos riscos e identificao das respostas.
9.24.3 Elementos
.1 Tolerncia a Risco
Um fator-chave na determinao da resposta que uma pessoa ou organizao ir
selecionar em relao a um risco a compreenso da sua tolerncia a risco. No
existe uma resposta correta ou ideal uma estratgia geral deve ser adaptada para
cada circunstncia particular. As trs categorias gerais de tolerncia a risco so:
Averso a Risco. Uma pessoa ou organizao avessa a risco procurar reduzir

os riscos, particularmente os negativos, e prefere aproximar-se ao mximo da
certeza. A reduo dos benefcios potenciais em vista de um resultado mais
garantido tida como uma troca aceitvel.
Neutralidade. Uma abordagem neutra ao risco significa que os benefcios

provveis da resposta ao risco devem se igualar ou superar os custos, no intuito
de justificar uma ao.
Busca por riscos. Uma pessoa ou organizao que busca riscos desejar aceitar
riscos relativamente altos, no intuito de maximizar o benefcio potencial. Pode
aceitar poucas chances de sucesso, se os benefcios do sucesso forem maiores.

Tcnicas Anlise de riscos
Um indivduo ou organizao pode exibir diferentes nveis de tolerncias a risco em

diferentes momentos. Por exemplo, foi demonstrado que a maior parte das pessoas
aceitar riscos maiores para evitar uma perda percebida do que aceitaria para
aumentar o pagamento por um sucesso, mesmo quando os resultados financeiros
forem idnticos. O tamanho e potencial impacto do risco podem tambm afetar a
tolerncia ao risco.
.2 Avaliao
A avaliao envolve determinar a probabilidade de ocorrncia de um risco e o
impacto, caso ele ocorra. Cada um desses fatores avaliado com base em uma escala
comum (alto, mdio e baixo, ou um nmero de 1 a 5, por exemplo). Isso permite que
a anlise foque nos riscos mais importantes.
.3 Resposta
As estratgias de resposta determinam como a organizao ir lidar com um risco.
Para riscos negativos, as estratgias incluem:
Aceitar. No feito nenhum esforo para lidar com o risco. A organizao aceita
a possibilidade de que o risco ocorra.
Transferir. A responsabilidade de lidar com o risco e com os possveis efeitos do

risco so movidos para terceiros.
Evitar. A organizao toma medidas para garantir que o risco no ocorrer.
Mitigar. A organizao toma aes para reduzir a probabilidade de ocorrncia

do risco ,ou para reduzir as possveis consequncias negativas ,caso ele ocorra.
Para riscos positivos, a aceitao tambm uma estratgia vivel. Outras estratgias
incluem:
Compartilhar. Trabalhar com um terceiro para aumentar a probabilidade de

resultado positivo e concordar em compartilhar os benefcios.
Melhorar. A organizao toma aes para aumentar a probabilidade do risco

ocorrer e os benefcios potenciais, caso o risco ocorra.
Explorar. A organizao trabalha para garantir que o evento ocorra.

.1 Vantagens
A anlise de riscos permite que uma organizao prepare-se para a possibilidade de
que pelo menos algumas coisas no ocorrero conforme planejado.
.2 Desvantagens
O nmero de riscos possveis na maior parte das iniciativas pode facilmente tornar-
se grande e no gerencivel. Pode ser possvel gerenciar apenas um subconjunto dos
riscos potenciais.
Uma vez que os riscos so intrinsecamente incertos, pode ser difcil estimar o
impacto dos riscos de forma til.

Anlise de Causa-Raiz Tcnicas
9.25 Anlise de Causa-Raiz

9.25.1 Propsito
O propsito da anlise de causa-raiz determinar a fonte implcita de um problema.
9.25.2 Descrio
A anlise de causa-raiz um exame estruturado dos aspectos de uma situao para
estabelecer as causas-razes e efeitos resultantes do problema. Um elemento-chave
da anlise de causa-raiz garantir que o pensamento do negcio e processos sejam
desafiados. Ou seja, eles ainda fazem sentido e fornecem bom valor para o negcio
sob a tica da realidade atual?
Figura 9-10: Diagrama de Espinha de Peixe

Categoria 1 Categoria 2
Causa Primria
Causa Terciria
Efeito
Causa Secundria
Categoria 3 Categoria N
9.25.3 Elementos
Dois mtodos de anlise mais comumente usados incluem o diagrama espinha de
peixe e os cinco por qus:
.1 O diagrama espinha de peixe

Um diagrama espinha de peixe (tambm conhecido como diagrama Ishikawa
ou de causa-efeito) usado para identificar e organizar as causas possveis de um
problema. Essa ferramenta ajuda a dar foco na causa de um problema versus sua
soluo e organiza as ideias para anlise futura. O diagrama serve como um mapa
descrevendo os relacionamentos causa-efeito possveis. Os passos para desenvolver
um diagrama de causa-efeito so:
Capturar a questo ou problema em discusso em uma caixa no topo do diagrama.
Desenhar uma linha a partir da caixa ao longo do papel ou quadro branco

(formando a espinha dorsal do peixe).
Desenhar linhas diagonais a partir da espinha para representar categorias de

causas potenciais do problema. As categorias podem incluir pessoas, processos,
ferramentas e polticas.
Desenhar linhas menores para representar causas mais profundas.

Tcnicas Cenrios e Casos de uso
Utilizar brainstorming em busca de categorias e causas potenciais do problema e

captur-las sob as categorias apropriadas.
Analisar os resultados. Lembrar que o grupo identificou apenas causas

potenciais para o problema. Anlise futura necessria para validar a causa de
fato, idealmente baseada em dados.
Utilizar brainstorming em busca de solues potenciais, uma vez identificada a

causa real.
.2 Cinco Por Qus

Os Cinco Por Qus um processo de pergunta e resposta para explorar a natureza e
a causa de um problema. A abordagem dos Cinco Por Qus faz perguntas repetidas
na tentativa de alcanar a causa-raiz do problema. Esta uma das ferramentas de
facilitao mais simples para se utilizar quando os problemas tm um componente
humano de interao. Para usar essa tcnica:
Escrever o problema em um flipchart ou quadro branco.
Perguntar: Por que voc pensa que esse problema ocorre? e capture a ideia
abaixo do problema.
Perguntar: Por qu? novamente e capture a ideia abaixo da primeira ideia.
Continuar com o passo trs at estar convencido de que a causa-raiz de fato tenha
sido identificada. Isso pode tomar por volta de cinco perguntas e por isso a tcnica
chamada dos Cinco Por Qus, pois costuma demandar cinco perguntas para
atingir a causa-raiz, no porque a pergunta deva ser feita exatamente cinco vezes.
Os Cinco Por Qus podem ser usados isoladamente ou como parte da tcnica
do diagrama espinha de peixe. Uma vez que todas as ideias sejam capturadas no
diagrama, utilizar os Cinco Por Qus para aprofundar para as causas-razes.

.1 Vantagens
A anlise de causa-raiz fornece um mtodo estruturado para identificar as causas-
razes dos problemas identificados, assegurando uma compreenso completa do
problema sob reviso.
.2 Desvantagens
A anlise de causa-raiz funciona melhor quando algum que possui um treinamento
formal ou experincia extensiva facilita um time de especialistas. A preocupao
primria fundamenta-se no fato do facilitador permanecer objetivo, um elemento-
chave para a efetiva anlise de causa-raiz.
9.26 Cenrios e Casos de uso

9.26.1 Propsito
Cenrios e casos de uso so escritos para descrever como um ator interage com uma
soluo para alcanar uma ou mais metas do ator, ou para responder a um evento.
9.26.2 Descrio
Enquanto os termos cenrio e caso de uso so frequentemente usados de forma
livre, um cenrio geralmente compreendido como descrevendo apenas uma forma

Cenrios e Casos de uso Tcnicas
com a qual um ator pode atingir uma meta em particular, enquanto um caso de uso
descreve todos os resultados possveis de uma tentativa de atingir uma determinada
meta que a soluo ir apoiar.
Os cenrios so escritos como uma srie de passos desempenhados pelos atores ou

pela soluo que permita que um ator atinja uma meta. Um caso de uso descreve
diversos cenrios na forma de fluxo primrio e alternativos. O fluxo primrio
ou bsico representa a forma mais simples de atingir uma meta do caso de uso.
Circunstncias especiais e excees que resultam em uma falha para complementar
a meta do caso de uso so documentadas em fluxos alternativos.
9.26.3 Elementos
.1 Nome
Um cenrio ou caso de uso deve ter um nome nico dentro do projeto. O nome do
caso de uso deve descrever qual meta ou evento ele tratar e geralmente inclui um
verbo (descrevendo a ao tomada pelo ator) e um substantivo (descrevendo o que
est sendo feito, ou o alvo da ao).
.2 Ator(es)
Um ator uma pessoa, sistema ou evento externo ao sistema que interage com
aquele sistema atravs do caso de uso. Cada ator deve possuir um nome nico que
represente o papel que ele desempenha nas interaes com o sistema. Este papel no
corresponde necessariamente a um nome de cargo e nunca deve ser o nome de uma
pessoa real. Uma pessoa em particular pode preencher os papis de mltiplos atores
ao longo do tempo.
Ateno: Um evento temporal raramente modelado como um ator que inicializa

um caso de uso. A utilizao mais comum de um evento temporal como um ator
o uso de um ator tempo que dispare um caso de uso que deve ser executado com
base em datas no calendrio (como um sistema de conciliao mensal ou anual).
Alguns autores no recomendam este uso.
.3 Precondies
Uma precondio qualquer fato que a soluo deva assumir como verdadeira
para quando o caso de uso inicia-se. Isso pode incluir declaraes textuais como
o usurio deve estar habilitado ou o item deve existir no catlogo, ou a execuo
com sucesso de outros casos de uso.
.4 Fluxo de eventos
Descreve o que o ator e o sistema esto fazendo durante a execuo do cenrio ou
caso de uso. A maior parte das descries de casos de uso far a quebra posterior
em um fluxo bsico, ou primrio (representando o caminho de sucesso mais curto)
e uma quantidade de fluxos alternativos que apresentam lgica mais complexa ou
tratamento de erros. Caso uma circunstncia ainda permita que o ator alcance com
sucesso a meta do caso de uso, ela definida como alternativa. Caso a circunstncia
no permita que o ator alcance com sucesso a meta, o caso de uso considerado
falho e terminado. Esta circunstncia definida como exceo.
.5 Ps-condies
Qualquer fato que deva ser verdadeiro quando o caso de uso esteja completo. As
ps-condies devem ser verdadeiras para todos os fluxos possveis ao longo do caso
de uso. O caso de uso pode descrever ps-condies separadas que so verdadeiras
para execues bem e mal sucedidas do caso de uso.

Tcnicas Cenrios e Casos de uso
.6 Relacionamentos
Os relacionamentos entre atores e casos de uso so chamados de associaes. As
associaes no representam entradas, sadas, tempo ou dependncias. Uma
linha de associao apenas indica que um ator possui acesso (de alguma forma)
funcionalidade representada pelo caso de uso.
Os relacionamentos entre casos de uso so conhecidos como esteretipos. Existem

dois tipos comumente utilizados de esteretipos:
Extenso: permite a insero de comportamento adicional ao caso de uso. Um caso

de uso que est sendo estendido deve ser completamente funcional por si s. O caso
de uso que o estende no precisa ser completo sem a referncia ao caso de uso base.
Uma extenso idntica a um fluxo alternativo, mas capturada em um caso de uso
separado por convenincia.
Incluso: permite que o caso de uso base faa uso de funcionalidade presente em
outro caso de uso. O caso de uso includo no precisa ser um cenrio completo por
si s, caso no seja disparado diretamente por um ator. Este relacionamento mais
frequentemente usado quando alguma funcionalidade compartilhada requerida
por vrios casos de uso.

.1 Vantagens
Os casos de uso so bons no esclarecimento do escopo e no fornecimento de uma
compreenso de alto nvel das metas de comportamento do usurio, situaes
normais, alternativas ou caminhos de exceo ao longo de uma atividade ou
processo de negcio.
Figura 9-11: Diagrama de Casos de Uso
Sistema
Caso de Uso Caso de Uso

3 4
estende inclui
Caso de Uso 2
Caso de Uso
Pontos de Extenso:
1
Chamar Caso de Uso 3
Ator 1 Ator 2
.2 Desvantagens
Os analistas de negcios so frequentemente tentados a descrever a maior parte do
comportamento do sistema, usando casos de uso. Uma vez que muitos requisitos
podem ser capturados no formato de casos de uso, existe uma tentao de us-los
para capturar todos os requisitos, mesmo em situaes nas quais difcil aplic-los,
ou quando outros mtodos seriam mais apropriados.
Os casos de uso no possuem muitos recursos para apoiar a interao ou descoberta

de elementos em comum, uma das razes para que eles sejam de fato escritos no

Modelagem do Escopo Tcnicas
nvel mais alto de abstrao. Anlise e desenho adicionais so normalmente

necessrios aps a definio do caso de uso estar completa para identificar esses
elementos comuns.
Figura 9-12: Diagrama de Contexto (Notao de Gane-Sarson)

0
Pacote de
Pacote de
Agente Dados de Agente
Entrada
Nome do Sistema Dados de
Externo (Entrada de de Negcio Sada (Sada Externo
de Sistema 1)
Sistema 1)
Figura 9-13: Diagrama de Contexto (Notao de Yourdon)
Entidade Depsito de
Externa Dados
Dados de Entrada
Dados de Sada
Dados de Sada
Nome
do
Sistema
Entidade
Dados de Sada
Externa
9.27 Modelagem do Escopo

9.27.1 Propsito
Modelos do escopo so usados para descrever o escopo da anlise ou o escopo da soluo.
9.27.2 Descrio
Os modelos do escopo servem como uma base para a definio e a delimitao
do escopo do trabalho da anlise de negcios e do projeto. Os modelos de escopo
permitem a definio de escopo completo isto , as fronteiras do escopo
correspondem com as fronteiras naturais de um domnio do negcio.
Existem muitos padres diferentes para a modelagem do escopo. Em geral, o

modelo de escopo selecionado depender das tcnicas de anlise selecionadas, para
posteriormente explorar o escopo.

Tcnicas Modelagem do Escopo
9.27.3 Elementos
.1 Diagrama de Contexto
Um diagrama de contexto um diagrama de fluxo de dados de alto nvel. Ele usa um
processo nico de dados para descrever o escopo e apresenta as entidades externas
e os depsitos de dados que fornecem e recebem dados do sistema. Os diagramas de
contexto ainda so usados em muitos projetos que no sejam contrrios ao uso de
diagramas de fluxo de dados.
.2 Eventos
Eventos externos ocorrem em uma Entidade Externa. Eles so externos s
fronteiras do sistema sendo estudado (um cliente faz um pedido, um parceiro envia
uma mensagem).
Os eventos temporais so dirigidos pelo tempo (ex.: relatrios mensais ou anuais).

O tempo determinado por regras de negcio relacionadas ao tempo (ex.: produzir
este relatrio ao final de cada dia, ou preparar uma declarao de impostos no final
do perodo fiscal).
Quando os eventos forem identificados, a prxima questo a ser feita quais

processos so necessrios para prover uma resposta completa para este evento?. As
respostas para essa pergunta identificam os processos do sistema. Esses processos
podem ser documentados e posteriormente analisados, usando uma tcnica de
modelagem de processos adequada.
.3 Recursos
Um recurso um servio que fornece a soluo para satisfazer uma ou mais
necessidades das partes interessadas. Os recursos so abstraes de alto nvel da
soluo que devem ser posteriormente expandidas em requisitos funcionais e
suplementares, descritos de forma completa. Eles permitem um gerenciamento
adiantado da prioridade e do escopo, e a validao da viso das partes interessadas
em relao soluo.
.4 Diagrama de Casos de Uso

Um diagrama de casos de uso descreve visualmente os casos de uso apoiados por um
sistema, os atores que disparam aqueles casos de uso e os relacionamentos entre os
casos de uso.
.5 Processo de Negcio
Um modelo de alto nvel de um processo de negcio pode tambm ser usado como
modelo do escopo.

.1 Vantagens
Um modelo de escopo tornar mais fcil a determinao do que deve estar dentro
e fora do escopo para uma soluo, mesmo quando requisitos forem identificados
ou alterados.
.2 Desvantagens
Um modelo de escopo normalmente deixar detalhes a serem investigados
posteriormente.

Diagramas de Sequncia Tcnicas
9.28 Diagramas de Sequncia

9.28.1 Propsito
Os diagramas de sequncia so utilizados para modelar a lgica de cenrios de uso
atravs da apresentao da informao passada entre objetos no sistema, a partir da
execuo do cenrio.
9.28.2 Descrio
Um diagrama de sequncia apresenta como classes e objetos interagem durante
um cenrio. As classes necessrias para executar o cenrio so mostradas no
diagrama, assim como as mensagens que elas trocam entre si (disparadas por
passos no caso de uso). O diagrama de sequncia apresenta como os objetos usados
no cenrio interagem, mas no como eles esto relacionados entre si. Os diagramas
de sequncia so frequentemente usados para apresentar como os componentes da
interface do usurio ou componentes do software interagem.
9.28.3 Recursos-Chave
O diagrama de sequncia apresenta instncias particulares de cada objeto, com
uma linha de vida sob cada objeto para indicar quando o objeto criado e destrudo.
Os primeiros eventos no cenrio so representados no topo da linha de vida com
os eventos posteriores apresentados abaixo. O diagrama de sequncia especifica
apenas a ordem dos eventos e no o tempo exato.
O diagrama de sequncia apresenta o estmulo fluindo entre os objetos. O estmulo

a mensagem e a chegada do estmulo a um objeto chamado de evento.
Uma mensagem apresentada como uma seta apontando da linha de vida do objeto
remetente para a linha de vida do objeto destinatrio. Os fluxos de controle de
mensagens descrevem os tipos de mensagens enviadas entre os objetos.
Transferncias de fluxos procedurais para o objeto destinatrio. O remetente

no pode agir at que uma mensagem de retorno seja recebida.
Fluxo assncrono (tambm conhecido como um sinal) permite que o objeto

continue com o seu processamento aps o envio do sinal. O objeto pode enviar
muitos sinais simultaneamente, mas pode aceitar somente um sinal por vez.
Figura 9-14: Diagrama de Sequncia (UML)
Nome do Objeto
Mensagem Simples
Mensagem Assncrona
Mensagem Sncrona
Mostra quando o objeto est ativo

Tcnicas Diagramas de Estados
9.28.4 Consideraes de Uso

.1 Vantagens
O diagrama de sequcia pode ser usado na anlise orientada a objetos para validar
diagramas de classes (descritos no item 9.7) em relao aos casos de uso (9.26), ou para
apresentar o tempo de interaes entre as entidades dentro do escopo do sistema.
.2 Desvantagens
Um diagrama de sequncia deve ser definido para cada cenrio possvel.
Estritamente falando, um diagrama de sequncia requer um modelo de classes
totalmente definido (veja Modelo de Dados), contudo, diagramas de sequncia
menos formais frequentemente desenvolvidos representam elementos da interface
do usurio ou interaes entre os atores.
9.29 Diagramas de Estados

9.29.1 Propsito
Um diagrama de estados apresenta como o comportamento de um conceito,
entidade ou objeto muda em resposta a eventos.
9.29.2 Descrio
Um diagrama de estados especifica a sequncia dos estados que um objeto passa
durante o seu tempo de vida e define quais eventos causam uma transio entre
esses estados. O comportamento permitido para um objeto dependente do
seu estado atual. Existem muitos ttulos para o diagrama de estados, incluindo
Diagrama de Mquina de Estados, Diagrama de Transio de Estados e Diagrama
do Ciclo de Vida da Entidade.
Figura 9-15: Diagrama de Mquina de Estados (UML)
Estado
Inicial
Estado
Nome do Estado
Final
entrada/ao
fazer/atividade Evento
Estado
sada/ao
evento/ao(parmetros)
Descreve as coisas que
podem acontecer
quando o objeto est Eventos causam a
naquele estado. mudana de estado
do objeto.
Nome do Estado Composto
Estado Estado
O objeto pode mudar entre Diagramas de Atividades UML

estes estados, uma vez que so um caso especial de
entra em um estado mquinas de estado.
composto.

Reviso Estruturada Tcnicas
9.29.3 Elementos
.1 Estados
Um estado representa uma condio nica que um objeto pode estar ou um estado
que ele pode ter. Todos os estados para um objeto so mutuamente exclusivos
um objeto pode estar apenas em um estado por vez. O significando de um estado
definvel dentro do contexto da rea de negcios que est sendo analisado.
Detalhes adicionais do estado, tais como caractersticas obrigatrias e demais
relacionamentos, descrevem o estado. Por exemplo, um Projeto Cancelado deve ter
uma data de cancelamento.
Todas as mquinas de estados devem possuir um estado inicial (representando

o estado do objeto na sua criao) e podem ter qualquer nmero de estados
intermedirios e finais.
.2 Transies
Uma transio representa um comportamento dinmico que move um item de um
estado para outro. As transies so disparadas por atividades completas, eventos
ou outros estmulos. Um evento apenas pode causar uma transio se o objeto
for afetado pelo evento no seu estado atual. Alm disso, regras de negcio podem
determinar se um objeto responde a um evento em particular.

.1 Vantagens
Os especialistas no assunto devem estar intimamente a par do ciclo de vida dos
estados das suas principais preocupaes. Auxili-los a listar e descrever os estados
e ento desenhar as transies permitidas entre estados frequentemente revela
dados, requisitos de controle e comportamento esquecidos, e pode ser til para
esclarecer requisitos confusos ou mesmo conflitantes.
.2 Desvantagens
Uma vez que os Especialistas no Assunto podem compreender e desenvolver
diagramas de estado muito rapidamente, ento importante no expandir
intencionalmente o escopo. Cada estado (e transies associadas) deve ser validado
para determinar se ele relevante para o escopo da soluo. Pode haver estados
reais de um objeto que avanam atravs da parte do seu ciclo de vida, mas que no
possuem relevncia para o domnio. Esses estados no devem ser modelados.
9.30 Reviso Estruturada

9.30.1 Propsito
As revises estruturadas so desempenhadas para comunicar, verificar e validar
requisitos.
9.30.2 Descrio
Uma reviso estruturada uma sesso de trabalho, na qual participantes convidados
revisam e discutem um conjunto de requisitos. Os participantes so requeridos a
responder a perguntas, fazer comentrios e dar sugestes. Outras questes podem
tambm ser identificadas durante a sesso. Todas as perguntas, comentrios,
preocupaes e sugestes so registradas.
Uma reviso estruturada pode resultar em requisitos revisados, bem como questes
que exigem investigao. Uma reviso estruturada pode tambm ser chamada de

Tcnicas Reviso Estruturada
reviso de requisitos. Uma inspeo similar, mas segue um processo mais formal,
utiliza checklists e outras ferramentas.
Figura 9-16: Papis em uma Reviso Estruturada
Papel Desempenhado por Descrio
Autor Autor do documento de requisitos, Responde s perguntas sobre o
normalmente o analista de negcios. Uma documento, ouve sugestes e
reviso no deve ser conduzida sem a comentrios. Incorpora mudanas no
presena do autor. documento aps a sesso de reviso.
Documentador Qualquer membro da equipe do projeto Pessoa que documenta todas as
que est familiarizado com o projeto pode sugestes, comentrios, questes,
desempenhar este papel. O autor pode preocupaes e perguntas pendentes
faz-lo. que surjam durante a reviso.
Moderador Um facilitador neutro. Muitas vezes Facilita a sesso de trabalho mantendo
desempenhado por um analista de os participantes focados em cada
negcios ou testador. Este papel parte do documento conforme ela
obrigatrio. melhor que o autor no discutida. Verifica que todos os
atue como moderador, embora, muitas participantes revisaram os documentos
vezes, a limitao de recursos o exija. antes do incio da sesso. Garante
Quando isso ocorre, o risco a falta de que todos os participantes estejam
objetividade em relao ao documento. participando da reviso.
Par Um outro analista de negcios que O par revisa o documento para garantir
possui experincia na preparao de a aderncia aos padres de boa
documentos de requisitos similares. documentao de requisitos.
Revisor Qualquer parte interessada. Revisa o documento antes da sesso
de trabalho. Apresenta perguntas,
comentrios, mudanas sugeridas e as
discute com o grupo.
9.30.3 Elementos
.1 Pr-requisitos
Um pacote completo de requisitos. Um modelo ou pacote de requisitos deve estar
completo para que se possa agendar uma reviso. A reviso pode cobrir apenas um
documento de requisitos, vrios documentos relacionados ou um pacote completo
de requisitos.
Uma lista de revisores apropriados. Os revisores podem ser partes interessadas

do processo, analistas de negcios ou outros recursos com expertises especficas no
tipo de requisito a ser revisado. Revisores apropriados incluem:
Representantes reconhecidos das partes interessadas que contriburam com os

requisitos.
Representantes reconhecidos das partes interessadas que utilizaro os

requisitos no desenvolvimento da soluo.
Revisores que representam o patrocinador ou os usurios finais do projeto. Esses

indivduos devem ser aprovados pela gerncia das unidades organizacionais e
ter autoridade para tomar decises, como seu representante. Isso configura uma
procurao de delegao de voto.
Um veculo de reunio. Uma reviso pode ser realizada em uma sala de conferncia
com todos os participantes presentes, ou pode ser realizada utilizando alguma

Reviso Estruturada Tcnicas
facilitao tcnica que permita participao distncia (ex.: ferramenta de

colaborao, videoconferncia, software de reunies via Internet).
.2 Processo
Revisar o Escopo
Fornecer aos participantes da reviso um checklist contendo os itens que o revisor
deve observar. Exemplos de coisas que podem estar em um checklist para uma
sesso em particular incluem requisitos que esto fora do escopo, requisitos que
descrevem como o requisito ser implementado (especificaes da soluo) ao invs
de requisitos de negcio ou de partes interessadas, ou a acuidade da descrio dos
processos de negcio atuais.
Organizar e Agendar a Reviso

O Analista de Negcios deve garantir que o pacote de requisitos seja enviado com
antecedncia suficiente para permitir que todas as partes interessadas possam
efetuar revises. As partes interessadas com autoridade de aprovao devem estar
presentes na sesso. Os revisores precisam entender que o propsito da reviso
encontrar e remover requisitos confusos, inconsistentes e incorretos.
Conduzir a Reviso
A sesso propriamente dita dever ter a seguinte estrutura:
Introduo das partes participantes;
Declarao do propsito da entrega a ser revisada;
Declarao dos objetivos da reviso;
Histrico do projeto (caso solicitado pelas partes externas);
Reviso estruturada formal / reviso da entrega;
Consenso em relao s aes/mudanas requeridas;
Reviso da situao da entrega (aprovada, no aprovada, etc).
Compilar Notas e Resultados da Reviso

Garantir que todos os comentrios dos participantes sejam registrados e
considerados para revises no documento de requisitos.
Ao final da reviso, deve ser consenso se:
Existem melhorias de qualidade que podem ser feitas no documento de

requisitos
O documento de requisitos aceitvel na sua forma atual
So necessrias revises adicionais para comentar ou aprovar o documento de

requisitos
Re-revisar Caso Necessrio

Uma deciso tambm ser tomada quanto necessidade de outra reviso/inspeo
caso a entrega no tiver sido aceita.

Tcnicas Pesquisa / Questionrio
.3 Regras Para Serem Seguidas Durante a Reviso

Existem algumas regras que devem ser seguidas na conduo de uma reviso
estruturada. O moderador responsvel por garantir a aderncia s regras por parte
de todos os participantes.
Sob circunstncias normais, supervisores ou gerentes (especialmente do autor)

devem exercitar cautela se participarem de uma reviso. A sua autoridade
organizacional, especialmente no que tange a outros participantes da reviso,
pode afetar negativamente o nvel de franqueza durante a reviso. Pode haver
tambm a tentao de fazer uso da sua autoridade nos momentos de deciso de
forma inapropriada.
Os revisores devem revisar e comentar o contedo, no o autor.
Os participantes devem revisar o documento antes da sesso.
O analista de negcios deve determinar as partes interessadas apropriadas do

projeto que participaro de uma reviso estrutura. A entrega de uma reviso
estruturada uma lista de perguntas, comentrios, preocupaes e sugestes que
so compiladas durante a sesso de trabalho. Veja Rastreamento de Problemas (9.20).

.1 Vantagens
Promove discusso dos requisitos entre as partes interessadas.
Efetivas na identificao de possveis ambiguidades e reas de mal- entendidos.
.2 Desvantagens
As sesses de reviso podem levar a repetidas revises, caso as mudanas no sejam
cuidadosamente gerenciadas. A durao do ciclo de reviso e anlise pode resultar
em um processo de aprovao demorado.
9.31 Pesquisa / Questionrio

9.31.1 Propsito
Uma pesquisa um meio de elicitar informaes de muitas pessoas, algumas vezes
de forma annima, em um perodo relativamente curto de tempo. Uma pesquisa
pode coletar informaes sobre clientes, produtos, prticas de trabalho e atitudes.
Uma pesquisa pode tambm ser chamada de questionrio.
9.31.2 Descrio
Uma pesquisa consiste em um conjunto de perguntas escritas s partes interessadas
e aos especialistas do assunto. De forma alternativa, so fornecidos aos respondentes
uma srie de declaraes em que so solicitados a indicar o seu grau de concordncia
ou apoio. As respostas so analisadas e distribudas s partes apropriadas.
As perguntas em uma pesquisa so de dois tipos:
Fechadas: solicitado ao respondente selecionar entre as respostas disponveis.

Isso til quando o espectro de respostas possveis bem compreendido, mas
a fora de cada categoria de respostas precisa ser determinada. As respostas s
perguntas fechadas so mais fceis de analisar do que aquelas adquiridas a partir
de perguntas abertas, porque elas podem ser vinculadas a coeficientes numricos.

Pesquisa / Questionrio Tcnicas
Abertas: O respondente livre para responder s perguntas da forma que

desejar. til quando as questes so conhecidas, mas o espectro de respostas
possveis no . As respostas a perguntas abertas podem fornecer mais detalhes
e um espectro maior de respostas do que as obtidas com perguntas fechadas.
Contudo, perguntas abertas so mais difceis de quantificar e resumir, pois elas
frequentemente incluem linguagem qualitativa ao invs de quantitativa.
9.31.3 Elementos
.1 Preparar
Uma pesquisa requer preparao detalhada para garantir que a informao
necessria seja obtida enquanto se busca diminuir o tempo necessrio para o
respondente complet-la.
Definir o propsito da pesquisa e o grupo alvo. Identificar os objetivos e o grupo

a ser pesquisado. Confirmar junto ao patrocinador.
Escolher o tipo apropriado de pesquisa. Os passos iniciais de uma pesquisa so

semelhantes aos de uma entrevista (9.14), mantendo-se em mente que entrevistas
semiestruturadas so similares s pesquisas com respostas abertas e entrevistas
estruturadas so similares s pesquisas de respostas fechadas.
Selecionar o grupo de amostra. Considere ambos os tipos de pesquisa (aberta

e fechada) e o nmero de pessoas no grupo identificado de usurios para
determinar se o grupo todo precisa ser pesquisado. Quando um grupo de
amostra pequeno, pode ser prtico entrevistar todos os membros do grupo.
Quando o grupo grande e a pesquisa desejada de perguntas abertas, pode ser
necessrio identificar um subconjunto de usurios. Pode tambm ser importante
pesquisar todos os membros de um grupo grande se seus perfis indicarem
grandes variaes devido distribuio geogrfica, diferenas reguladoras ou
falta de padronizao nos cargos ou processos de negcios. Para situaes como
essas, o uso de amostragem estatstica ir auxiliar a garantir que os resultados
da pesquisa no sejam tendenciosos.
Seleo dos mtodos de distribuio e coleta. Para cada grupo de amostra

determinar o modo apropriado de comunicao, como questionrio impresso,
correio eletrnico (e-mail) ou frum na web.
Projetar o nvel desejado de resposta. Determinar qual seria o percentual de

retorno de respostas aceitvel. Se o percentual atual de respostas estiver abaixo
do limite aceitvel, o uso do resultado da pesquisa pode ser limitado. Oferecer
um incentivo pode aumentar o percentual de respostas, mas o custo do incentivo
deve ser justificado e orado.
Determinar se a pesquisa deve ser apoiada por entrevistas individuais. Uma vez
que uma pesquisa no fornece o aprofundamento das informaes como ocorre
nas entrevistas individuais, considerar:
Entrevistas preliminares pesquisa com indivduos-chave podem fornecer

ideais para perguntas da pesquisa.
Entrevistas aps a pesquisa podem atacar respostas especficas da pesquisa

ou temas para elicitar um nvel maior de detalhe.
Escrever as perguntas da pesquisa.

Tcnicas Pesquisa / Questionrio
Comunicar o propsito. Explicar os objetivos da pesquisa. Se as partes

interessadas puderem ver razo para completar a pesquisa, elas so mais
propensas a faz-la.
Estar ciente das caractersticas do grupo. Compreender o histrico do

grupo alvo, incluindo o seu ambiente e terminologia especfica. Utilize essa
informao ao escrever as perguntas. Se existir uma diversidade significativa
nos histricos do grupo, pode ser til dividir o grupo grande em grupos
menores e homogneos durante o estgio de preparao e, ento, produzir
variaes da pesquisa que se adaptam ao histrico de cada subgrupo.
Foco nos requisitos: Todas as perguntas devem ser feitas na direo dos
objetivos declarados.
Fazer a pesquisa fcil e rpida de ser completada, de preferncia em no mais

de cinco ou dez minutos. Isso implica limitar o nmero de itens da pesquisa
e organiz-los em uma ordem que conte uma histria.
Garantir que as palavras utilizadas nas perguntas sejam claras e concisas,

usando terminologia familiar para os respondentes.
Cada item deve abordar um ponto especfico. Evitar perguntas duplas em

uma nica pergunta.
Evitar o uso de frases na negativa.
Evitar estruturas complexas nas quais o resultado de um se filtrado

atravs de subsequentes se.
Evitar fazer perguntas que possam deixar os respondentes desconfortveis.

A tentativa de elicitar informaes que so restritas por regulamentos tende
a colocar as pessoas na defensiva.
Teste a pesquisa. Execute um teste de usabilidade na pesquisa. Utilize os

resultados para fazer ajustes pesquisa.
.2 Distribuir a pesquisa
Os meios de distribuio devem ser selecionados com base em:
Polticas organizacionais
Urgncia na obteno dos resultados
Nvel de segurana requerido
Distribuio geogrfica dos respondentes
.3 Documentar os resultados da pesquisa

Confrontar as respostas. Para as respostas de perguntas abertas, avaliar os
detalhes e identificar quaisquer temas emergentes.
Analista e resumir os resultados.
Reportar descobertas ao patrocinador.

Anlise SWOT Tcnicas

.1 Vantagens
Na utilizao de perguntas fechadas, as pesquisas podem ser efetivas na
obteno de dados quantitativos para uso em anlise estatstica.
Na utilizao de perguntas abertas, os resultados da pesquisa podem levar a

insights e opinies de difcil obteno atravs de outras tcnicas de elicitao.
Costumam no requerer um tempo significativo dos respondentes.
Efetivas e eficientes quando as partes interessadas no esto na mesma

localidade.
Podem gerar grande nmero de respostas.
Rpida e de complexidade relativamente baixa para administrar.
.2 Desvantagens
O uso de perguntas abertas requer mais anlise.
Para alcanar resultados no tendenciosos, habilidades especializadas em

mtodos de amostragem estatstica so necessrias quando se decide fazer a
pesquisa a um subconjunto dos respondentes em potenciais.
Algumas perguntas podem ser deixadas sem respostas ou serem respondidas

incorretamente em virtude da sua natureza ambgua.
Pode requerer perguntas de acompanhamento ou mais iteraes de pesquisa,

dependendo das respostas fornecidas.
No serem apropriadas para a coleta de informaes sobre comportamentos

reais.
As taxas de respostas s pesquisas costumam ser muito baixas para uma

significncia estatstica. O uso de incentivos ou meios de reforo pode ser
aplicado para aliviar este problema.
9.32 Anlise SWOT

9.32.1 Propsito
A anlise SWOT uma ferramenta valiosa para analisar rapidamente os vrios
aspectos do estado atual dos processos de negcio que esto passando por mudanas.
9.32.2 Descrio
SWOT um acrnimo em ingls para Foras, Fraquezas, Oportunidades e Ameaas.
A anlise SWOT um framework para planejamento estratgico, para anlise de
oportunidade, para anlise competitiva e para desenvolvimento de produtos e
negcios.
9.32.3 Elementos
Os passos para conduzir uma anlise SWOT so os seguintes:
Desenhar uma grade ou matriz.

Tcnicas Anlise SWOT
Descrever a questo ou problema em discusso no topo da grade.
Conduzir uma sesso de brainstorming para completar cada seo da

grade. Foras e Fraquezas so fatores internos da organizao, da unidade
organizacional ou da soluo, enquanto Oportunidades e Ameaas so fatores
externos.
Foras. Qualquer coisa que o grupo avaliado faa bem. Isso pode incluir
pessoal experiente, processos efetivos, sistemas de TI, relacionamento com
os clientes ou quaisquer outros fatores internos que levam ao sucesso.
Fraquezas. Aquelas coisas que o grupo avaliado faz de forma pobre, ou

simplesmente no fazem. As fraquezas tambm so internas.
Oportunidades. Fatores externos dos quais o grupo avaliado pode tirar

proveito. Pode incluir novos mercados, nova tecnologia, mudanas no
mercado competitivo ou outros motivos. As oportunidades existem alm
do escopo de controle do grupo avaliado; a escolha se deve, ou no, tirar
vantagem da oportunidade, quando identificada.
Ameaas. Fatores externos que podem afetar negativamente o grupo

avaliado. Elas podem incluir fatores como a entrada no mercado de um novo
competidor, crises econmicas ou outros motivos. As ameaas tambm
esto fora do controle do grupo.
Facilitar a discusso para analisar os resultados. Lembrar que o grupo

identificou apenas caractersticas potenciais do problema. Anlise posterior
necessria para validar as caractersticas de fato, confirmadas, de preferncia,
atravs de dados.
Uma vez que as caractersticas da questo ou do problema foram validadas, o

grupo realiza um brainstorm das potenciais solues para resolver o problema.
Uma prtica padro para isso comparar foras internas e fraquezas com
oportunidades externas e ameaas e tentar definir estratgias para cada clula
da matriz.
Figura 9-17: Matriz SWOT

Oportunidades Ameaas
(Opportunities) (Threats)
Estratgias SO Estratgias ST
Como a fora do grupo pode Como o grupo pode usar as suas
Foras ser utilizada para explorar foras para eliminar possveis
(Strengths) oportunidades potenciais? ameaas? As ameaas podem ser
Estratgias SO so bastante diretas transformadas em oportunidades?
para se implementar.
Estratgias WO Estratgias WT
O grupo pode usar uma O grupo pode se reestruturar para
oportunidade para eliminar ou evitar a ameaa? O grupo deveria
Fraquezas
mitigar uma fraqueza? considerar a sada deste mercado?
(Weaknesses)
A oportunidade garante o Estratgias WT envolvem cenrios
desenvolvimento de novas crticos
capacidades?

Histrias do usurio Tcnicas

.1 Vantagens
A anlise SWOT auxilia na anlise rpida de vrios aspectos do estado atual da
organizao e do seu ambiente antes de identificar opes de solues potenciais.
.2 Desvantagens
A anlise SWOT uma viso de nvel muito alto; anlises mais detalhadas so quase
sempre necessrias.
9.33 Histrias do usurio

9.33.1 Propsito
As histrias do usurio so descries breves de funcionalidades que os usurios
precisam para que uma soluo atenda a um objetivo do negcio.
9.33.2 Descrio
Uma histria do usurio uma descrio textual de coisas que a soluo precisa
permitir que os usurios faam. As histrias do usurio so geralmente uma sentena
ou duas que descreve quem usa a histria, a meta que se est tentando alcanar e
quaisquer informaes adicionais que possam ser crticas para compreender o
escopo da histria.
9.33.3 Recursos-chave
Uma histria do usurio inclui uma descrio curta do problema a ser resolvido
a partir da perspectiva do usurio. O nico detalhe que precisa ser includo a
informao que reduza o risco de incompreenso por parte dos desenvolvedores que
fazem a estimativa.
Uma histria do usurio inclui:
Ator: A parte interessada que se beneficia da histria do usurio.
Descrio: Uma viso de alto nvel da funcionalidade que a histria inclui.
Benefcio: O valor de negcio que a histria entrega.
Uma histria do usurio deve tambm possuir Critrios de Aceite e Avaliao (9.1).
9.33.4 Quando utilizar

.1 Vantagens
Histrias do usurio criam um ambiente de propriedade do cliente em relao aos
recursos e prioridades em um ambiente incremental e iterativo de desenvolvimento.
Elas podem eliminar a necessidade de fornecer requisitos funcionais em alguns
ambientes. As histrias do usurio tambm requerem que o valor entregue pela
histria esteja claramente articulado.
.2 Desvantagens
Elas podem no ser a melhor tcnica para alguns ambientes com restries
regulatrias ou quando uma organizao demanda documentao. Esta tcnica de
modelagem pode no ser efetiva quando os participantes no esto localizados no
mesmo lugar. Esta tcnica no aborda explicitamente como documentar requisitos
no-funcionais.

Tcnicas Avaliao de fornecedores
9.34 Avaliao de fornecedores

9.34.1 Propsito
Avaliar a habilidade de um fornecedor potencial para atender compromissos em
relao a um produto ou servio.
9.34.2 Descrio
Quando as solues so em parte providas por fornecedores externos (que podem
estar envolvidos no desenho, construo, implementao ou manuteno da soluo
ou componente da soluo), ou quando a soluo terceirizada, podem existir
requisitos especficos em relao ao envolvimento destes terceiros.
Por exemplo, pode existir a necessidade de garantir que o fornecedor seja

financeiramente seguro, capaz de manter nveis especficos de pessoal, designar
colaboradores habilidosos para apoiar a soluo e assim por diante. Requisitos no-
funcionais (9.17) podem ser usados para definir os nveis de servio esperados de um
terceiro. A avaliao de fornecedores conduzida para garantir que o fornecedor
confivel e que o nvel do servio ir atender s expectativas da organizao.
9.34.3 Elementos
.1 Conhecimento e habilidades
Uma razo usual para a utilizao de fornecedores terceirizados a possibilidade
deles oferecerem conhecimento e habilidades no disponveis dentro da organizao.
Nesses casos, o analista de negcios deve considerar se essa habilidade necessitar
ser transferida e o quo capaz o fornecedor de faz-lo. Pode-se desejar focar em
fornecedores com essa habilidade particular em metodologias ou tecnologias com
a meta de ter essas habilidades transferidas para as pessoas dentro da organizao.
.2 Modelos e preos de licenciamento

Nos casos nos quais uma soluo ou componente de soluo comprada ou
terceirizada por um fornecedor externo, o modelo de licenciamento ou de
preos dever ser levado em conta. Em muitos casos, as solues podem oferecer
funcionalidades similares e diferir fortemente nos seus modelos de licenciamento,
requerendo uma anlise de diferentes cenrios de uso para determinar quais
opes iro fornecer a melhor relao custo/benefcio nos cenrios provavelmente
encontrados na empresa.
.3 Reputao e posio no mercado do produto

Quantos clientes esto atualmente utilizando o produto ou servio? O produto
amplamente aceito e usado em organizaes similares? Existe um agendamento
regular de atualizao e um roadmap de recursos que esto planejados para entrega?
.4 Termos e condies
Os servios providos pelo fornecedor so temporrios ou permanentes? O analista de
negcios deve investigar se os termos de licenciamento e infraestrutura tecnolgica
tendem a apresentar desafios caso a organizao opte posteriormente por uma
transio para outro fornecedor. Podem existir tambm consideraes em relao
ao uso e responsabilidade do fornecedor na proteo da integridade dos dados
confidenciais da organizao. Alm disso, as condies sob as quais personalizaes
do produto devem ser consideradas.

Avaliao de fornecedores Tcnicas
.5 Experincia e reputao do fornecedor

A experincia do fornecedor com outros clientes pode prover informaes valiosas
a respeito do quo provvel ser o atendimento do fornecedor s suas obrigaes
contratuais e no-contratuais. O fornecedor pode tambm ser avaliado em relao
conformidade e atendimento aos padres externos e relevantes de qualidade,
segurana e profissionalismo.
.6 Estabilidade do fornecedor
Qual a certeza de que o fornecedor ser capaz de prover os servios requeridos
no futuro? Pode ser necessrio requisitar que alguns passos sejam tomados para
garantir que no existam riscos, caso o fornecedor passe por dificuldades financeiras
e que seja possvel manter e aperfeioar a soluo, mesmo se a situao do fornecedor
mudar radicalmente.

.1 Vantagens
Uma avaliao efetiva do fornecedor reduz o risco da organizao desenvolver um
relacionamento com um fornecedor inadequado e tende a prover satisfao de longo
prazo em relao deciso.
.2 Desvantagens
Pode consumir muito tempo para coletar informaes suficientes sobre mltiplos
fornecedores. Algumas informaes podem no estar prontamente disponveis.
Fornecedores com produtos novos e inovadores podem ser subavaliados por no
terem histria significativa no mercado.

Glossrio
Apndice A
Abordagem da Anlise de Negcios Anlise de Impacto
O conjunto de processos, modelos Uma anlise de impacto avalia os efeitos
e atividades que sero usados para que uma mudana proposta ter sobre
desempenhar a anlise de negcios em um uma parte interessada ou grupo de partes
contexto especfico. interessadas, projeto ou sistema.
Alocao Anlise de Oportunidade

Veja alocao de requisitos. O processo de examinar novas
oportunidades de negcio para aperfeioar o
Alocao de Requisitos desempenho organizacional.
O processo de distribuio de requisitos em
subsistemas e componentes (ex.: pessoas, Anlise de Varincia
hardware e software). Anlise das discrepncias entre o
desempenho planejado e realizado
Anlise Custo Benefcio para determinar a magnitude dessas
Anlise realizada para quantificar e discrepncias e recomendar aes
comparar os custos financeiros e no- corretivas e preventivas quando necessrio.
financeiros de uma mudana ou da
implementao de uma soluo comparados Anlise de Viabilidade
aos benefcios ganhos. Veja estudo de viabilidade.
Anlise Competitiva Anlise de Documentos

Um processo estruturado que captura as Anlise de documentos um meio de elicitar
principais caractersticas de um mercado requisitos de um sistema existente atravs
para prever as perspectivas de lucratividade do estudo da documentao disponvel e da
a longo prazo e para determinar as prticas identificao da informao relevante.
dos concorrentes mais significantes.
Anlise de Negcios
Anlise da Causa-Raiz Anlise de negcios o conjunto de
Anlise da causa-raiz um exame tarefas e tcnicas usadas para atuar como
estruturado de um problema identificado uma ligao entre as partes interessadas,
para compreender as causas implcitas. no intuito de compreender a estrutura,
polticas e operaes de uma organizao
Anlise das Partes Interessadas e recomendar solues que capacitam esta
O trabalho para identificar as partes organizao a atingir as suas metas.
interessadas que podem ser impactadas por
uma iniciativa proposta e avaliar os seus Anlise Decisria
interesses e provvel participao. Uma abordagem para a tomada de deciso
que examina e modela as possveis
Anlise de Gaps (Lacunas) conseqncias para diferentes decises.
Uma comparao do estado atual com o Anlise decisria auxilia na tomada da
estado futuro desejado de uma organizao deciso tima sob condies de incerteza.
no intuito de identificar diferenas que
precisam ser abordadas.

Apndice A: Glossrio Anlise do Campo de ForaAvaliao
Anlise do Campo de Fora rvore de Deciso

Um mtodo grfico para descrever as Um modelo de anlise que prov uma
foras que apoiam e que se opem a uma alternativa grfica s tabelas de deciso
mudana. Envolve a identificao das foras, atravs da ilustrao das condies e aes
descrevendo-as como lados de uma linha em sequncia.
(foras de apoio e de oposio) e, ento,
estimando a fora total de cada conjunto de Associao
foras. Um vnculo entre dois elementos ou objetos
em um diagrama.
Anlise SWOT
SWOT um acrnimo em ingls para Atividade
Foras, Fraquezas, Oportunidades e Uma unidade de trabalho desempenhada
Ameaas. Trata-se de um modelo usado como parte de uma iniciativa ou processo.
para compreender fatores influenciadores
e apresentar como eles podem afetar uma Ativos de Processos Organizacionais
iniciativa. Todos os materiais usados pelos grupos
dentro da organizao para definir, adaptar,
Analista implementar e manter os seus processos.
Um nome genrico para um papel com
as responsabilidades de desenvolver e Ator Secundrio
gerenciar requisitos. Outros nomes incluem Um ator que participa, mas que no inicia
analista de negcios, integrador de negcios, um caso de uso.
analista de requisitos, engenheiro de
Ator(es)
requisitos e analista de sistemas.
Os papis humanos e no-humanos que
Analista de Negcios interagem com o sistema.
Um praticante da anlise de negcios.
Atributo
rea de Conhecimento Um elemento de dados com um tipo
Um grupo de tarefas relacionadas que especificado de dado que descreve
apoiam uma funo-chave da anlise de informao associada com um conceito ou
negcios. entidade.
Arquitetura Corporativa Atributo de Requisito(s)

Arquitetura corporativa uma descrio Metadado relacionado ao requisito usado
dos processos de negcio de uma para auxiliar no desenvolvimento e
organizao, software e hardware, pessoas, gerenciamento de requisitos.
operaes e projetos, e os relacionamentos
Atributos de Qualidade
entre eles.
O subconjunto de requisitos no-funcionais
Arquitetura do Negcio que descreve propriedades das operaes,
Um subconjunto da arquitetura corporativa desenvolvimento e implantao do software
que define um estado atual ou futuro de (ex.: desempenho, segurana, usabilidade,
uma organizao, incluindo a sua estratgia, portabilidade e testabilidade.
suas metas e objetivos, o ambiente interno,
Avaliao
atravs de um processo ou viso funcional,
A avaliao sistemtica e objetiva de uma
o ambiente externo no qual o negcio opera
soluo para determinar seu estado e
e as partes interessadas afetadas pelas
eficcia no atendimento dos objetivos ao
atividades da organizao.
longo do tempo e para identificar meios
de aperfeioar a soluo para melhor
atender aos objetivos. Veja tambm mtrica,
indicador e monitoramento.

Avaliao da Prontido OrganizacionalDeclarao do Problema Apndice A: Glossrio
Avaliao da Prontido Organizacional Cenrio

Uma avaliao que descreve se as partes Um modelo de anlise que descreve uma
interessadas esto preparadas para aceitar srie de aes ou tarefas que respondem a
a mudana associada com a soluo e se so um evento. Cada cenrio uma instncia de
capazes de utiliz-la de forma eficaz. um caso de uso.
Backlog do Produto Classe

Um conjunto de histrias do usurio, Um descritor para um conjunto de objetos
requisitos ou caractersticas que foram do sistema que compartilham os mesmos
identificados como candidatos para atributos, operaes, relacionamentos e
potencial implementao, priorizados e comportamentos. Uma classe representa
estimados. um conceito dentro do sistema sendo
desenhado. Quando usado como um modelo
Benchmarking de anlise, uma classe ir geralmente
Uma comparao do custo, tempo, tambm corresponder a uma entidade do
qualidade ou outras mtricas de um mundo real.
processo ou sistema em relao aos das
organizaes lderes para identificar Cdigo
oportunidades de melhoria. Um sistema de instrues de
programao, smbolos e regras usados
Brainstorming
para representar as instrues para um
Brainstorming uma atividade de equipe
computador.
que procura produzir um amplo ou diverso
conjunto de opes atravs da rpida e no- Comit de Controle de Mudanas (CCM)
crtica gerao de ideias. Um pequeno grupo de partes interessadas
que ir tomar decises relativas disposio
Business Case
e tratamento de mudanas em requisitos.
Uma avaliao dos custos e benefcios
associados a uma iniciativa proposta. Consumidor
Uma parte interessada que utiliza produtos
Capacidade
ou servios entregues pela organizao.
Uma funo de organizao que a capacita a
atingir uma meta ou objetivo do negcio. Corporao
Uma unidade organizacional, organizao ou
Cardinalidade
coleo de organizaes que compartilham
O nmero de ocorrncias de uma entidade
um conjunto de metas comuns e colaboram
em um modelo de dados que esto
para prover produtos e servios especficos
associadas a uma segunda entidade.
para os consumidores.
Cardinalidade apresentada em um modelo
de dados atravs de uma notao especial, Declarao de Viso (declarao de viso
nmero (ex.: 1) ou letra (ex.: M significando do produto)
muitos). Uma declarao breve, ou pargrafo, que
descreve o porqu, o que e quem de um
Caso de Uso
produto de software desejado, do ponto de
Um modelo de anlise que descreve as
vista do negcio.
tarefas que o sistema ir desempenhar para
atores e as metas que o sistema atingir Declarao do Problema
para aqueles atores ao longo do caminho. Uma breve declarao ou pargrafo que
descreve os problemas no estado atual e
Casos de Uso Includos
esclarece como uma soluo bem sucedida
Um caso de uso composto de um conjunto
se parecer.
de medidas utilizadas por mltiplos casos
de uso.

Apndice A: Glossrio DecomposioDomnio
Decomposio Diagrama de Entidade-Relacionamento

Uma tcnica que subdivide um problema Um diagrama de entidade-relacionamento
em suas partes componentes no intuito uma representao grfica das entidades
de facilitar a anlise e compreender esses relevantes de um determinado domnio do
componentes. problema, os relacionamentos entre elas e os
seus atributos.
Defeito
Uma deficincia em um produto ou Diagrama de Estados
servio que reduz a sua qualidade ou Um modelo de anlise apresentando o ciclo
varia em relao a um atributo, estado ou de vida de um dado, entidade ou classe.
funcionalidade desejada. Veja tambm
defeito dos requisitos. Diagrama de Mquina de Estados
Veja diagrama de estados.
Defeito de Requisito(s)
Um erro nos requisitos causado por Diagrama de Sequncia
requisitos incorretos, incompletos, ausentes Um tipo de diagrama que apresenta objetos
ou conflitantes. participando em interaes e as mensagens
trocadas entre eles.
Desenvolvedor
Desenvolvedores so responsveis pela Diagrama de Transio de Estados
construo de aplicaes de software. Veja diagrama de estados.
reas de expertise incluem linguagens
de desenvolvimento, prticas de Diagrama Espinha de Peixe
desenvolvimento e componentes de Uma tcnica de diagramao usada na
aplicaes. anlise de causa-raiz para identificar causas
implcitas de um problema observado e os
Diagrama de Atividades relacionamentos que existem entre essas
Um modelo que ilustra o fluxo de processos causas.
e/ou casos de uso complexos, atravs da
apresentao de cada atividade junto Dicionrio de Dados
aos fluxos de informao e atividades Um modelo de anlise descrevendo as
concorrentes. Os passos podem ser estruturas de dados e atributos necessrios
posicionados em raias para os papis que para o sistema.
executam esses passos.
Documento de Requisitos do Negcio
Diagrama de Casos de Usos Um documento de Requisitos do Negcio
Um tipo de diagrama definido pela UML um pacote que descreve os requisitos
que captura todos os atores e casos de uso do negcio e das partes interessadas (ele
envolvidos com um sistema ou produto. documenta os requisitos de interesse para
o negcio ao invs de documentar os atuais
Diagrama de Causa e Efeito requisitos do negcio).
Veja diagrama espinha de peixe.
Documento de Requisitos do Usurio
Diagrama de Contexto Um documento de requisitos escrito para
Um modelo de anlise que ilustra o escopo um pblico de usurios, descrevendo
do produto atravs da apresentao do requisitos do usurio e o impacto das
sistema no seu ambiente junto s entidades mudanas antecipadas sobre os usurios.
externas (pessoas e sistemas) que do e
recebem do sistema. Documento de Requisitos
Veja pacote de requisitos.
Domnio
A rea problema sob anlise.

Domnio do NegcioEstudo de Viabilidade Apndice A: Glossrio
Domnio do Negcio Especialista

Veja domnio. (SME - Subject Matter Expert)
Uma parte interessada com expertise
Elicitao especfica em um aspecto do domnio
Uma atividade dentro do desenvolvimento do problema ou potenciais solues
dos requisitos que identifica as fontes alternativas, ou componentes.
de requisitos e ento utiliza tcnicas de
elicitao (ex.: entrevistas, prottipos, Especialista em implementao de
workshops, estudos de documentao) para solues
reunir requisitos dessas fontes. (Implementation SME - Subject Matter
Expert)
Engenheiro de Software Uma parte interessada que ser responsvel
Veja desenvolvedor. por desenhar, desenvolver e implementar
a mudana descrita nos requisitos e que
Entidade de Dados possui conhecimento especializado no
Um grupo de informaes relacionadas a que tange construo de um ou mais
ser armazenadas pelo sistema. Entidades componentes da soluo.
podem ser pessoas, papis, lugares, coisas,
organizaes, ocorrncias no tempo, Especialista no Assunto
conceitos ou documentos. (Domain SME - Subject Matter Expert)
Uma pessoa com expertise especfica em
Entrega uma rea ou domnio sob investigao.
Qualquer produto ou servio de trabalho
nico e verificvel que uma parte concordou Especificao dos Requisitos do
em entregar. Software/Sistema
Um documento de requisitos escrito
Entrega Incremental especialmente para especialistas em
Criao de software funcional em mltiplas implementao da soluo, descrevendo
liberaes de modo que o produto inteiro requisitos funcionais e no-funcionais.
entregue em pores ao longo do tempo.
Estratgia de Mitigao de Riscos
Entrevista Veja estratgia de mitigao de riscos dos
Uma abordagem sistemtica para extrair requisitos
informao de uma pessoa ou grupo de
pessoas em uma configurao formal ou Estratgia de Mitigao de Riscos em
informal, atravs de perguntas referentes Requisitos
a questes relevantes e da documentao Uma anlise dos riscos associados aos
das respostas. requisitos que gradua os riscos e identifica
aes para evit-los ou minimiz-los.
Escopo
A rea coberta por uma atividade particular Estrutura Analtica do Projeto (EAP)
ou tpico de interesse. Veja tambm escopo Uma decomposio hierrquica orientada
do projeto e escopo da soluo. s entregas do trabalho a ser executado pela
equipe do projeto para atingir os objetivos
Escopo da Soluo do projeto e criar as entregas requeridas. Ela
O conjunto de capacidades que uma organiza e define o escopo total do projeto.
soluo deve entregar, no intuito de atender
necessidade do negcio. Veja tambm Estudo de Viabilidade
escopo. Uma avaliao de alternativas propostas
para determinar se elas so tecnicamente
Escopo do Produto possveis dentro das restries da
Os recursos e funes que caracterizam um organizao e se elas iro entregar os
produto, servio ou resultado. benefcios desejados para a organizao.

Apndice A: Glossrio EventoInspeo
Evento Glossrio
Um evento algo que ocorre e ao qual uma Uma lista de definio dos termos de
unidade organizacional, sistema ou processo negcio e conceitos relevantes para a
deve responder. soluo sendo construda ou aperfeioada.
Evento do Negcio Grupo Focal

Um gatilho do sistema que iniciado por Um grupo focal um meio de extrair idias
humanos. e atributos a respeito de um produto,
servio ou oportunidade especfica em
Evento Temporal um ambiente de grupo interativo. Os
Um gatilho do sistema que acionado pelo participantes, guiados por um moderador,
tempo. compartilham suas impresses, preferncias
e necessidades.
Extenso de controle
A extenso de controle o nmero de Hierarquia de Dilogo
empregados sob a responsabilidade direta, Um modelo de anlise que apresenta os
ou indireta, de um gestor. dilogos da interface do usurio arranjados
como hierarquias.
Ferramenta de Gerenciamento de
Requisitos Histria do Usurio
Uma ferramenta de software que armazena Uma descrio de alto nvel, informal e
as informaes dos requisitos em uma base curta de uma capacidade da soluo que
de dados, captura os atributos e associaes prov valor para uma parte interessada.
dos requisitos e facilita o reporte de Uma histria do usurio possui tipicamente
requisitos. uma ou duas frases e prov o mnimo
necessrio de informao para permitir
Fornecedor que um desenvolvedor estime o trabalho
Uma parte interessada que prov produtos requerido para implement-la.
ou servios para uma organizao.
Indicador
Funcionalidade Um indicador identifica uma medida
Um conjunto coeso de funcionalidade numrica especfica que indica o progresso
externamente visvel que deve estar no alcance de um impacto, sada, atividade
alinhado com metas e objetivos do ou entrada. Veja tambm mtrica.
negcio. Cada recurso um agrupamento
logicamente relacionado de requisitos Iniciativa
funcionais ou de requisitos no-funcionais Um esforo assumido com uma meta ou
descritos de forma geral. objetivo definido.
Garantia da Qualidade Inspeo
Atividades desempenhadas para garantir Um tipo formal de reviso em pares
que um processo ir entregar produtos que que utiliza um processo prdefinido e
atendem a um nvel de qualidade apropriado. documentado, papis de participantes
especficos e a captura de defeitos e
Gerente do Projeto mtricas do processo. Veja tambm reviso
A parte interessada convocada pela estruturada.
organizao para gerenciar o trabalho
requerido para atingir os objetivos do projeto.

IteraoMetadado Apndice A: Glossrio
Iterao Lista de Partes Interessadas, Papis e

Um processo dentro do qual uma Designao de Responsabilidade
entrega (ou a soluo como um todo) Uma lista das partes interessadas afetadas
progressivamente elaborada. Cada iterao por uma necessidade do negcio ou
um mini-projeto autocontido, no qual um soluo proposta e uma descrio das
grupo de atividades executado, resultando suas participaes em um projeto, ou em
no desenvolvimento de um subconjunto de outra iniciativa.
entregas do projeto.
Lista de Verificao (Checklist)
Para cada iterao o time planeja o seu Uma tcnica de controle da qualidade. Elas
trabalho, realiza o trabalho e verifica a podem incluir um conjunto padro de
qualidade e completude. (Iteraes podem elementos de qualidade que os revisores
ocorrer dentro de outras iteraes. Por usam para a verificao e validao
exemplo, uma iterao de desenvolvimento dos requisitos, ou ser especificamente
de requisitos incluiria atividades de desenvolvidas para capturar questes que
elicitao, anlise, especificao e preocupam o projeto.
validao).
Mapa de Dilogo
Iterao de Requisitos Um modelo de anlise que ilustra a
Uma iterao que define requisitos para arquitetura da interface do usurio do
um subconjunto do escopo da soluo. sistema.
Por exemplo, uma iterao de requisitos
incluiria: a identificao de uma parte do Mapa de Processo
produto a ser focada, identificao das Um modelo de negcios que apresenta
fontes de requisitos para aquela poro do um processo de negcio nos termos dos
produto, anlise das partes interessadas e passos, fluxos de entrada e sada ao longo de
planejamento de como extrair requisitos mltiplas funes, organizaes ou cargos.
junto a elas, conduo de tcnicas de
elicitao, documentao e validao dos Mapa de Relacionamento
requisitos. Um modelo de negcio que apresenta o
contexto organizacional em termos dos
Interface relacionamentos que existem ao longo da
Uma fronteira compartilhada entre duas organizao, dos consumidores externos e
pessoas e/ou sistemas atravs da qual a fornecedores.
informao comunicada.
Matriz de Rastreabilidade de Requisitos
Interfaces Externas Uma matriz usada para rastrear os
Interfaces com outros sistemas (hardware, relacionamentos dos requistos. Cada
software e humanos) com os quais um coluna na matriz fornece informao dos
sistema proposto ir interagir. requisitos e componentes do projeto ou do
desenvolvimento de software associados.
Interoperabilidade
Habilidade dos sistemas em se comunicar Meta
atravs da troca de dados ou de servios. Veja meta do negcio.
Linha de base Meta do Negcio

Uma viso dos requisitos no momento em Um estado ou condio que o negcio deve
que foi revista e acordada como sendo a base satisfazer para alcanar a sua viso.
para desenvolvimento posterior.
Metadado
Metadado a informao usada para
compreender o contexto e a validao da
informao registrada em um sistema.

Apndice A: Glossrio MetodologiaNecessidade(s)
Metodologia Modelo de Dados

Um conjunto de processos, regras, modelos Um modelo de anlise que descreve a
e mtodos de trabalho que prescrevem como estrutura lgica de dados, independente do
a anlise de negcios, o desenvolvimento desenho dos dados ou dos mecanismos de
da soluo e a implementao so armazenamento de dados.
desempenhados em um contexto particular.
Modelo de Processo
Metodologia Orientada ao Planejamento Um modelo visual ou representao do
Qualquer metodologia que enfatize o fluxo sequencial e das lgicas de controle
planejamento e a documentao formal do de um conjunto de atividades ou aes
processo usado para conduzir um projeto e relacionadas.
os seus resultados. Metodologias orientadas
ao planejamento enfatizam a reduo do Modelo de Requisitos
risco e o controle em detrimento da rpida Uma representao dos requisitos
entrega de uma soluo. utilizando texto e diagramas. Modelos de
requisitos podem tambm ser chamados
Metodologia orientada mudana de modelos de requisitos do usurio ou
Uma metodologia que foca na entrega modelos de anlise e podem suplementar as
rpida das capacidades da soluo de especificaes textuais de requisitos.
forma incremental e com o envolvimento
direto das partes interessadas para coletar Modelo do Domnio do Negcio
feedback do desempenho da soluo. Uma viso conceitual de uma corporao,
ou parte de uma corporao, com foco
Mtrica nos produtos, entregas e eventos que so
Uma mtrica um nvel quantificvel de importantes para a misso da organizao.
um indicador que uma organizao deseja O modelo do domnio til para validar
alcanar em um ponto especfico do tempo. o escopo da soluo junto s partes
interessadas (tcnica e do negcio). Veja
Modelagem da Organizao tambm modelo.
A tcnica de anlise usada para descrever
papis, responsabilidades e estruturas Modelo do Escopo
existentes dentro de uma organizao. Um modelo que define as fronteiras de um
domnio do negcio ou da soluo.
Modelagem Orientada a Objetos
Uma abordagem da engenharia de software Modelo(s)
onde o software formado por componentes Uma representao e simplificao da
que so grupos encapsulados de dados e realidade desenvolvida para entregar
funes que podem herdar comportamentos informao a um pblico especfico,
e atributos de outros componentes, e onde facilitando a anlise, comunicao e
os componentes se comunicam entre entendimento.
si atravs de mensagens. Em algumas
organizaes a mesma abordagem usada Monitoramento
para engenharia de negcios para descrever Monitoramento um processo contnuo
e empacotar os componentes lgicos do de coleta de dados para determinar o quo
negcio. bem uma soluo est implementada em
comparao com os resultados esperados.
Modelo de Classes Veja tambm mtrica e indicador.
Um tipo de modelo de dados que descreve os
grupos de informao na forma de classes. Necessidade(s)
Veja necessidade do negcio.

Necessidade(s) do NegcioProcesso de Lies Aprendidas Apndice A: Glossrio
Necessidade(s) do Negcio Pesquisa

Um tipo de requisito de negcio de alto nvel Uma pesquisa administra um conjunto
que uma declarao de um objetivo do de perguntas escritas para as partes
negcio ou um impacto que a soluo dever interessadas, no intuito de coletar respostas
trazer ao ambiente do negcio. de um grande grupo, em um perodo de
tempo relativamente curto.
Objetivo
Um alvo ou mtrica que uma pessoa ou Plano da Anlise de Negcios
organizao procura alcanar no intuito de Uma descrio das atividades planejadas
progredir na direo de uma meta. que o analista de negcios ir executar
no intuito de desempenhar o trabalho
Observao de anlise de negcios envolvido em uma
Observao um meio de extrair requisitos iniciativa especfica.
atravs da conduo e avaliao do
ambiente de trabalho da parte interessada. Plano de Comunicao da Anlise de
Negcios
Opcionalidade Uma descrio dos tipos de comunicao
Definir se um relacionamento entre que o analista de negcios ir desempenhar
entidades em um modelo de dados durante a anlise de negcios, os receptores
mandatrio. Opcionalidade apresentada dessas comunicaes e a forma pela qual a
em um modelo de dados atravs de uma comunicao deve ocorrer.
notao especial.
Plano de Gerenciamento de Requisitos
Organizao Uma descrio do processo de
Uma unidade autnoma dentro de gerenciamento dos requisitos.
uma corporao sob o gerenciamento
de uma nica pessoa ou comit, com Poltica de Negcio
uma fronteira claramente definida, que Uma poltica de negcio uma diretiva no-
trabalha na direo de metas e objetivos acionvel que apoia uma meta do negcio.
comuns. Organizaes operam em uma
base contnua, diferente de uma unidade Prazo
organizacional ou uma equipe de projeto, Um perodo fixo de tempo para alcanar um
que pode se dispersar, uma vez atingidos resultado desejado.
seus objetivos.
Priorizao
Pacote de Requisitos O processo de determinar a importncia
Um pacote de requisitos um conjunto de relativa de um conjunto de itens no intuito
requisitos agrupado em um documento ou de determinar a ordem na qual eles sero
apresentao para comunicao s partes abordados.
interessadas.
Processo
Parte Interessada Veja processo de negcio.
Uma pessoa ou grupo que possui interesses
que podem ser afetados por uma iniciativa Processo de Lies Aprendidas
ou excercer influncia sobre ela. Uma tcnica de aperfeioamento de
processos usada para aprender a respeito
Patrocinador de e melhorar um processo ou projeto. Uma
Uma parte interessada que autoriza ou sesso de lies aprendidas envolve uma
legitima o esforo para desenvolvimento reunio especial na qual a equipe explora o
do produto, atravs da contratao ou que deu certo, o que deu errado, o que pode
pagamento do projeto. ser aprendido da iterao recm-completada
e como adaptar os processos e tcnicas
antes de continuar ou reiniciar.

Apndice A: Glossrio Processo de NegcioRegulador
Processo de Negcio Qualidade

Um conjunto de atividades de colaborao O grau para o qual um conjunto de
definidas particularmente ou em sequncia caractersticas inerentes preenche os
que so desempenhadas de forma repetvel requisitos.
por uma organizao.
Qualidade dos Requisitos
Produto Veja validao dos requisitos e verificao
Uma soluo ou componente de uma soluo dos requisitos.
que resultado de um projeto.
Questionrio
Produto do Trabalho Veja pesquisa.
Um documento ou coleo de notas ou
diagramas usados pelo analista de negcios Raia
durante o processo de desenvolvimento dos A seco horizontal ou vertical de um
requisitos. modelo de processo que apresenta quais
atividades so desempenhadas por um ator
Projeto ou papel particular.
Uma empreitada temporria levada adiante
para criar um produto, servio ou resultado Rastreabilidade de Requisitos
nico. A habilidade de identificar e documentar a
linhagem de cada requisito, incluindo a sua
Prottipo derivao (rastreabilidade para trs), sua
Uma verso parcial ou preliminar do alocao (rastreabilidade para frente) e o
sistema. seu relacionamento com outros requisitos.
Prottipo Descartvel Regra(s) de Negcio

Um prottipo usado para esclarecer Uma regra de negcio uma diretiva
rapidamente requisitos da interface usando especfica, acionvel e testvel que est sob
ferramentas simples, algumas vezes, apenas o controle do negcio e apia uma poltica de
papel e caneta. Geralmente descartado, uma negcio.
vez que o sistema final foi desenvolvido.
Regra(s) Operativa(s)
Prottipo Evolucionrio As regras de negcios que uma organizao
Um prottipo que continuamente escolhe reforar como parte de uma poltica.
modificado e atualizado em resposta ao Elas so destinadas a guiar as aes de
feedback dos usurios. pessoas que trabalham dentro do negcio.
Elas podem obrigar as pessoas a tomar
Prottipo Exploratrio certas aes, previnir que pessoas tomem
Um prottipo desenvolvido para explorar ou certas aes ou prescrever as condies sob
verificar requisitos. as quais uma ao deve ser tomada.
Prottipo Horizontal Rastreabilidade
Um prottipo que apresenta uma viso Veja rastreabilidade dos requisitos.
superficial e possivelmente abrangente
da funcionalidade do sistema, mas que Regulador
geralmente no suporta nenhum uso ou Uma parte interessada com autoridade legal
interao de fato. ou governana sobre a soluo, ou sobre o
processo usado para desenvolv-la.
Prottipo Vertical
Um prottipo que mergulha nos detalhes da
interface, da funcionalidade ou de ambos.

Regra EstruturalRestrio Apndice A: Glossrio
Regra Estrutural Requisito(s) Funcional(is)

Regras estruturais determinam quando As capacidades do produto, ou coisas que o
algo , ou no, verdadeiro ou quando produto deve fazer pelos seus usurios.
algo se enquadra em certa categoria. Elas
descrevem categorizaes que podem Requisitos de Transio
mudar ao longo do tempo. Uma classificao dos requisitos que
descrevem capacidades que a soluo deve
Relacionamento possuir, no intuito de facilitar a transio
Uma associao definida entre conceitos, de um estado corrente da corporao para
classes ou entidades. Relacionamentos o estado futuro desejado, mas que no sero
so usualmente denominados e incluem a mais necessrios uma vez completada a
cardinalidade da associao. transio.
Repositrio Requisitos Declarados

Uma instalao virtual ou real onde toda Um requisito articulado por uma parte
a informao a respeito de um tpico interessada que no foi analisado, verificado
especfico armazenada e est disponvel ou validado. Requisitos declarados
para consulta. frequentemente refletem os desejos de
uma parte interessada e no a sua real
Requisito necessidade.
1. Uma condio ou capacidade necessria
para uma parte interessada para resolver um Requisito do Negcio
problema ou atingir um objetivo. Uma necessidade de negcio de nvel mais
alto que, quando atendido, permitir que a
2. Uma condio ou capacidade que deve ser organizao aumente a receita, evite custos,
atendida ou possuda por uma soluo ou melhore o servio ou atenda a requisitos
componente de soluo para satisfazer um regulatrios.
contrato, padro, especificao ou outros
documentos formalmente impostos. Requisitos No-Funcionais
Os atributos de qualidade, restries ao
3. Uma representao documentada de uma desenho e implementao e interfaces
condio ou capacidade como em 1 ou 2. externas que o produto deve possuir.
Requisito da Soluo Requisitos Validados
Uma caracterstica de uma soluo que Requisitos que provaram entregar valor para
atende aos requisitos do negcio e das o negcio e apoiar as metas e objetivos do
partes interessadas. Pode ser subdividido negcio.
em requisitos funcionais e no-funcionais.
Requisitos Verificados
Requisito das Partes Interessadas Requisitos que apresentaram caractersticas
Requisitos das partes interessadas so de qualidade de requisitos como sendo
declaraes das necessidades de uma coesos, completos, consistentes, corretos,
parte interessada particular ou classe viveis, modificveis, no-ambguos e
de partes interessadas. Eles descrevem testveis.
as necessidades que uma dada parte
interessada possui e como a parte Restrio
interessada ir interagir com a soluo. Uma restrio descreve quaisquer
Requisitos das partes interessadas servem limitaes impostas soluo que no
como uma ponte entre os requisitos do suportam as necessidades do negcio ou das
negcio e as vrias classes de requisitos da partes interessadas.
soluo.
Requisito do Usurio
Veja requisito(s) das partes interessadas.

Apndice A: Glossrio Restrio(es) do NegcioSolicitao de Informao (RFI -Request For Information)
Restrio(es) do Negcio Revises

Restries do negcio so limitaes Um tipo de reviso em pares, na qual
colocadas sobre o desenho da soluo os participantes apresentam, discutem
pela organizao que precisa da soluo. e utilizam o produto do trabalho para
Restries do negcio descrevem as encontrar erros. Revises da documentao
limitaes das solues disponveis ou um dos requisitos so usadas para verificar se
aspecto do estado corrente que no pode ser os requisitos esto corretos. Veja tambm
alterado pela implantao da nova soluo. revises estruturadas.
Veja tambm restrio tcnica.
Risco
Restries de Design Um evento ou condio incerta que, se
Requisitos do software que limitam as ocorrer, afetar as metas e objetivos de uma
opes disponveis para o desenhista do mudana proposta.
sistema.
Servio
Restrio(es) Tcnica(s) Trabalho desempenhado em prol de outros.
Restries tcnicas so limitaes no design
de uma soluo que deriva da tecnologia Sesso de Descoberta
usada na sua implementao. Veja tambm Veja workshop de requisitos.
restrio do negcio.
Sesso de Descoberta de Requisitos
Resultado Desejado Veja workshop de requisitos.
Os benefcios para o negcio que iro
resultar do atendimento necessidade do Sistema
negcio e o estado final desejado pelas partes Uma coleo de elementos inter-
interessadas. relacionados que interagem para atingir
um objetivo. Elementos do sistema podem
Retorno Sobre o Investimento incluir hardware, software e pessoas. Um
Uma medida da lucratividade de um projeto sistema pode ser um subelemento (ou
ou investimento. subsistema) de outro sistema.
Retrospectiva Solicitao de Cotao

Veja processo de lies aprendidas. (RFQ Request For Quote)
Uma solicitao informal de propostas para
Reviso Estruturada fornecedores.
Uma reviso estruturada uma reviso
de uma entrega organizada em pares com Solicitao de Informao
o objetivo de encontrar erros e omisses. (RFI -Request For Information)
considerada uma forma de garantia de Um documento de requisitos submetido
qualidade. para solicitar informaes de fornecedores
a respeito de um produto ou processo
Reviso por Pares proposto. Uma RFI usada quando
Uma tcnica de validao na qual um a organizao que o redigiu procura
pequeno grupo de partes interessadas avalia comparar diferentes alternativas ou est
uma poro de um produto de trabalho indecisa em relao s opes disponveis.
para encontrar erros com o objetivo de
aperfeioar a sua qualidade.

Solicitao de Proposta (RFP Request for Proposal)Usurio Apndice A: Glossrio
Solicitao de Proposta Tcnica

(RFP Request for Proposal) Tcnicas alteram a forma com a qual
Um documento de requisitos submetido uma tarefa de anlise de negcios
quando uma organizao est buscando desempenhada ou descreve uma forma
uma proposta formal com os fornecedores. especfica de sada que uma tarefa pode
Uma RFP tipicamente requer que as assumir.
propostas sejam submetidas seguindo um
processo especfico e utilizando propostas Termo de Abertura do Projeto
fechadas, que sero avaliadas em relao Um documento redigido pelo iniciador ou
metodologia de avaliao formal. patrocinador do projeto que formalmente
autoriza a existncia de um projeto e
Soluo fornece ao gerente do projeto a autoridade
Uma soluo atende a uma necessidade para aplicar os recursos organizacionais s
de negcio resolvendo um problema ou atividades do projeto.
permitindo que uma organizao se
beneficie de uma oportunidade. Testador
Uma parte interessada responsvel por
Software de Prateleira avaliar a qualidade de, e identificar defeitos
(COTS Commercial-off-the-Shelf Software) em um aplicativo de software.
Software desenvolvido e vendido para um
mercado particular. Teste de Aceitao do Usurio
Casos de teste que os usurios empregam
Storyboard para julgar se um sistema entregue
Veja hierarquia do dilogo e mapa do dilogo. aceitvel. Cada teste de aceitao descreve
um conjunto de entradas do sistema e
Suporte Operacional resultados esperados.
Uma parte interessada que auxilia a manter
a soluo em funcionamento, seja provendo Testes Caixa-Preta
apoio aos usurios finais (instrutores, help Testes escritos sem considerao sobre
desk) ou mantendo a soluo operacional como o software implementado. Esses
diariamente (rede e outro suporte tcnico). testes apresentam apenas quais sero as
entradas e sadas esperadas.
Suposies
Suposies so fatores influenciadores que Unidade Organizacional
se acredita serem verdadeiros, mas que Qualquer associao reconhecida de
ainda no foram confirmados. pessoas no contexto de uma organizao ou
corporao.
Tabelas de Deciso
Um modelo de anlise que especifica regras Unified Modeling Language (UML)
ou lgicas de negcio complexas, de forma Uma linguagem no-proprietria de
concisa, em um formato tabular de fcil modelagem e especificao usada para
leitura, especificando todas as condies e especificar, visualizar e documentar
aes possveis que precisam ser levadas em entregas para sistemas de software
conta nas regras de negcio. orientados a objetos.
Tabela de Resposta a Eventos Usurio

Um modelo de anlise em formato de tabela Uma parte interessada, pessoa, dispositivo
que define os eventos (ex.: o estmulo de ou sistema, que acessa direta ou
entrada que leva o sistema a acionar alguma indiretamente um sistema.
funo) e suas respostas.

Apndice A: Glossrio Usurio FinalWorkshop de Requisitos
Usurio Final Verificao dos Requisitos

Uma pessoa ou sistema que interage O trabalho feito para avaliar os
diretamente com a soluo. Usurios requisitos para garantir que eles esto
finais podem ser humanos que interagem corretamente definidos e esto em um
com o sistema, ou sistemas que enviam ou nvel aceitvel de qualidade. Isso garante
recebem arquivos de dados para, ou, do que os requisitos esto suficientemente
sistema. definidos e estruturados para que a equipe
de desenvolvimento da soluo possa
Validao us-los no desenho, desenvolvimento e
O processo de checagem de um produto implementao da soluo.
para garantir que ele satisfaz o seu uso
planejado e que atende aos seus requisitos. Workshop de Elicitao
A validao garante que voc construiu a Veja workshop de requisitos.
soluo correta. Veja tambm validao
dos requisitos. Workshop de Requisitos
Um workshop de requisitos uma
Validao dos Requisitos reunio estruturada, na qual um grupo
O trabalho feito para garantir que os cuidadosamente selecionado de partes
requisitos enunciados apoiam e esto interessadas colabora para definir e/ou
alinhados s metas e aos objetivos do refinar requisitos sob a orientao de um
negcio. facilitador habilidoso e neutro.
Verificao
O processo de checagem de que uma
entrega produzida em um dado estgio
do desenvolvimento satisfaz as condies
e especificaes do estgio anterior. A
verificao garante que voc construiu
a soluo corretamente. Veja tambm
verificao dos requisitos.

Bibliografia
Apndice B
As obras a seguir foram consultadas pelos Armour, Frank, and Granville Miller. 2000. Ad-
contribuintes do Guia BABOK durante o vanced Use Case Modeling: Software Systems.
desenvolvimento desta verso ou das verses Addison-Wesley Professional.
anteriores. Nos casos em que mltiplas
Association of Business Process Management
edies de uma obra foram consultadas,
Professionals. 2008. Guide to the Business Pro-
apenas a edio mais recente est listada. cess Management Common Body of Knowledge.
ABPMP.
Alm das obras aqui listadas, vrias outras
fontes de informaes a respeito de anlise Baird, Jim, A. Ross Little, Valerie LeBlanc, and
de negcios foram consultadas pelos Louis Molnar. 2001. Business Requirements
contribuintes e pelos revisores, ou de alguma Analysis: Applied Best Practices, 4th Edition. The
forma, influenciaram o desenvolvimento Information Architecture Group.
do Guia BABOK, incluindo artigos, white
papers, websites, posts em blogs, fruns on- Bechtold, Richard. 2007. Essentials of Software
line, seminrios, oficinas e conferncias. Project Management, 2nd Edition. Management
Concepts.
Fora algumas poucas excees, as idias e os
Bensoussan, Babette E., and Craig S. Fleisher.
conceitos encontrados no Guia BABOK no
2008. Analysis Without Paralysis: 10 Tools to
foram criados para ele ou originados nele. Make Better Strategic Decisions. FT Press.
O Guia BABOK uma sntese de dcadas
de pesquisa sobre como as organizaes Berman, Jeff. 2006. Maximizing Project Value:
funcionam e sobre os mtodos que podem Defining, Managing, and Measuring for Optimal
ser utilizados para identificar potenciais Return. Amacom.
melhorias. Mesmo as obras listadas a seguir
so construdas sobre os pensamentos e Berman, Karen, and Joe Knight. 2008. Financial
pesquisas de outrem. Intelligence for IT Professionals. Harvard Busi-
ness School Press.
Aaker, David A. 1995. Developing Business Strat-
egies. John Wiley & Sons Inc. Bittner, Kurt, and Ian Spence. 2002. Use Case
Modeling. Addison-Wesley Professional.
Adelman, Sid, Larissa Moss, and Majid Abai.
2005. Data Strategy. Addison-Wesley Profes- Boar, Bernard H. 2001. The Art of Strategic Plan-
sional. ning for Information Technology. John Wiley &
Sons Inc.
Alexander, Ian, and Neil Maiden. 2004. Scenari-
os,Stories, Use Cases: Through the Systems Devel- Boehm, Barry, and Richard Turner. 2003. Bal-
opment Life-Cycle. John Wiley & Sons Inc. ancing Agility and Discipline: A Guide for the Per-
plexed. Addison-Wesley Professional.
Alexander, Ian, and Richard Stevens. 2002. Writ-
ing Better Requirements. Addison-Wesley Profes- Brache, Alan P. and Sam Bodley-Scott. 2005. Im-
sional. plementation: How to Transform Strategic Initia-
tives into Blockbuster Results. McGraw-Hill.
Altier, William J. 1999. The Thinking Managers
Toolbox: Effective Processes for Problem Solving Brassard, Michael, Lynda Finn, and Dana Ginn.
and Decision Making. Oxford University Press. 2002. The Six SIGMA Memory Jogger II: A Pocket-
guide of Tools for Six SIGMA Improvement Teams.
Ambler, Scott W. 2004. The Object Primer: Agile Goal/QPC.
Model-Driven Development with UML 2.0. Cam-
bridge University Press.

Apndice B: Bibliografia
Bridgeland, David M., and Ron Zahavi. 2008. Davis, Alan M. 2005. Just Enough Requirements
Business Modeling: A Practical Guide to Realizing Management: Where Software Development
Business Value. Morgan Kaufmann. Meets Marketing. Dorset House.
Brooks, Frederick P. 1995. The Mythical Man- Demarco, Tom, and Timothy Lister. 2003. Waltz-
Month: Essays on Software Engineering, Anniver- ing With Bears: Managing Risk on Software Proj-
sary Edition. Addison-Wesley Professional. ects. Dorset House.
Brown, Dan. 2006. Communicating Design: De- Denney, Richard. 2005. Succeeding with Use Cas-
veloping Web Site Documentation for Design and es: Working Smart to Deliver Quality. Addison-
Planning. New Riders Press. Wesley Professional.
Burton, Richard M., Gerardine DeSanctis, and Dye, Lowell D., and James S. Pennypacker. 2003.
Brge Obel. 2006. Organizational Design: A Step- Project Portfolio Management: Selecting and Pri-
by-Step Approach. Cambridge University Press. oritizing Projects for Competitive Advantage. Ctr
for Business Practices.
Carkenord, Barbara A. 2009. Seven Steps to Mas-
tering Business Analysis. J. Ross Publishing. Dymond, Kenneth M. 1995. A Guide to the CMM:
Understanding the Capability Maturity Model for
Carnegie Mellon University. 1995. The Capabil- Software. Process Inc. U.S.
ity Maturity Model: Guidelines for Improving the
Software Process. Addison-Wesley Professional. Eckerson, Wayne W. 2005. Performance Dash-
boards: Measuring, Monitoring, and Managing
Chrissis, Mary Beth, Mike Konrad, and Sandy Your Business. John Wiley & Sons Inc.
Shrum. 2006. CMMI: Guidelines for Process In-
tegration and Product Improvement (2nd Edition). Eriksson, Hans-Erik, and Magnus Penker. 2000.
Addison-Wesley Professional. Business Modeling with UML: Business Patterns
at Work. John Wiley & Sons Inc.
Cimperman, Rob. 2006. UAT Defined: A Guide to
Practical User Acceptance Testing. Addison-Wes- Fisher, Roger. 1991. Getting to Yes: Negotiating
ley Professional. Agreement Without Giving In. Penguin.
Clemen, Robert T. 1996. Making Hard Decisions: Fitzpatrick, Jody L, James R Sanders, and Blaine
An Introduction to Decision Analysis. Wadsworth R Worthen. 2003. Program Evaluation: Alterna-
Publishing Company. tive Approaches and Practical Guidelines. Allyn
& Bacon.
Cockburn, Alistair. 2000. Writing Effective Use
Cases. Addison-Wesley Professional. Forsberg, Kevin, Hal Mooz, and Howard Cot-
terman. 2005. Visualizing Project Management:
Cockburn, Alistair. 2004. Crystal Clear: A Hu- Models and Frameworks for Mastering Complex
man-Powered Methodology for Small Teams. Ad- Systems. Wiley.
dison-Wesley Professional.
Fowler, Martin. 2003. UML Distilled: A Brief
Cohn, Mike. 2004. User Stories Applied: For Agile Guide to the Standard Object Modeling Lan-
Software Development. Addison-Wesley Profes- guage. Addison-Wesley Professional.
sional.
Freedman, Daniel P., and Gerald M. Weinberg.
Constantine, Larry L., and Lucy A.D. Lockwood. 1990. Handbook of Walkthroughs, Inspections,
1999. Software for Use: A Practical Guide to the and Technical Reviews: Evaluating Programs,
Models and Methods of Usage-Centered Design. Projects, and Products. Dorset House.
Addison-Wesley Professional.
Gause, Donald C., and Gerald M. Weinberg.
Craig, Malcolm. 2000. Thinking Visually: Busi- 1989. Exploring Requirements: Quality Before De-
ness Applications of Fourteen Core Diagrams. sign. Dorset House.
Continuum International Publishing Group.
Davis, Alan M. 1995. 201 Principles of Software

Development. McGraw-Hill, Inc.

George, Michael L., John Maxey, David T. Row- Havey, Michael. 2005. Essential Business Process
lands, and Malcolm Upton. 2004. The Lean Six Modeling. OReilly Media.
Sigma Pocket Toolbook: A Quick Reference Guide
to 70 Tools for Improving Quality and Speed. Mc- Hay, David C. 2002. Requirements Analysis: From
Graw-Hill. Business Views to Architecture. Prentice Hall.
Goldsmith, Robin F. 2004. Discovering Real Busi- Hetzel, Bill. 1993. The Complete Guide to Soft-
ness Requirements for Software Project Success. ware Testing. Wiley.
Artech.
Hiatt, Jeffrey M., and Timothy J. Creasey. 2003.
Goodpasture, John C. 2001. Managing Projects Change Management. Prosci Research.
for Value. Project Management Institute.
Hohmann, Luke. 1996. Journey of the Software
Gottesdiener, Ellen. 2002. Requirements by Col- Professional: The Sociology of Computer Pro-
laboration: Workshops for Defining Needs. Addi- gramming. Prentice Hall.
son-Wesley Professional.
Hopkins, Richard, and Kevin Jenkins. 2008. Eat-
Gottesdiener, Ellen. 2005. The Software Require- ing the IT Elephant: Moving from Greenfield De-
ments Memory Jogger: A Pocket Guide to Help velopment to Brownfield. IBM Press.
Software and Business Teams Develop and Man-
age Requirements. Goal/QPC. Hubbard, Douglas W. 2007. How to Measure Any-
thing: Finding the Value of Intangibles in Busi-
Gygi, Craig, Neil DeCarlo, and Bruce Williams. ness. Wiley.
2005. Six Sigma For Dummies. Wiley Publishing,
Inc. IEEE Computer Society. 1990. IEEE Std. 610-12-
1990: IEEE Standard Glossary of Software Engi-
Hadden, Rita Chao. 2003. Leading Culture neering Terminology. Institute of Electrical and
Change in Your Software Organization: Deliver- Electronics Engineers.
ing Results Early. Management Concepts.
IEEE Computer Society. 1998. IEEE Std. 1233
Hammer, Michael, and James Champy. 2003. 1998: IEEE Guide for Developing System Require-
Reengineering the Corporation: A Manifesto for ments Specifications . Institute of Electrical and
Business Revolution. HarperCollins Publishers. Electronics Engineers.
Hammond, John S, Ralph L Keeney, and Howard IEEE Computer Society. 1998. IEEE Std. 830
Raiffa. 1998. Smart Choices. Harvard Business 1998: IEEE Recommended Practice for Software
School Press. Requirements Specifications. Institute of Elec-
trical and Electronics Engineers.
Harmon, Paul. 2007. Business Process Change: A
Guide for Business Managers and BPM and Six IEEE Computer Society. 2004. Guide to the Soft-
Sigma Professionals. Morgan Kaufmann. ware Engineering Body of Knowledge, 2004 Ver-
sion. Institute of Electrical and Electronics En-
Harvard Business Review. 1998. Harvard Busi- gineers.
ness Review on Measuring Corporate Perfor-
mance. Harvard Business School Press. International Organization for Standardiza-
tion. 2008. ISO/IEC CD 25010: Software engineer-
Harvard Business Review. 2007. Harvard Busi- ing Software product Quality Requirements
ness Review on Making Smarter Decisions. Har- and Evaluation (SQuaRE) Software and qual-
vard Business School Press. ity in use models Requirements and Evaluation
(SQuaRE) Quality Model, Version 0.55. ISO/IEC.
Hass, Kathleen B. 2007. The Business Analyst as
Strategist: Translating Business Strategies into Jackson, M. 1995. Software Requirements And
Valuable Solutions. Management Concepts. Specifications. Addison-Wesley Professional.
Hass, Kathleen B., Don J. Wessels, and Kevin Jacobson, Ivar, and Pan-Wei Ng. 2004. Aspect-
Brennan. 2007. Getting it Right: Business Require- Oriented Software Development with Use Cases.
ments Analysis Tools and Techniques. Manage- Addison-Wesley Professional.
ment Concepts Inc.

Jalote, Pankaj. 1999. CMM in Practice: Processes Leffingwell, Dean, and Don Widrig. 2003. Man-
for Executing Software Projects at Infosys. Addi- aging Software Requirements: A Use Case Ap-
son-Wesley Professional. proach, 2nd Edition. Addison-Wesley Profession-
al.
Jonasson, Hans. 2007. Determining Project Re-
quirements. Auerbach Publications. Leffingwell, Dean. 2007. Scaling Software Agility:
Best Practices for Large Enterprises. Addison-
Jones, Morgan D. 1998. The Thinkers Toolkit: 14 Wesley Professional.
Powerful Techniques for Problem Solving. Three
Rivers Press. Lepsinger, Richard, and Anntoinette D. Lucia.
1999. The Art and Science of Competency Models:
Jones, T. Capers. 1998. Estimating Software Pinpointing Critical Success Factors in Organiza-
Costs. McGraw-Hill. tions. Jossey-Bass/Pfeiffer.
Juran, J. M. 1992. Juran on Quality by Design: The Lowy, Alex. 2007. No Problem. Authorhouse.
New Steps for Planning Quality into Goods and
Services. Free Press. Maister, David H., Charles H. Green, and Robert
M. Galford. 2001. The Trusted Advisor. Free Press.
Kaplan, Robert S., and David P. Norton. 1996.
The Balanced Scorecard: Translating Strategy Martin, James. 1989. Information Engineering
into Action. Harvard Business School Press. Book I: Introduction. Prentice Hall.
Kessler, Carl, and John Sweitzer. 2007. Outside- Martin, James. 1990. Information Engineering
in Software Development: A Practical Approach Book II: Planning & Analysis. Prentice Hall.
to Building Successful Stakeholder-based Prod-
ucts. IBM Press. Martin, James. 1990. Information Engineering
Book III: Design and Construction. Prentice Hall.
Khoshafian, Setrag. 2006. Service Oriented En-
terprises. Auerbach Publications. McConnell, Steve. 1996. Rapid Development. Mi-
crosoft.
Kit, Edward. 1995. Software Testing In The Real
World: Improving The Process. Addison-Wesley Mintzberg, Henry, and James Brian Quinn. 1995.
Professional. The Strategy Process: Concepts, Context and Cas-
es. Prentice Hall.
Kotonya, Gerald, and Ian Sommerville. 1998.
Requirements Engineering: Processes and Tech- Morabito, Joseph, Ira Sack, and Anilkumar
niques. Wiley. Bhate. 1999. Organization Modeling: Innovative
Architectures for the 21st Century. Prentice Hall.
Kotter, John P. 1996. Leading Change. Harvard
Business School Press. Moss, Larissa T., and Shaku Atre. 2003. Business
Intelligence Roadmap: The Complete Project Life-
Kovitz, Benjamin L. 1998. Practical Software Re- cycle for Decision-Support Applications. Addi-
quirements: A Manual of Content and Style. Man- son-Wesley Professional.
ning Publications.
Myers, Glenford J. 2004. The Art of Software Test-
Larman, Craig. 2004. Applying UML and Pat- ing, 2nd Edition. Wiley.
terns: An Introduction to Object-Oriented Analy-
sis and Design and Iterative Development. Pren- Nielsen, Jakob. 1993. Usability Engineering. Mor-
tice Hall. gan Kaufmann.
Lauesen, Soren. 2001. Software Requirements: Niven, Paul R. 2008. Balanced Scorecard: Step-
Styles & Techniques. Addison-Wesley Profes- by-Step for Government and Nonprofit Agencies.
sional. Wiley.
Lawson, Raef, Denis Desroches, and Toby Hatch. Object Management Group. 2007. Business Moti-
2007. Scorecard Best Practices: Design, Imple- vation Model (BMM) Specification. Object Man-
mentation, and Evaluation. Wiley. agement Group, Inc.

Object Management Group. 2008. Business Pro- Ross, Ronald G. 2005. Business Rule Concepts -
cess Maturity Model (BPMM), Version 1.0. Object Getting to the Point of Knowledge, 2nd Edition.
Management Group, Inc. Business Rule Solutions Inc.
Object Management Group. 2008. Business Pro- Ruble, David. 1997. Practical Analysis and De-
cess Modeling Notation, V1.2. Object Manage- sign for Client/Server and GUI Systems. Prentice
ment Group, Inc. Hall.
Ould, Martyn A. 2005. Business Process Manage- Rumbaugh, James, Ivar Jacobson, and Grady
ment: A Rigorous Approach. Meghan Kiffer Pr. Booch. 2004. The Unified Modeling Language
Reference Manual, 2nd Edition. Addison-Wesley
Page-Jones, Meilir. 1988. Practical Guide to Professional.
Structured Systems Design. Prentice Hall.
Rummler, Geary A., and Alan P. Brache. 1995.
Paul, Debra, and Donald Yeates. 2006. Business Improving Performance: How to Manage the
Analysis. British Computer Society. White Space in the Organization Chart. Jossey-
Bass.
Perry, William E. 2000. Effective Methods for
Software Testing, 2nd Edition. John Wiley & Sons. Scholtes, Peter R. 1997. The Leaders Handbook:
Making Things Happen, Getting Things Done.
Porter, Michael E. 1980. Competitive Strategy: McGraw-Hill.
Techniques for Analyzing Industries and Com-
petitors. Free Press. Schwaber, Ken. 2004. Agile Project Management
With Scrum. Microsoft.
Porter, Michael. 1985. Competitive Advantage.
Free Press. Senge, Peter M. 1990. The Fifth Discipline. Dou-
bleday.
Pressman, Roger S. 2000. Software Engineering:
A Practitioners Approach. McGraw-Hill. Senge, Peter M. 1999. The Dance of Change. Dou-
bleday.
Project Management Institute. 2008. A Guide to
the Project Management Body of Knowledge, 4th Sharp, Alec, and Patrick McDermott. 2001.
Edition. Project Management Institute. Workflow Modeling: Tools for Process Improve-
ment and Application Development. Artech
Rad, Parviz F., and Ginger Levin. 2002. The Ad- House.
vanced Project Management Office: A Compre-
hensive Look at Function and Implementation. Sodhi, Jag, and Prince Sodhi. 2001. IT Project
CRC Press. Management Handbook. Management Con-
cepts.
Roam, Dan. 2008. Back Of The Napkin. Penguin
Group. Sodhi, Jag, and Prince Sodhi. 2003. Managing IT
Systems Requirements. Management Concepts.
Robertson, Suzanne, and James C. Robertson.
2004. Requirements-Led Project Management: Software Engineering Institute. 2006. CMMI
Discovering Davids Slingshot. Addison-Wesley for Development, Version 1.2. Carnegie Mellon
Professional. University.
Robertson, Suzanne, and James C. Robertson. Software Engineering Institute. 2007. CMMI
2006. Mastering the Requirements Process, 2nd for Acquisition, Version 1.2. Carnegie Mellon
Edition. Addison-Wesley Professional. University.
Ross, Jeanne W, Peter Weill, and David C. Rob- Sommerville, Ian, and Pete Sawyer. 1997. Re-
ertson. 2006. Enterprise Architecture as Strategy. quirements Engineering: A Good Practice Guide.
Harvard Business School Press. Wiley.
Ross, Ronald G. 2003. Principles of the Business Stanford, Naomi. 2007. Guide to Organisation
Rule Approach. Addison-Wesley Professional. Design: Creating High-Performing and Adaptable
Enterprises. Profile Books.

Stevens, Richard, Peter Brook, Ken Jackson, and Weinberg, Gerald M. 1998. The Psychology of
Stuart Arnold. 1998. System Engineering, Coping Computer Programming: Silver Anniversary Edi-
with Complexity. Pearson Education. tion. Dorset House.
Streibel, Barbara J., Brian L. Joiner, and Peter R. White, Stephen A., Derek Miers, and Layna
Scholtes. 2003. The Team Handbook: Third Edi- Fischer. 2008. BPMN Modeling and Reference
tion. Joiner/Oriel Inc. Guide. Future Strategies Inc.
Tarantino, Anthony. 2008. Governance, Risk, Wiegers, Karl E. 2003. Software Requirements,
and Compliance Handbook: Technology, Finance, 2nd Edition. Microsoft.
Environmental, and International Guidance and
Best Practices. Wiley. Wiegers, Karl E. 2006. More About Software Re-
quirements: Thorny Issues and Practical Advice.
Tayntor, Christine B. 2005. Successful Packaged Microsoft Press.
Software Implementation. CRC Press.
Wiegers, Karl E. 2007. Practical Project Initia-
Thayer, Richard H. 1997. Software Engineering tion: A Handbook with Tools. Microsoft.
Project Management. Wiley-IEEE Computer So-
ciety Press. Young, Ralph R. 2001. Effective Requirements
Practices. Addison-Wesley Professional.
Thayer, Richard H., and Merlin Dorfman. 1996.
Software Engineering. Wiley-IEEE Computer So- Young, Ralph R. 2004. Requirements Engineering
ciety Press. Handbook. Artech House.
Thayer, Richard H., and Merlin Dorfman. 1997. Yourdon, Edward. 1978. Structured Walk-
Software Requirements Engineering, 2nd Edition. throughs, 2nd Edition. Yourdon Press.
Wiley-IEEE Computer Society Press.
Thorp, John, and Fujitsu Consultings Center for

Strategic Leadership. 2003. The Information Par-
adox: Realizing the Business Benefits of Informa-
tion Technology, Revised Edition. McGraw-Hill.
Tockey, Steve. 2004. Return on Software: Maxi-

mizing the Return on Your Software Investment.
Addison-Wesley Professional.
Ury, William. 1993. Getting Past No: Negotiating

in Difficult Situations. Bantam.
Van Assen, Marcel, Gerben Van den Berg, and

Paul Pietersma. 2008. Key Management Models:
The 60+ models every manager needs to know.
Pearson Education Canada.
Van Bon, Jan, Arjen de Jong, and Axel Kolthof.

2007. Foundations of IT Service Management
Based on ITIL V3. Van Haren Publishing.
Von Halle, Barbara. 2001. Business Rules Ap-

plied: Building Better Systems Using the Business
Rules Approach. Wiley.
Ward, John L., and Elizabeth Daniel. 2006. Ben-

efits Management: Delivering Value from IS & IT
Investments. Wiley.
Weill, Peter, and Jeanne W Ross. 2004. IT Gover-

nance. McGraw-Hill Europe.

Contribuintes
Apndice C
C.1 Verso 2.0
C.1.1 Comit do Corpo de Conhecimento
O contedo desta edio foi originalmente desenvolvido pelo Comit do Corpo de
Conhecimento:
Kevin Brennan, CBAP, OCEB, PMP, Vice President, Body of Knowledge (Require
ments Analysis, Underlying Competencies, Post-Review Revision and Publication)
Barbara A. Carkenord, MBA, CBAP (Requirements Management and Communica

tion, Solution Assessment and Validation)
Mary Gorman, CBAP (Elicitation)
Kathleen B. Hass, PMP (Enterprise Analysis)
Brenda Kerton, MA (Glossary)
Elizabeth Larson, CBAP, PMP (Business Analysis Planning and Monitoring)
Richard Larson, CBAP, PMP (Review Committee Chair)
Jason Questor (Editor, Graphics Team Lead)
Laura Paton, MBA, CBAP, PMP (Project Manager)
C.1.2 Contribuintes de Contedo

As seguintes pessoas contriburam com contedo adicional utilizado nesta verso:
Tony Alderson Monica Jain

James Baird Cherifa Mansoura Liamani, Ph.D.
Jake Calabrese, CBAP Karen Little
Bruce C. Chadbourne, PgMP, PMP Laura Markey
Karen Chandler Richard Martin
Carrolynn Chang Gillian McCleary
Richard Fox, CBAP William B. Murray
Rosemary Hossenlopp Angie Perris, MBA, CBAP, PMP
Peter Gordon, CBAP David Wright
Ellen Gottesdiener
A equipe grfica desenvolveu as artes e os padres grficos:
Carl Gosselin Patricia Sandino

Perry McLeod, CBAP, PMP Maggie Yang
Alexandre Romanov
A verso 2.0 tambm inclui contedos desenvolvidos para verses anteriores do
Guia BABOK.

Verso 2.0 Contribuintes
C.1.3 Consultoria de Especialistas e Grupo de Reviso

Os seguintes especialistas de mercado generosamente forneceram para o IIBA
conselhos e orientaes sobre o escopo e contedo da verso 2.0 do Guia BABOK,
durante o seu planejamento e desenvolvimento, e auxiliaram a formatar o contedo
e a direo desta edio.
Scott Ambler Kent J. McDonald

James Baird Mark McGregor
Kurt Bittner Meilir Page-Jones
Rafael Dorantes James Robertson
Robin F. Goldsmith, JD Suzanne Robertson
Ellen Gottesdiener Ronald G. Ross
Paul Harmon David Ruble
Dean Leffingwell Steve Tockey
Gladys S.W. Lam
C.1.4 Revisores Praticantes

As seguintes pessoas participaram da reviso da verso 2.0 e forneceram feedback
utilizado na reviso do Rascunho para Reviso Pblica:
Sharon M. Aker Karen Gras, CBAP

Betty H. Baker, CBAP Kwabby Gyasi
B. D. Barnes PhD, PE, PMP, CSSBB Bob Hillier, PMP
Jennifer S. Battan, CBAP Billie Johnson, CBAP
Subrahmanya Gupta Boda Peter Johnson, CBAP
Craig W. Brown, MPM, CSM Hans Jonasson, CBAP, PMP
Cathy Brunsting Barbara Koenig
Peter Burg, PMP Steven R. Koss, MBA
Greg Busby, CBAP Douglas Kowalczyk
Diana Cagle, MBA, CBAP Robert Lam, MBA, ISP
Duncan Cairns Richard Larson, CBAP, PMP
Bruce Chadbourne, PgMP, PMP Karen Little, CBAP
Carrollynn Chang Joy Matthews
Patricia Chappell, CBAP, MBA Perry McLeod, CBAP, PMP
Mark Cheek, PMP Holly M. Meyer
Charlie Huai-Ling Chng, CBAP Michael Mohammed
Desire Purvis (ne Chu), CBAP Brian Monson, PMP
Pauline Chung Nancy A. Murphy, PMP, CBAP
Joseph Da Silva Richard L. Neighbarger, CSQA, CSQE
Nitza Dovenspike Tony Newport, CBAP
James Downey, Ph.D., PMP Samia Osman
Tamer El-Tonsy, CISA, PRINCE2, ITIL Cecilia Rathwell
Steve Erlank, BSc, BCom (Hons) Suzanna Etheridge Rawlins, PMP
Margaret Gaino Ewing, MBA, CBAP Helen Ronnenbergh
Stephanie Garwood, CBAP Zoya Roytblat
Joe Goss Christopher Ryba

Contribuintes Verso 2.0
Julian Sammy Leah Sturm, CBAP

Keith Sarre, CBAP James M. Szuch
Laura Schleicher Robin Tucker
Fred Seip Krishna Vishwanath
Thomas Slahetka, CBAP A. S. Umashankar
Warren Steger
As seguintes pessoas tambm serviram como lderes de equipes de reviso:
Cathy Brunsting
Patricia Chappell, CBAP, MBA
Stephanie Garwood, CBAP
Robert Lam, MBA, ISP
C.1.5 Outros Contribuintes Importantes

Os seguintes voluntrios e colaboradores do IIBA contriburam com idias e
prestaram apoio durante o planejamento, o processo de desenvolvimento e liberao
desta verso.
Kathleen Barret, President and CEO
Angela Barrington-Foote, Chair, Role Delineation Committee (Present)
Suzanne Bertschi, Certification Manager
Michael Gladstone, CBAP, Vice President, Certification
Sandra Micallef, Program Manager
Indy Mitra, Secretary and Head of Operational Compliance
Cleve Pillifant, Chair, Role Delineation Committee (Former)
Lynda Sydney, Head of Communications
Katie Wise, Graphic Design
C.1.6 Agradecimentos Adicionais

O IIBA e o Comit do Corpo de Conhecimento gostariam de agradecer a todos
os praticantes de anlise de negcios que nos forneceram comentrios e feedback
ao longo dos anos, como tambm aos aos que nos forneceram feedback sobre o
Rascunho para Reviso Pblica.
C.1.7 Guia BABOK Verso 2.0 na Lngua Portuguesa

O Captulo So Paulo do IIBA agradece ao comprometimento e dedicao de todos
os voluntrios que participaram do processo de traduo e reviso deste material.
Tradutores:
Claudio Brancher Kerber (Coordenador da traduo)
Flvio Augusto Serra Kauling

Verso 1.6 Contribuintes
Revisores da Anlise de Negcios:
Alfonso Jos Izarra Molina, MBA
Aline Vicente So
Crin Cristina Orsi Duarte, PMP
Celso Luiz Bicca
Fabrcio Costa Moraes, MSc
Fabrcio Laguna, MBA, CBAP, PMP (Coordenador da reviso e do projeto de

traduo)
Fernando Carvalho, MSc
Marcelo Menezes Neves
Rafael Oliveira Cardoso
Suzandeise de Almeida Incio Thom, MSc, CBAP
Tatiana Pereira
Judith Pavn, PhD
Reviso do gramatical, sinttica e ortogrfica:
Marina Mello
Coordenao Geral:
Ana Teresa SantAnna Laguna, PhD
IIBA Captulo So Paulo:
Suzandeise de Almeida Incio Thom, CBAP, Presidente
Fabrcio Laguna, CBAP, PMP, Vice Presidente de Comunicao e Marketing
Marcelo Schneck de Paula Pessa, PhD, Vice Presidente de Educao
Adriana Selleri Rocha, Secretria Geral
Fernando Vinicius Anacleto Artea, Tesoureiro
C.2 Verso 1.6

C.2.1 Comit do Corpo de Conhecimento
Kathleen Barret (President)
Kevin Brennan, CBAP, PMP (Vice-President, Body of Knowledge (at time of

publication) and Chair, Requirements Analysis & Documentation and BA
Fundamentals Sub-committees)

Contribuintes Verso 1.6
Barbara Carkenord, MBA, CBAP (Chair, Requirements Communication Sub-

committee and Solution Assessment and Validation Sub-committee)
Mary Gorman, CBAP (Chair, Requirements Elicitation Sub-committee)
Kathleen B. Hass, PMP (Chair, Enterprise Analysis Sub-committee)
Brenda Kerton (Chairperson, Body of Knowledge Committee (during development))
Elizabeth Larson, CBAP, PMP (Co-chair, BOK Review Sub-committee)
Richard Larson, CBAP, PMP (Co-chair, BOK Review Sub-committee)
Dulce Oliveira (Chair, Requirements Planning & Management Sub-committee)
Cleve Pillifant (Member, Accreditation liaison to Body of Knowledge Committee)
C.2.2 Contribuintes da Verso 1.6

Tony Alderson Patricia Martin
Finny Barker Richard Martin
Neil Burton Rosina Mete
Karen Chandler William Murray
Richard Fox, CBAP Harish Pathria
Rosemary Hossenlopp Kathleen Person
Peter Gordon, CBAP Tony Rice
Monica Jain John Slater
Peter Kovaks Mark Tracy
Chris Matts Jacqueline Young
Laura Markey
C.2.3 Revisores da Verso 1.6

Sharon Aker Kelly Piechota
Betty H. Baker, CBAP Howard Podeswa
Jo Bennett Leslie Ponder
Cathy Brunsting Cecilia Rathwell
Carrollynn Chang, CBAP Jennifer Rojek
Patricia Chappell, CBAP, MBA Keith Sarre, CBAP
Pauline Chung Jessica Gonzalez Solis
Joseph R. Czarnecki Jim Subach
Stephanie Garwood, CBAP Diane Talbot
May Jim, CBAP Krishna Vishwanath
Day Knez Marilyn Vogt
Barb Koenig Scott Witt
Robert Lam
Cherifa Mansoura Liamani, Ph.D.
Gillian McCleary
Angie Perris, MBA, CBAP, PMP

Sumrio de Mudanas da verso 1.6
Apndice D
D.1 Viso Geral
A Verso 2.0 do Guia BABOK foi amplamente revista, reestruturada e reescrita em
comparao com a Verso 1.6. Este apndice fornece uma viso geral dos temas
abordados na verso 1.6 que podem ser encontrados na Verso 2.0. Este resumo no
uma descrio completa das mudanas e, em alguns casos, o escopo da tarefa ou
tcnica foi alterado significativamente num nvel inferior.
D.2 Anlise Corporativa

As tarefas Definir a Necessidade do Negcio (5.1) e Avaliar os Gaps (Lacunas) de Capa-
cidades (5.2) no tm equivalncia direta na 1.6.
Tarefa ou Tcnica 1.6 Tarefa ou Tcnica 2.0
Criao e Manuteno da No diretamente abordada na verso 2.0. A Anlise de Negcios em

Arquitetura de Negcios (2.2) toda empresa, ou em nvel estratgico, ser abordada em uma extenso
de rea de aplicao separada.
Conduo dos Estudos de Determinar a Abordagem da Soluo (5.3).

Viabilidade (2.3) Veja tambm o Captulo 9 para algumas das tcnicas referenciadas.
Determinao do Escopo do Definir o Escopo da Soluo (5.4). O contedo de gerenciamento de pro-

Projeto (2.4) jetos nessa tarefa foi removido. Veja tambm o Captulo 9 para algumas
das tcnicas referenciadas.
Preparao do Business Case Definir o Business Case (5.5)

(2.5) Veja tambm o Captulo 9 para algumas das tcnicas referenciadas.
Conduo da Avaliao Definir o Business Case (5.5)

Inicial dos Riscos (2.6) Anlise de Riscos (9.24)
Preparao do Pacote de Preparar Pacote de Requisitos (4.4)

Deciso (2.7) Comunicar Requisitos (4.5)
Seleo e Priorizao de No diretamente abordada na verso 2.0. A Anlise de Negcios em

Projetos (2.8) toda empresa, ou em nvel estratgico, ser abordada em uma extenso
de rea de aplicao separada.
Lanamento de Novos No tem tarefas diretamente equivalentes.

Projetos (2.9)
Gerenciamento de Projetos Definir o Business Case (5.5). Na verso 2.0, no h tarefas distintas para
por Valor (2.10) reavaliar ou atualizar o trabalho feito por outra tarefa. Estas situaes
so tratadas como outra instncia da tarefa original.
Rastreamento de Benefcios Avaliar o Desempenho da Soluo (7.6)

do Projeto (2.11)

Planejamento e Gerenciamento de Requisitos Sumrio de Mudanas da verso 1.6
D.3 Planejamento e Gerenciamento de Requisitos

Esta rea de Conhecimento passou por uma reviso considervel. Concluiu-se que
ela tentava cobrir trs temas distintos:
Gerenciamento de uma equipe de analistas de negcios, tpico fora do escopo

da anlise de negcios propriamente dita.
Gerenciamento de requisitos, que foi transferido para a rea de Conhecimento

Gesto e Comunicao de Requisitos.
Planejamento e gerenciamento da execuo das atividades de anlise de neg-

cios, que foi transferido para a rea de Conhecimento Planejamento e Monitora-
mento da Anlise de Negcios.
A tarefa P lanejar o Processo de Gerenciamento de Requisitos (2.5) no tem equivaln-

cia direta na verso 1.6.
Entender os Papis da Equipe de Projeto (3.2) Conduzir a Anlise das Partes Interessadas (2.2).
A tarefa da verso 2.0 explicitamente limitada a
analisar as funes e responsabilidades em relao
participao dos interessados em atividades de
anlise de negcios.
Veja tambm Anlise de Documentos (9.9),
Entrevista (9.14), Pesquisa e Questionrio (9.31)
para as tcnicas descritas nesta tarefa.
Definir a Estratgia de Diviso de Trabalho do No tem equivalncia na verso 2.0.

Analista de Negcios (3.3)
Definir Abordagem de Risco de Requisitos (3.4) No h tarefa diretamente equivalente. Os riscos so

identificados atravs de levantamento de atividades
e podem ser transmitidos e gerenciados. Veja tcni-
cas de Rastreamento de Problemas (9.20) e Anlise
de Riscos (9.24).
Determinar Consideraes de Planejamento (3.5) Planejar a Abordagem da Anlise de Negcios (2.1)
Selecionar Atividades de Requisitos (3.6) Planejar Atividades da Anlise de Negcios (2.3).

Sesso 3.6.3 correspondentes para Planejar a Comu-
nicao da Anlise de Negcios (2.4).
Estimar Atividades de Requisitos (3.7) Planejar Atividades da Anlise de Negcios (2.3) e

Estimativas (9.10)
Gerenciar o Escopo de Requisitos (3.8) Mltiplas tarefas: veja abaixo
Estabelecer Requisitos Bsicos (3.8.1) Gerenciar o Escopo e os Requisitos da Soluo (4.1)
Estrutura de Requisitos para Rastreabilidade Gerenciar Rastreabilidade dos Requisitos (4.2)

(3.8.2)

Sumrio de Mudanas da verso 1.6 Elicitao de Requisitos
Identificar Impactos para Sistemas Externos e/ou Avaliar a Prontido Organizacional (7.3)
Outras reas dos Projetos (3.8.3)
Identificar as alteraes resultantes de mudanas Gerenciar o Escopo e os Requisitos da Soluo (4.1)

de requisitos (Gesto de Mudana) (3.8.4)
Manter a Aprovao de Escopo (3.8.5) Gerenciar o Escopo e os Requisitos da Soluo (4.1)
Medir e Relatar as Atividades de Requisitos (3.9) Gerenciar o Desempenho da Anlise de Negcios

(2.6). A discusso de mtricas na tarefa da verso 2.0
explicitamente limitada para atividades de mtri-
cas de anlise de negcios e resultados.
Gesto de Mudana de Requisitos (3.10) Gerenciar o Escopo e os Requisitos da Soluo (4.1)
D.4 Elicitao de Requisitos

O nome desta rea de Conhecimento foi alterado para Elicitao.
Tarefa ou Tcnica 1.6 Tarefa ou Tcnica 2.0 ou Tcnica
Elicitao de Requisitos (4.2) Preparar a Elicitao (3.1)

Conduzir a Atividade de Elicitao (3.2)
Documentar os Resultados da Elicitao (3.3)
Confimar Resultados da Elicitao (3.4)
Brainstorming (4.3) Brainstorming (9.3)
Anlise de Documentos (4.4) Anlise de Documentos (9.9)
Grupo Focal (4.5) Grupo Focal (9.11)
Anlise de Interface (4.6) Anlise de Interface (9.13)
Entrevista (4.7) Entrevista (9.14)
Observao (4.8) Observao (9.18)
Prototipao (4.9) Prototipao (9.22)
Workshop de Requisitos (4.10) Workshop de Requisitos (9.23)
Engenharia Reversa (4.11) No includa na verso 2.0
Pesquisa / Questionrio (4.12) Pesquisa / Questionrio (9.31)

Documentao e Anlise de Requisitos Sumrio de Mudanas da verso 1.6
D.5 Documentao e Anlise de Requisitos

O nome desta rea de Conhecimento foi alterado para Anlise de Requisitos. Priori-
zar Requisitos (6.1) no tem equivalncia direta na 1.6.
Estrutura de Pacotes de Requisitos (5.2) O propsito desta tarefa est estritamente rela-
cionado com Organizar Requisitos (6.2), mas o
contedo real est mais prximo de Decomposio
Funcional (9.12).
Criar o Modelo de Domnio do Negcio (5.3) Organizar Requisitos (6.2) e Especificar e

Modelar Requisitos (6.3)
Analisar Requisitos de Usurio (5.4) Organizar Requisitos (6.2) e Especificar e

Analisar Requisitos Funcionais (5.5) Organizar Requisitos (6.2) e Especificar e

Analisar Requisitos de Qualidade de Servios (5.6) Organizar Requisitos (6.2), Especificar e Modelar
Requisitos (6.3) e Anlise de Requisitos No-Funcio-
nais (9.17)
Determinar Suposies e Restries (5.7) Definir Suposies e Restries (6.4)
Determinar Atributos de Requisitos (5.8) A determinao dos atributos que sero utilizados
acontece em Planejar o Processo de Gerenciamento
de Requisitos (2.5). A captura de atributos para um
determinado requisito acontece em Especificar e
Modelar Requisitos (6.3).
Documentar Requisitos (5.9) Preparar Pacote de Requisitos (4.4)
Validar Requisitos (5.10) Validar Requisitos (6.6)
Verificar Requisitos (5.11) Verificar Requisitos (6.5)
Modelos de Dados e Comportamento (5.12) Nenhuma tcnica equivalente para este agrupa-
mento. Muitas das tcnicas individuais esto presen-
tes na verso 2.0, conforme descrito abaixo:
Regras de Negcios (5.12.1) Anlise de Regras de Negcios (9.4)
Modelos de Classe (5.12.2) Modelagem de Dados (9.7)
Matrix CRUD (5.12.3) No est descrito na verso 2.0
Dicionrio de Dados (5.12.4) Dicionrio de Dados e Glossrio (9.5)
Transformao de Dados e Mapeamento (5.12.5) Definir Requisitos de Transio (7.4)
Diagrama de Entidade e Relacionamento (5.12.6) Modelagem de Dados (9.7)
Definio de Metadados (5.12.7) Modelagem de Dados (9.7)

Sumrio de Mudanas da verso 1.6 Comunicao de Requisitos
Modelo de Fluxo/Processo (5.13) Nenhuma tcnica equivalente para este agrupa-

Diagrama de Atividade (5.13.1) Modelagem de Processos (9.21)
Diagrama de Fluxo de Dados (5.13.2) Diagrama de Fluxo de Dados (9.6)
Identificao de Evento (5.13.3) No descrito na verso 2.0. Os eventos so de-

scritos em relao a uma srie de outras tcnicas e
podem ser usados como base para a Modelagem de
Escopo (9.27)
Flowchart (5.13.4) Modelagem de Processo (9.21)
Diagrama de Sequncia (5.13.5) Diagrama de Sequncia (9.28)
Diagrama de Mquina de Estado (5.13.6) Diagrama de Estados (9.29)
Modelos de Workflow (5.13.7) Modelagem de Processos (9.21)
Modelos de Uso (5.14) Nenhuma tcnica equivalente para este agrupa-

Prototipao (5.14.1) Prototipao (9.22)
Storyboards / Fluxo de Telas (5.14.2) Prototipao (9.22)
Descrio de Casos de Uso (5.14.3) Cenrios e Casos de Uso (9.26)
Diagrama de Casos de Uso (5.14.4) Cenrios e Casos de Uso (9.26). Diagramas de Casos
de Uso tambm so usados para Modelagem de
Escopo (9.27)
Projetos de Interface de Usurio (5.14.5) Prototipao (9.22)
Perfis de Usurio (5.14.6) Nenhuma tcnica equivalente direta em 2.0. Esta

tcnica estaria dentro da tcnica de Anlise das
Partes Interessadas (2.2).
Histrias de Usurio (5.14.7) Histrias de Usurio (9.33)
D.6 Comunicao de Requisitos

Esta rea de Conhecimento foi unida com as tarefas de gerenciamento de requisi-
tos, transferidas de Planejamento e Gerenciamento de Requisitos para Gerenciamento
e Comunicao de Requisitos. A tarefa Manter Requisitos para Reuso (4.3) no tem
equivalncia direta na 1.6.

Avaliao e Validao da Soluo Sumrio de Mudanas da verso 1.6
Criar Plano de Comunicao de Requisitos (6.2) Planejar a Comunicao da Anlise de Negcios (2.4)
Gerenciar Conflitos de Requisitos (6.3) Gerenciar o Escopo e os Requisitos da Soluo (4.1)
Determinar o Formato Apropriado dos Requisitos Planejar a Comunicao da Anlise de Negcios (2.4)
(6.4) e Preparar Pacote de Requisitos (4.4)
Criar um Pacote de Requisitos (6.5) Preparar Pacote de Requisitos (4.4)
Realizar uma Apresentao de Requisitos (6.6) Comunicar Requisitos (4.5)
Realizar uma Reviso Formal de Requisitos (6.7) Revises Estruturadas (9.30)
Obter Aprovao dos Requisitos (6.8) Gerenciar o Escopo e os Requisitos da Soluo (4.1)
D.7 Avaliao e Validao da Soluo

O texto para estas tarefas estavam incompletos at o momento em que a verso 1.6 foi
publicada. As tarefas na verso 2.0 usam uma estrutura conceitual muito diferente e,
portanto. as tarefas s podem corresponder de uma forma muito aproximada.
Desenvolver Solues Alternativas (7.2) Alocar Requisitos (7.2)
Avaliar Opes de Tecnologia (7.3) Avaliar a Soluo Proposta (7.1)
Facilitar a Seleo de uma Soluo (7.4) Avaliar a Soluo Proposta (7.1)
Garantir a Usabilidade da Soluo (7.5) Validar a Soluo (7.5)
Apoiar o Processo de Garantia da Qualidade (7.6) Validar a Soluo (7.5)
Apoiar a Implementao da Soluo (7.7) Definir Requisitos de Transio (7.4)
Comunicar o Impacto da Soluo (7.8) Avaliar a Prontido Organizacional (7.3)
Reviso e Avaliao Ps-Implementao (7.9) Gerenciar o Desempenho da Anlise de Negcios

(2.6) e Avaliar o Desempenho da Soluo (7.6)
D.8 Fundamentos Bsicos

Nenhum contedo foi criado para esta seo no momento em que foi publicada a
verso 1.6. Esta rea de Conhecimento, em geral, equivale rea de Conhecimento
Competncias Fundamentais na verso 2.0, mas os temas individuais so estrutura-
dos de forma muito diferente.


Babok 2.0 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Babok 2.0 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Um guia para o

Imagem da Capa 2006 iStockphoto.com/Damkier Media Group.

Este documento disponibilizado comunidade de anlise de negcios para propsitos educa-

CMMI uma marca registrada da Carnegie Mellon University.

O Instituto Internacional de Anlise de Negcios no tem a inteno de fazer qualquer objeo ao

Qualquer questionamento relacionado a esta publicao, solicitao de direitos de uso do material

Prefcio da Edio em Lngua Portuguesa 3

Planejamento e Monitoramento da Anlise de Negcios 21

Gerenciamento e Comunicao dos Requisitos 67

Guia BABOK Verso 2.0 III

Anlise de Requisitos 105

Avaliao e Validao da Soluo 127

Competncias Fundamentais 147

IV Um guia para o Corpo de Conhecimento de Anlise de Negcios

9.21 Modelagem de processos 198

Sumrio de Mudanas da verso 1.6 253

Guia BABOK Verso 2.0 V

Criao e desenvolvimento da conscincia e reconhecimento do valor e da contribuio

Definio de Um Guia para o Corpo de Conhecimento de Anlise de Negcios (BABOK);

Estabelecimento de um frum para compartilhamento do conhecimento e contribuio

Reconhecimento pblico e certificao dos praticantes de Anlise de Negcios atravs

Esta publicao substitui Um Guia para o Corpo de Conhecimento de Anlise de Negcios,

O Guia BABOK contm a descrio de prticas geralmente aceitas no campo da anlise

Guia BABOK Verso 2.0 1

Esta reviso tem como meta:

Completar a descrio de todas as reas de conhecimentos;

Simplificar a estrutura e torn-la mais fcil de entender e aplicar;

Aperfeioar a consistncia e qualidade do texto e ilustraes;

Integrar reas de conhecimento e evitar reas de sobreposio;

Aperfeioar a consistncia em relao a outros padres geralmente aceitos relacionados

Estender a cobertura do Guia BABOK para descrever a anlise de negcios para

Esclarecer o relacionamento entre a anlise de negcios e outras disciplinas,

Foco na prtica da anlise de negcios no contexto da iniciativa individual, com

As principais mudanas nesta edio incluem:

Mudanas gerais direcionadas para as metas descritas acima;

Tarefas na rea de Conhecimento Planejamento e Gerenciamento dos Requisitos

Tcnicas so aplicveis entre mltiplas reas de Conhecimento;

Entradas e Sadas foram definidas para todas as tarefas.

O IIBA gostaria de estender seus agradecimentos e os agradecimentos da comunidade de

2 Um guia para o Corpo de Conhecimento de Anlise de Negcios

Este trabalho envolveu profissionais analistas de negcios membros do Captulo e

Guia BABOK Verso 2.0 3

1.1 O que o Corpo de Conhecimento de Anlise de Negcios?

O propsito primrio do Guia BABOK definir a profisso de Anlise de Negcios.

Este captulo introduz os principais conceitos relacionados anlise de negcios

1.2 O que Anlise de Negcios?

Anlise de Negcios envolve compreender como as organizaes funcionam e

Analistas de negcios devem analisar e sintetizar informaes fornecidas por grande

Guia BABOK Verso 2.0 5

profissionais de TI e executivos. O analista de negcios responsvel por desvendar

Um analista de negcios qualquer pessoa que executa atividades de anlise de

Grande parte das solues envolve um sistema de componentes de soluo que

A anlise de negcios auxilia a organizao a definir a melhor soluo para suas

1. Uma condio ou capacidade necessria para uma parte interessada resolver

1 Baseado no IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.

6 Um guia para o Corpo de Conhecimento de Anlise de Negcios

3. Uma representao documentada de uma condio ou capacidade como em (1)

O termo requisito gera muitas discusses na comunidade de anlise de negcios.

Muito da literatura existente a respeito de anlise de negcios escrita com

De forma semelhante, ns no assumimos que requisitos so analisados em algum

.1 Esquema de classificao de requisitos

Requisitos do Negcio so metas de mais alto nvel, objetivos ou necessidades

Requisitos das partes interessadas so necessidades de uma parte interessada

Prefcio da Edio em Lngua Portuguesa 3

Planejamento e Monitoramento da Anlise de Negcios 21

Gerenciamento e Comunicao dos Requisitos 67

Anlise de Requisitos 105

Avaliao e Validao da Soluo 127

Competncias Fundamentais 147

9.21 Modelagem de processos 198

Sumrio de Mudanas da verso 1.6 253