(BR) Babok 2.0

Um guia para o Corpo de Conhecimento de Anlise de Negcios (Guia BABOK) Verso 2.
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 reservados. Partes do Apndice A: Glossrio so oriundos do The Software Requirements Memory Jogger, de Ellen 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 educacionais. 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 Institute of Business Analysis. Instituto Internacional de Anlise de Negcios, Corpo de Conhecimento de Anlise de Negcios, CCBA, Certification of Competency in Business Analysis, Certified Business 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 Institute 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
1.1 O que o Corpo de Conhecimento de Anlise de Negcios? 1.2 O que Anlise de Negcios? 1.3 Conceitos-Chave 1.4 reas de Conhecimento 1.5 Tarefas 1.6 Tcnicas 1.7 Competncias Fundamentais Outras Fontes de Informao sobre Anlise de Negcios 1.8
3
5 5 6 8 10 16 17 18
Introduo5
Planejamento e Monitoramento da Anlise de Negcios

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

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

III
Tabela de Contedos
Anlise de Requisitos
6.1 6.2 6.3 6.4 6.5 6.6 Priorizar Requisitos Organizar Requisitos Especicar e Modelar Requisitos Denir Suposies e Restries Vericar Requisitos Validar Requisitos
105
105 109 113 117 120 123
Avaliao e Validao da Soluo

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

Tabela de Contedos 9.21 Modelagem de processos 9.22 Prototipagem 9.23 Workshop de requisitos 9.24 Anlise de riscos 9.25 Anlise de Causa-Raiz 9.26 Cenrios e Casos de uso 9.27 Modelagem do Escopo 9.28 Diagramas de Sequncia 9.29 Diagramas de Estados 9.30 Reviso Estruturada 9.31 Pesquisa / Questionrio 9.32 Anlise SWOT 9.33 Histrias do usurio 9.34 Avaliao de fornecedores 198 202 204 206 208 209 212 214 215 216 219 222 224 225
Glossrio227 Bibliograa241 Contribuintes247

C.1 C.2 Verso 2.0 Verso 1.6 247 250
Sumrio de Mudanas da verso 1.6

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

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
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.

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
1.1
UM
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
1.3.1
Conceitos-Chave
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.
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. Esquema de classicao de requisitos .1 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

Anlise Corporativa Elicitao Anlise de Requisitos
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.
10

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 Externamente Produzido pela tarefa (veja a tarefa #)
*
Produzido por mltiplas tarefas
Associao
Tarefas e reas de Conhecimento

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

11
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
12

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 Analista de Negcios Cliente Especialista no assunto Usurio nal Especialista em implementao da soluo Exemplos e Papis Alternativos Analista de Negcios e Sistemas, Analista de Sistemas, Analista de Processos, Consultor, Dono do Produto, etc. Segmentado por mercado, geograa, indstria, etc. Por unidade organizacional, cargo, etc. Por unidade organizacional, cargo, etc. Bibliotecrio do projeto, gerente de mudanas, gerente de congurao, arquiteto de soluo, desenvolvedor, DBA, arquiteto da informao, analista de usabilidade, instrutor, consultor de mudana organizacional, etc. Help Desk, tcnicos de rede, gerente de verso (release) Scum Master, lder de equipe Provedores de produto ou servio, consultores, etc. Analista de qualidade Governo, entidades de regulamentao, auditores 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.
Suporte operacional Gerente de Projetos Fornecedor Testador Regulador Patrocinador

13
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. Prossionais 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. Prossionais 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.
14

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. Regulador .8 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.

15
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)
16

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 1.6.3
Descrio
Descreve o que a tcnica e como ela usada.
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
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

17
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)
18

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.

19

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

Entradas Sadas
5.1 Necessidade do Negcio 2.1 Abordagem de Anlise de Negcios 2.4 Plano de Comunicao da Anlise de Negcios 2.6 2.6 Avaliao do Desempenho da Anlise de Negcios 2.5
*
Mtricas de Desempenho da Anlise de Negcios
Tarefas
2.1 Planejar a Abordagem da Anlise de Negcios 2.3 Planejar Atividades da Anlise de Negcios 2.5 Planejar o Processo de Gerenciamento de Requisitos 2.2 Conduzir a Anlise de Partes Interessadas 2.4 Planejar a Comunicao da Anlise de Negcios 2.6 Gerenciar o Desempenho da Anlise de Negcios
2.3 Plano(s) da Anlise de Negcios
Arquitetura Corporativa
Opinio de Especialistas
Ativos de Plano de Processos de Gerenciamento Anlise de de Requisitos Negcios 2.2 Lista de Partes Interessadas, Papis e Responsabilidade
Ativos de Processos Organizacionais

21
Planejar a abordagem da Anlise de Negcios
2.1
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).
22

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 de Negcio Opinio de Especialistas Ativos de Processos Organizacionais
2.1 Planejar a Abordagem da Anlise de Negcios
2.1 Abordagem da Anlise de Negcios
Tarefas que usam esta sada

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

23
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
24

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. Guia BABOK Verso 2.0
25
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. Ferramentas de Anlise e Gerenciamento dos Requisitos .7 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. 26 Um guia para o Corpo de Conhecimento de Anlise de Negcios
.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.

27
Conduzir a Anlise das Partes Interessadas
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
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.
28

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 do Negcio Arquitetura Corporativa Ativos de Processos Organizacionais
2.2 Conduzir a Anlise das Partes Interessadas
2.2 Lista de Partes Interessadas, Papis e Responsabilidades

2.3 Planejar Atividades da Anlise de Negcios 2.4 Planejar a Comunicao da Anlise de Negcios 3.1 Preparar a Elicitao
4.1 Gerenciar escopo e requisitos da soluo
6.1 Priorizar Requisitos
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.

29
.1 Identicao 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. Atitude e Inuncia .3 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? 30 Um guia para o Corpo de Conhecimento de Anlise de Negcios
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, Guia BABOK Verso 2.0
31
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.
32

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

.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 partes interessadas.
Figura 2-5: Matriz de Partes Interessadas

Alto Trabalhar prximo Parte Interessada para garantir que ela esteja de acordo e apoie as mudanas.
Inuncia da Parte Interessada
Assegurar que a Parte Interessada permanea satisfeita.
Monitorar se a inuncia ou o interesse da Parte Interessada no se altera.
Manter informada; provvel que a Parte Interessada esteja muito preocupada e possa se sentir 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 Organizao ou Corporao Unidade Organizacional Afetada Entrega da Soluo
Patrocinadores, executivos, especialista no assunto e outras pessoas que interagem com o grupo afetado. Usurio nal, help desk e outros, cujo trabalho muda quando a soluo entregue. Equipe de projeto e outros diretamente envolvidos com a criao da soluo.
34

Planejar Atividades da Anlise de Negcios
2.2.6
Partes Interessadas
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 partes interessadas. 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
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.

35
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.
36

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 Abordagem da Anlise de Negcios 2.6 2.2
Avaliao do Ativos de Processos Lista de Partes Desempenho da Organizacionais Interessadas, Anlise de Papis e Negcios Responsabilidade
2.3 Planejar Atividades da Anlise de Negcios
2.3 Plano(s) da Anlise de Negcios

2.4 Planejar o Processo de Gerenciamento de Requisitos 2.5 Planejar a Comunicao da Anlise de Negcios
Tarefas gerenciadas por esta sada

Elicitao
+
Gerenciamento e Comunicao de Requisitos

+
2.6 Gerenciar o Desempenho da Anlise de Negcios
Anlise Corporativa
+
+

+

37
2.3.4
Elementos
.1 Distribuio geogrca 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.
38

.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. Guia BABOK Verso 2.0
39
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
40

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
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

41
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.
42

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

Entradas
2.1 Abordagem da Anlise de Negcios 2.3 Plano(s) da Anlise de Negcios Ativos de Processos Organizacionais 2.2 Lista de Partes Interessadas, Papis e Responsabilidade
2.4 Planejar a Comunicao da Anlise de Negcios
2.4 Plano de Comunicao da Anlise de Negcios

4.4 Preparar Pacote de Requisitos 4.5 Comunicar Requisitos
2.4.4
Elementos
.1 Geograa 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.

43
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. Freqncia da comunicao .4 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. 44 Um guia para o Corpo de Conhecimento de Anlise de Negcios
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.
2.4.6
Partes Interessadas
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.

45
Planejar o Processo de Gerenciamento de Requisitos
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
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
46

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 Abordagem da Anlise de Negcios 2.3 Plano(s) da Anlise de Negcios Ativos de Processos Organizacionais
2.5 Planejar o Processo de Gerenciamento de Requisitos
2.5 Plano de Gerenciamento de Requisitos

2.6 Gerenciar o Desempenho da Anlise de Negcios 3.2 Conduzir Atividades de Elicitao 4.1 Gerenciar o Escopo e os Requisitos da Soluo
4.2 Gerenciar Rastreabilidade dos 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

47
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.
48

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 Guia BABOK Verso 2.0
49
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 noambguos. 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. 50 Um guia para o Corpo de Conhecimento de Anlise de Negcios
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. Adaptando Processo de Gerenciamento dos Requisitos .6 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:

51
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.
2.5.6
Partes Interessadas
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.
52

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
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.

53
Figura 2-10: Diagrama de Entrada/Sada de Gerenciar o Desempenho da Anlise de Negcios

Entradas
*
Mtricas de Desempenho da Anlise de Negcios
2.3 Plano(s) da Anlise de Negcios Padres de Desempenho Organizacional
2.6 Gerenciar o Desempenho da Anlise de Negcios
2.6 Avaliao do Desempenho da Anlise de Negcios
2.6 Ativos de Processos da Anlise de Negcios

2.3 Planejar Atividades da Anlise de Negcios
Sada usada tambm por

Ativos de Processos Organizacionais
+
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.
54

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.

55
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.
2.6.6
Partes Interessadas
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.
56

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 Brainstorming (9.3) Anlise de Documentos (9.9) Grupos Focais (9.11) Anlise de Interface (9.13) Entrevistas (9.14) Observao (9.18) Prototipao (9.22) Workshops de Requisitos (9.23) Pesquisa / Questionrio (9.31) Sinnimo Reviso de documentao existente Anlise de Interface Externa Job Shadowing Storyboarding, uxo de navegao, prototipao em papel, uxos de tela Workshop de Elicitao, Workshop Facilitado

57
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
5.5 5.1 Ativos de Processos Organizacionais
Sadas Tarefas
3.1 Preparar a Elicitao 3.2 Conduzir a Atividade de Elicitao 3.2 3.1
Business Case Necessidade do Negcio
Resultados da Recursos Elicitao Agendados 3.3, 3.4
5.4 Escopo da Soluo
2.2 Lista de Partes Interessadas, Papis e Responsabilida de
3.3 Documentar os Resultados da Elicitao
3.4 Conrmar Resultados da Elicitao
3.1
Preocupaes Materiais de das Partes Apoio Interessadas
3.1
3.1.1
Preparar a Elicitao
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.
58

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 (veja o texto) Negcio (veja o texto)
Escopo da Lista de Partes Soluo Interessadas, (veja o Papis e texto) Responsabilidade
3.1 Preparar a Elicitao
3.1 Recursos Agendados
3.1 Materiais de Apoio
Tarefas que usam estas sadas

3.2 Conduzir a Atividade 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.

59
Conduzir a Atividade de Elicitao Brainstorming (9.3) Anlise Documental (9.9) Grupos Focais (9.11) Anlise de Interfaces (9.13) Entrevistas (9.14) Observao (9.18) Prototipagem (9.22) Workshops de Requisitos (9.23) Pesquisa/Questionrio (9.31)
Elicitao
3.1.6
Partes Interessadas
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
3.2.1
Conduzir a Atividade de Elicitao

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.
60

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 Gerenciamento Agendados de Requisitos
Escopo da Materiais de Soluo Apoio (veja o texto)
3.2 Conduzir a Atividade de Elicitao
3.2 Resultados da Elicitao


61
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) Grupos Focais (9.11) Anlise de Interface (9.13) Entrevistas (9.14) Observao (9.18) Prototipagem (9.22) Workshops de Requisito (9.23) Pesquisa/Questionrio (9.31)
3.2.6
Partes Interessadas
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.
62

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
3.3.1 3.3.2
Documentar os Resultados da Elicitao

Propsito
Registrar as informaes providas pelas partes interessadas para o uso na anlise.
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.

63
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 Requisitos [Declarados]
3.3 Preocupaes das Partes Interessadas

3.4 Conrmar Resultados da Elicitao 6.1 Priorizar Requisitos 5.1 Denir a Necessidade do Negcio 6.3 Especicar e Modelar Requisitos

3.4 Conrmar os Resultados da Elicitao 6.5 Denir Suposies e Restries 5.5 Denir o Business Case 7.3 Avaliar a Prontido Organizacional
7.4 Denir Requisitos de Transio
3.3.6
Partes Interessadas
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.
64

Elicitao
Conrmar Resultados da Elicitao
3.4
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)
3.4.6
Partes Interessadas
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.

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

Entradas
3.3 Requisitos [Declarados, No conrmados] 3.3 Preocupaes das Partes Interessadas [No Conrmadas]
3.4 Conrmar Resultados da Elicitao
3.4 Requisitos [Declarados, Conrmados]
3.4 Preocupaes das Partes Interessadas [Conrmadas]
Tarefas que usam esta sada (veja o texto)

5.1 Denir a Necessidade do Negcio 6.3 Especicar e Modelar Requisitos 6.1 Priorizar Requisitos
Tarefas que usam esta sada (veja o texto)

5.5 Denir o Business Case 6.5 Denir Suposies e Restries
7.3 Avaliar a Prontido Organizacional
66


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
2.4 Plano de Ativos de Comunicao Processos da Anlise de Organizacionais Negcios 2.5 6.2
*
Requisitos
Sadas Tarefas
4.1 Gerenciar o Escopo e os Requisitos da Soluo 4.3 Manter Requisitos para Reutilizao 4.2 Gerenciar Rastreabilidade dos Requisitos 4.4 Preparar o Pacote de Requisitos 4.1 Requisitos [Aprovados] 4.5 Requisitos [Comunicados] 4.2 Requisitos [Rastreados] 4.4 Pacotes de Requisitos
5.4 Escopo da Soluo
4.3 Requisitos [Mantidos e Reusveis]
Plano de Estrutura de Gerenciamento Requisitos de Requisitos 2.2 Lista de Partes Interessadas, Papis e Responsabilidade
4.5 Comunicar Requisitos
4.1
4.1.1
Gerenciar o Escopo e os Requisitos da Soluo

Propsito
Obter e manter consenso entre as principais partes interessadas acerca do escopo genrico da soluo e os requisitos que sero implementados. Guia BABOK Verso 2.0
67
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.
68

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

Entradas
2.5 Plano de Gerenciamento de Requisitos 5.4 Escopo da Soluo 2.2 Lista de Partes Interessadas, Papis e Responsabilidade 4.2, 4.5 Requisitos das partes interessadas, da soluo ou de transio [Comunicados ou Rastreados]
4.1 Gerenciar o Escopo e os Requisitos da Soluo
4.1 Requisitos [Aprovados]

4.3 Manter os Requisitos para Reutilizao 7.1 Avaliar a Soluo Proposta 7.2 Alocar Requisitos
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 Conitos 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

69
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.
70

.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.
4.1.6
Partes Interessadas
Especialista no assunto: Pode estar envolvido na reviso e aprovao dos requisitos, conforme definido pela designao dos papis e responsabilidade das partes interessadas. 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.

71
Gerenciar Rastreabilidade dos Requisitos
4.2
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 interrelacionamentos. 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.
72

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
*
Requisitos
4.2 Gerenciar Rastreabilidade dos Requisitos
4.2 Requisitos [Rastreados]

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.

73
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 Congurao 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).
4.2.6
Partes Interessadas
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.
74

Manter Requisitos para Reutilizao
4.3
4.3.1 4.3.2

Propsito
Gerenciar o conhecimento sobre os requisitos aps sua implementao.
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 Processos Organizacionais Requisitos
4.3 Manter Requisitos para Reutilizao
4.3 Requisitos [Mantidos e Reusveis]

Arquitetura Corporativa
+
Iniciativas Futuras
+

75
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. Requisitos Atendidos .2 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 4.3.6
Tcnicas
Nenhuma.
Partes Interessadas
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.
76

Preparar o Pacote de Requisitos
4.4
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.

77
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 Plano de Ativos de Comunicao Processos da AN Organizacionais
*
Requisitos
6.2 Estrutura de Requisitos
4.4 Preparar o Pacote de Requisitos
4.4 Pacotes de Requisitos

78

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.

79
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. Requisitos Para Seleo do Fornecedor .2 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
80

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.
4.4.6
Partes Interessadas
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.

81
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
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.
82

Figura 4-6: Diagrama de Entrada/Sada de Comunicar Requisitos

Entradas
2.4 Plano de Comunicao da Anlise de Negcios
*
Requisitos
4.4 Pacote de Requisitos
4.5 Requisitos [Comunicados]

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 Guia BABOK Verso 2.0
83
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.
84

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.
4.5.6 4.5.7
Partes Interessadas
Todas.
Sada
Requisitos Comunicados: As partes interessadas devem entender quais so os requisitos e a sua situao atual.

85
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
6.4 Suposies e Restries Metas e Objetivos do Negcio 3.3 Ativos de Processos Organizacionais Requisitos [Declarados] 3.3 Preocupaes das Partes Interessadas Arquitetura Corporativa 5.1 Denir a Necessidade do Negcio 5.3 Determinar a Abordagem da Soluo
Tarefas
5.2 Avaliar Gaps (Lacunas) de Capacidades 5.4 Denir o Escopo da Soluo 5.5
Sadas
5.1
Business Case Necessidade de Negcio 5.2 Capacidades Requeridas 5.3 Abordagem de Soluo 5.4 Escopo da Soluo
7.6 Avaliao do Desempenho da Soluo
5.5 Denir o Business Case

87
Denir a Necessidade do Negcio
Anlise Corporativa
5.1
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 Denir a Necessidade do Negcio

Entradas
3.3 Metas e Objetivos do Negcio Requisitos [Declarados]
5.1 Denir a Necessidade do Negcio
5.1 Necessidade do Negcio

2.1 Planejar a Abordagem da AN 2.2 Conduzir a Anlise das Partes Interessadas 5.2 Avaliar Gaps (Lacunas) de Capacidades 5.5 Denir o Escopo da Soluo 3.1 Preparar a Elicitao
3.2 Conduzir Atividade de Elicitao
5.3 Determinar a Abordagem da Soluo
6.5 Vericar Requisitos

+
88

Anlise Corporativa
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

89
Denir a Necessidade do Negcio Alcanveis Testando a viabilidade do esforo
Anlise Corporativa
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.
90

Anlise Corporativa Brainstorming (9.3): Gera insights e opes.
Avaliar Gaps (Lacunas) de Capacidades
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.
5.1.6
Partes Interessadas
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
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

91
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 Necessidade do Negcio Arquitetura Corporativa 7.6 Avaliao do Desempenho da Soluo
5.2 Avaliar Gaps (Lacunas) de Capacidades
5.2 Capacidades Requeridas

5.3 Determinar a Abordagem da Soluo 5.4 Denir o Escopo da Soluo

+
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
92

Anlise Corporativa
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).

93
Determinar a Abordagem da Soluo
Anlise Corporativa
5.2.6
Partes Interessadas
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
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
94

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

Entradas
5.1 Necessidade do Negcio 5.2 Capacidades Ativos de Requeridas Processos Organizacionais
5.3 Determinar a Abordagem da Soluo
5.3 Abordagem da Soluo

5.4 Denir 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:

95
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.
96

Anlise Corporativa
Denir 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 negciochave 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.
5.3.6
Partes Interessadas
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
5.4.1 5.4.2

Propsito
Definir quais novas capacidades um projeto ou iterao ir entregar.
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.

97
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 Denir o Escopo da Soluo

Entradas
6.4 Suposies e Restries 5.1 5.2 5.3 Abordagem da Soluo
Necessidade do Capacidades Negcio Requeridas
5.4 Denir o Escopo da Soluo
5.4 Escopo da Soluo

3.1 Preparar a Elicitao 3.2 Conduzir a Atividade de Elicitao 6.2 Organizar Requisitos 7.3 Avaliar a Prontido Organizacional 5.5 Denir o Business Case 6.5 Vericar Requisitos
7.2 Alocar Requisitos

+
98

Anlise Corporativa
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 Denio 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. Abordagem de Implementao .2 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.

99
Denir 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 Afeta Cujo impacto Uma soluo bem sucedida poderia Descreva o problema. As Partes Interessadas afetadas pelo problema. Qual o impacto do problema sobre cada Parte Interessada. Listar alguns dos principais benefcios de uma boa soluo.
5.4.6
Partes Interessadas
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
5.5.1

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

Anlise Corporativa
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 Denir o Business Case

Entradas
6.4 Suposies e Restries 5.1 Necessidade do Negcio 5.4 Escopo da Soluo 3.3 Preocupaes das Partes Interessadas
5.5 Business Case

3.1 Preparar a Elicitao 3.2 Conduzir a Atividade de Elicitao 6.1 Priorizar Requisitos
6.6 Validar Requisitos

+

101
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. Custos .2 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.
102

Anlise Corporativa
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.
5.5.6
Partes Interessadas
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.

103
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
*
Requisitos 3.3
Tarefas
6.1 Priorizar Requisitos 6.3 Especicar e Modelar Requisitos 6.5 Vericar Requisitos 6.2 Organizar Requisitos 6.4 Denir Suposies e Restries 6.6 Validar Requisitos 6.4 Suposies e Restries 6.6 Requisitos [Validados]
Sadas
6.2 Estrutura de Requisitos 6.5 Requisitos [Vericados] 6.1 Requisitos [Priorizados] 6.3 Requisitos das Partes Interessadas ou da Soluo
Business Case Necessidade do Negcio 2.5
Ativos de Preocupaes Plano de Processos Gerenciamento das Partes Organizacionais de Requisitos Interessadas 2.2 Lista de Partes Interessadas, Papis e Responsabilidade 5.4 Escopo da Soluo
6.1
6.1.1
Priorizar Requisitos
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.

105
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 Business Case 5.1 Necessidade do Negcio
*
Requisitos
2.2 Lista de Partes Interessadas, Papis e Responsabilidade
6.1 Requisitos [Priorizados]

7.1 Avaliar a Soluo Proposta 7.2 Alocar Requisitos Gerenciamento e Comunicao de Requisitos
+
7.5 Validar a Soluo
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.
106

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. Desaos .2 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.

107
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 xo 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.
108

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 distribulos entre as funcionalidades ou requisitos propostos. Os requisitos que receberem mais votos sero aqueles que sero investigados ou desenvolvidos primeiro.
6.1.6
Partes Interessadas
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
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

109
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
*
Ativos de Processos Organizacionais Requisitos [Declarados]
5.4 Escopo da Soluo
6.2 Organizar Requisitos
6.2 Estrutura de Requisitos

4.4 Preparar o Pacote de Requisitos 6.3 Especicar e Modelar Requisitos
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).
110

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) Guia BABOK Verso 2.0
111
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.
112

Especicar 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.
6.2.6
Partes Interessadas
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
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.

113
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 Especicar e Modelar Requisitos

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

6.1 Priorizar Requisitos 6.5 Vericar Requisitos Gerenciamento e Comunicao de 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.
114

Anlise de 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.

115
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.
116

Denir 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)
6.3.6
Partes Interessadas
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
6.4.1

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

117
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 necessidade do negcio. 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,
118

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 Denir Suposies e Restries

Entradas
6.4 Denir Suposies e Restries
6.4 Suposies e Restries

5.4 Denir o Escopo da Soluo 5.5 Denir o Business Case Gerenciamento e Comunicao de Requisitos
+
7.1 Avaliar a Soluo Proposta

119
Vericar Requisitos
6.4.5
Partes Interessadas
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
6.5.1
Vericar Requisitos
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:
120

Vericar Requisitos
Figura 6-6: Diagrama de Entrada/Sada de Vericar Requisitos

Entradas
*
Requisitos [Exceto os Declarados]
6.5 Requisitos [Vericados]

+
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. Guia BABOK Verso 2.0
121
Vericar 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 Vericao 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
122

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.
6.5.6
Partes Interessadas
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
6.6.1
Validar Requisitos
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 Business Case 6.5 Requisitos das Partes Interessadas, da Soluo ou de Transio [Vericados]
6.6 Requisitos [Validados]

+
7.5 Validar a Soluo

123
Validar 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 Identicar 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 Denir 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.
124

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 partes interessadas. 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.
6.6.6
Partes Interessadas
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.

125

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
6.4 Suposies e Restries Arquitetura Corporativa
Sadas
*
Requisitos 7.1 Avaliar a Soluo Proposta 7.3 Avaliar a Prontido Organizacional 7.5 Validar a Soluo
Tarefas
7.2 Alocar Requisitos 7.4 Denir Requisitos de Transio 7.6 Avaliar o Desempenho da Soluo
7.1
7.5
7.5 Aes de Mitigao
Avaliao da Defeitos Soluo Identicados Proposta 7.3 7.2
7.4 Requisitos de Transio
Soluo Alternativa(s) Mtricas de [Construda, de Soluo Desempenho Desenvolvida ou da Soluo Desenhada] 5.4 Escopo da Soluo 3.3 Preocupaes das Partes Interessadas
Avaliao da Requisitos [Alocados] Prontido Organizacional 7.6 Avaliao do Desempenho da Soluo
7.5 Avaliao da Validao Soluo
7.1
7.1.1
Avaliar Soluo Proposta

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.

127
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 Suposies e Restries 4.1, 6.1 Requisitos [Priorizados e Aprovados] Alternativa (s) de Soluo
7.1 Avaliar a Soluo Proposta
7.1 Avaliao da Soluo Proposta

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.
128

7.1.4
Elementos
.1 Ranqueamento das Opes de Solues Quando h relativamente poucos critrios envolvidos, pode ser mais produtivo focarse 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. Identicao de Capacidades Potenciais Adicionais .2 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.
7.1.6
Partes Interessadas
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.

129
Alocar Requisitos
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
7.2.1
Alocar Requisitos
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, 6.1 Requisitos [Priorizados e Aprovados] Soluo [Desenhada] 5.4 Escopo da Soluo
7.2 Alocar Requisitos
7.2 Requisitos [Alocados]
Tarefas Usadas nesta Sada

+
Seleo ou Desenho da Soluo

+
130

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:

131
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.
132

Avaliar a Prontido Organizacional
7.2.6
Partes Interessadas
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
7.3.1 7.3.2

Propsito
Avaliar se a organizao est pronta para fazer uso efetivo de uma nova soluo.
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

133
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 Arquitetura Corporativa
Soluo [Desenhada]
Escopo da Soluo
7.3 Avaliar a Prontido Organizacional
7.3 Avaliao da Prontido Organizacional

Denir 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.
134

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 desempenhlas? 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.

135
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 Fora Foras de Apoio Mudana Foras de Oposio Potncia da Mudana Fora
Fora de Apoio 1
Fora de Oposio 1
Proposta de Alterao do Sistema de Negcio 2

Fora de Apoio 2 Fora de Oposio 2
Total: 7
Total: 4
7.3.6
Partes Interessadas
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.
136

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
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.

137
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 Denir Requisitos de Transio

Entradas
7.3 Avaliao da Prontido Organizacional 3.3 Requisitos [Declarados] Soluo [Em Soluo Operao] [Desenhada]
7.4 Requisitos de Transio

6.1 Priorizar Requisitos 6.5 Vericar Requisitos Gerenciamento e Comunicao de 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.
138

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.
7.4.6
Partes Interessadas
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.

139
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
7.5.1
Validar a Soluo
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
140

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 [Priorizados e Validados] Soluo [Construda]
7.5 Validar a Soluo
7.5 Defeitos Identicados
7.5 Mitigao
7.5 Avaliao da Validao Soluo

7.6 Avaliar o Desempenho da Soluo
Sadas usadas tambm por Sadas usadas

tambm por
+

141
Validar a 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).
7.5.6
Partes Interessadas
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.
142

Avaliar o Desempenho da Soluo
7.6
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 Identicados 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.

143
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 necessidade do negcio. 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
144

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.
7.6.6
Partes Interessadas
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.

145
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
8.1.1
Pensamento Analtico e Resoluo de Problemas

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. Denio .2 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 Eccia 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 Denio 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

147
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. .3 Medidas de Eccia 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 Denio 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. .3 Medidas de Eccia 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.
148

.2 Denio Para definir um problema, necessrio garantir que a natureza do problema claramente compreendida por todas as partes e que questes implcitas tornemse 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. .3 Medidas de Eccia 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 Denio 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. .3 Medidas de Eccia 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.

149
Caractersticas Comportamentais
8.2
8.2.1
Caractersticas Comportamentais
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 Denio 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. .3 Medidas de Eccia 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 Denio 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. .3 Medidas de Eccia Sinais de organizao pessoal incluem: Habilidade do analista de negcios em encontrar informaes.
150

Competncias Fundamentais Finalizao de tarefas dentro do tempo previsto. Eficincia na finalizao do trabalho.
Conhecimento de Negcios
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 Denio 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. .3 Medidas de Eccia 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
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 Denio 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

151
Conhecimento de Negcios 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. .3 Medidas de Eccia 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 Denio 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. .3 Medidas de Eccia 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.
152

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 Denio 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. .3 Medidas de Eccia 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 Denio 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

153
Habilidades de Comunicao
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. .3 Medidas de Eccia 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
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 Denio 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. .3 Medidas de Eccia 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.
154

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 Denio 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. .3 Medidas de Eccia 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 Denio 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.

155
Habilidades de Interao
.3 Medidas de Eccia 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
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 Denio 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. .3 Medidas de Eccia 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.
156

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 Denio 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. .3 Medidas de Eccia 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 Denio 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

157
Aplicativos de Software
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. .3 Medidas de Eccia 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
8.6.1
Aplicativos de Uso Geral
.1 Propsito Analistas de negcios utilizam aplicativos de uso geral para documentar e rastrear requisitos. .2 Denio 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.
158

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. .3 Medidas de Eccia 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.

159
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 Denio 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. .3 Medidas de Eccia 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.
160

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
9.1.1
Denio dos Critrios de Aceite e Avaliao

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.

161
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. Determinar ranqueamento e pontuao .2 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
9.2.1
Benchmarking
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
162

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
9.2.4
Consideraes de uso
.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
9.3.1
Brainstorming
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.

163
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. Sesso .2 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 prdeterminados, 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.
9.3.4
Consideraes de uso
.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.
164

Tcnicas
Anlise de regras de negcio
9.4
9.4.1
Anlise de regras de negcio

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)

165
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.
9.4.4
Consideraes de uso
.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
9.5.1
Dicionrio de dados e glossrio

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
166

Tcnicas
Diagramas de uxos 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 partes interessadas. 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.
9.5.4
Consideraes de uso
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
9.6.1
Diagramas de uxos de dados

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;

167
Diagramas de uxos 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.
9.6.4
Consideraes de uso
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.
168

Tcnicas
Modelagem de dados
Figura 9-1: Diagrama de Fluxo de Dados (Notao de Gane-Sarson)

Pacote de Dados de Entrada do Diagrama Pai (Entrada de Sistema 1)
1
Verbo Substantivado Frase Nominal Processo 1
Pacote de Entrada de Dados Pacote de Sada de Dados
2
Verbo Substantivado Frase Nominal Processo 2
Pacote de Dados de Sada para Diagrama Pai (Sada de Sistema 1)
Depsito de Dados
Figura 9-2: Diagrama de Fluxo de Dados (Notao de Yourdon)

Entrada de Dados Sada de Dados Depsito de Dados
Entidade Externa
Processameto de Dados
9.7
9.7.1
Modelagem de dados
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 EntidadeRelacionamento (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.

169
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 como um retngulo com o nome da entidade O identicador nico da entidade apresentado abaixo do nome da entidade
Entidade 1 Identicador nico Atributo
relacionamento da esquerda para a direita relacionamento da direita para a esquerda
Entidade 2 Identicador nico Atributo
Entidade 3 Identicador nico Atributo 1 Atributo 2
Entidade 4 Identicador nico Chave Estrangeira Atributo Relacionamentos so indicados por uma linha, com smbolos nas pontas para mostrar cardinalidade Cardinalidade
Os atributos da entidade esto listados abaixo do identicador nico
Entidade
Qualquer nmero (zero a muitos)
Entidade
Zero ou Um
Entidade
Somente Um
Entidade
Qualquer nmero de um a muitos
170

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 opcionalmente ter um esteretipo que dene propriedades adicionais. Os relacionamentos so indicados por uma linha que tambm pode mostrar a multiplicidade.
<<Esteretipo>> Classe 1 Atributo 1: Tipo de Dados Atributo 2: Tipo de Dados Operao 1 Operao 2 Operao 3 1
Classe 2 Atributo 1 0..* Atributo 2 Atributo 3 Atributo 4
Os atributos da classe so listados em uma caixa abaixo do nome. Operaes so listadas abaixo dos atributos. Multiplicidade
Classe
Classe
X..Y
Classe
1..*
Classe
Qualquer nmero (zero a muitos)
Deve ser exatamente X
Qualquer nmero de X a Y
Qualquer nmero de um a muitos

171
Anlise de deciso
Tcnicas
9.7.4
Consideraes de uso
.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. Desvantagens .2 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 entendlos e relacionar-se com eles. Termos e definies podem variar o uso em diferentes unidades ou domnios organizacionais.
9.8
9.8.1 9.8.2
Anlise de deciso
Propsito
Apoiar a tomada de deciso em situaes complexas, difceis e incertas.
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.
172

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-nanceiros 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. Escolhas .3 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.

173
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 Evento Incerto Fim
2.1.1 Cenrio A Deciso 2.1 Deciso A 2.1.2 Cenrio B Deciso a ser tomada
Resultado, Probabilidade
2.2 Deciso B
9.8.4
Consideraes de uso
.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.
174

Tcnicas
Anlise de documentos
9.9
9.9.1
Anlise de documentos
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.
9.9.4
Consideraes de uso
.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 ).

175
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
9.10.1
Estimativa
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 apoiamse 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
176

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.
9.10.4
Consideraes de uso
.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.

177
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
9.11.1
Grupos focais
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
178

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.

179
Decomposio funcional
Tcnicas
9.11.4
Consideraes de uso
.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
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 subprocessos 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
180

Tcnicas
Figura 9-6: Diagrama de Decomposio Funcional

Funo
Subfuno 1
Subfuno 2
Processo 1.1 Atividade 1.1.1 Atividade 1.1.2 Atividade 1.1.3
Processo 1.2 Atividade 1.2.1 Atividade 1.2.2
Processo 1.3
Processo 2.1
Processo 2.2 Processo 2.1.1 Processo 2.2.2
Processo 2.3
Processo 2.4
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.
9.12.4
Consideraes de uso
.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.

181
Anlise de interface
Tcnicas
9.13
9.13.1
Anlise de interface
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 identicao 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 identicao 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.
182

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 Denir 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.
9.13.4
Consideraes de uso
.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
9.14.1
Entrevistas
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.

183
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. Identicar 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
184

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 prdefinidas. 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. Seguimento ps-entrevista e conrmao .3 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 esqueceuse 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.

185
Processo de lies aprendidas
Tcnicas
9.14.4
Consideraes de uso
.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 partes interessadas. 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
9.15.1
Processo de lies aprendidas

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.
186

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.
9.15.4
Consideraes de uso
.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
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 partes interessadas.

187
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.
188

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.
9.16.4
Consideraes de uso
.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.

189
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
9.17.1
Anlise de Requisitos No-Funcionais

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 nofuncionais 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 nofuncionais. .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.
190

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 nofuncionais 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.

191
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
9.18.1
Observao
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.
192

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 Conrmao 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.
9.18.4
Consideraes de uso
.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.

193
Modelagem Organizacional .2 Desvantagens Possvel apenas para processos existentes. Pode consumir muito tempo. Pode atrapalhar a pessoa sendo observada.
Tcnicas
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
9.19.1
Modelagem Organizacional
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 partes interessadas.
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
194

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 Funo de Gerncia
Vaga de Funo
Nome do Titular da Funo de Gerncia da rea de Negcios (sem funcionrios)
Nome do Titular da Funo de Funcionrio com relacionamento de subordinao por linha pontilhada
Nome do Titular da Funo de Funcionrio Nome do Titular da Funo de Funcionrio

195
Rastreamento de problemas
Tcnicas
9.19.4
Consideraes de uso
.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. Desvantagens .2 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
9.20.1
Rastreamento de problemas
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.
196

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 IndicadoresChave 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).
9.20.4
Consideraes de uso
.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.

197
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
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.
198

Tcnicas
Figura 9-8: Fluxograma
Raia para o papel

Inicio
Raia para o papel
Tarefa 1
O uxo de trabalho divide-se. As tarefas so executadas em paralelo.
Tarefa 2A
Tarefa 2B
Entrada/ Sada
Fluxo funde-se em uma tarefa
Subprocesso
Deciso
Falso
Tarefa 3
Verdadeiro Pare
Um subprocesso incorpora um outro modelo de processo
Raias so extraociais, mas so uma extenso comum no padro de uxogramas.

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.

199
Tcnicas
Figura 9-9: Diagrama de Atividades
Raia para o papel 1
Raia para o papel 2
Tarefa 1 O uxo de trabalho divide-se. As tarefas so executadas em paralelo.
Tarefa 2A
Tarefa 2B
Fluxo funde-se
Tarefa (I/O)
Subprocesso
Deciso
[falso] [verdadeiro]
Tarefa 3 Um subprocesso 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). 200 Um guia para o Corpo de Conhecimento de Anlise de Negcios
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.
9.21.4
Consideraes de uso
.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.

201
Prototipagem
Tcnicas
9.22
9.22.1
Prototipagem
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.
202

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.
9.22.4
Consideraes de uso
.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.

203
Workshop de requisitos
Tcnicas
9.23
9.23.1
Workshop de requisitos
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
204

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.
9.23.4
Consideraes de uso
.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

205
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
9.24.1
Anlise de riscos
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.
206

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.
9.24.4
Consideraes de uso
.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 tornarse 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.

207
Anlise de Causa-Raiz
Tcnicas
9.25
9.25.1 9.25.2
Anlise de Causa-Raiz
Propsito
O propsito da anlise de causa-raiz determinar a fonte implcita de um problema.
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.
208

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.
9.25.4
Consideraes de uso
.1 Vantagens A anlise de causa-raiz fornece um mtodo estruturado para identificar as causasrazes 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 elementochave para a efetiva anlise de causa-raiz.
9.26
9.26.1
Cenrios e Casos de uso

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

209
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). Ator(es) .2 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. Ps-condies .5 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.
210

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.
9.26.4
Consideraes 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 3
Caso de Uso 4
estende
inclui
Caso de Uso 1 Ator 1
Caso de Uso 2 Pontos de Extenso: Chamar Caso de Uso 3 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 Guia BABOK Verso 2.0
211
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)

Pacote de Dados de Entrada (Entrada de Sistema 1)
0
Nome do Sistema de Negcio
Pacote de Dados de Sada (Sada de Sistema 1)
Agente Externo
Agente Externo
Figura 9-13: Diagrama de Contexto (Notao de Yourdon)
Entidade Externa
Dados de Entrada Dados de Sada
Depsito de Dados
Dados de Sada
Nome do Sistema
Entidade Externa
Dados de Sada
9.27
9.27.1 9.27.2
Modelagem do Escopo
Propsito
Modelos do escopo so usados para descrever o escopo da anlise ou o escopo da soluo.
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.
212

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. Diagrama de Casos de Uso .4 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.
9.27.4
Consideraes de uso
.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.

213
Diagramas de Sequncia
Tcnicas
9.28
9.28.1
Diagramas de Sequncia
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

214 Um guia para o Corpo de Conhecimento de Anlise de Negcios
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
9.29.1
Diagramas de Estados
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
Nome do Estado entrada/ao fazer/atividade sada/ao evento/ao(parmetros)
Estado Final
Evento
Estado
Descreve as coisas que podem acontecer quando o objeto est naquele estado.
Nome do Estado Composto
Eventos causam a mudana de estado do objeto.
Estado
O objeto pode mudar entre estes estados, uma vez que entra em um estado composto.
Estado
Diagramas de Atividades UML so um caso especial de mquinas de estado.

215
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. Transies .2 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.
9.29.4
Consideraes de Uso
.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
9.30.1
Reviso Estruturada
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
216

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

Desempenhado por Autor do documento de requisitos, normalmente o analista de negcios. Uma reviso no deve ser conduzida sem a presena do autor. Documentador Qualquer membro da equipe do projeto que est familiarizado com o projeto pode desempenhar este papel. O autor pode faz-lo. Moderador Um facilitador neutro. Muitas vezes desempenhado por um analista de negcios ou testador. Este papel obrigatrio. melhor que o autor no atue como moderador, embora, muitas vezes, a limitao de recursos o exija. Quando isso ocorre, o risco a falta de objetividade em relao ao documento. Par Um outro analista de negcios que possui experincia na preparao de documentos de requisitos similares. Revisor Qualquer parte interessada. Papel Autor Descrio Responde s perguntas sobre o documento, ouve sugestes e comentrios. Incorpora mudanas no documento aps a sesso de reviso. Pessoa que documenta todas as sugestes, comentrios, questes, preocupaes e perguntas pendentes que surjam durante a reviso. Facilita a sesso de trabalho mantendo os participantes focados em cada parte do documento conforme ela discutida. Verica que todos os participantes revisaram os documentos antes do incio da sesso. Garante que todos os participantes estejam participando da reviso. O par revisa o documento para garantir a aderncia aos padres de boa documentao de requisitos. 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

217
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.
218

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).
9.30.4
Consideraes de Uso
.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
9.31.1
Pesquisa / Questionrio
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.

219
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.
220

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.

221
Anlise SWOT
Tcnicas
9.31.4
Consideraes de uso
.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. Desvantagens .2 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
9.32.1
Anlise SWOT
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.
222

Tcnicas Descrever a questo ou problema em discusso no topo da grade.
Anlise SWOT
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 (Opportunities) Estratgias SO Como a fora do grupo pode ser utilizada para explorar oportunidades potenciais? Estratgias SO so bastante diretas para se implementar. Estratgias WO O grupo pode usar uma oportunidade para eliminar ou mitigar uma fraqueza? A oportunidade garante o desenvolvimento de novas capacidades? Ameaas (Threats) Estratgias ST Como o grupo pode usar as suas foras para eliminar possveis ameaas? As ameaas podem ser transformadas em oportunidades? Estratgias WT O grupo pode se reestruturar para evitar a ameaa? O grupo deveria considerar a sada deste mercado? Estratgias WT envolvem cenrios crticos
Foras (Strengths)
Fraquezas (Weaknesses)

223
Histrias do usurio
Tcnicas
9.32.4
Consideraes de uso
.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
9.33.1
Histrias do usurio
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. Desvantagens .2 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.
224

Tcnicas
Avaliao de fornecedores
9.34
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 nofuncionais (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. Modelos e preos de licenciamento .2 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.

225
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.
9.34.4
Consideraes de uso
.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.
226

Glossrio
Apndice
Abordagem da Anlise de Negcios O conjunto de processos, modelos e atividades que sero usados para desempenhar a anlise de negcios em um contexto especfico. Alocao Veja alocao de requisitos. Alocao de Requisitos O processo de distribuio de requisitos em subsistemas e componentes (ex.: pessoas, hardware e software). Anlise Custo Benefcio Anlise realizada para quantificar e comparar os custos financeiros e nofinanceiros de uma mudana ou da implementao de uma soluo comparados aos benefcios ganhos. Anlise Competitiva Um processo estruturado que captura as principais caractersticas de um mercado para prever as perspectivas de lucratividade a longo prazo e para determinar as prticas dos concorrentes mais significantes. Anlise da Causa-Raiz Anlise da causa-raiz um exame estruturado de um problema identificado para compreender as causas implcitas. Anlise das Partes Interessadas O trabalho para identificar as partes interessadas que podem ser impactadas por uma iniciativa proposta e avaliar os seus interesses e provvel participao. Anlise de Gaps (Lacunas) Uma comparao do estado atual com o estado futuro desejado de uma organizao no intuito de identificar diferenas que precisam ser abordadas.
Anlise de Impacto Uma anlise de impacto avalia os efeitos que uma mudana proposta ter sobre uma parte interessada ou grupo de partes interessadas, projeto ou sistema . Anlise de Oportunidade O processo de examinar novas oportunidades de negcio para aperfeioar o desempenho organizacional. Anlise de Varincia Anlise das discrepncias entre o desempenho planejado e realizado para determinar a magnitude dessas discrepncias e recomendar aes corretivas e preventivas quando necessrio. Anlise de Viabilidade Veja estudo de viabilidade. Anlise de Documentos Anlise de documentos um meio de elicitar requisitos de um sistema existente atravs do estudo da documentao disponvel e da identificao da informao relevante. Anlise de Negcios Anlise de negcios o conjunto de tarefas e tcnicas usadas para atuar como uma ligao entre as partes interessadas, no intuito de compreender a estrutura, polticas e operaes de uma organizao e recomendar solues que capacitam esta organizao a atingir as suas metas. Anlise Decisria Uma abordagem para a tomada de deciso que examina e modela as possveis conseqncias para diferentes decises. Anlise decisria auxilia na tomada da deciso tima sob condies de incerteza.

227
Apndice A: Glossrio Anlise do Campo de Fora Um mtodo grfico para descrever as foras que apoiam e que se opem a uma mudana. Envolve a identificao das foras, descrevendo-as como lados de uma linha (foras de apoio e de oposio) e, ento, estimando a fora total de cada conjunto de foras. Anlise SWOT SWOT um acrnimo em ingls para Foras, Fraquezas, Oportunidades e Ameaas. Trata-se de um modelo usado para compreender fatores influenciadores e apresentar como eles podem afetar uma iniciativa. Analista Um nome genrico para um papel com as responsabilidades de desenvolver e gerenciar requisitos. Outros nomes incluem analista de negcios, integrador de negcios, analista de requisitos, engenheiro de requisitos e analista de sistemas. Analista de Negcios Um praticante da anlise de negcios. rea de Conhecimento Um grupo de tarefas relacionadas que apoiam uma funo-chave da anlise de negcios. Arquitetura Corporativa Arquitetura corporativa uma descrio dos processos de negcio de uma organizao, software e hardware, pessoas, operaes e projetos, e os relacionamentos entre eles. Arquitetura do Negcio Um subconjunto da arquitetura corporativa que define um estado atual ou futuro de uma organizao, incluindo a sua estratgia, suas metas e objetivos, o ambiente interno, atravs de um processo ou viso funcional, o ambiente externo no qual o negcio opera e as partes interessadas afetadas pelas atividades da organizao.
Anlise do Campo de ForaAvaliao rvore de Deciso Um modelo de anlise que prov uma alternativa grfica s tabelas de deciso atravs da ilustrao das condies e aes em sequncia. Associao Um vnculo entre dois elementos ou objetos em um diagrama. Atividade Uma unidade de trabalho desempenhada como parte de uma iniciativa ou processo. Ativos de Processos Organizacionais Todos os materiais usados pelos grupos dentro da organizao para definir, adaptar, implementar e manter os seus processos. Ator Secundrio Um ator que participa, mas que no inicia um caso de uso. Ator(es) Os papis humanos e no-humanos que interagem com o sistema. Atributo Um elemento de dados com um tipo especificado de dado que descreve informao associada com um conceito ou entidade. Atributo de Requisito(s) Metadado relacionado ao requisito usado para auxiliar no desenvolvimento e gerenciamento de requisitos. Atributos de Qualidade O subconjunto de requisitos no-funcionais que descreve propriedades das operaes, desenvolvimento e implantao do software (ex.: desempenho, segurana, usabilidade, portabilidade e testabilidade. Avaliao A avaliao sistemtica e objetiva de uma soluo para determinar seu estado e eficcia no atendimento dos objetivos ao longo do tempo e para identificar meios de aperfeioar a soluo para melhor atender aos objetivos. Veja tambm mtrica , indicador e monitoramento.
228

Avaliao da Prontido OrganizacionalDeclarao do Problema Avaliao da Prontido Organizacional Uma avaliao que descreve se as partes interessadas esto preparadas para aceitar a mudana associada com a soluo e se so capazes de utiliz-la de forma eficaz. Backlog do Produto Um conjunto de histrias do usurio, requisitos ou caractersticas que foram identificados como candidatos para potencial implementao, priorizados e estimados. Benchmarking Uma comparao do custo, tempo, qualidade ou outras mtricas de um processo ou sistema em relao aos das organizaes lderes para identificar oportunidades de melhoria. Brainstorming Brainstorming uma atividade de equipe que procura produzir um amplo ou diverso conjunto de opes atravs da rpida e nocrtica gerao de ideias. Business Case Uma avaliao dos custos e benefcios associados a uma iniciativa proposta. Capacidade Uma funo de organizao que a capacita a atingir uma meta ou objetivo do negcio. Cardinalidade O nmero de ocorrncias de uma entidade em um modelo de dados que esto associadas a uma segunda entidade. Cardinalidade apresentada em um modelo de dados atravs de uma notao especial, nmero (ex.: 1) ou letra (ex.: M significando muitos). Caso de Uso Um modelo de anlise que descreve as tarefas que o sistema ir desempenhar para atores e as metas que o sistema atingir para aqueles atores ao longo do caminho. Casos de Uso Includos Um caso de uso composto de um conjunto de medidas utilizadas por mltiplos casos de uso.
Apndice A: Glossrio
Cenrio Um modelo de anlise que descreve uma srie de aes ou tarefas que respondem a um evento. Cada cenrio uma instncia de um caso de uso. Classe Um descritor para um conjunto de objetos do sistema que compartilham os mesmos atributos, operaes, relacionamentos e comportamentos. Uma classe representa um conceito dentro do sistema sendo desenhado. Quando usado como um modelo de anlise, uma classe ir geralmente tambm corresponder a uma entidade do mundo real. Cdigo
Um sistema de instrues de programao, smbolos e regras usados para representar as instrues para um computador.
Comit de Controle de Mudanas (CCM) Um pequeno grupo de partes interessadas que ir tomar decises relativas disposio e tratamento de mudanas em requisitos. Consumidor Uma parte interessada que utiliza produtos ou servios entregues pela organizao. Corporao Uma unidade organizacional, organizao ou coleo de organizaes que compartilham um conjunto de metas comuns e colaboram para prover produtos e servios especficos para os consumidores. Declarao de Viso (declarao de viso do produto) Uma declarao breve, ou pargrafo, que descreve o porqu, o que e quem de um produto de software desejado, do ponto de vista do negcio. Declarao do Problema Uma breve declarao ou pargrafo que descreve os problemas no estado atual e esclarece como uma soluo bem sucedida se parecer.

229
Apndice A: Glossrio Decomposio Uma tcnica que subdivide um problema em suas partes componentes no intuito de facilitar a anlise e compreender esses componentes. Defeito Uma deficincia em um produto ou servio que reduz a sua qualidade ou varia em relao a um atributo, estado ou funcionalidade desejada. Veja tambm defeito dos requisitos. Defeito de Requisito(s) Um erro nos requisitos causado por requisitos incorretos, incompletos, ausentes ou conflitantes. Desenvolvedor Desenvolvedores so responsveis pela construo de aplicaes de software. reas de expertise incluem linguagens de desenvolvimento, prticas de desenvolvimento e componentes de aplicaes. Diagrama de Atividades Um modelo que ilustra o fluxo de processos e/ou casos de uso complexos, atravs da apresentao de cada atividade junto aos fluxos de informao e atividades concorrentes. Os passos podem ser posicionados em raias para os papis que executam esses passos. Diagrama de Casos de Usos Um tipo de diagrama definido pela UML que captura todos os atores e casos de uso envolvidos com um sistema ou produto. Diagrama de Causa e Efeito Veja diagrama espinha de peixe. Diagrama de Contexto Um modelo de anlise que ilustra o escopo do produto atravs da apresentao do sistema no seu ambiente junto s entidades externas (pessoas e sistemas) que do e recebem do sistema.
DecomposioDomnio Diagrama de Entidade-Relacionamento Um diagrama de entidade-relacionamento uma representao grfica das entidades relevantes de um determinado domnio do problema, os relacionamentos entre elas e os seus atributos. Diagrama de Estados Um modelo de anlise apresentando o ciclo de vida de um dado, entidade ou classe. Diagrama de Mquina de Estados Veja diagrama de estados. Diagrama de Sequncia Um tipo de diagrama que apresenta objetos participando em interaes e as mensagens trocadas entre eles. Diagrama de Transio de Estados Veja diagrama de estados. Diagrama Espinha de Peixe Uma tcnica de diagramao usada na anlise de causa-raiz para identificar causas implcitas de um problema observado e os relacionamentos que existem entre essas causas. Dicionrio de Dados Um modelo de anlise descrevendo as estruturas de dados e atributos necessrios para o sistema. Documento de Requisitos do Negcio Um documento de Requisitos do Negcio um pacote que descreve os requisitos do negcio e das partes interessadas (ele documenta os requisitos de interesse para o negcio ao invs de documentar os atuais requisitos do negcio). Documento de Requisitos do Usurio Um documento de requisitos escrito para um pblico de usurios, descrevendo requisitos do usurio e o impacto das mudanas antecipadas sobre os usurios. Documento de Requisitos Veja pacote de requisitos. Domnio A rea problema sob anlise.
230

Domnio do NegcioEstudo de Viabilidade Domnio do Negcio Veja domnio. Elicitao Uma atividade dentro do desenvolvimento dos requisitos que identifica as fontes de requisitos e ento utiliza tcnicas de elicitao (ex.: entrevistas, prottipos, workshops, estudos de documentao) para reunir requisitos dessas fontes. Engenheiro de Software Veja desenvolvedor. Entidade de Dados Um grupo de informaes relacionadas a ser armazenadas pelo sistema. Entidades podem ser pessoas, papis, lugares, coisas, organizaes, ocorrncias no tempo, conceitos ou documentos. Entrega Qualquer produto ou servio de trabalho nico e verificvel que uma parte concordou em entregar. Entrega Incremental Criao de software funcional em mltiplas liberaes de modo que o produto inteiro entregue em pores ao longo do tempo. Entrevista Uma abordagem sistemtica para extrair informao de uma pessoa ou grupo de pessoas em uma configurao formal ou informal, atravs de perguntas referentes a questes relevantes e da documentao das respostas. Escopo A rea coberta por uma atividade particular ou tpico de interesse. Veja tambm escopo do projeto e escopo da soluo. Escopo da Soluo O conjunto de capacidades que uma soluo deve entregar, no intuito de atender necessidade do negcio. Veja tambm escopo. Escopo do Produto Os recursos e funes que caracterizam um produto, servio ou resultado.
Apndice A: Glossrio Especialista (SME - Subject Matter Expert) Uma parte interessada com expertise especfica em um aspecto do domnio do problema ou potenciais solues alternativas, ou componentes. Especialista em implementao de solues (Implementation SME - Subject Matter Expert) Uma parte interessada que ser responsvel por desenhar, desenvolver e implementar a mudana descrita nos requisitos e que possui conhecimento especializado no que tange construo de um ou mais componentes da soluo. Especialista no Assunto (Domain SME - Subject Matter Expert) Uma pessoa com expertise especfica em uma rea ou domnio sob investigao. Especicao dos Requisitos do Software/Sistema Um documento de requisitos escrito especialmente para especialistas em implementao da soluo, descrevendo requisitos funcionais e no-funcionais. Estratgia de Mitigao de Riscos Veja estratgia de mitigao de riscos dos requisitos Estratgia de Mitigao de Riscos em Requisitos Uma anlise dos riscos associados aos requisitos que gradua os riscos e identifica aes para evit-los ou minimiz-los. Estrutura Analtica do Projeto (EAP) Uma decomposio hierrquica orientada s entregas do trabalho a ser executado pela equipe do projeto para atingir os objetivos do projeto e criar as entregas requeridas. Ela organiza e define o escopo total do projeto. Estudo de Viabilidade Uma avaliao de alternativas propostas para determinar se elas so tecnicamente possveis dentro das restries da organizao e se elas iro entregar os benefcios desejados para a organizao.

231
Apndice A: Glossrio Evento Um evento algo que ocorre e ao qual uma unidade organizacional , sistema ou processo deve responder. Evento do Negcio Um gatilho do sistema que iniciado por humanos. Evento Temporal Um gatilho do sistema que acionado pelo tempo. Extenso de controle A extenso de controle o nmero de empregados sob a responsabilidade direta, ou indireta, de um gestor. Ferramenta de Gerenciamento de Requisitos Uma ferramenta de software que armazena as informaes dos requisitos em uma base de dados, captura os atributos e associaes dos requisitos e facilita o reporte de requisitos. Fornecedor Uma parte interessada que prov produtos ou servios para uma organizao. Funcionalidade Um conjunto coeso de funcionalidade externamente visvel que deve estar alinhado com metas e objetivos do negcio. Cada recurso um agrupamento logicamente relacionado de requisitos funcionais ou de requisitos no-funcionais descritos de forma geral. Garantia da Qualidade Atividades desempenhadas para garantir que um processo ir entregar produtos que atendem a um nvel de qualidade apropriado. Gerente do Projeto A parte interessada convocada pela organizao para gerenciar o trabalho requerido para atingir os objetivos do projeto.
EventoInspeo Glossrio Uma lista de definio dos termos de negcio e conceitos relevantes para a soluo sendo construda ou aperfeioada. Grupo Focal Um grupo focal um meio de extrair idias e atributos a respeito de um produto, servio ou oportunidade especfica em um ambiente de grupo interativo. Os participantes, guiados por um moderador, compartilham suas impresses, preferncias e necessidades. Hierarquia de Dilogo Um modelo de anlise que apresenta os dilogos da interface do usurio arranjados como hierarquias. Histria do Usurio Uma descrio de alto nvel, informal e curta de uma capacidade da soluo que prov valor para uma parte interessada. Uma histria do usurio possui tipicamente uma ou duas frases e prov o mnimo necessrio de informao para permitir que um desenvolvedor estime o trabalho requerido para implement-la. Indicador Um indicador identifica uma medida numrica especfica que indica o progresso no alcance de um impacto, sada, atividade ou entrada. Veja tambm mtrica . Iniciativa Um esforo assumido com uma meta ou objetivo definido. Inspeo Um tipo formal de reviso em pares que utiliza um processo prdefinido e documentado, papis de participantes especficos e a captura de defeitos e mtricas do processo. Veja tambm reviso estruturada.
232

IteraoMetadado Iterao Um processo dentro do qual uma entrega (ou a soluo como um todo) progressivamente elaborada. Cada iterao um mini-projeto autocontido, no qual um grupo de atividades executado, resultando no desenvolvimento de um subconjunto de entregas do projeto. Para cada iterao o time planeja o seu trabalho, realiza o trabalho e verifica a qualidade e completude. (Iteraes podem ocorrer dentro de outras iteraes. Por exemplo, uma iterao de desenvolvimento de requisitos incluiria atividades de elicitao, anlise, especificao e validao). Iterao de Requisitos Uma iterao que define requisitos para um subconjunto do escopo da soluo. Por exemplo, uma iterao de requisitos incluiria: a identificao de uma parte do produto a ser focada, identificao das fontes de requisitos para aquela poro do produto, anlise das partes interessadas e planejamento de como extrair requisitos junto a elas, conduo de tcnicas de elicitao, documentao e validao dos requisitos. Interface Uma fronteira compartilhada entre duas pessoas e/ou sistemas atravs da qual a informao comunicada. Interfaces Externas Interfaces com outros sistemas (hardware, software e humanos) com os quais um sistema proposto ir interagir. Interoperabilidade Habilidade dos sistemas em se comunicar atravs da troca de dados ou de servios. Linha de base Uma viso dos requisitos no momento em que foi revista e acordada como sendo a base para desenvolvimento posterior.
Apndice A: Glossrio Lista de Partes Interessadas, Papis e Designao de Responsabilidade Uma lista das partes interessadas afetadas por uma necessidade do negcio ou soluo proposta e uma descrio das suas participaes em um projeto, ou em outra iniciativa. Lista de Vericao (Checklist) Uma tcnica de controle da qualidade. Elas podem incluir um conjunto padro de elementos de qualidade que os revisores usam para a verificao e validao dos requisitos, ou ser especificamente desenvolvidas para capturar questes que preocupam o projeto. Mapa de Dilogo Um modelo de anlise que ilustra a arquitetura da interface do usurio do sistema. Mapa de Processo Um modelo de negcios que apresenta um processo de negcio nos termos dos passos, fluxos de entrada e sada ao longo de mltiplas funes, organizaes ou cargos. Mapa de Relacionamento Um modelo de negcio que apresenta o contexto organizacional em termos dos relacionamentos que existem ao longo da organizao, dos consumidores externos e fornecedores. Matriz de Rastreabilidade de Requisitos Uma matriz usada para rastrear os relacionamentos dos requistos. Cada coluna na matriz fornece informao dos requisitos e componentes do projeto ou do desenvolvimento de software associados. Meta Veja meta do negcio. Meta do Negcio Um estado ou condio que o negcio deve satisfazer para alcanar a sua viso. Metadado Metadado a informao usada para compreender o contexto e a validao da informao registrada em um sistema.

233
Apndice A: Glossrio Metodologia Um conjunto de processos, regras, modelos e mtodos de trabalho que prescrevem como a anlise de negcios, o desenvolvimento da soluo e a implementao so desempenhados em um contexto particular. Metodologia Orientada ao Planejamento Qualquer metodologia que enfatize o planejamento e a documentao formal do processo usado para conduzir um projeto e os seus resultados. Metodologias orientadas ao planejamento enfatizam a reduo do risco e o controle em detrimento da rpida entrega de uma soluo. Metodologia orientada mudana Uma metodologia que foca na entrega rpida das capacidades da soluo de forma incremental e com o envolvimento direto das partes interessadas para coletar feedback do desempenho da soluo. Mtrica Uma mtrica um nvel quantificvel de um indicador que uma organizao deseja alcanar em um ponto especfico do tempo. Modelagem da Organizao A tcnica de anlise usada para descrever papis, responsabilidades e estruturas existentes dentro de uma organizao. Modelagem Orientada a Objetos Uma abordagem da engenharia de software onde o software formado por componentes que so grupos encapsulados de dados e funes que podem herdar comportamentos e atributos de outros componentes, e onde os componentes se comunicam entre si atravs de mensagens. Em algumas organizaes a mesma abordagem usada para engenharia de negcios para descrever e empacotar os componentes lgicos do negcio. Modelo de Classes Um tipo de modelo de dados que descreve os grupos de informao na forma de classes.
MetodologiaNecessidade(s) Modelo de Dados Um modelo de anlise que descreve a estrutura lgica de dados, independente do desenho dos dados ou dos mecanismos de armazenamento de dados. Modelo de Processo Um modelo visual ou representao do fluxo sequencial e das lgicas de controle de um conjunto de atividades ou aes relacionadas. Modelo de Requisitos Uma representao dos requisitos utilizando texto e diagramas. Modelos de requisitos podem tambm ser chamados de modelos de requisitos do usurio ou modelos de anlise e podem suplementar as especificaes textuais de requisitos. Modelo do Domnio do Negcio Uma viso conceitual de uma corporao, ou parte de uma corporao, com foco nos produtos, entregas e eventos que so importantes para a misso da organizao. O modelo do domnio til para validar o escopo da soluo junto s partes interessadas (tcnica e do negcio). Veja tambm modelo. Modelo do Escopo Um modelo que define as fronteiras de um domnio do negcio ou da soluo. Modelo(s) Uma representao e simplificao da realidade desenvolvida para entregar informao a um pblico especfico, facilitando a anlise, comunicao e entendimento. Monitoramento Monitoramento um processo contnuo de coleta de dados para determinar o quo bem uma soluo est implementada em comparao com os resultados esperados. Veja tambm mtrica e indicador. Necessidade(s) Veja necessidade do negcio.
234

Necessidade(s) do NegcioProcesso de Lies Aprendidas Necessidade(s) do Negcio Um tipo de requisito de negcio de alto nvel que uma declarao de um objetivo do negcio ou um impacto que a soluo dever trazer ao ambiente do negcio. Objetivo Um alvo ou mtrica que uma pessoa ou organizao procura alcanar no intuito de progredir na direo de uma meta . Observao Observao um meio de extrair requisitos atravs da conduo e avaliao do ambiente de trabalho da parte interessada. Opcionalidade Definir se um relacionamento entre entidades em um modelo de dados mandatrio. Opcionalidade apresentada em um modelo de dados atravs de uma notao especial. Organizao Uma unidade autnoma dentro de uma corporao sob o gerenciamento de uma nica pessoa ou comit, com uma fronteira claramente definida, que trabalha na direo de metas e objetivos comuns. Organizaes operam em uma base contnua, diferente de uma unidade organizacional ou uma equipe de projeto, que pode se dispersar, uma vez atingidos seus objetivos. Pacote de Requisitos Um pacote de requisitos um conjunto de requisitos agrupado em um documento ou apresentao para comunicao s partes interessadas. Parte Interessada Uma pessoa ou grupo que possui interesses que podem ser afetados por uma iniciativa ou excercer influncia sobre ela. Patrocinador Uma parte interessada que autoriza ou legitima o esforo para desenvolvimento do produto, atravs da contratao ou pagamento do projeto.
Apndice A: Glossrio Pesquisa Uma pesquisa administra um conjunto de perguntas escritas para as partes interessadas, no intuito de coletar respostas de um grande grupo, em um perodo de tempo relativamente curto. Plano da Anlise de Negcios Uma descrio das atividades planejadas que o analista de negcios ir executar no intuito de desempenhar o trabalho de anlise de negcios envolvido em uma iniciativa especfica. Plano de Comunicao da Anlise de Negcios Uma descrio dos tipos de comunicao que o analista de negcios ir desempenhar durante a anlise de negcios, os receptores dessas comunicaes e a forma pela qual a comunicao deve ocorrer. Plano de Gerenciamento de Requisitos Uma descrio do processo de gerenciamento dos requisitos. Poltica de Negcio Uma poltica de negcio uma diretiva noacionvel que apoia uma meta do negcio. Prazo Um perodo fixo de tempo para alcanar um resultado desejado. Priorizao O processo de determinar a importncia relativa de um conjunto de itens no intuito de determinar a ordem na qual eles sero abordados. Processo Veja processo de negcio. Processo de Lies Aprendidas Uma tcnica de aperfeioamento de processos usada para aprender a respeito de e melhorar um processo ou projeto. Uma sesso de lies aprendidas envolve uma reunio especial na qual a equipe explora o que deu certo, o que deu errado, o que pode ser aprendido da iterao recm-completada e como adaptar os processos e tcnicas antes de continuar ou reiniciar.

235
Apndice A: Glossrio Processo de Negcio Um conjunto de atividades de colaborao definidas particularmente ou em sequncia que so desempenhadas de forma repetvel por uma organizao. Produto Uma soluo ou componente de uma soluo que resultado de um projeto. Produto do Trabalho Um documento ou coleo de notas ou diagramas usados pelo analista de negcios durante o processo de desenvolvimento dos requisitos. Projeto Uma empreitada temporria levada adiante para criar um produto, servio ou resultado nico. Prottipo Uma verso parcial ou preliminar do sistema. Prottipo Descartvel Um prottipo usado para esclarecer rapidamente requisitos da interface usando ferramentas simples, algumas vezes, apenas papel e caneta. Geralmente descartado, uma vez que o sistema final foi desenvolvido. Prottipo Evolucionrio Um prottipo que continuamente modificado e atualizado em resposta ao feedback dos usurios. Prottipo Exploratrio Um prottipo desenvolvido para explorar ou verificar requisitos. Prottipo Horizontal Um prottipo que apresenta uma viso superficial e possivelmente abrangente da funcionalidade do sistema, mas que geralmente no suporta nenhum uso ou interao de fato. Prottipo Vertical Um prottipo que mergulha nos detalhes da interface, da funcionalidade ou de ambos.
Processo de NegcioRegulador Qualidade O grau para o qual um conjunto de caractersticas inerentes preenche os requisitos. Qualidade dos Requisitos Veja validao dos requisitos e verificao dos requisitos. Questionrio Veja pesquisa. Raia A seco horizontal ou vertical de um modelo de processo que apresenta quais atividades so desempenhadas por um ator ou papel particular. Rastreabilidade de Requisitos A habilidade de identificar e documentar a linhagem de cada requisito, incluindo a sua derivao (rastreabilidade para trs), sua alocao (rastreabilidade para frente) e o seu relacionamento com outros requisitos. Regra(s) de Negcio Uma regra de negcio uma diretiva especfica, acionvel e testvel que est sob o controle do negcio e apia uma poltica de negcio. Regra(s) Operativa(s) As regras de negcios que uma organizao escolhe reforar como parte de uma poltica. Elas so destinadas a guiar as aes de pessoas que trabalham dentro do negcio. Elas podem obrigar as pessoas a tomar certas aes, previnir que pessoas tomem certas aes ou prescrever as condies sob as quais uma ao deve ser tomada. Rastreabilidade Veja rastreabilidade dos requisitos. Regulador Uma parte interessada com autoridade legal ou governana sobre a soluo, ou sobre o processo usado para desenvolv-la.
236

Regra EstruturalRestrio Regra Estrutural Regras estruturais determinam quando algo , ou no, verdadeiro ou quando algo se enquadra em certa categoria. Elas descrevem categorizaes que podem mudar ao longo do tempo. Relacionamento Uma associao definida entre conceitos, classes ou entidades. Relacionamentos so usualmente denominados e incluem a cardinalidade da associao. Repositrio Uma instalao virtual ou real onde toda a informao a respeito de um tpico especfico armazenada e est disponvel para consulta. Requisito 1. Uma condio ou capacidade necessria para uma parte interessada para resolver um problema ou atingir um objetivo. 2. Uma condio ou capacidade que deve ser atendida 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. Requisito da Soluo Uma caracterstica de uma soluo que atende aos requisitos do negcio e das partes interessadas. Pode ser subdividido em requisitos funcionais e no-funcionais. Requisito das Partes Interessadas Requisitos das partes interessadas so declaraes das necessidades de uma parte interessada particular ou classe de partes interessadas. Eles 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 entre os requisitos do negcio e as vrias classes de requisitos da soluo. Requisito do Usurio Veja requisito(s) das partes interessadas. Guia BABOK Verso 2.0
Apndice A: Glossrio Requisito(s) Funcional(is) As capacidades do produto, ou coisas que o produto deve fazer pelos seus usurios. Requisitos de Transio Uma classificao dos requisitos que descrevem capacidades que a soluo deve possuir, no intuito de facilitar a transio de um estado corrente da corporao para o estado futuro desejado, mas que no sero mais necessrios uma vez completada a transio. Requisitos Declarados Um requisito articulado por uma parte interessada que no foi analisado, verificado ou validado. Requisitos declarados frequentemente refletem os desejos de uma parte interessada e no a sua real necessidade. Requisito do Negcio Uma necessidade de negcio de nvel mais alto que, quando atendido, permitir que a organizao aumente a receita, evite custos, melhore o servio ou atenda a requisitos regulatrios. Requisitos No-Funcionais Os atributos de qualidade, restries ao desenho e implementao e interfaces externas que o produto deve possuir. Requisitos Validados Requisitos que provaram entregar valor para o negcio e apoiar as metas e objetivos do negcio. Requisitos Vericados Requisitos que apresentaram caractersticas de qualidade de requisitos como sendo coesos, completos, consistentes, corretos, viveis, modificveis, no-ambguos e testveis. Restrio Uma restrio descreve quaisquer limitaes impostas soluo que no suportam as necessidades do negcio ou das partes interessadas.
237
Apndice A: Glossrio
Restrio(es) do NegcioSolicitao de Informao (RFI -Request For Information) Revises Um tipo de reviso em pares, na qual os participantes apresentam, discutem e utilizam o produto do trabalho para encontrar erros. Revises da documentao dos requisitos so usadas para verificar se os requisitos esto corretos. Veja tambm revises estruturadas. Risco Um evento ou condio incerta que, se ocorrer, afetar as metas e objetivos de uma mudana proposta. Servio Trabalho desempenhado em prol de outros. Sesso de Descoberta Veja workshop de requisitos. Sesso de Descoberta de Requisitos Veja workshop de requisitos. Sistema Uma coleo de elementos interrelacionados que interagem para atingir um objetivo. Elementos do sistema podem incluir hardware, software e pessoas. Um sistema pode ser um subelemento (ou subsistema) de outro sistema. Solicitao de Cotao (RFQ Request For Quote) Uma solicitao informal de propostas para fornecedores. Solicitao de Informao (RFI -Request For Information) Um documento de requisitos submetido para solicitar informaes de fornecedores a respeito de um produto ou processo proposto. Uma RFI usada quando a organizao que o redigiu procura comparar diferentes alternativas ou est indecisa em relao s opes disponveis.
Restrio(es) do Negcio Restries do negcio so limitaes colocadas sobre o desenho da soluo pela organizao que precisa da soluo. Restries do negcio descrevem as limitaes das solues disponveis ou um aspecto do estado corrente que no pode ser alterado pela implantao da nova soluo. Veja tambm restrio tcnica . Restries de Design Requisitos do software que limitam as opes disponveis para o desenhista do sistema. Restrio(es) Tcnica(s) Restries tcnicas so limitaes no design de uma soluo que deriva da tecnologia usada na sua implementao. Veja tambm restrio do negcio. Resultado Desejado Os benefcios para o negcio que iro resultar do atendimento necessidade do negcio e o estado final desejado pelas partes interessadas. Retorno Sobre o Investimento Uma medida da lucratividade de um projeto ou investimento. Retrospectiva Veja processo de lies aprendidas. Reviso Estruturada Uma reviso estruturada uma reviso de uma entrega organizada em pares com o objetivo de encontrar erros e omisses. considerada uma forma de garantia de qualidade. Reviso por Pares Uma tcnica de validao na qual um pequeno grupo de partes interessadas avalia uma poro de um produto de trabalho para encontrar erros com o objetivo de aperfeioar a sua qualidade.
238

Solicitao de Proposta (RFP Request for Proposal)Usurio Solicitao de Proposta (RFP Request for Proposal) Um documento de requisitos submetido quando uma organizao est buscando uma proposta formal com os fornecedores. Uma RFP tipicamente requer que as propostas sejam submetidas seguindo um processo especfico e utilizando propostas fechadas, que sero avaliadas em relao metodologia de avaliao formal. Soluo Uma soluo atende a uma necessidade de negcio resolvendo um problema ou permitindo que uma organizao se beneficie de uma oportunidade. Software de Prateleira (COTS Commercial-o-the-Shelf Software) Software desenvolvido e vendido para um mercado particular. Storyboard Veja hierarquia do dilogo e mapa do dilogo. Suporte Operacional Uma parte interessada que auxilia a manter a soluo em funcionamento, seja provendo apoio aos usurios finais (instrutores, help desk) ou mantendo a soluo operacional diariamente (rede e outro suporte tcnico). Suposies Suposies so fatores influenciadores que se acredita serem verdadeiros, mas que ainda no foram confirmados. Tabelas de Deciso Um modelo de anlise que especifica regras ou lgicas de negcio complexas, de forma concisa, em um formato tabular de fcil leitura, especificando todas as condies e aes possveis que precisam ser levadas em conta nas regras de negcio. Tabela de Resposta a Eventos Um modelo de anlise em formato de tabela que define os eventos (ex.: o estmulo de entrada que leva o sistema a acionar alguma funo) e suas respostas.
Apndice A: Glossrio Tcnica Tcnicas alteram a forma com a qual uma tarefa de anlise de negcios desempenhada ou descreve uma forma especfica de sada que uma tarefa pode assumir. Termo de Abertura do Projeto Um documento redigido pelo iniciador ou patrocinador do projeto que formalmente autoriza a existncia de um projeto e fornece ao gerente do projeto a autoridade para aplicar os recursos organizacionais s atividades do projeto. Testador Uma parte interessada responsvel por avaliar a qualidade de, e identificar defeitos em um aplicativo de software. Teste de Aceitao do Usurio Casos de teste que os usurios empregam para julgar se um sistema entregue aceitvel. Cada teste de aceitao descreve um conjunto de entradas do sistema e resultados esperados. Testes Caixa-Preta Testes escritos sem considerao sobre como o software implementado. Esses testes apresentam apenas quais sero as entradas e sadas esperadas. Unidade Organizacional Qualquer associao reconhecida de pessoas no contexto de uma organizao ou corporao. Unied Modeling Language (UML) Uma linguagem no-proprietria de modelagem e especificao usada para especificar, visualizar e documentar entregas para sistemas de software orientados a objetos. Usurio Uma parte interessada, pessoa, dispositivo ou sistema, que acessa direta ou indiretamente um sistema.

239
Apndice A: Glossrio Usurio Final Uma pessoa ou sistema que interage diretamente com a soluo. Usurios finais podem ser humanos que interagem com o sistema, ou sistemas que enviam ou recebem arquivos de dados para, ou, do sistema. Validao O processo de checagem de um produto para garantir que ele satisfaz o seu uso planejado e que atende aos seus requisitos. A validao garante que voc construiu a soluo correta. Veja tambm validao dos requisitos. Validao dos Requisitos O trabalho feito para garantir que os requisitos enunciados apoiam e esto alinhados s metas e aos objetivos do negcio. Vericao 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.
Usurio FinalWorkshop de Requisitos Vericao dos Requisitos O trabalho feito para avaliar os requisitos para garantir que eles esto corretamente definidos e esto em um nvel aceitvel de qualidade. Isso garante que os requisitos esto suficientemente definidos e estruturados para que a equipe de desenvolvimento da soluo possa us-los no desenho, desenvolvimento e implementao da soluo. Workshop de Elicitao Veja workshop de requisitos. Workshop de Requisitos Um workshop de requisitos uma reunio estruturada, na qual um grupo cuidadosamente selecionado de partes interessadas colabora para definir e/ou refinar requisitos sob a orientao de um facilitador habilidoso e neutro.
240

Bibliografia
Apndice
As obras a seguir foram consultadas pelos contribuintes do Guia BABOK durante o desenvolvimento desta verso ou das verses anteriores. Nos casos em que mltiplas edies de uma obra foram consultadas, apenas a edio mais recente est listada. Alm das obras aqui listadas, vrias outras fontes de informaes a respeito de anlise de negcios foram consultadas pelos contribuintes e pelos revisores, ou de alguma forma, influenciaram o desenvolvimento do Guia BABOK, incluindo artigos, white papers, websites, posts em blogs, fruns online, seminrios, oficinas e conferncias. Fora algumas poucas excees, as idias e os conceitos encontrados no Guia BABOK no foram criados para ele ou originados nele. O Guia BABOK uma sntese de dcadas de pesquisa sobre como as organizaes funcionam e sobre os mtodos que podem ser utilizados para identificar potenciais melhorias. Mesmo as obras listadas a seguir so construdas sobre os pensamentos e pesquisas de outrem.
Aaker, David A. 1995. Developing Business Strategies. John Wiley & Sons Inc. Adelman, Sid, Larissa Moss, and Majid Abai. 2005. Data Strategy. Addison-Wesley Professional. Alexander, Ian, and Neil Maiden. 2004. Scenarios,Stories, Use Cases: Through the Systems Development Life-Cycle. John Wiley & Sons Inc. Alexander, Ian, and Richard Stevens. 2002. Writing Better Requirements. Addison-Wesley Professional. Altier, William J. 1999. The Thinking Managers Toolbox: Effective Processes for Problem Solving and Decision Making. Oxford University Press. Ambler, Scott W. 2004. The Object Primer: Agile Model-Driven Development with UML 2.0. Cambridge University Press.
Armour, Frank, and Granville Miller. 2000. Advanced Use Case Modeling: Software Systems. Addison-Wesley Professional. Association of Business Process Management Professionals. 2008. Guide to the Business Process Management Common Body of Knowledge. ABPMP. Baird, Jim, A. Ross Little, Valerie LeBlanc, and Louis Molnar. 2001. Business Requirements Analysis: Applied Best Practices, 4th Edition. The Information Architecture Group. Bechtold, Richard. 2007. Essentials of Software Project Management, 2nd Edition. Management Concepts. Bensoussan, Babette E., and Craig S. Fleisher. 2008. Analysis Without Paralysis: 10 Tools to Make Better Strategic Decisions. FT Press. Berman, Jeff. 2006. Maximizing Project Value: Defining, Managing, and Measuring for Optimal Return. Amacom. Berman, Karen, and Joe Knight. 2008. Financial Intelligence for IT Professionals. Harvard Business School Press. Bittner, Kurt, and Ian Spence. 2002. Use Case Modeling. Addison-Wesley Professional. Boar, Bernard H. 2001. The Art of Strategic Planning for Information Technology. John Wiley & Sons Inc. Boehm, Barry, and Richard Turner. 2003. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional. Brache, Alan P. and Sam Bodley-Scott. 2005. Implementation: How to Transform Strategic Initiatives into Blockbuster Results. McGraw-Hill. Brassard, Michael, Lynda Finn, and Dana Ginn. 2002. The Six SIGMA Memory Jogger II: A Pocketguide of Tools for Six SIGMA Improvement Teams. Goal/QPC.

241
Apndice B: Bibliograa
Bridgeland, David M., and Ron Zahavi. 2008. Business Modeling: A Practical Guide to Realizing Business Value. Morgan Kaufmann. Brooks, Frederick P. 1995. The Mythical ManMonth: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional. Brown, Dan. 2006. Communicating Design: Developing Web Site Documentation for Design and Planning. New Riders Press. Burton, Richard M., Gerardine DeSanctis, and Brge Obel. 2006. Organizational Design: A Stepby-Step Approach. Cambridge University Press. Carkenord, Barbara A. 2009. Seven Steps to Mastering Business Analysis. J. Ross Publishing. Carnegie Mellon University. 1995. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley Professional. Chrissis, Mary Beth, Mike Konrad, and Sandy Shrum. 2006. CMMI: Guidelines for Process Integration and Product Improvement (2nd Edition). Addison-Wesley Professional. Cimperman, Rob. 2006. UAT Defined: A Guide to Practical User Acceptance Testing. Addison-Wesley Professional. Clemen, Robert T. 1996. Making Hard Decisions: An Introduction to Decision Analysis. Wadsworth Publishing Company. Cockburn, Alistair. 2000. Writing Effective Use Cases. Addison-Wesley Professional. Cockburn, Alistair. 2004. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley Professional. Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Addison-Wesley Professional. Constantine, Larry L., and Lucy A.D. Lockwood. 1999. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley Professional. Craig, Malcolm. 2000. Thinking Visually: Business Applications of Fourteen Core Diagrams. Continuum International Publishing Group. Davis, Alan M. 1995. 201 Principles of Software Development. McGraw-Hill, Inc. Davis, Alan M. 2005. Just Enough Requirements Management: Where Software Development Meets Marketing. Dorset House. Demarco, Tom, and Timothy Lister. 2003. Waltzing With Bears: Managing Risk on Software Projects. Dorset House. Denney, Richard. 2005. Succeeding with Use Cases: Working Smart to Deliver Quality. AddisonWesley Professional. Dye, Lowell D., and James S. Pennypacker. 2003. Project Portfolio Management: Selecting and Prioritizing Projects for Competitive Advantage. Ctr for Business Practices. Dymond, Kenneth M. 1995. A Guide to the CMM: Understanding the Capability Maturity Model for Software. Process Inc. U.S. Eckerson, Wayne W. 2005. Performance Dashboards: Measuring, Monitoring, and Managing Your Business. John Wiley & Sons Inc. Eriksson, Hans-Erik, and Magnus Penker. 2000. Business Modeling with UML: Business Patterns at Work. John Wiley & Sons Inc. Fisher, Roger. 1991. Getting to Yes: Negotiating Agreement Without Giving In. Penguin. Fitzpatrick, Jody L, James R Sanders, and Blaine R Worthen. 2003. Program Evaluation: Alternative Approaches and Practical Guidelines. Allyn & Bacon. Forsberg, Kevin, Hal Mooz, and Howard Cotterman. 2005. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems. Wiley. Fowler, Martin. 2003. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Professional. Freedman, Daniel P., and Gerald M. Weinberg. 1990. Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products. Dorset House. Gause, Donald C., and Gerald M. Weinberg. 1989. Exploring Requirements: Quality Before Design. Dorset House.
242

George, Michael L., John Maxey, David T. Rowlands, and Malcolm Upton. 2004. The Lean Six Sigma Pocket Toolbook: A Quick Reference Guide to 70 Tools for Improving Quality and Speed. McGraw-Hill. Goldsmith, Robin F. 2004. Discovering Real Business Requirements for Software Project Success. Artech. Goodpasture, John C. 2001. Managing Projects for Value. Project Management Institute. Gottesdiener, Ellen. 2002. Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley Professional. Gottesdiener, Ellen. 2005. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. Goal/QPC. Gygi, Craig, Neil DeCarlo, and Bruce Williams. 2005. Six Sigma For Dummies. Wiley Publishing, Inc. Hadden, Rita Chao. 2003. Leading Culture Change in Your Software Organization: Delivering Results Early. Management Concepts. Hammer, Michael, and James Champy. 2003. Reengineering the Corporation: A Manifesto for Business Revolution. HarperCollins Publishers. Hammond, John S, Ralph L Keeney, and Howard Raiffa. 1998. Smart Choices. Harvard Business School Press. Harmon, Paul. 2007. Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals. Morgan Kaufmann. Harvard Business Review. 1998. Harvard Business Review on Measuring Corporate Performance. Harvard Business School Press. Harvard Business Review. 2007. Harvard Business Review on Making Smarter Decisions. Harvard Business School Press. Hass, Kathleen B. 2007. The Business Analyst as Strategist: Translating Business Strategies into Valuable Solutions. Management Concepts. Hass, Kathleen B., Don J. Wessels, and Kevin Brennan. 2007. Getting it Right: Business Requirements Analysis Tools and Techniques. Management Concepts Inc. Havey, Michael. 2005. Essential Business Process Modeling. OReilly Media. Hay, David C. 2002. Requirements Analysis: From Business Views to Architecture. Prentice Hall. Hetzel, Bill. 1993. The Complete Guide to Software Testing. Wiley. Hiatt, Jeffrey M., and Timothy J. Creasey. 2003. Change Management. Prosci Research. Hohmann, Luke. 1996. Journey of the Software Professional: The Sociology of Computer Programming. Prentice Hall. Hopkins, Richard, and Kevin Jenkins. 2008. Eating the IT Elephant: Moving from Greenfield Development to Brownfield. IBM Press. Hubbard, Douglas W. 2007. How to Measure Anything: Finding the Value of Intangibles in Business. Wiley. IEEE Computer Society. 1990. IEEE Std. 610-121990: IEEE Standard Glossary of Software Engineering Terminology. Institute of Electrical and Electronics Engineers. IEEE Computer Society. 1998. IEEE Std. 1233 1998: IEEE Guide for Developing System Requirements Specifications . Institute of Electrical and Electronics Engineers. IEEE Computer Society. 1998 . IEEE Std. 830 1998: IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers. IEEE Computer Society. 2004. Guide to the Software Engineering Body of Knowledge, 2004 Version. Institute of Electrical and Electronics Engineers. International Organization for Standardization. 2008. ISO/IEC CD 25010: Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Software and quality in use models Requirements and Evaluation (SQuaRE) Quality Model, Version 0.55. ISO/IEC. Jackson, M. 1995. Software Requirements And Specifications. Addison-Wesley Professional. Jacobson, Ivar, and Pan-Wei Ng. 2004. AspectOriented Software Development with Use Cases. Addison-Wesley Professional.

243
Jalote, Pankaj. 1999. CMM in Practice: Processes for Executing Software Projects at Infosys. Addison-Wesley Professional. Jonasson, Hans. 2007. Determining Project Requirements. Auerbach Publications. Jones, Morgan D. 1998. The Thinkers Toolkit: 14 Powerful Techniques for Problem Solving. Three Rivers Press. Jones, T. Capers. 1998. Estimating Software Costs. McGraw-Hill. Juran, J. M. 1992. Juran on Quality by Design: The New Steps for Planning Quality into Goods and Services. Free Press. Kaplan, Robert S., and David P. Norton. 1996. The Balanced Scorecard: Translating Strategy into Action. Harvard Business School Press. Kessler, Carl, and John Sweitzer. 2007. Outsidein Software Development: A Practical Approach to Building Successful Stakeholder-based Products. IBM Press. Khoshafian, Setrag. 2006. Service Oriented Enterprises. Auerbach Publications. Kit, Edward. 1995. Software Testing In The Real World: Improving The Process. Addison-Wesley Professional. Kotonya, Gerald, and Ian Sommerville. 1998. Requirements Engineering: Processes and Techniques. Wiley. Kotter, John P. 1996. Leading Change. Harvard Business School Press. Kovitz, Benjamin L. 1998. Practical Software Requirements: A Manual of Content and Style. Manning Publications. Larman, Craig. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Prentice Hall. Lauesen, Soren. 2001. Software Requirements: Styles & Techniques. Addison-Wesley Professional. Lawson, Raef, Denis Desroches, and Toby Hatch. 2007. Scorecard Best Practices: Design, Implementation, and Evaluation. Wiley. Leffingwell, Dean, and Don Widrig. 2003. Managing Software Requirements: A Use Case Approach, 2nd Edition. Addison-Wesley Professional. Leffingwell, Dean. 2007. Scaling Software Agility: Best Practices for Large Enterprises. AddisonWesley Professional. Lepsinger, Richard, and Anntoinette D. Lucia. 1999. The Art and Science of Competency Models: Pinpointing Critical Success Factors in Organizations. Jossey-Bass/Pfeiffer. Lowy, Alex. 2007. No Problem. Authorhouse. Maister, David H., Charles H. Green, and Robert M. Galford. 2001. The Trusted Advisor. Free Press. Martin, James. 1989. Information Engineering Book I: Introduction. Prentice Hall. Martin, James. 1990. Information Engineering Book II: Planning & Analysis. Prentice Hall. Martin, James. 1990. Information Engineering Book III: Design and Construction. Prentice Hall. McConnell, Steve. 1996. Rapid Development. Microsoft. Mintzberg, Henry, and James Brian Quinn. 1995. The Strategy Process: Concepts, Context and Cases. Prentice Hall. Morabito, Joseph, Ira Sack, and Anilkumar Bhate. 1999. Organization Modeling: Innovative Architectures for the 21st Century. Prentice Hall. Moss, Larissa T., and Shaku Atre. 2003. Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications. Addison-Wesley Professional. Myers, Glenford J. 2004. The Art of Software Testing, 2nd Edition. Wiley. Nielsen, Jakob. 1993. Usability Engineering. Morgan Kaufmann. Niven, Paul R. 2008. Balanced Scorecard: Stepby-Step for Government and Nonprofit Agencies. Wiley. Object Management Group. 2007. Business Motivation Model (BMM) Specification. Object Management Group, Inc.
244

Object Management Group. 2008. Business Process Maturity Model (BPMM), Version 1.0. Object Management Group, Inc. Object Management Group. 2008. Business Process Modeling Notation, V1.2. Object Management Group, Inc. Ould, Martyn A. 2005. Business Process Management: A Rigorous Approach. Meghan Kiffer Pr. Page-Jones, Meilir. 1988. Practical Guide to Structured Systems Design. Prentice Hall. Paul, Debra, and Donald Yeates. 2006. Business Analysis. British Computer Society. Perry, William E. 2000. Effective Methods for Software Testing, 2nd Edition. John Wiley & Sons. Porter, Michael E. 1980. Competitive Strategy: Techniques for Analyzing Industries and Competitors. Free Press. Porter, Michael. 1985. Competitive Advantage. Free Press. Pressman, Roger S. 2000. Software Engineering: A Practitioners Approach. McGraw-Hill. Project Management Institute. 2008. A Guide to the Project Management Body of Knowledge, 4th Edition. Project Management Institute. Rad, Parviz F., and Ginger Levin. 2002. The Advanced Project Management Office: A Comprehensive Look at Function and Implementation. CRC Press. Roam, Dan. 2008. Back Of The Napkin. Penguin Group. Robertson, Suzanne, and James C. Robertson. 2004. Requirements-Led Project Management: Discovering Davids Slingshot. Addison-Wesley Professional. Robertson, Suzanne, and James C. Robertson. 2006. Mastering the Requirements Process, 2nd Edition. Addison-Wesley Professional. Ross, Jeanne W, Peter Weill, and David C. Robertson. 2006. Enterprise Architecture as Strategy. Harvard Business School Press. Ross, Ronald G. 2003. Principles of the Business Rule Approach. Addison-Wesley Professional. Ross, Ronald G. 2005. Business Rule Concepts Getting to the Point of Knowledge, 2nd Edition. Business Rule Solutions Inc. Ruble, David. 1997. Practical Analysis and Design for Client/Server and GUI Systems. Prentice Hall. Rumbaugh, James, Ivar Jacobson, and Grady Booch. 2004. The Unified Modeling Language Reference Manual, 2nd Edition. Addison-Wesley Professional. Rummler, Geary A., and Alan P. Brache. 1995. Improving Performance: How to Manage the White Space in the Organization Chart. JosseyBass. Scholtes, Peter R. 1997. The Leaders Handbook: Making Things Happen, Getting Things Done. McGraw-Hill. Schwaber, Ken. 2004. Agile Project Management With Scrum. Microsoft. Senge, Peter M. 1990. The Fifth Discipline. Doubleday. Senge, Peter M. 1999. The Dance of Change. Doubleday. Sharp, Alec, and Patrick McDermott. 2001. Workflow Modeling: Tools for Process Improvement and Application Development. Artech House. Sodhi, Jag, and Prince Sodhi. 2001. IT Project Management Handbook. Management Concepts. Sodhi, Jag, and Prince Sodhi. 2003. Managing IT Systems Requirements. Management Concepts. Software Engineering Institute. 2006. CMMI for Development, Version 1.2. Carnegie Mellon University. Software Engineering Institute. 2007. CMMI for Acquisition, Version 1.2. Carnegie Mellon University. Sommerville, Ian, and Pete Sawyer. 1997. Requirements Engineering: A Good Practice Guide. Wiley. Stanford, Naomi. 2007. Guide to Organisation Design: Creating High-Performing and Adaptable Enterprises. Profile Books.

245
Stevens, Richard, Peter Brook, Ken Jackson, and Stuart Arnold. 1998. System Engineering, Coping with Complexity. Pearson Education. Streibel, Barbara J., Brian L. Joiner, and Peter R. Scholtes. 2003. The Team Handbook: Third Edition. Joiner/Oriel Inc. Tarantino, Anthony. 2008. Governance, Risk, and Compliance Handbook: Technology, Finance, Environmental, and International Guidance and Best Practices. Wiley. Tayntor, Christine B. 2005. Successful Packaged Software Implementation. CRC Press. Thayer, Richard H. 1997. Software Engineering Project Management. Wiley-IEEE Computer Society Press. Thayer, Richard H., and Merlin Dorfman. 1996. Software Engineering. Wiley-IEEE Computer Society Press. Thayer, Richard H., and Merlin Dorfman. 1997. Software Requirements Engineering, 2nd Edition. Wiley-IEEE Computer Society Press. Thorp, John, and Fujitsu Consultings Center for Strategic Leadership. 2003. The Information Paradox: Realizing the Business Benefits of Information Technology, Revised Edition. McGraw-Hill. Tockey, Steve. 2004. Return on Software: Maximizing 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 Applied: Building Better Systems Using the Business Rules Approach. Wiley. Ward, John L., and Elizabeth Daniel. 2006. Benefits Management: Delivering Value from IS & IT Investments. Wiley. Weill, Peter, and Jeanne W Ross. 2004. IT Governance. McGraw-Hill Europe. Weinberg, Gerald M. 1998. The Psychology of Computer Programming: Silver Anniversary Edition. Dorset House. White, Stephen A., Derek Miers, and Layna Fischer. 2008. BPMN Modeling and Reference Guide. Future Strategies Inc. Wiegers, Karl E. 2003. Software Requirements, 2nd Edition. Microsoft. Wiegers, Karl E. 2006. More About Software Requirements: Thorny Issues and Practical Advice. Microsoft Press. Wiegers, Karl E. 2007. Practical Project Initiation: A Handbook with Tools. Microsoft. Young, Ralph R. 2001. Effective Requirements Practices. Addison-Wesley Professional. Young, Ralph R. 2004. Requirements Engineering Handbook. Artech House. Yourdon, Edward. 1978. Structured Walkthroughs, 2nd Edition. Yourdon Press.
246

Contribuintes
C.1
C.1.1
Verso 2.0
Comit do Corpo de Conhecimento
Apndice
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 James Baird Jake Calabrese, CBAP Bruce C. Chadbourne, PgMP, PMP Karen Chandler Carrolynn Chang Richard Fox, CBAP Rosemary Hossenlopp Peter Gordon, CBAP Ellen Gottesdiener Monica Jain Cherifa Mansoura Liamani, Ph.D. Karen Little Laura Markey Richard Martin Gillian McCleary William B. Murray Angie Perris, MBA, CBAP, PMP David Wright
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. Guia BABOK Verso 2.0
247
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 James Baird Kurt Bittner Rafael Dorantes Robin F. Goldsmith, JD Ellen Gottesdiener Paul Harmon Dean Leffingwell Gladys S.W. Lam Kent J. McDonald Mark McGregor Meilir Page-Jones James Robertson Suzanne Robertson Ronald G. Ross David Ruble Steve Tockey
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 Betty H. Baker, CBAP B. D. Barnes PhD, PE, PMP, CSSBB Jennifer S. Battan, CBAP Subrahmanya Gupta Boda Craig W. Brown, MPM, CSM Cathy Brunsting Peter Burg, PMP Greg Busby, CBAP Diana Cagle, MBA, CBAP Duncan Cairns Bruce Chadbourne, PgMP, PMP Carrollynn Chang Patricia Chappell, CBAP, MBA Mark Cheek, PMP Charlie Huai-Ling Chng, CBAP Desire Purvis (ne Chu), CBAP Pauline Chung Joseph Da Silva Nitza Dovenspike James Downey, Ph.D., PMP Tamer El-Tonsy, CISA, PRINCE2, ITIL Steve Erlank, BSc, BCom (Hons) Margaret Gaino Ewing, MBA, CBAP Stephanie Garwood, CBAP Joe Goss Karen Gras, CBAP Kwabby Gyasi Bob Hillier, PMP Billie Johnson, CBAP Peter Johnson, CBAP Hans Jonasson, CBAP, PMP Barbara Koenig Steven R. Koss, MBA Douglas Kowalczyk Robert Lam, MBA, ISP Richard Larson, CBAP, PMP Karen Little, CBAP Joy Matthews Perry McLeod, CBAP, PMP Holly M. Meyer Michael Mohammed Brian Monson, PMP Nancy A. Murphy, PMP, CBAP Richard L. Neighbarger, CSQA, CSQE Tony Newport, CBAP Samia Osman Cecilia Rathwell Suzanna Etheridge Rawlins, PMP Helen Ronnenbergh Zoya Roytblat Christopher Ryba
248

Contribuintes
Julian Sammy Keith Sarre, CBAP Laura Schleicher Fred Seip Thomas Slahetka, CBAP Warren Steger Leah Sturm, CBAP James M. Szuch Robin Tucker Krishna Vishwanath A. S. Umashankar
Verso 2.0
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

249
Verso 1.6 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
Contribuintes
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
C.2.1
Verso 1.6
Comit do Corpo de Conhecimento
Kathleen Barret (President) Kevin Brennan, CBAP, PMP (Vice-President, Body of Knowledge (at time of publica t ion) and Chair, Requirements Analysis & Documentation and BA Fundamentals Sub-committees)
250

Contribuintes
Verso 1.6 Barbara Carkenord, MBA, CBAP (Chair, Requirements Communication Subcom mittee 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 Finny Barker Neil Burton Karen Chandler Richard Fox, CBAP Rosemary Hossenlopp Peter Gordon, CBAP Monica Jain Peter Kovaks Chris Matts Laura Markey Patricia Martin Richard Martin Rosina Mete William Murray Harish Pathria Kathleen Person Tony Rice John Slater Mark Tracy Jacqueline Young
C.2.3
Revisores da Verso 1.6 Sharon Aker Betty H. Baker, CBAP Jo Bennett Cathy Brunsting Carrollynn Chang, CBAP Patricia Chappell, CBAP, MBA Pauline Chung Joseph R. Czarnecki Stephanie Garwood, CBAP May Jim, CBAP Day Knez Barb Koenig Robert Lam Cherifa Mansoura Liamani, Ph.D. Gillian McCleary Angie Perris, MBA, CBAP, PMP
Kelly Piechota Howard Podeswa Leslie Ponder Cecilia Rathwell Jennifer Rojek Keith Sarre, CBAP Jessica Gonzalez Solis Jim Subach Diane Talbot Krishna Vishwanath Marilyn Vogt Scott Witt

251

Apndice
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 Capacidades (5.2) no tm equivalncia direta na 1.6.
Tarefa ou Tcnica 1.6

Criao e Manuteno da Arquitetura de Negcios (2.2)

No diretamente abordada na verso 2.0. A Anlise de Negcios em toda empresa, ou em nvel estratgico, ser abordada em uma extenso de rea de aplicao separada. Determinar a Abordagem da Soluo (5.3). Veja tambm o Captulo 9 para algumas das tcnicas referenciadas. Denir o Escopo da Soluo (5.4). O contedo de gerenciamento de projetos nessa tarefa foi removido. Veja tambm o Captulo 9 para algumas das tcnicas referenciadas. Denir o Business Case (5.5) Veja tambm o Captulo 9 para algumas das tcnicas referenciadas. Denir o Business Case (5.5) Anlise de Riscos (9.24) Preparar Pacote de Requisitos (4.4) Comunicar Requisitos (4.5) No diretamente abordada na verso 2.0. A Anlise de Negcios em toda empresa, ou em nvel estratgico, ser abordada em uma extenso de rea de aplicao separada. No tem tarefas diretamente equivalentes.
Conduo dos Estudos de Viabilidade (2.3) Determinao do Escopo do Projeto (2.4)
Preparao do Business Case (2.5) Conduo da Avaliao Inicial dos Riscos (2.6) Preparao do Pacote de Deciso (2.7) Seleo e Priorizao de Projetos (2.8)
Lanamento de Novos Projetos (2.9) Gerenciamento de Projetos por Valor (2.10)
Denir o Business Case (5.5). Na verso 2.0, no h tarefas distintas para reavaliar ou atualizar o trabalho feito por outra tarefa. Estas situaes so tratadas como outra instncia da tarefa original. Avaliar o Desempenho da Soluo (7.6)
Rastreamento de Benefcios do Projeto (2.11)

253
Planejamento e Gerenciamento de Requisitos
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 negcios, que foi transferido para a rea de Conhecimento Planejamento e Monitoramento da Anlise de Negcios. A tarefa P lanejar o Processo de Gerenciamento de Requisitos (2.5) no tem equivalncia 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. No tem equivalncia na verso 2.0.
Denir a Estratgia de Diviso de Trabalho do Analista de Negcios (3.3) Denir Abordagem de Risco de Requisitos (3.4)
No h tarefa diretamente equivalente. Os riscos so identicados atravs de levantamento de atividades e podem ser transmitidos e gerenciados. Veja tcnicas de Rastreamento de Problemas (9.20) e Anlise de Riscos (9.24). Planejar a Abordagem da Anlise de Negcios (2.1) Planejar Atividades da Anlise de Negcios (2.3). Sesso 3.6.3 correspondentes para Planejar a Comunicao da Anlise de Negcios (2.4). Planejar Atividades da Anlise de Negcios (2.3) e Estimativas (9.10) Mltiplas tarefas: veja abaixo Gerenciar o Escopo e os Requisitos da Soluo (4.1) Gerenciar Rastreabilidade dos Requisitos (4.2)
Determinar Consideraes de Planejamento (3.5) Selecionar Atividades de Requisitos (3.6)
Estimar Atividades de Requisitos (3.7)
Gerenciar o Escopo de Requisitos (3.8) Estabelecer Requisitos Bsicos (3.8.1) Estrutura de Requisitos para Rastreabilidade (3.8.2)
254


Identicar Impactos para Sistemas Externos e/ou Outras reas dos Projetos (3.8.3) Identicar as alteraes resultantes de mudanas de requisitos (Gesto de Mudana) (3.8.4) Manter a Aprovao de Escopo (3.8.5) Medir e Relatar as Atividades de Requisitos (3.9)
Elicitao de Requisitos
Avaliar a Prontido Organizacional (7.3)
Gerenciar o Escopo e os Requisitos da Soluo (4.1)
Gerenciar o Escopo e os Requisitos da Soluo (4.1) Gerenciar o Desempenho da Anlise de Negcios (2.6). A discusso de mtricas na tarefa da verso 2.0 explicitamente limitada para atividades de mtricas de anlise de negcios e resultados. Gerenciar o Escopo e os Requisitos da Soluo (4.1)
Gesto de Mudana de Requisitos (3.10)
D.4
Elicitao de Requisitos
O nome desta rea de Conhecimento foi alterado para Elicitao.

Elicitao de Requisitos (4.2)
Tarefa ou Tcnica 2.0 ou Tcnica

Preparar a Elicitao (3.1) Conduzir a Atividade de Elicitao (3.2) Documentar os Resultados da Elicitao (3.3) Conmar Resultados da Elicitao (3.4) Brainstorming (9.3) Anlise de Documentos (9.9) Grupo Focal (9.11) Anlise de Interface (9.13) Entrevista (9.14) Observao (9.18) Prototipao (9.22) Workshop de Requisitos (9.23) No includa na verso 2.0 Pesquisa / Questionrio (9.31)
Brainstorming (4.3) Anlise de Documentos (4.4) Grupo Focal (4.5) Anlise de Interface (4.6) Entrevista (4.7) Observao (4.8) Prototipao (4.9) Workshop de Requisitos (4.10) Engenharia Reversa (4.11) Pesquisa / Questionrio (4.12)

255
Documentao e Anlise de Requisitos
D.5
Documentao e Anlise de Requisitos

O nome desta rea de Conhecimento foi alterado para Anlise de Requisitos. Priorizar Requisitos (6.1) no tem equivalncia direta na 1.6.

Estrutura de Pacotes de Requisitos (5.2)

O propsito desta tarefa est estritamente relacionado com Organizar Requisitos (6.2), mas o contedo real est mais prximo de Decomposio Funcional (9.12). Organizar Requisitos (6.2) e Especicar e Modelar Requisitos (6.3) Organizar Requisitos (6.2) e Especicar e Modelar Requisitos (6.3) Organizar Requisitos (6.2) e Especicar e Modelar Requisitos (6.3) Organizar Requisitos (6.2), Especicar e Modelar Requisitos (6.3) e Anlise de Requisitos No-Funcionais (9.17) Denir Suposies e Restries (6.4) 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 Especicar e Modelar Requisitos (6.3). Preparar Pacote de Requisitos (4.4) Validar Requisitos (6.6) Vericar Requisitos (6.5) Nenhuma tcnica equivalente para este agrupamento. Muitas das tcnicas individuais esto presentes na verso 2.0, conforme descrito abaixo: Anlise de Regras de Negcios (9.4) Modelagem de Dados (9.7) No est descrito na verso 2.0 Dicionrio de Dados e Glossrio (9.5) Denir Requisitos de Transio (7.4) Modelagem de Dados (9.7) Modelagem de Dados (9.7)
Criar o Modelo de Domnio do Negcio (5.3)
Analisar Requisitos de Usurio (5.4)
Analisar Requisitos Funcionais (5.5)
Analisar Requisitos de Qualidade de Servios (5.6)
Determinar Suposies e Restries (5.7) Determinar Atributos de Requisitos (5.8)
Documentar Requisitos (5.9) Validar Requisitos (5.10) Vericar Requisitos (5.11) Modelos de Dados e Comportamento (5.12)
Regras de Negcios (5.12.1) Modelos de Classe (5.12.2) Matrix CRUD (5.12.3) Dicionrio de Dados (5.12.4) Transformao de Dados e Mapeamento (5.12.5) Diagrama de Entidade e Relacionamento (5.12.6) Denio de Metadados (5.12.7)
256


Modelo de Fluxo/Processo (5.13)
Comunicao de Requisitos
Nenhuma tcnica equivalente para este agrupamento. Muitas das tcnicas individuais esto presentes na verso 2.0, conforme descrito abaixo: Modelagem de Processos (9.21) Diagrama de Fluxo de Dados (9.6) No descrito na verso 2.0. Os eventos so descritos em relao a uma srie de outras tcnicas e podem ser usados como base para a Modelagem de Escopo (9.27) Modelagem de Processo (9.21) Diagrama de Sequncia (9.28) Diagrama de Estados (9.29) Modelagem de Processos (9.21) Nenhuma tcnica equivalente para este agrupamento. Muitas das tcnicas individuais esto presentes na verso 2.0, conforme descrito abaixo: Prototipao (9.22) Prototipao (9.22) Cenrios e Casos de Uso (9.26) Cenrios e Casos de Uso (9.26). Diagramas de Casos de Uso tambm so usados para Modelagem de Escopo (9.27) Prototipao (9.22) Nenhuma tcnica equivalente direta em 2.0. Esta tcnica estaria dentro da tcnica de Anlise das Partes Interessadas (2.2). Histrias de Usurio (9.33)
Diagrama de Atividade (5.13.1) Diagrama de Fluxo de Dados (5.13.2) Identicao de Evento (5.13.3)
Flowchart (5.13.4) Diagrama de Sequncia (5.13.5) Diagrama de Mquina de Estado (5.13.6) Modelos de Workow (5.13.7) Modelos de Uso (5.14)
Prototipao (5.14.1) Storyboards / Fluxo de Telas (5.14.2) Descrio de Casos de Uso (5.14.3) Diagrama de Casos de Uso (5.14.4)
Projetos de Interface de Usurio (5.14.5) Pers de Usurio (5.14.6)
Histrias de Usurio (5.14.7)
D.6
Comunicao de Requisitos
Esta rea de Conhecimento foi unida com as tarefas de gerenciamento de requisitos, 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.

257

Criar Plano de Comunicao de Requisitos (6.2) Gerenciar Conitos de Requisitos (6.3) Determinar o Formato Apropriado dos Requisitos (6.4) Criar um Pacote de Requisitos (6.5) Realizar uma Apresentao de Requisitos (6.6) Realizar uma Reviso Formal de Requisitos (6.7) Obter Aprovao dos Requisitos (6.8)

Planejar a Comunicao da Anlise de Negcios (2.4) Gerenciar o Escopo e os Requisitos da Soluo (4.1) Planejar a Comunicao da Anlise de Negcios (2.4) e Preparar Pacote de Requisitos (4.4) Preparar Pacote de Requisitos (4.4) Comunicar Requisitos (4.5) Revises Estruturadas (9.30) Gerenciar o Escopo e os Requisitos da Soluo (4.1)
D.7

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) Avaliar Opes de Tecnologia (7.3) Facilitar a Seleo de uma Soluo (7.4) Garantir a Usabilidade da Soluo (7.5) Apoiar o Processo de Garantia da Qualidade (7.6) Apoiar a Implementao da Soluo (7.7) Comunicar o Impacto da Soluo (7.8) Reviso e Avaliao Ps-Implementao (7.9)

Alocar Requisitos (7.2) Avaliar a Soluo Proposta (7.1) Avaliar a Soluo Proposta (7.1) Validar a Soluo (7.5) Validar a Soluo (7.5) Denir Requisitos de Transio (7.4) Avaliar a Prontido Organizacional (7.3) 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 estruturados de forma muito diferente.
258


(BR) Babok 2.0

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

(BR) Babok 2.0

Enviado por

Direitos autorais:

Formatos disponíveis

Um guia para o Corpo de Conhecimento de Anlise de Negcios (Guia BABOK) Verso 2.

Planejamento e Monitoramento da Anlise de Negcios

Gerenciamento e Comunicao dos Requisitos

Guia BABOK Verso 2.0

Avaliao e Validao da Soluo

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Glossrio227 Bibliograa241 Contribuintes247

Sumrio de Mudanas da verso 1.6

Guia BABOK Verso 2.0

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Prefcio da Edio em Lngua Portuguesa

Guia BABOK Verso 2.0

O que o Corpo de Conhecimento de Anlise de Negcios?

O que Anlise de Negcios?

Guia BABOK Verso 2.0

Baseado no IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Guia BABOK Verso 2.0

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Guia BABOK Verso 2.0

Figure 11: Relacionamentos entre as reas de Conhecimento

Anlise Corporativa Elicitao Anlise de Requisitos

Avaliao e Validao da Soluo

Gerenciamento e Comunicao dos Requisitos

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Figura 1-2: Diagramas de Entrada/Sada de Tarefa

Tarefas e reas de Conhecimento

Guia BABOK Verso 2.0

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Figura 1-3: Exemplos de partes interessadas genricas

Suporte operacional Gerente de Projetos Fornecedor Testador Regulador Patrocinador

Guia BABOK Verso 2.0

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Guia BABOK Verso 2.0

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Guia BABOK Verso 2.0

Outras Fontes de Informao sobre Anlise de Negcios

Outras Fontes de Informao sobre Anlise de Negcios

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Guia BABOK Verso 2.0

Planejamento e Monitoramento da Anlise de Negcios

Figura 2-1: Diagrama de Entrada/Sada do Planejamento e Monitoramento da Anlise de Negcios

2.3 Plano(s) da Anlise de Negcios

Ativos de Processos Organizacionais

Guia BABOK Verso 2.0

Planejar a abordagem da Anlise de Negcios

Planejamento e Monitoramento da Anlise de Negcios

Planejar a abordagem da Anlise de Negcios

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Planejamento e Monitoramento da Anlise de Negcios

Planejar a abordagem da Anlise de Negcios

Figura 2-2: Diagrama de Entrada/Sada de Planejar a Abordagem da Anlise de Negcios

2.1 Planejar a Abordagem da Anlise de Negcios

2.1 Abordagem da Anlise de Negcios

Tarefas que usam esta sada

Guia BABOK Verso 2.0

Planejar a abordagem da Anlise de Negcios

Planejamento e Monitoramento da Anlise de Negcios

Um guia para o Corpo de Conhecimento de Anlise de Negcios

Planejamento e Monitoramento da Anlise de Negcios

Planejar a abordagem da Anlise de Negcios

Planejar a abordagem da Anlise de Negcios

Planejamento e Monitoramento da Anlise de Negcios

Planejamento e Monitoramento da Anlise de Negcios

Gerenciamento e Comunicao dos Requisitos

Avaliao e Validao da Soluo

Glossrio227 Bibliograa241 Contribuintes247

Sumrio de Mudanas da verso 1.6