GerenciamentoRequisitos PDF

1
Volume
UNIFIED PROCESS & UNIFIED MODELING LANGUAGE
LABORATRIO DE ENGENHARIA DE SOFTWARE
Gerenciamento de Requisitos
de Software
LABORATRIO DE ENGENHARIA DE SOFTWARE
Gerenciamento de Requisitos de
Software
Leffingwell, Dean & Widrig, Don. Managing Software Requirements: A Unified Approach
Addison-Wesley object technology series, Addison Wesley, 2000. ISBN: 0-201-61593-2
Traduo e Reviso Tcnica

Osvaldo Kotaro Takai,
e-mail: otakai@uol.com.br
ndice
NDICE ........................................................................................................................................................................3
CAPTULO 1...............................................................................................................................................................8
O PROBLEMA DA PEDRA (POR ED YOURDON) ................................................................................................8
CAPTULO 2.............................................................................................................................................................11
INTRODUO AO GERENCIAMENTO DE REQUISITOS ...................................................................................11
Definies.......................................................................................................................................................................11
O que um Requisito?................................................................................................................................................................................. 11
O que o Gerenciamento de Requisitos? .................................................................................................................................................... 11
Aplicao das Tcnicas de Gerenciamento de Requisitos ..................................................................13

Tipos de Aplicaes de Software ................................................................................................................................................................. 13
Aplicaes de Sistemas ................................................................................................................................................................................ 13
O Mapa da Mina ...........................................................................................................................................................14

O Domnio do Problema............................................................................................................................................................................. 14
Necessidades dos Stakeholders .................................................................................................................................................................... 15
Caminhando em Direo ao Domnio da Soluo ....................................................................................................................................... 15
Caractersticas do Sistema ............................................................................................................................................................................ 15
Requisitos de Software................................................................................................................................................................................. 15
Uma Introduo aos Use Cases ................................................................................................................................................................... 16
Resumo ............................................................................................................................................................................16
CAPTULO 3.............................................................................................................................................................17
A EQUIPE DE SOFTWARE ...................................................................................................................................17
Desenvolvimento de Software como uma Atividade de Equipe .........................................................18
Habilidades da Equipe de Requisitos para o Gerenciamento Efetivo de Requisitos .................................................................................... 18
Membros da Equipe possuem Habilidades Distintas ................................................................................................................................... 19
A Organizao da Equipe de Software ........................................................................................................................................................ 19
O Caso de Estudo........................................................................................................................................................20
Escopo do Caso de Estudo ......................................................................................................................................................................... 20
A Equipe de Desenvolvimento do Software HOLIS ................................................................................................................................... 21
Sumrio............................................................................................................................................................................22
HABILIDADE DE EQUIPE 1 .................................................................................................................................23

ANALISANDO O PROBLEMA ...............................................................................................................................23
CAPTULO 4.............................................................................................................................................................25
OS CINCO PASSOS DA ANLISE DO PROBLEMA...........................................................................................25
Passo 1: Chegar ao Acordo sobre a Definio do Problema ................................................................26
A Declarao do Problema .......................................................................................................................................................................... 27
Passo 2: Entender a causa raiz do problema o problema por detrs do problema...............28

Atacando a Causa Raiz................................................................................................................................................................................. 29
Passo 3: Identificar Stakeholders e Usurios..............................................................................................30

Passo 4: Definir a Fronteira da Soluo Sistmica...................................................................................32
Passo 5: Identificar as restries que sero impostas soluo ....................................................34
Sumrio............................................................................................................................................................................36
Vislumbrando o Futuro.............................................................................................................................................36
CAPTULO 5.............................................................................................................................................................38
MODELAGEM DE NEGCIO ................................................................................................................................38
Propsito da Modelagem de Negcio...............................................................................................................39
Usando Tcnicas de Engenharia de Software para Modelar Negcios..........................................39
Escolhendo a Tcnica Correta ..................................................................................................................................................................... 39
A Linguagem de Modelagem Unificada ....................................................................................................................................................... 40
Modelagem de Negcio Usando UML ........................................................................................................................................................ 40
Da Modelagem de Negcio aos Modelos de Sistemas ............................................................................42

Quando Usar a Modelagem de Negcio ..........................................................................................................42
Sumrio............................................................................................................................................................................43
Vislumbrando o Futuro.............................................................................................................................................43
CAPTULO 6.............................................................................................................................................................44
ENGENHARIA DE SISTEMAS DE SOFTWARE INTENSIVOS ...........................................................................44

O que Engenharia de Sistemas? .....................................................................................................................44
Princpios Pragmticos da Engenharia de Sistemas...................................................................................................................................... 45
A Composio e Decomposio de Sistemas Complexos............................................................................................................................ 46
Alocao de Requisitos na Engenharia de Sistemas...............................................................................47

Sobre Requisitos Derivados ......................................................................................................................................................................... 48
Uma Revoluo Silenciosa ........................................................................................................................................................................... 49
Quando as Geraes se Colidem: os Ancies Encontram os Jovens Arrogantes......................................................................................... 49
Evitando o problema do sistema de chamins ............................................................................................................................................. 51
Quando Subsistemas So Subcontratos ....................................................................................................................................................... 51
Fazendo o Trabalho de Corretamente ......................................................................................................................................................... 51
O Caso de Estudo........................................................................................................................................................54
Necessidades Preliminares do Usurio......................................................................................................................................................... 54
Anlise do Problema.................................................................................................................................................................................... 54
HOLIS: O Sistema, Atores e Stakeholders.....................................................................................................56

Engenharia de Sistemas do HOLIS ............................................................................................................................................................. 57
Os Subsistemas do HOLIS.......................................................................................................................................................................... 58
SUMRIO DA HABILIDADE DE EQUIPE 1.......................................................................................................61

HABILIDADE DE EQUIPE 2 .................................................................................................................................62
ENTENDENDO AS NECESSIDADES DOS USURIOS .......................................................................................62
CAPTULO 7.............................................................................................................................................................64
OS DESAFIOS DA ELUCIDAO DE REQUISITOS ..........................................................................................64
Obstculos da Elucidao......................................................................................................................................64
A Sndrome do Sim, Mas ......................................................................................................................................................................... 64
A Sndrome das Runas Desconhecidas......................................................................................................65

A Sndrome Usurio e o Desenvolvedor ......................................................................................................66
Tcnicas de Elucidao de Requisitos ...........................................................................................................67
CAPTULO 8.............................................................................................................................................................68
AS CARACTERSTICAS (FEATURES) DE UM PRODUTO OU SISTEMA ........................................................68
Stakeholders e Necessidades do Usurio .....................................................................................................68
Caractersticas (Features).....................................................................................................................................69
Gerenciando a Complexidade Escolhendo o Nvel de Abstrao ................................................................................................................ 71
Atributos das Caractersticas do Produto..................................................................................................................................................... 71
CAPTULO 9.............................................................................................................................................................73
ENTREVISTA .........................................................................................................................................................73
O Contexto da Entrevista .......................................................................................................................................73
As Questes livres de contexto.................................................................................................................................................................... 73
A Importncia do Contexto da Soluo ..........................................................................................................74

O Momento da Verdade: A Entrevista ..............................................................................................................77
Compilando os Dados de Necessidade (Needs) .........................................................................................77
O Resumo do Analista: 10 + 10 + 10 30.................................................................................................................................................. 78
O Estudo de Caso ....................................................................................................................................................................................... 78
Uma Nota sobre Questionrios ...........................................................................................................................79
CAPTULO 10...........................................................................................................................................................80
WORKSHOPS DE REQUISITOS...........................................................................................................................80
Acelerando o Processo de Deciso...................................................................................................................80
Preparando o Workshop ..........................................................................................................................................81
Vendendo o Conceito.................................................................................................................................................................................. 81
Assegurando a Preparao dos Stakeholders Corretos.........................................................................81

Logsticas ..................................................................................................................................................................................................... 81
Material de Aquecimento ......................................................................................................................................................................... 82
Papel do Facilitador ..................................................................................................................................................84

Preparando a Agenda ...............................................................................................................................................84
Executando o Workshop .........................................................................................................................................85
Problemas e Truques do Ofcio ................................................................................................................................................................... 85
Brainstorming e Reduo de Idias.............................................................................................................................................................. 87
Produo e Continuidade ............................................................................................................................................................................ 88
CAPTULO 11...........................................................................................................................................................89
BRAINSTORMING E A
REDUO DE IDIAS .......................................................................89
Brainstorming Presencial .......................................................................................................................................90

Reduo de Idias......................................................................................................................................................91
Expurgando ................................................................................................................................................................................................. 92
Agrupando Idias ........................................................................................................................................................................................ 92
Definio de Caractersticas......................................................................................................................................................................... 93
Priorizao................................................................................................................................................................................................... 93
Brainstorming Baseado em Web.........................................................................................................................95

O Caso de Estudos: O Workshop de Requisitos do HOLIS 2000.........................................................95
Participantes ................................................................................................................................................................................................ 95
O Workshop................................................................................................................................................................................................ 97
A sesso....................................................................................................................................................................................................... 97
Anlise de Resultados .................................................................................................................................................................................. 98
CAPTULO 12.........................................................................................................................................................100
STORYBOARDING ..............................................................................................................................................100
Tipos de Storyboards..............................................................................................................................................101
O que os Storyboards Fazem ..............................................................................................................................102
Ferramentas e Tcnicas para o Storyboarding.........................................................................................103
Dicas do Storyboarding .........................................................................................................................................103
Sumrio..........................................................................................................................................................................104
CAPTULO 13.........................................................................................................................................................107
APLICANDO USE CASES ..................................................................................................................................107
Construindo o Modelo Use-Case .......................................................................................................................108
Aplicando Use Cases para Elucidao de Requisitos ...........................................................................109
Caso de Estudos: Os Use Cases do HOLIS..................................................................................................110
Sumrio..........................................................................................................................................................................111
CAPTULO 14.........................................................................................................................................................112
ROLE PLAYING ..................................................................................................................................................112
Como Interpretar o Papel .....................................................................................................................................113
Tcnicas Similares ao Role Playing................................................................................................................114
Roteiro de Acompanhamento.................................................................................................................................................................... 114
Cartes CRC (Classe-Responsabilidade-Colaborao) ............................................................................................................................... 114
Sumrio..........................................................................................................................................................................115
CAPTULO 15.........................................................................................................................................................116
PROTOTIPAO .................................................................................................................................................116
Tipos de Prottipos..................................................................................................................................................116
Prottipos de Requisitos.......................................................................................................................................117
O que Prototipar ........................................................................................................................................................118
Construindo o Prottipo ........................................................................................................................................119
Avaliando os Resultados.......................................................................................................................................119
Sumrio..........................................................................................................................................................................120
SUMRIO DA HABILIDADE DE EQUIPE 2.....................................................................................................121

HABILIDADE DE EQUIPE 3 ...............................................................................................................................122
DEFININDO O SISTEMA ....................................................................................................................................122
CAPTULO 16.........................................................................................................................................................125
ORGANIZANDO INFORMAES DE REQUISITOS..........................................................................................125
Organizando Requisitos de Sistemas Complexos de Hardware e Software..............................126
Requisitos de Organizao para Famlia de Produtos...........................................................................129
Sobre os Requisitos Futuros ...........................................................................................................................130
Requisitos de Negcio e de Marketing versus Requisitos de Produto .........................................130
O Caso de Estudos ...................................................................................................................................................131
Sumrio..........................................................................................................................................................................132
CAPTULO 17.........................................................................................................................................................133
O DOCUMENTO DA VISO ...............................................................................................................................133
Componentes do Documento da Viso..........................................................................................................133
O Documento da Viso Delta..........................................................................................................................137
Documento da Viso para o Release 1.0.................................................................................................................................................... 137
Documento da Viso para a Verso 2.0 ..................................................................................................................................................... 138
O Documento da Viso Delta num Ambiente de Sistema Legado ............................................................................................................ 140
CAPTULO 18.........................................................................................................................................................141
O CAMPEO .......................................................................................................................................................141
O Papel do Campeo do Produto ......................................................................................................................141
O Campeo do Produto num Ambiente de Produto de Software .....................................................142
O Campeo do Produto numa Empresa de IS/IT .......................................................................................145

GERENCIANDO O ESCOPO ...............................................................................................................................148
CAPTULO 19.........................................................................................................................................................150
O PROBLEMA DO ESCOPO DE PROJETO .......................................................................................................150
A Difcil Questo........................................................................................................................................................153
CAPTULO 20.........................................................................................................................................................154
ESTABELECENDO O ESCOPO DE PROJETO ..................................................................................................154
O Baseline de Requisitos......................................................................................................................................154
Definindo as Prioridades .......................................................................................................................................155
Avaliando o Esforo.................................................................................................................................................156
Adicionando o Elemento Risco..........................................................................................................................158
Reduzindo o Escopo ................................................................................................................................................159
Uma Estimativa Inicial Razovel ............................................................................................................................................................... 159
O Caso de Estudos ...................................................................................................................................................161
CAPTULO 21.........................................................................................................................................................164
GERENCIANDO O SEU CLIENTE .....................................................................................................................164
Engajando Clientes para Gerenciar Seu Escopo de Projeto ..............................................................164
Comunicando os Resultados ..............................................................................................................................164
Negociando com o Cliente...................................................................................................................................165
Gerenciando o Baseline ........................................................................................................................................166
Mudana Oficial ........................................................................................................................................................................................ 167
Mudana No-oficial ................................................................................................................................................................................. 167
CAPTULO 22.........................................................................................................................................................168
GERENCIAMENTO DE ESCOPO E MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 168
O Modelo Cascata ....................................................................................................................................................168
O Modelo Espiral .......................................................................................................................................................170
A Abordagem Iterativa ...........................................................................................................................................172
Fases do Ciclo-de-Vida .............................................................................................................................................................................. 173
Iteraes .................................................................................................................................................................................................... 173
Workflows ................................................................................................................................................................................................. 174
O que fazer, O que fazer ......................................................................................................................................175

REFINANDO A DEFINIO DO SISTEMA ........................................................................................................177
CAPTULO 23.........................................................................................................................................................179
REQUISITOS DE SOFTWARE ............................................................................................................................179
Captulo 1
O Problema da Pedra (por Ed Yourdon)

Ponto chave
Stakeholder algum que tem interesse no sistema de software que ser desenvolvido, ou
algum que afetado pelo sistema durante ou aps o seu desenvolvimento.
m de meus estudantes resumiu o assunto discutido neste volume como o

problema da pedra. Ela trabalha como engenheira de software num
laboratrio de pesquisa, onde seus clientes de projeto normalmente do a
misso a qual ela descreve como Traga-me uma pedra. Mas quando voc lhe
entrega a pedra, o cliente diz: Sim, mas na verdade, o que eu realmente queria era uma
pequena pedra azul. Ao entregar uma pequena pedra azul, verifica se que o que o cliente
realmente desejava era uma pequena pedra esfrica e azul.
No final, concluiu-se que, o que o cliente estava querendo era uma pequena pedra de
mrmore azul talvez ele no estivesse seguro do que estava querendo, mas um pequeno
mrmore azul! Bem, talvez quem sabe, um pequeno olho de gato azul, de mrmore
tambm teria servido. Provavelmente ele tenha mudado o seu desejo sobre o que queria,
entre a entrega da primeira pedra (grande) e a terceira (pequena e azul).
A cada encontro subseqente com o cliente, comum que o desenvolvedor pergunte:
O que voc quer fazer com isto?. O desenvolvedor fica frustrado porque ele pensou
em algo totalmente diferente quando realizou o rduo trabalho de produzir uma pedra
com as caractersticas prescritas; o cliente fica igualmente frustrado porque, mesmo que
ele tenha encontrado dificuldades para articular o que ele queria, ele est convencido de
que expressou seus desejos claramente. O desenvolvedor apenas no entendeu!
Para complicar mais ainda, em muitos projetos reais, mais que dois indivduos esto
envolvidos. Alm do cliente e o do desenvolvedor que podem, naturalmente, ter
diferentes nomes e ttulos existem provavelmente o pessoal de marketing, o pessoal de
testes e garantia de qualidade, gerentes de produtos, gerente geral, e uma variedade de
stakeholders (envolvidos) que no seu dia-a-dia sero afetados pelo desenvolvimento do
novo sistema.
Todo esse pessoal fica frustrado com o problema de especificar uma pedra aceitvel,
principalmente porque, normalmente, no h tempo suficiente no mundo atual to
competitivo, onde as rpidas mudanas no mundo dos negcios no permitem gastar,
por exemplo, 2 anos no projeto da pedra e, no final, ter que refaz-lo tudo novamente.
Embora existam dificuldades suficientes ao lidamos com artefatos fsicos e tangveis
como a pedra, isso pode se complicar mais ainda. Atualmente, as organizaes de negcio
e agncias governamentais so do tipo informaes-intensivas, de tal forma que,
mesmo que elas nominalmente estejam no negcio de construir e vender pedras, existe
uma boa chance de que a pedra contenha um sistema computacional embutido. Mesmo
que isso no ocorra, existe uma boa chance de que o negcio precise de sistemas
elaborados para manter as informaes sobre as vendas de pedras, clientes que compram
8
pedra, fornecedores, concorrncia, e todas as outras informaes que so necessrias para

manter competitivo o negcio de vendas de pedras via e-commerce.
Os sistemas de software, devido a sua natureza, so intangveis, abstratos, complexos e
teoricamente ao menos esto infinitamente sujeitos a mudanas. Assim, se o cliente
comear a articular requisitos vagos para um sistema de pedras, ele o faz supondo,
normalmente, que ele poder esclarecer, mudar, e fornecer detalhes a posteriori. Seria
maravilhoso se desenvolvedores e quaisquer outras pessoas envolvidas na criao, teste,
implantao, e manuteno do sistema de pedras pudessem realizar esta tarefa em
tempo zero e em custo zero; mas isso no acontece assim.
De fato, isso no acontece nunca: Mais da metade dos projetos de sistemas de software
que esto, atualmente, em andamento, j ultrapassaram substancialmente o custo e o
cronograma previstos, e 25% a 33% desses projetos sero cancelados antes que estejam
finalizados, normalmente aps consumirem grandes somas de dinheiro.
Prevenir tais falhas e fornecer uma abordagem racional para construir sistemas que o cliente deseja
o objetivo deste volume. importante advertir que este volume no trata de assuntos de
programao e, muito menos escrito somente para desenvolvedores de software.
Este volume trata do assunto Gerenciamento de Requisitos para aplicaes de
software complexas. Assim, este volume foi escrito para todos os membros da equipe de
desenvolvimento analistas, desenvolvedores, testers, pessoal da Garantia de Qualidade (QA),
gerentes de projetos, pessoal de documentao, entre outros, assim como para aqueles membros da
equipe de clientes usurios e outros stakeholders, da rea de marketing e gerenciamento enfim,
todos que, de fato, tenham necessidade e desejos de contribuir com a soluo de
requisitos.
Ir se descobrir quo crucial que membros de ambas as equipes, incluindo pessoas
da equipe externa que no so da rea tcnica, dominem as habilidades necessrias
para definir e gerenciar com sucesso o processo de requisitos para o novo sistema
isso por uma nica razo: so eles que criam inicialmente os requisitos e que, no
final, determinam o sucesso ou a falha do sistema. Os programadores heris e
solitrios so figuras do passado: Eles podem descansar em paz.
Uma simples comparao: Um empreiteiro no precisa ser convencido de que so
necessrias vrias conversas, cuidadosamente orquestradas com o dono da casa, para
que no seja construda uma casa com dois quartos, quando o dono queria trs. Mas
igualmente importante que esses requisitos sejam discutidos e negociados com as
autoridades governamentais, responsveis pelo cdigo de construo civil e leis de
zoneamento, e conversar com os moradores das casas vizinhas antes de podar
algumas rvores sob a propriedade onde a casa ser construda.
Os agentes fiscais da construo civil e das leis de zoneamento, bem como os vizinhos
esto entre os stakeholders que, junto com a pessoa que pretende pagar pela casa e morar,
iro determinar se a casa, aps sua construo, atender ao conjunto total de requisitos.
claro, tambm, que muitos stakeholders, tais como vizinhos e agentes fiscais, no sero os
moradores dessa casa (ou usurios do sistema), e parece igualmente bvio que as
perspectivas desses stakeholders sobre o que uma casa (ou sistema) de qualidade pode
variar bastante.
Cozinha
Sala de
Jantar
Sala de
Estar
Sala de
Estudos
Vale ressaltar que, estamos discutindo aplicaes de software neste volume, no

sobre casas e pedras. Os requisitos de uma casa podem ser descritos, ao menos em
parte, por um conjunto de desenhos e projetos de engenharia; da mesma forma, um
sistema de software pode ser descrito com diagramas e modelos. Mas apenas os
desenhos da casa so usados como mecanismo de comunicao e negociao entre
pessoas leigas (advogados, agentes fiscais e vizinhos abelhudos) e engenheiros.
9
Assim, diagramas tcnicos associados ao sistema de software tambm podem ser

criados com o objetivo de permitir que qualquer pessoa possa entend-los.
Muitos requisitos cruciais e importantes no necessitam de quaisquer diagramas; por
exemplo, potenciais compradores da casa podem escrever requisitos em portugus
comum: Minha casa deve ter trs quartos e deve ter uma garagem grande o
suficiente para acomodar dois carros e seis bicicletas. Poder ser verificado, ao
longo deste volume, que requisitos de um sistema de software, em sua grande
maioria, podem ser escritos em portugus comum.
Muitas das habilidades que a equipe precisar para se tornar um especialista, a fim de
vencer desafios, pode tambm ser descrito em termos prticos, como conselhos de
senso comum. Por exemplo, para um novato em construo de casas, o seguinte
conselho poderia ser dado: Assegure-se de conversar com os agentes fiscais antes
de cavar a fundao da casa e no aps preench-lo com cimento, construir paredes
e levantar o teto. Num projeto de desenvolvimento de software, conselhos similares
podem ser fornecidos: Assegure-se de fazer perguntas corretas; assegure-se de
priorizar os requisitos e no permita que clientes lhe digam que 100% dos requisitos
so crticos, porque assim, no dar tempo para finaliz-los antes de prazo previsto.
10
Captulo 2
Introduo ao Gerenciamento de
Requisitos
Pontos chaves
Um requisito uma capacidade que o sistema deve apresentar.
Gerenciamento de requisitos um processo sistemtico de elucidar, organizar e
documentar requisitos de sistemas complexos.
Nosso problema est em entender os problemas dos usurios, sua cultura, sua
linguagem, e construir sistemas que atendam as suas necessidades (need).
Uma caracterstica (feature) um servio que o sistema fornece para atender um
ou mais necessidades dos stakeholders.
Um use case descreve uma seqncia de aes que, quando executada pelo
sistema, produz resultados importantes para o usurio.
ma das 6 Melhores Prticas da Engenharia de Software, Gerenciamento de

Requisitos, justifica o foco no gerenciamento de requisitos. Mas antes de
explanar as vrias tcnicas e estratgias para gerenciar requisitos, necessrio
fornecer algumas definies e exemplos. necessrio definir o que se entende
por requisitos.
Definies
O que um Requisito?
Embora vrias definies para requisitos de software tenham sido usadas durante anos, a
definio dada por Dorfman e Thayer (1990) perfeitamente cabvel:
Uma capacidade que o software que o usurio precisa a fim de resolver um

problema e atingir seu objetivo.
Uma capacidade de software que deve ser atendida ou possuda por um sistema
ou componentes do sistema para satisfazer um contrato, padro, especificao,
ou outros documentos formalmente impostos.
Esta definio pode parecer um tanto vago, mas por ora esta definio ser o suficiente.
O que o Gerenciamento de Requisitos?

Requisitos definem as capacidades que o sistema deve apresentar. Normalmente, a
adequao ou no do sistema ao conjunto de requisitos determina o sucesso ou o fracasso
dos projetos. Assim, importante descobrir quais so os requisitos do sistema, descrevlos, organiz-los, e rastrear os eventos que provocam as suas mudanas. Dessa forma,
define-se Gerenciamento de Requisitos como:
11
Uma abordagem sistemtica de elucidar, organizar e documentar os requisitos do sistema; e

Um processo que estabelece e mantm um contrato entre cliente e a equipe de projeto sobre as
mudanas de requisitos do sistema.
Qualquer um que j tenha se envolvido com o desenvolvimento de sistemas de

software complexo seja na perspectiva de cliente ou de desenvolvedor sabe
que a habilidade mais importante a habilidade de elucidar requisitos de usurios e
stakeholders.
Uma vez que centenas, se no milhares, de requisitos podem estar associados a
um sistema, importante organiz-los.
J que o ser humano no possui a capacidade de manipular mais do que 12 peas
de informaes simultaneamente, importante documentar os requisitos para
garantir a comunicao efetiva entre os vrios stakeholders. Os requisitos devem
ser registrados em algum meio acessvel: documento, modelo, base de dados, ou
em uma lista sobre o quadro negro.
Mas o que isso tm a ver com o gerenciamento de requisitos? O tamanho e a

complexidade de um projeto so os principais fatores aqui: ningum se preocuparia em
gerenciar requisitos num projeto com duas pessoas e que tivesse apenas 10 requisitos para
serem atendidos. Mas ao tentar atender a 1.000 requisitos num pequeno produto de
software a ser adquirido ou a 300.000 requisitos num Boeing 777 torna-se bvio
que surgiro problemas para organizar, priorizar, controlar o acesso, e fornecer recursos
para esses vrios requisitos.
Quais membros da equipe de projeto so responsveis pelo requisito (#278), e

quem tem a permisso de modific-lo ou remov-lo?
Se o requisito #278 for modificado, quais outros requisitos sero afetados?
Como assegurar que os cdigos escritos e respectivos casos de testes,
desenvolvidos para satisfazer o requisito #278, sero plenamente atendidos?
As atividades associadas e que respondem a estas e outras questes so as que constituem

o Gerenciamento de Requisitos.
O Gerenciamento de Requisitos no nada novo, no algo que tenha sido inventada
por mero capricho; ele formado por atividades do senso comum as quais muitas
organizaes de desenvolvimento afirmam realizar de uma forma ou de outra. Mas,
normalmente, realizada de uma maneira informal e persistindo os problemas de um
projeto a outro, e algumas das atividades chaves so provavelmente negligenciadas ou
levemente alteradas devido s presses e polticas associadas maioria dos projetos de
desenvolvimento. Portanto, o gerenciamento de requisitos pode ser entendido como um
conjunto de tcnicas e processos organizados, padronizados e sistematizados com o
objetivo de lidar com requisitos de um projeto significativamente complexo.
Existem vrios esforos no sentido de organizar e formalizar processos, tais como o SEICMM (Software Engineering Institutes Capability Maturity Model) e os padres de
gerenciamento da qualidade ISO 9000. As vises de Gerenciamento de Requisitos da
SEI-CMM e ISO 2000 sero discutidas no Apndice D.
12
Aplicao das Tcnicas de Gerenciamento de

Requisitos
Tipos de Aplicaes de Software
No incio, sugeriu-se que as aplicaes de software podem ser categorizadas como:
Sistemas de informao e outras aplicaes desenvolvidas para serem utilizadas

dentro de uma empresa, tais como Sistemas de Folha de Pagamento utilizados
para calcular o salrio lquido para o prximo ms. Esta categoria a base para a
indstria de sistemas de informao / tecnologia de informao, ou IS/IT
(Information system / information technology).
Software desenvolvido e vendido como produto comercial, tal como o
Processador de Textos utilizado para escrever este captulo. Empresas que
normalmente desenvolvem este tipo de software so chamadas de fornecedores
de software independentes, ou ISV (Independent software vendors).
Software que so executados em computadores embutidos em outros perifricos,
mquinas, ou sistemas complexos, tais como aqueles que esto contidos nos
avies; telefones celulares; e em alguns automveis de luxo. Este tipo de software
chamado de aplicaes de sistemas embutidos, ou simplesmente de aplicaes
embutidas.
A natureza das aplicaes desenvolvidas nestes trs tipos de sistemas extremamente

adversa. Elas podem consistir de 5.000.000 linhas de programas COBOL, executados
num mainframe e desenvolvidos ao longo de muitos anos por 50 a 100 indivduos. Elas
podem consistir de 10.000 linhas de cdigo em Java, executados sobre uma aplicao
cliente Web e escrita em apenas um ano por uma equipe de uma a duas pessoas. Ou elas
podem consistir de 1.000.000 de linhas de cdigo C de tempo extremamente crtico e
executada sobre um sistema de telefonia complexo, de tempo-real.
Pode se afirmar que as tcnicas de Gerenciamento de Requisitos apresentadas neste
volume podem ser aplicadas em qualquer um desses trs tipos de sistemas. Muitas dessas
tcnicas so independentes do tipo de aplicao; outros podem necessitar de um
refinamento para que possam ser aplicadas no contexto especfico da aplicao. Para
elevar o entendimento pelo leitor, sero fornecidos exemplos para ilustrar a aplicao
dessas diversas tcnicas.
Aplicaes de Sistemas
O Gerenciamento de Requisitos pode tambm ser aplicado no desenvolvimento de
quaisquer outros tipos de sistemas. Vrias tcnicas apresentadas neste volume podem ser
teis no gerenciamento de requisitos de sistemas arbitrariamente complexos, contendo
subsistemas mecnicos, subsistemas computacionais, subsistemas qumicos e peas interrelacionadas. Claramente, esta uma disciplina muito ampla e ponderaes devem ser
feitas para que traga resultados teis aos membros das equipes de software. Assim, o foco
estar num processo e nas tcnicas especificas de gerenciamento de requisitos que possam
ser aplicadas diretamente nos trs tipos de aplicaes de software descritos anteriormente:
IS/IT, ISV e sistemas embutidos.
13
O Mapa da Mina
J que foi dada a largada para a jornada de se desenvolver software com qualidade dentro do
prazo e cronograma previstos e que atenda as reais necessidades dos clientes, seria muito til
apresentar um mapa descrevendo este territrio. No ser fcil, uma vez que, durante essa
jornada em particular, diversas pessoas que falam diferentes linguagens podem ser
encontradas pelo caminho. Muitas dvidas iro aparecer:
Isso uma necessidade ou um requisito?

Isso uma coisa que deve ter ou que seria bom ter?
Isso uma declarao do problema ou uma declarao de uma soluo?
Isso um objetivo do sistema ou um requisito contratual?
Ter que ser programado em Java? Ento quem ser o programador?
Quem que no gostou do novo sistema e onde est a pessoa que estava aqui
antes?
A fim de caminhar com segurana atravs desse territrio, ser necessrio conhecer onde
estaremos em alguns pontos do tempo, quem sero as pessoas que encontraremos pelo
caminho, a lngua que eles falam, e que informaes devemos obter dessas pessoas para
completar com sucesso a nossa jornada. A jornada comea na ilha do problema.
O Domnio do Problema
Muitas jornadas de requisitos que obtiveram sucesso comearam com uma visita ilha do
problema. O domnio do problema a casa dos verdadeiros usurios e stakeholders, pessoas
cujas necessidades devem ser atendidas a fim de poder construir o sistema perfeito. a
casa das pessoas que necessitam da pedra, ou de um sistema para dar entrada aos pedidos
de venda, ou um sistema de gerenciamento de configuraes bom o suficiente para
vencer a concorrncia. Provavelmente, essas pessoas no so como ns. As experincias
tcnicas e econmicas so diferentes dos nossos, eles falam siglas engraadas, eles vo a
festas diferentes e tomam bebidas diferentes, eles no vestem camisetas para trabalhar, e
possuem motivaes que so estranhos e impenetrveis. (O qu? Voc no gosta do filme
Star Trek?).
Em raras ocasies, eles so como ns. So programadores procurando por uma nova
ferramenta ou desenvolvedores de sistemas que pediram que voc desenvolvesse uma
parte do sistema. Nesses raros casos, esta parte da jornada talvez seja fcil, mas pode
tambm ser muito mais difcil.
Mas normalmente, esse no o caso, e ns nos encontramos na ilha do usurio
aliengena. Esses usurios tm negcios ou problemas tcnicos que necessitam que ns
ajudemos a resolver. Assim, o nosso problema est em entender o seu problema, dentro de
sua cultura e sua linguagem, para que seja possvel construir o sistema que atenda a suas
necessidades. Como esse territrio pode parecer nublado, o domnio do problema
representado como uma nuvem cinza. Isso foi feito propositadamente para nos lembrar e
nos assegurar de que ns visualizamos claramente todos os casos dentro do espao do
problema.
Domnio do Problema
Dentro do domnio do problema, usamos um conjunto de habilidades de equipe como o

mapa e o compasso para entendermos o problema que ter que ser resolvido. Enquanto
14
estivermos aqui, precisaremos adquirir um entendimento do problema e as necessidades

que devem ser atendidas para atacar esse problema.
Necessidades dos Stakeholders
NVe
eeds
tambm de nossa responsabilidade entender as necessidades dos usurios e de outros

stakeholders cujas vidas sero afetadas pela nossa soluo. Quando ns elucidarmos essas
necessidades, ns os colocaremos numa pequena pilha chamada Needs (necessidades)
dos stakeholders, a qual representamos como uma pirmide.
Caminhando em Direo ao Domnio da Soluo

Felizmente, a jornada atravs do domnio do problema no necessariamente difcil, e os
artefatos no so muitos. No entanto, mesmo com essa pequena quantidade de dados,
esse o trecho da jornada no qual ns devemos estar mais bem preparados para fornecer
uma soluo para o problema. No espao da soluo, ns focalizamos na definio de
uma soluo para o problema do usurio; este o mundo dos computadores,
programao, sistemas operacionais, redes e dispositivos de processamento. Aqui, ns
podemos aplicar diretamente, todas as habilidades que ns aprendemos.
Caractersticas do Sistema
Inicialmente, ser til declarar o que aprendemos no domnio do problema e como
pretendemos resolv-lo atravs da soluo. Isso no muito difcil e deve consistir de
itens como:
O carro ter quadros de potncia

Grficos de anlise de defeitos fornecer um visual significativo para estimar o
progresso
Entrada dos pedidos de vendas via Web
Ciclos de repetio automtica
So descries simples, na linguagem do usurio, as quais sero utilizadas como rtulos

para comunicar ao usurio sobre como o nosso sistema ir atacar o problema. Esses
rtulos se tornaro parte da linguagem diria, e ser gasta muita energia para defini-los,
debat-los e prioriz-los. Ns chamamos esta descrio de features (caractersticas) do
sistema que ser construdo.
Features
Uma feature um servio que o sistema fornece para atender um ou mais necessidades dos
stakeholders.
Graficamente, representamos as caractersticas como a base para pirmide das
necessidades.
Requisitos de Software
Requisitos
de Software
Tendo estabelecido o conjunto de caractersticas em comum acordo com o cliente, ns

partimos para definir os requisitos mais especficos necessrios para a soluo. Se
construirmos um sistema que atenda a esses requisitos, podemos estar certos de que o
sistema que desenvolvemos ir apresentar as caractersticas que prometemos. Uma vez
15
que cada uma dessas caractersticas atenda a um ou mais necessidades dos stakeholders,
teremos atendido todas as necessidades diretamente na soluo.
Esses requisitos mais especficos so os requisitos de software. Representamos esses
requisitos de software da mesma forma que fizemos para representar as caractersticas.
Uma Introduo aos Use Cases
Controlar lmpada
Um construtor chave ir nos ajudar no final de nossa jornada. Este construtor chave o
use case, o qual usamos de vrias maneiras atravs desde volume. De forma simples, um
use case descreve uma seqncia de aes, executadas pelo sistema, e que produz um resultado til
para um usurio. Em outras palavras, um use case descreve uma srie de interaes usuriosistema as quais ajudam o usurio a executar alguma tarefa. Representamos o use case
como cone oval com o nome do use case. Por exemplo, se quisermos descrever um use
case de acordo com a inteno do usurio de simplesmente acender ou apagar uma
lmpada, ns podemos cham-lo, por exemplo, de Controlar lmpada, e o colocamos
esse nome abaixo do cone oval.
Resumo
Agora, vamos olhar o mapa que acabamos de construir. Na figura 2-1, voc pode ver que
fizemos uma transio sutil, porm importante, em nossa forma de pensar. Ns
caminhamos do domnio do problema, representado pela nuvem, passamos pelas
necessidades que descobrimos do usurio, at chegarmos na definio de um sistema a
qual constitui no domnio da soluo, representado pelas caractersticas do sistema e pelos
requisitos do software, os quais iro dirigir o projeto e a implementao do novo sistema.
Mais ainda, fizemos de tal forma que conseguimos assegurar que entendemos o problema
e as necessidades do usurio antes de antever ou definir a soluo. Este mapa da mina,
junto com suas importantes diferenas, iro continuar a serem importantes durante o
restante deste volume.
Needs
Domnio do Problema
Features
Domnio da Soluo
Figura 2-1 Viso global dos domnios do problema/soluo
16
Captulo 3
A Equipe de Software
A programao de computadores uma atividade de negcio (Weinberg 1971)
Pontos chaves
O gerenciamento de requisitos afeta todos os membros da equipe, embora de
maneiras diferentes.
O gerenciamento efetivo de requisitos somente poder ser realizado por uma
equipe de software efetiva.
So necessrias seis habilidades de equipes para o gerenciamento de requisitos.
s pessoas optam pela profisso de desenvolver software por razes variadas.

Alguns lem a revista Popular Science e Popular Mechanics em casa, realizam cursos
de programao de computadores no colgio, estudam Engenharia ou Cincia
da Computao na faculdade e por isso, direcionam suas vidas para seguir
especificamente o caminho da tecnologia. Para outros, devido capacidade de
demonstrar e de realizar descobertas; encontraram um lugar no tempo e no espao
quando a necessidade por software era premente; e acabaram por se comprometer,
gradualmente, com esta rea em tempo integral.
Em muitos casos, a atrao por tecnologia manteve a chama acesa. Ns amamos bits e
bytes, os sistemas operacionais, os bancos de dados, as ferramentas de desenvolvimento,
atalhos de teclado e as linguagens de programao. Quem mais, seno os
desenvolvedores de software, poderiam ter criado o sistema operacional UNIX? Nosso
foco est na tecnologia; essa a nossa motivao. Talvez pela tendncia gentica inata ou
talvez por no ter assistido todas as aulas bobas na faculdade psicologia, sociologia,
ou pior, Portugus! ns geralmente focamos menos nas pessoas de nosso negcio e
muito mais em bits e bytes. Ns tendemos a no participar de festas, e alguns de ns
temos problemas em se relacionar com pessoas fora do trabalho, onde no existe
sustentao tecnolgica comum que possam servir de base para uma discusso.
Como conseqncia desse comportamento, surgiram ferramentas de natureza
monousuria utilizada para desenvolver aplicaes de tamanho limitado, fazendo com
que o desenvolvimento de software se tornasse, cada vez mais, numa atividade individual.
Os programadores definiam, projetavam, escreviam e, normalmente, testavam seus
prprios trabalhos. s vezes, testers eram alocados para ajud-los nessa terrvel tarefa, mas
o foco era, claramente, a atividade individual. Programadores heris era um paradigma
comum.
17
Desenvolvimento de Software como uma

Atividade de Equipe
O Desenvolvimento de Software transformou-se num esporte de equipe. (Booch, 1998)
Em algum ponto, houve a virada. Porqu? Watts Humphrey (1989) observou que:
A histria do
desenvolvimento de
software revela o
aumento em escala.
O processo de
gerenciamento de
requisitos afeta
todos os membros
da equipe, embora
de maneiras
diferentes.
O gerenciamento
efetivo de requisitos
somente pode ser
realizado por uma
equipe de software
efetiva.
a histria do desenvolvimento de software revela o aumento em escala. Inicialmente, alguns

indivduos podiam manipular pequenos programas; o trabalho em pouco tempo cresceu alm de suas
capacidades. Ento, equipes de uma ou duas dzias de pessoas foram usadas, mas o sucesso era
imprevisvel. Ao mesmo tempo em que as organizaes resolviam problemas para pequenos sistemas,
a escala de nossos trabalhos continuaram a crescer. Atualmente, grandes projetos normalmente
necessitam de trabalho coordenado de vrias equipes.
Hamphrey observou que a complexidade ultrapassa a nossa habilidade de resolver
problemas intuitivamente. Por exemplo, estamos envolvidos num projeto de requisitos
que afeta simultaneamente, aproximadamente 30 produtos de uma grande famlia de
produtos. Os requisitos que so gerados influenciam, em tempo real, software que esto
sendo escritos por mais de 400 programadores distribudos em diversas localizaes. O
sucesso deste projeto depende da coordenao intensa de uma equipe de equipes, todas
trabalhando com uma metodologia comum para atender os desafios impostos pelos
requisitos.
O que fazer? Claramente, teremos que trabalhar em equipe e trabalhar bem. Como
Boehm (1981) concluiu em seu modelo de estimativas de custo, COCOMO, a capacidade
da equipe tem grande impacto na produo de software. Davis (1995b) sustenta em sua
discusso sobre produtividade da equipe: otimizar a produtividade de todos os
indivduos no resulta, necessariamente, na otimizao da produtividade da equipe.
(pgina 170). Assim, parece lgico investir algum recurso para tornar a equipe de software
mais produtiva.
Habilidades da Equipe de Requisitos para o Gerenciamento

Efetivo de Requisitos
Este mdulo foi organizado em funo de 6 habilidades de equipe, necessrias para uma
equipe moderna de software enfrentar os desafios de requisitos.
Na Habilidade de Equipe 1, Analisando o Problema, ns desenvolvemos um

conjunto de tcnicas que a equipe pode usar para obter entendimento apropriado
do problema que o novo sistema de software pretende resolver.
Na Habilidade de Equipe 2, Entendendo as Necessidades dos Usurios, ns
introduzimos vrias tcnicas que a equipe pode usar para elucidar requisitos a partir
dos usurios do sistema e stakeholders. Nenhum conjunto de tcnicas ir
funcionar em todas as situaes; nem ser necessrio que a equipe se especialize
em todas as tcnicas. Mas com um pouco de prtica e alguma coerncia nas
selees e escolhas, a equipe ir elevar sua habilidade de entender as reais
necessidades que o sistema dever atender.
Na Habilidade de Equipe 3, Definindo o Sistema, ns descrevemos o processo
inicial pelo qual a equipe converte o entendimento do problema e necessidades
18
dos usurios para uma definio inicial do sistema que dever atender tais
necessidades.
Na Habilidade de Equipe 4, Gerenciamento do Escopo, ns municiamos a
equipe com a habilidade de gerenciar melhor o escopo de um projeto. A final de
contas, no importa quo bem entendamos as necessidades, a equipe no pode
fazer o impossvel, e normalmente ser necessrio negociar o que ser entregue
antes que o sucesso possa ser obtido.
Na Habilidade de Equipe 5, Refinando a Definio do Sistema, ns ajudamos
a equipe a organizar as informaes dos requisitos. Alm disso, ns introduzimos
um conjunto de tcnicas que a equipe pode usar para elaborar a definio do
sistema, ou refin-la at o nvel apropriado para dirigir o projeto e implementao,
tal que toda a equipe conhea exatamente qual tipo de sistema ser construdo.
Finalmente, na Habilidade de Equipe 6, Construindo o Sistema Correto,
cobrimos alguns aspectos mais tcnicos sobre garantia, verificao, validao,
teste e gerenciamento de mudanas de projeto, mostramos como a rastreabilidade
pode ser usada para ajudar a assegurar a qualidade resultante.
Membros da Equipe possuem Habilidades Distintas

Uma das coisas mais interessantes sobre equipes que seus indivduos tm diferentes
habilidades. Afinal de contas, isso que faz de uma equipe uma equipe. Walker Royce
(1998) diz o seguinte:
Equilbrio e cobertura so dois dos aspectos mais importantes para uma equipe de excelncia...
Uma equipe de futebol precisa ter diversas habilidades; assim como uma equipe de
desenvolvimento de software... Raramente uma equipe jogar um bom futebol se no tiver uma
boa cobertura, ataque, defesa e um bom tcnico. Grandes equipes necessitam de cobertura nas
vrias posies chaves, com jogadores adequados para cada posio. Mas uma equipe cheia de
superstars, cada um se esforando para marcar gols e competindo para ser o lder da equipe, pode
ser preocupante para o equilbrio da equipe. Jogadores adequados em cada posio e somente
alguns poucos lderes preocupados com a equipe normalmente vencem o jogo.
Na equipe de software, ns esperamos que alguns jogadores tenham provado suas
habilidades em trabalhar efetivamente com clientes, que outros tenham habilidades de
programao de software, e que outros tenham habilidades para testes. Ainda, outros
jogadores da equipe iro precisar ter a habilidade para projeto e arquitetura. Muitas outras
habilidades so necessrias. Ns esperamos tambm que a habilidade da equipe de
requisitos, em gerenciar requisitos, afete vrios membros da equipe de diversas maneiras.
Assim, de certa forma, ns esperamos desenvolver todas as habilidades individuais da
equipe para ajudar no gerenciamento efetivo de requisitos. Alm disso, tentaremos indicar
onde podemos alocar cada membro da equipe com habilidade particular necessria.
A Organizao da Equipe de Software

O desenvolvimento de software extremamente complexo, e o domnio no qual ns
aplicamos nossas habilidades variam enormemente. Assim, no parece razovel que uma
maneira especfica de organizar uma equipe de software funcione para todos os casos e
nem que seja a mais eficiente do que outras abordagens. Apesar de tudo, certos elementos
comuns ocorrem na maioria das equipes de sucesso. Assim, achamos que seja mais
importante estabelecer uma equipe hipottica. Porm, ao invs de inventarmos uma
equipe ideal, o que seria muito mais fcil e muito acadmico, decidimos modelar nossa
19
equipe hipottica considerando uma equipe de desenvolvimento de software existente no

mundo real.
A equipe que ns iremos modelar baseia-se numa equipe de software do mundo real que
provou ser efetivo em duas grandes reas: (1) efetividade no gerenciamento de requisitos
e (2) cumprimento do cronograma e oramento. (Naturalmente, ns acreditamos que este
seja um relacionamento bvio de causa-efeito!). Alm disso, ns admitimos que muitas
outras habilidades devem estar presentes numa equipe que verdadeiramente cumpram
sempre esses objetivos. Em nosso caso de estudo, a equipe trabalha para a empresa
chamada Lumenations S.A., que ir desenvolver um Sistema de Automao para
Iluminao de Residncias, para uso em residncias de ltima gerao.
O Caso de Estudo
Ns poderemos atingir um outro objetivo neste volume se pudermos desenvolver um
caso de estudo que ns trilhamos a partir dos requisitos iniciais at os requisitos finais.
Assim, estaremos aptos no s a aplicar as tcnicas que estaremos discutindo em nosso
exemplo, mas tambm, em fornecer exemplos dos produtos do trabalho, ou artefatos,
que possam ilustrar os pontos chaves e servir de exemplos para os nossos prprios
projetos. O apndice A deste livro fornece um conjunto de exemplos de artefatos do
nosso caso de estudo.
Escopo do Caso de Estudo

A Lumenations S.A. tem sido, por 40 anos, um fornecedor comercial mundial de sistemas
de iluminao para uso em produes teatrais amadoras e profissionais. Em 1999, seu
rendimento anual atingiu aproximadamente 120 milhes de dlares e as vendas esto
caindo. A Lumenations uma empresa pblica e o baixo crescimento nas vendas no,
pior ainda, a falta de qualquer possibilidade razovel de elevar o crescimento em vendas
est afetando negativamente no valor da empresa e o humor de seus acionistas. A ltima
reunio anual foi um tanto desconfortvel, pois havia poucas novidades relatadas sobre a
perspectiva de crescimento da empresa. O valor de cada ao na ltima primavera havia
chegado a 25 dlares devido a uma enorme quantidade de novos pedidos, mas desde
ento vem vagarosamente caindo, oscilando em torno de 15 dlares.
A indstria de equipamentos para teatros como um todo tem poucos interessados por
novos desenvolvimentos. A indstria encontra-se madura e muito bem consolidada. Uma
vez que as aes da Lumenations esto na reserva e sua capitalizao bastante modesta,
a sua venda no uma opo da empresa.
O que necessrio um novo nicho de mercado, no to distante do que a empresa faz
melhor, mas um que apresente substancial oportunidade de crescimento no rendimento e
lucro. Depois de executado um projeto de pesquisa de mercado e gasto muitos dlares
para pagar consultores de mercado, a empresa decidiu entrar num novo mercado: Sistema
de Automao para Iluminao de Residncias de ltima Gerao. Este mercado
aparentemente est crescendo de 25 a 35% ao ano. Melhor ainda, o mercado imaturo, e
nenhuma empresa j estabelecida ocupa a posio de domnio do mercado. O forte canal
de distribuio mundial da Lumenations ser a real vantagem para ocupar posio no
mercado, e os distribuidores esto vidos por novos produtos. Procurando uma grande
oportunidade!
20
A Equipe de Desenvolvimento do Software HOLIS

O projeto que ns escolhemos desenvolver ser o HOLIS, nosso codinome para o novo
Sistema de Automao de Iluminao Residencial (HOme Lighting automation System)
da Lumenations. O tamanho e escopo da equipe HOLIS normal. Para o propsito do
nosso caso de estudos ns procuramos mant-lo pequeno, composto por apenas 15
pessoas, mas grande o suficiente para cobrir todas as habilidades necessrias
perfeitamente representadas por indivduos com algum grau de especializao em suas
funes. O mais importante a estrutura da equipe, a qual permite adicionar mais
desenvolvedores e testers. A estrutura da equipe HOLIS fornece boa escalabilidade,
permitindo elevar o tamanho da equipe para 30 a 50 pessoas, proporcionalmente muito
maior do que o sistema HOLIS necessita.
Para atender o novo mercado, a Lumenations configurou uma nova diviso, a Diviso de
Automao para Iluminao Residencial. Como a diviso e a tecnologia so novidades
para a Lumenations, a equipe HOLIS foi montada num novo local, embora alguns
poucos membros da equipe tenham sido transferidos da diviso de iluminao comercial.
A figura abaixo ilustra a organizao da equipe de desenvolvimento e as associaes entre
os membros da equipe. Ns visitaremos cada membro da equipe periodicamente no
decorrer deste volume e veremos como eles aplicam suas habilidades para enfrentar os
desafios de requisitos do sistema HOLIS.
Lumenations S.A
Diviso de Automao para Iluminao Residencial
Organizao da Equipe de Software
Emily
VP e GM
Brooke
Diretor de Engenharia
Jack
Lder de QA
Equipe
de
Teste
Louise
Lder de
Doc
Michel
Arquiteto
John
Lder de
Software
Eric
Diretor de Marketing
Pete
Gerente de
Desenvolvimento de
Software
Russ
Lder de
Software
Mike
Lder de
Software
Cathy
Gerente de
Produto
Desenvolvedores
21
Sumrio
difcil para algum racional ir contra a idia de gerenciar e documentar requisitos de um
sistema a fim de assegurar que os resultados iro realmente atender o que o cliente deseja.
No entanto as pesquisas demonstram que, como uma indstria, ns freqentemente
realizamos um trabalho pobre. A falta de retorno dos usurios, requisitos e especificaes incompletas,
e mudanas de requisitos e especificaes so comumente as causas dos problemas citados nos
projetos que falham em atender esses objetivos. E ns sabemos que h um nmero
significativo de projetos de software falham em atender esses objetivos.
Um pensamento comum entre desenvolvedores e clientes : mesmo que ns no
estejamos seguros dos detalhes que queremos, melhor iniciar logo a implementao,
porque estamos atrasados no cronograma e temos pressa. Ns podemos determinar os
requisitos mais tarde. Mas quase sempre esta abordagem, embora bem intencionada,
degenera-se para um esforo de desenvolvimento catico, sem nenhuma segurana sobre
o que o usurio realmente deseja ou o que o sistema, assim construdo, realmente faz.
Com o potencial das ferramentas de prototipao de fcil utilizao, existe a percepo de
que se os desenvolvedores podem construir um rascunho aproximado do que os usurios
desejam num prottipo, o usurio pode indicar as caractersticas que necessitam ser
adicionadas, removidas ou modificadas. Isso pode funcionar, e um importante aspecto
do desenvolvimento interativo. Mas devido em parte ao extremo custo em corrigir erros
de requisitos, este processo precisa fazer parte do contexto global da estratgia de
gerenciamento de requisitos, caso contrrio resultar no caos.
Como saberemos o que o sistema dever fazer? Como manteremos a trilha do estado
atual dos requisitos? Como determinar o impacto de uma mudana? Devido a questes
como essas, o gerenciamento de requisitos comeou a emergir como uma disciplina de
engenharia de software prtica. Ns introduzimos uma filosofia confinada ao
gerenciamento de requisitos e fornecemos um conjunto de definies que sustentam tais
atividades.
Visto que a histria do desenvolvimento de software bem como o futuro, pelo menos
at onde podemos prever revela o aumento em escala, ou seja, a elevao da quantidade
de trabalho com o passar do tempo, podemos entender que o problema do
desenvolvimento de software deve ser atacado por equipes de software bem estruturadas
e treinadas. Na disciplina de gerenciamento de requisitos em particular, todos os
membros da equipe estaro eventualmente envolvidas em atividades que auxiliem o
gerenciamento de requisitos de projeto. Essas equipes devem desenvolver as habilidades
de requisitos para entender as necessidades dos usurios, para gerenciar o escopo da
aplicao, e para construir sistemas que atendam as necessidades desses usurios. A
equipe de requisitos deve trabalhar como uma equipe de futebol vencedora, para enfrentar os
desafios que o gerenciamento de requisitos impem.
A fim de fazer isso, o primeiro passo no processo de gerenciamento de requisitos
assegurar que o desenvolvedor entenda o problema que o usurio est tentando
resolver. Ns iremos cobrir este tpico nos trs prximos captulos: Habilidade de
Equipe 1, Analisando o Problema.
22
Habilidade de Equipe 1
Analisando o Problema
Captulo 4: Os Cinco Passos da Anlise do Problema

Captulo 5: Modelagem de Negcio
Captulo 6: Engenharia de Sistemas Sistemas de Software-Intensivo
23
Problema
Equipes de
desenvolvimento
tendem a avanar
continuamente,
fornecendo solues
baseadas em
entendimentos
inadequados do
problema a ser
resolvido.
Em poucos anos veremos um aumento sem precedentes no poder das ferramentas e

tecnologias que os desenvolvedores de software usaro para construir aplicaes
empresariais. Novas linguagens iro elevar o nvel de abstrao e aumentar a
produtividade de atacar e resolver problemas de usurios. A utilizao de mtodos
orientados a objetos tem produzido projetos que so mais robustos e extensveis.
Ferramentas de gerenciamento de verses, gerenciamento de requisitos, anlise e
projeto, rastreamento de falhas, e testes automatizados, tm ajudado os desenvolvedores
de software a gerenciar a complexidade de milhares de requisitos e centenas de milhares
de linhas de cdigos.
Com a elevao da produtividade dos ambientes de desenvolvimento de software, ser
mais fcil desenvolver sistemas de software que atendam as reais necessidades de
negcio. No entanto, como vimos, as pesquisas demonstram que continuamos sendo
desafiados em entender e satisfazer verdadeiramente essas necessidades. Talvez exista
uma explicao simples para essa dificuldade: o problema por detrs do problema. A equipe
de desenvolvimento gasta muito pouco tempo em entender os reais problemas de negcio, as necessidades
dos usurios e de outros stakeholders, e a natureza do ambiente na qual suas aplicaes devem ter sucesso.
Ns desenvolvedores tendemos a avanar constantemente, fornecendo solues
tecnolgicas baseadas sobre um entendimento inadequado do problema a ser resolvido.
Como esperado, o sistema resultante no atende as necessidades dos usurios e
stakeholders. Entre as conseqncias desse insucesso esto: o baixo retorno financeiro
de clientes e desenvolvedores do sistema, usurios insatisfeitos, e problemas constantes.
Assim, parece bvio que um investimento incremental na anlise do problema ir
produzir resultados gratificantes. O objetivo desta habilidade de equipe fornecer um
guia para a anlise do problema definindo metas para esta habilidade no
desenvolvimento da aplicao.
Nos captulos seguintes iremos explorar maneiras e meios de definir exatamente o que
um problema. Afinal, se sua equipe no puder definir o problema, ser difcil encontrar
uma soluo apropriada.
24
Captulo 4
Os Cinco Passos da Anlise do

Problema
Pontos chaves
A anlise de problemas o processo de entender problemas do mundo real,
entender as necessidades dos usurios e propor solues que satisfaam tais
necessidades.
O objetivo da anlise do problema adquirir maior entendimento do problema
a ser resolvido, antes que se inicie o desenvolvimento.
Para identificar a causa raiz do problema, ou o problema por detrs do
problema, pergunte s pessoas diretamente envolvidas.
Identificar os atores envolvidos no sistema o principal passo da anlise do
problema.
ste captulo descreve as maneiras em que a equipe de desenvolvimento pode

entender as necessidades de stakeholders e usurios de um novo sistema ou
aplicao do mundo real. Uma vez que, na maioria das vezes, sistemas so
construdos para resolver problemas especficos, iremos usar tcnicas de anlise
de problemas para assegurar que entendemos o que o problema.
Mas devemos tambm reconhecer que nem todas as aplicaes so desenvolvidas para
resolver problemas; alguns so construdos para ganhar vantagens sobre oportunidades
que o mercado apresenta, mesmo quando a existncia de um problema no esteja clara.
Por exemplo, aplicaes nicas de software, tais como SimCity e Myst, provaram seu
valor para aqueles que gostam de jogos de computador e desafios mentais, ou para
aqueles que apreciam modelagem e simulao, ou para aqueles que simplesmente querem
se divertir jogando em seus computadores. Portanto, ainda que seja difcil dizer qual o
problema que SimCity e Myst resolvem bem, talvez o problema de no existirem
muitas coisas divertidas para fazer como o seu computador ou o problema de ter
demasiado tempo livre sem ter o que fazer claro que os produtos fornecem real valor
para um grande nmero de usurios.
Nesse sentido, problemas e oportunidades so ambos, os lados de uma mesma moeda;
seu problema minha oportunidade. Isso apenas uma questo de perspectiva. Mas
como muitos sistemas atendem a algum problema identificvel, podemos simplificar a
discusso evitando a esquizofrenia do problema/oportunidade, concentrando-nos em
apenas um dos lados da moeda: o lado do problema. Afinal de contas, gostamos de
pensar que somos os solucionadores de problemas.
Definimos a anlise de problemas como:
o processo de entender problemas do mundo real, entender as necessidades
dos usurios e propor solues que satisfaam tais necessidades.
25
Dito isso, o domnio do problema deve ser analisado e entendido, e uma variedade de
domnios da soluo devem ser explorados. Normalmente, vrias solues so possveis,
e nosso trabalho encontrar a soluo que seja o timo para o problema a ser resolvido.
Para estarmos aptos a realizar a anlise de problemas, ser til definir o que um
problema. De acordo com Gause e Weinberg (1989):
um problema pode ser definido como a diferena entre coisas so desejadas
e coisas que so percebidas.
Essa definio pelo menos elimina o problema de desenvolvedores acharem que o real
problema que o usurio no sabe qual o real problema! De acordo com a definio, se
o usurio percebe algo como problema, esse um real problema digno de ser atacado.
s vezes, a soluo
mais simples uma
soluo de contorno,
ou uma reviso do
processo de negcio,
ao invs de um novo
sistema.
Ainda, com base nesta definio, nosso colega Elemer Magaziner notou que existem
vrias maneiras de se atacar um problema. Por exemplo, mudar o desejo ou percepo do
usurio pode ser a abordagem de melhor custo efetivo. Assim, pode ser uma questo de
ajuste e gerenciamento de expectativas, fornecendo solues de contorno ou
aperfeioamento incremental para sistemas existentes, fornecendo solues alternativas
que no requeiram o desenvolvimento de novos sistemas, ou fornecendo treinamento
adicional. A experincia prtica mostra muitos exemplos onde mudar a percepo da
diferena tem conduzido a solues vantajosas, rpidas, baratas e de altssima qualidade!
Como solucionadores de problemas, estamos incumbidos em explorar essas solues
alternativas antes de saltar para a soluo de um novo sistema.
Todavia, quando a atividade de encontrar uma soluo alternativa para reduzir a diferena
entre o percebido e o desejado falhar, estaremos diante de um grande desafio: o de
efetivamente reduzir a distncia entre o percebido e a realidade. Isso ns devemos realizar
definindo e implementando novos sistemas que reduzam a diferena entre o percebido e o
desejado.
O objetivo da
anlise de problemas
adquirir melhor
entendimento do
problema a ser
resolvido antes de
iniciar o
desenvolvimento.
Como em qualquer exerccio de soluo de problemas complexos, devemos iniciar tendo

um objetivo em mente. O objetivo da anlise de problemas adquirir melhor
entendimento do problema a ser resolvido antes de iniciar o desenvolvimento. Os passos
que devem ser tomados a fim de alcanar esse objetivo so:
1.
2.
3.
4.
5.
Chegar ao acordo sobre a definio do problema.

Entender a causa raiz do problema o problema por detrs do problema.
Identificar os stakeholders e usurios.
Definir a fronteira da soluo sistmica.
Identificar as restries que sero impostas soluo.
Permita-nos trabalhar cada um desses passos e ver se podemos desenvolver as habilidades

de equipe que precisamos para chegar soluo pretendida!
Passo 1: Chegar ao Acordo sobre a Definio

do Problema
O primeiro passo chegar ao acordo sobre a definio do problema as ser resolvido.
Uma maneira simples de chegar a esse acordo simplesmente descrever o problema e ver se todos
concordam.
26
Como parte deste processo, normalmente benfico entender alguns dos benefcios
propostos pela soluo, seja cuidadoso assegurando-se de que os benefcios sejam
descritos utilizando termos fornecidos pelos clientes/usurios. Descries realizadas por
usurios fornecem fundamento contextual adicional ao real problema. Ao ver os
benefcios sob o ponto de vista do cliente, tambm obtemos a um melhor entendimento
do problema do ponto de vista dos stakeholders.
A Declarao do Problema
Voc poder achar til descrever o seu problema num formato padro (Tabela 41). O
preenchimento da tabela, ainda que simples, uma tcnica poderosa para assegurar que
todos os stakeholders do seu projeto estejam trabalhando em direo aos mesmos
objetivos.
Tabela 41
Formato da Declarao do problema
Elementos
O problema
afeta
devido
Os benefcios desse
Descrio
Descrever o problema.
Identificar os stakeholders afetados pelo problema
Descrever o impacto deste problema nos stakeholders e
atividades de negcio.
Indicar a soluo proposta e listar os principais
benefcios.
Gastar tempo para chegar ao acordo sobre o problema a ser resolvido pode parecer um
passo pequeno e insignificante, e em muitas circunstncias, isso verdade. Mas algumas
vezes, no . Por exemplo, um de nossos clientes, um fabricante de equipamentos, foi
realizar uma grande atualizao no seu sistema de informao, o qual realiza o
faturamento e fornece relatrios financeiros entre a empresa e seus fornecedores. O tema
para o novo programa foi aperfeioar comunicaes com fornecedores. Dito isso, a
equipe tinha iniciado um esforo significativo para o desenvolvimento de um novo
sistema.
Um exerccio de como chegar ao acordo sobre o problema a ser resolvido foi realizado. A
equipe de desenvolvimento definiu uma soluo prevendo um novo sistema
poderosssimo que fornecia: relatrios financeiros muito melhores; aperfeioamento do
faturamento e do formato da fatura, tratamento de pedidos online; e e-mail. Ah, a
propsito, a equipe esperava, em algum momento, fornecer a capacidade de transferncia
de fundos eletronicamente entre a empresa e seus fornecedores.
Durante o exerccio de fazer a declarao do problema, a gerncia da empresa tinha a
oportunidade de fornecer informaes. A viso dos gerentes foi substancialmente
diferente. O principal objetivo do novo sistema era transferir fundos eletronicamente para
melhorar o fluxo de caixa da empresa. Depois de uma discusso acalorada, ficou claro que o
principal problema a ser atendido pelo novo sistema era a transferncia eletrnica de
fundos; e-mail e outras caractersticas de comunicao com fornecedores foram
considerados como algo que poderia ter. Desnecessrio dizer que foi uma substancial
reorientao dos objetivos do novo sistema, incluindo uma nova definio do problema
que identifica a transferncia de fundos como principal problema a ser resolvido. Esta
reorientao tambm disparou o desenvolvimento de uma arquitetura diferente daquele
que havia sido previsto, o qual foi completado com a capacidade de segurana consistente
com o risco inerente ao banco eletrnico.
27
Passo 2: Entender a causa raiz do problema o

problema por detrs do problema
Sua equipe pode usar uma variedade de tcnicas para obter um entendimento do real
problema e suas reais causas. Uma dessas tcnicas a anlise causa raiz, a qual uma
forma sistemtica de descobrir a causa raiz, ou a origem, de um problema identificado ou
um sintoma de um problema.
Por exemplo, considere um exemplo do mundo real: uma empresa, chamada
GoodsAreUs, vende produtos atravs de catlogos enviados por e-mail; manufatura e
vende uma variedade de itens baratos para uso residencial e pessoal. Essa empresa,
mobilizada para atacar o problema de baixa lucratividade, utiliza tcnicas de
gerenciamento de qualidade total (TQM) aprendido em seu programa de qualidade, para
solucionar o problema. Baseada em sua experincia, a empresa rapidamente concentrou
seu foco para o custo da no-conformidade, que o custo de todas as coisas que esto erradas
e que geram perdas, detritos, e outros custos excessivos. Este custo inclui o re-trabalho,
detritos, insatisfao de clientes, rotatividade de empregados, e outros fatores que
contribuem negativamente. Quando a empresa quantificou seu custo de noconformidade, suspeitou que as perdas na produo, ou desperdcio, era um dos
principais fatores que contribuam para a baixa lucratividade da empresa.
O prximo passo para descobrir a causa raiz, ou o problema por detrs do problema de
desperdcio, determinar quais fatores contribuem para o problema de desperdcio. O
TQM nos ensina que devemos usar o diagrama espinha de peixe (veja a Figura 41) para
identificar o problema por detrs do problema. Em nossa anlise especfica, a empresa
identificou muitas fontes que contribuam para o desperdcio. Cada fonte foi identificada
em cada um dos ossos do diagrama.
Muito bem, ento como voc determina a causa raiz? Bem, isso depende. Em muitos
casos, isso apenas uma questo de perguntar s pessoas diretamente envolvidas sobre o
que eles acham que a causa raiz. incrvel como a maioria dessas pessoas conhece o
problema por detrs do problema; apenas isso, mais nada pelo que ns entendemos
de gerenciamento sempre pergunte antes. Assim, pergunte e pergunte vrias vezes.
Figura 41
Diagrama espinha de peixe de causa raiz
28
Se o problema mais srio e levianamente ficarmos perguntando o que pode estar

causando o problema, poder gerar um ambiente desconfortvel; pode ser necessrio
realizar uma investigao detalhada de cada causa do problema e quantificar
individualmente seu impacto. Isso pode ser feito utilizando desde um simples
brainstorming com participantes que tenham conhecimento do domnio do problema at
um pequeno projeto de coleta de dados, ou, potencialmente, at uma investigao
cientfica mais rigorosa. Em muitos casos, o objetivo quantificar as contribuies
provveis para cada causa raiz.
Atacando a Causa Raiz

Naturalmente, o engenheiro em todos ns gostaria de corrigir todas as causas razes
identificadas nos ossos do diagrama. Isso parece coisa certa a fazer. Mas mesmo?
Normalmente, no ; informaes da qualidade mostram, com freqncia, que muitas causas razes
no valem a pena serem corrigidas, quando o custo de corrigir excede o custo do problema.
Ento, como vou saber quais causas razes devo corrigir? Resposta: Voc deve determinar a
importncia, ou a contribuio, de cada causa raiz. Os resultados dessa investigao
podem ser colocados num grfico como o de Pareto, ou num simples histograma que
exponha visualmente os verdadeiros culpados.
De volta ao nosso exemplo: Suponha que os resultados dos dados obtidos tenham
produzido o grfico da Figura 42. Como voc pode ver, a equipe descobriu que uma
nica causa raiz pedidos errados produziu a metade de todos os desperdcios. Se,
por sua vez, o sistema de pedidos existente for um exemplo de um cdigo legado ruim,
associado a uma interface de usurio cheia de vcios e no houver tratamento de erros
online, esta pode ser a oportunidade de reduzir o desperdcio atravs do desenvolvimento
de um novo sistema.
neste ponto, e somente neste ponto, que a equipe ir conseguir justificar o propsito de
trocar o sistema de entrada de pedidos existentes. Alm disso, a justificativa de custo
desse novo sistema pode ser quantificada determinando o custo do desenvolvimento e o
retorno deste investimento atravs da reduo do desperdcio.
60
50
pedidos errados
Porcentagem
Dados de qualidade
demonstram que
muitas causas razes
no valem a pena
serem corrigidas.
40
danos no transporte
devolues
30
mercadoria obsoleta
defeitos de manufatura
20
outros
10
0
Contribuies
Figura 42
Grfico de Pareto das causas razes
29
Posteriormente, a anlise do diagrama espinha de peixe pode ser usada para determinar
quais tipos especficos de erros contribuem para o problema de pedidos errados de
vendas. Esses dados, mais detalhados, podem ento ser usados para definir as
caractersticas do sistema de software para atacar tais erros. Para o nosso propsito, no
entanto, podemos finalizar a nossa anlise e concordar com a troca do sistema de pedidos
que, ao menos uma soluo parcial para o problema de muitos desperdcios.
Uma vez que identificamos pedidos errados como uma das causas razes do problema
que vale a pena ser resolvido, ns podemos criar uma declarao do problema para o
problema dos pedidos de venda, como ilustrado na Tabela 42.
Tabela 42
Declarao do problema dos pedidos de venda
Elementos
O problema
afeta
devido
Os benefcios desse
Descrio
de pedidos errados
o pessoal de vendas, clientes, fabricantes, transportadores
e servio de atendimento ao cliente
ao aumento de desperdcios, excessiva manipulao de
custos, insatisfao de clientes e baixa lucratividade.
novo sistema que ir atacar o problema so:
Aumento de preciso dos pedidos de venda nos
pontos de venda
Aperfeioamento de relatrios gerenciais com os
dados de venda
E, finalmente, alta lucratividade.
Uma vez descrita, a declarao do problema pode ser divulgada entre os stakeholders para
criticarem e tecerem comentrios. Quando esse perodo de receber crticas e comentrios
estiver finalizado, e a declarao do problema consolidada, a declarao do problema
passar a ser uma misso declarada, a qual todos os membros da equipe de projeto tero
que ter em suas mentes, para que todos trabalhem para atingir aos mesmos objetivos.
Passo 3: Identificar Stakeholders e Usurios

O entendimento das
necessidades dos
usurios e
stakeholders o
fator chave para o
desenvolvimento de
uma soluo efetiva.
A soluo efetiva de qualquer problema complexo quase sempre envolve a satisfao das
necessidades de diversos grupos de stakeholders. Os stakeholders, normalmente,
possuem vrias perspectivas sobre o problema e vrias necessidades que esperam que
sejam atacadas pela soluo. Ns iremos definir um stakeholder como:
qualquer um que possa ser substancialmente afetado pela implementao de um novo sistema ou
aplicao.
Muitos stakeholders so usurios do sistema e suas necessidades so fceis de identificar
porque eles esto diretamente envolvidos com a definio e uso do sistema. Porm,
alguns stakeholders so apenas usurios indiretos do sistema ou so afetados apenas pelos
resultados de negcio que o sistema influencia. Esses stakeholders tendem a serem
encontrados alm do escopo de negcio, ou nos arredores do ambiente de uma
particular aplicao. Ainda em outros casos, esses stakeholders sero removidos do
ambiente da aplicao. Incluem-se, por exemplo, as pessoas e organizaes envolvidas no
desenvolvimento do sistema, subcontratados, os clientes dos clientes, agncias externas,
tais como a FAA (U.S. Federal Aviation Administration) ou a FDA (Food and Drug
30
Administration), ou outras agncias que interagem com o sistema ou com o processo de

desenvolvimento. Cada uma dessas classes de stakeholders pode influenciar os requisitos
do sistema ou ir de alguma forma estar envolvida com os resultados do sistema.
Stakeholders que
no so usurios
devem tambm ser
identificados e
tratados.
O entendimento de quem so os stakeholders e de suas necessidades particulares um

fator importante para o desenvolvimento de uma soluo efetiva. Dependendo do
domnio de especialidade da equipe de desenvolvimento, identificar stakeholders pode ser
uma tarefa trivial ou no na anlise do problema. Freqentemente, isso envolve
simplesmente entrevistar as pessoas que decidem, usurios potenciais, e outras partes
interessadas. As seguintes questes podem ser teis nesse processo:
Quem so os usurios do sistema?

Quem o cliente (aquele que paga) do sistema?
Quem mais ser afetado pelas sadas que o sistema ir produzir?
Quem ir avaliar e homologar o sistema quando ele for entregue e
implantado?
Existem outros usurios internos ou externos do sistema cujas necessidades
devam ser atendidas?
Quem ir manter o sistema?
Existe algum mais?
Em nosso exemplo da substituio do sistema de pedidos, o principal e o mais bvio dos

usurios so os vendedores que entram com os pedidos de vendas. Esses usurios so
obviamente stakeholders uma vez que a sua produtividade, convenincia, conforto,
desempenho e satisfao no trabalho so afetados pelo sistema. Quais outros
stakeholders podem ser identificados?
Outros stakeholders, o supervisor de pedidos de vendas, por exemplo, so diretamente
afetados pelo sistema, mas acessam o sistema atravs de diferentes relatrios e interfaces
de usurios. Ainda outras pessoas, o diretor financeiro da empresa, por exemplo, so
evidentemente stakeholders, uma vez que o sistema pode ser afetar a produtividade,
qualidade e lucratividade da empresa. Para no esquecermos, o diretor de sistemas de
informao e membros da equipe de desenvolvimento do sistema so tambm
stakeholders, uma vez que eles so responsveis pelo desenvolvimento e manuteno do
sistema. Eles tero que viver com os resultados, assim como os usurios. A Tabela 43
sumariza os resultados da anlise de stakeholders e identifica usurios e outros
stakeholders do novo sistema de pedidos.
Tabela 43
Usurios e Outros Stakeholders do novo sistema
Usurios
Vendedores
Supervisor de Vendas
Controle da Produo
Pessoal de Faturamento
Outros Stakeholders
Diretor de SI e equipe de desenvolvimento
Diretor Financeiro
Gerente de Produo
31
Passo 4: Definir a Fronteira da Soluo

Sistmica
Uma vez que se tenha chegado ao acordo sobre a declarao do problema e, usurios e
stakeholders tenham sido identificados, ns podemos voltar nossa ateno para a definio
do sistema que poder ser desenvolvido para atacar o problema. Ao fazer isso, ns
entraremos numa importante transio de estados, onde teremos que manter duas coisas
em mente: a compreenso do problema e as consideraes de uma soluo em potencial.
O prximo passo importante determinar a fronteira da soluo sistmica. A fronteira do
sistema define o limite entre a soluo e o mundo real que cerca a soluo (Figura 43).
Em outras palavras, a fronteira do sistema descreve um invlucro no qual a soluo est
contida. As informaes, existentes nos formulrios de entrada e sada, so repassadas
para fora do sistema, para usurios que vivem fora do sistema. Todas as interaes com o
sistema ocorrem via interfaces entre o sistema e o mundo externo.
Sistema
entradas
Ns dividimos o
mundo em duas
classes:
1. Nosso sistema
2. Coisas que
interagem com
o nosso sistema
Figura 43
sadas
A associao entrada/sistema/sada
Em outras palavras, se ns tivermos que construir ou modificar algo, esse algo ser parte
de nossa soluo e estar dentro da fronteira; caso contrrio, ser externo ao nosso
sistema. Assim, dividimos o mundo em duas classes interessantes:
1. Nosso sistema
2. Coisas que interagem com o sistema
Identificar as coisas que interagem com o nosso sistema o mesmo que identificar os
atores de nosso sistema. Afinal de contas, eles possuem um papel para interpretar, que
o de fazer com que o nosso sistema trabalhe. Ns representamos um ator com um
simples desenho de um ser humano. Ns definimos um ator como:
Ator
algum ou alguma coisa, fora do sistema, que interage com o sistema.

Uma vez que temos a notao de um ator, podemos ilustrar a fronteira do sistema como
ilustra a Figura 44.
Fronteira do
sistema
E/S
Nossa soluo
E/S
Usurios
Outros sistemas
Figura 44
Fronteira do sistema
32
Em muitos casos, a fronteira do sistema bvia. Por exemplo, uma copiadora pessoal,
conectada a um PC-Windows 2000 tem a fronteira relativamente bem definida. Existe
apenas um usurio e uma plataforma. A interface entre o usurio e a aplicao
construda por caixas de dilogo, o qual o usurio utiliza para acessar informaes do
sistema e configurar qualquer relatrio e caminhos de comunicao que o sistema utilize
para documentar ou transmitir essas informaes.
Em nosso exemplo, sistema de pedidos, que ser integrada a um sistema legado, a
fronteira no to clara. O analista deve determinar se os dados sero compartilhados
com outras aplicaes, se a nova aplicao estar distribuda entre os vrios servidores e
clientes, e quem sero os usurios. Por exemplo, o pessoal de produo ter acesso online
os pedidos? Existe um controle de qualidade ou funes de auditoria que ter que ser
fornecido? O sistema executar num mainframe ou sobre um novo front end
cliente/servidor? Relatrios gerenciais especficos tero que ser fornecidos?
Embora possa parecer bastante bvio, a identificao de atores o principal passo
analtico da anlise do problema. Como encontramos esses atores? Aqui esto algumas
questes que podero ajudar a encontrar esses atores:
Quem ir fornecer, usar, ou remover informaes do sistema?

Quem ir operar o sistema?
Quem ir realizar as manutenes no sistema?
Onde o sistema ser usado?
Onde o sistema obtm suas informaes?
Quais outros sistemas externos iro interagir com o sistema?
A partir das respostas para essas questes, o analista poder criar uma perspectiva do
sistema, um diagrama de blocos que descreve a fronteira do sistema, os usurios, e
outras interfaces. A Figura 45 fornece uma perspectiva simplificada do sistema para o
novo sistema de pedidos.
Nossa nova soluo
Fronteira do
sistema
Vendedor
Novo Sistema de Pedidos

Sistema legado com
os dados sobre preos
Faturista
Transportadora
Figura 45
Gerente de Produo
Perspectiva do Sistema
33
A linha tracejada ilustra a fronteira do sistema para a soluo proposta. O diagrama ilustra
que a maior parte da soluo ir ser desenvolvida para um novo sistema de pedidos, mas
uma parte do cdigo da soluo dever ser desenvolvida e implantada sob o sistema
legado existente.
Passo 5: Identificar as restries que sero

impostas soluo
Restries so
limitaes sobre o
grau de liberdade
que temos em
fornecer uma
soluo.
Antes de gastar trilhes de dlares num esforo bem intencionado que ir revolucionar o
estado da arte de sistemas de pedidos, ns devemos parar e considerar as restries que
sero impostas soluo. Definimos uma restrio como:
um limite sobre o grau de liberdade que temos em fornecer uma soluo.
Cada restrio tem o potencial para restringir severamente a nossa habilidade de produzir
uma soluo da forma como estava prevista. Assim, cada restrio deve ser
cuidadosamente considerada como parte de um processo de planejamento, pois muitos
podem at fazer com que reconsideremos a abordagem tecnolgica que previmos
inicialmente.
Uma variedade de fontes de recursos deve ser considerada. Isso inclui planejamento
retorno de investimento, oramento de pessoal e equipamentos, assuntos ambientais,
sistemas operacionais, banco de dados, sistemas clientes e servidores, assuntos tcnicos,
assuntos polticos internos organizao, compra de software, polticas e procedimentos
da empresa, escolha de ferramentas e linguagens, pessoal e outras fontes de recursos, alm
de vrias outras consideraes. Essas restries podem ser impostas antes mesmo que
iniciemos qualquer atividade (Nenhum novo hardware), ou teremos que ir atrs e
descobri-los.
Para auxiliar nessa descoberta, til conhecer o tipo de coisa que devemos procurar. A
Tabela 44 apresenta fontes potenciais de restries de sistemas. Responder questes
apresentadas nesta tabela ajudar a descobrir as principais restries que iro afetar nossa
soluo. Alm disso, essa atividade poder, provavelmente, ajudar na identificao da
lgica para a restrio, tanto para assegurar que voc entendeu a perspectiva da restrio
quanto para voc reconhecer quando a restrio no mais se aplica para a nossa soluo.
Quanto menos restrito, melhor.
Uma vez que as restries tenham sido identificadas, algumas delas iro se tornar
requisitos para o novo sistema (usar o sistema MRP desenvolvido pelo nosso fornecedor
de sistema de conta corrente). Outras restries iro afetar recursos, planos de
implementao e planos de projeto. responsabilidade do solucionador entender as
potencias fontes de restries para cada ambiente especfico da aplicao e determinar o
impacto de cada restrio sobre o potencial espao da soluo.
34
Tabela 44
Potenciais restries do sistema
Fonte
Econmica
Exemplo de Consideraes
Que restries financeiras ou oramentrias so
aplicveis?
Existem custos associados nas vendas de mercadorias ou
consideraes sobre preo de produtos?
Existe algum problema de licenciamento?
Poltica
Existem problemas polticos internos ou externos que

possam, potencialmente, afetar a soluo?
Existem problemas interdepartamentais?
Temos restries quanto escolha de tecnologia?
Temos restries para trabalhar com a plataforma ou
tecnologias existentes?
Utilizaremos algum pacote de software adquirido?
Tcnica
Sistmica
A soluo ser construda sobre o sistema existente?

Devemos manter compatibilidade com a soluo
existente?
Que sistemas operacionais e ambientes devem ser
suportados?
Ambiental
Existem restries ambientais ou legais?

Existem requisitos de segurana?
Estamos restritos a algum padro?
De planejamento
e recursos
O planejamento est definido?

Estamos restritos aos recursos existentes?
Podemos utilizar trabalho externo?
Podemos aumentar os recursos temporrios ou
permanentes?
Retornando ao nosso exemplo, quais restries podem ser impostas sobre o novo sistema
de pedidos? A Tabela 45 sumariza os recursos e restries que foram impostas sobre o
novo sistema.
35
Tabela 45
Restries, fontes e lgica para o sistema de pedidos
Fonte
Operacional
Restrio
Uma cpia exata dos dados
dos pedidos de venda deve
permanecer na base de dados
legado por um ano.
Lgica
O risco de perda de dados
muito grande; ns precisamos
executar em paralelo durante
um ano.
Sistema e SO
A aplicao no deve utilizar

mais que 20 megabytes da
memria RAM do servidor.
Existe limitao de memria

no servidor.
Oramento de equipamentos
O
sistema
deve
ser
desenvolvido no servidor
existente; novos hardwares
clientes para usurios sero
fornecidos.
Controle
de
custos
e
conservao
do
sistema
existente.
Oramento de pessoal
Recursos fixos de pessoal;

sem terceirizao.
Custos operacionais fixos de

acordo
com
o
atual
oramento.
Tecnologia obrigatria
Ser
utilizada
a
nova
metodologia
orientada
a
objetos.
Ns acreditamos que esta

tecnologia ir aumentar a
produtividade e elevar a
confiabilidade do software.
Sumrio
Completado este passo, podemos ficar razoavelmente confiantes de que conseguimos:
Entender o problema a ser resolvido, bem como as causas razes do problema.

Identificar os stakeholders que, com seu julgamento coletivo, ir, ao final,
determinar o sucesso ou o fracasso do nosso sistema.
Obter uma noo da fronteira da soluo.
Conhecer as restries e o grau de liberdade que temos para solucionar o
problema.
Vislumbrando o Futuro
Com esta base conceitual, podemos agora voltar nossa ateno para duas tcnicas mais
especficas de solucionar problemas, as quais podem ser aplicadas em certos domnios de
aplicaes. No Captulo 5, ns veremos a modelagem de negcio, uma tcnica que podemos
aplicar em aplicaes de Sistemas de Informao - IS/IT (Information system / information
technology). No Captulo 6, veremos a Engenharia de Sistemas para sistemas de software
intensivo, que pode ser aplicado para aplicao do domnio de sistemas embutidos.
Quanto ao terceiro domnio - ISV (Independent software vendors), pertencente a fornecedores
independentes de software, as tcnicas de anlise de problemas esto normalmente
focadas nas seguintes atividades:
36
Identificar as oportunidades e segmentos de mercado.

Identificar as classes de potenciais usurios e suas necessidades particulares.
Estudar a demografia da potencial base de usurios.
Entender o potencial da demanda, do preo e da flexibilidade de preos.
Entender as estratgias de venda e canais de distribuio.
Claramente, estes tpicos so interessantes, mas para nos ajudar a gerenciar o escopo
deste volume, ns no iremos explorar tais assuntos especficos. No entanto, voc pode
ficar confiante e seguro de que as habilidades de equipe que iremos explorar nos
prximos captulos iro se aplicar igualmente bem para esta classe de aplicao, como
iremos demonstrar.
Nota: Uma das coisas mais difceis que encontramos ao escrever este livro foi tentar
apresentar vrias tcnicas para construir o conjunto de habilidades de equipe. Nenhuma
tcnica funciona em todas as situaes; nunca duas situaes sero as mesmas.
Nos captulos anteriores, focamos numa abordagem geral e filosfica da anlise
de problemas que parece funcionar em vrios contextos de sistemas. No entanto, esse
problema de seleo de tcnicas para aplicar se transformar em algo muito mais srio
nos prximos captulos, onde definiremos a tcnica de modelagem de negcio, a tcnica de
engenharia de sistemas, e continuamos a definir uma variedade de tcnicas na Habilidade
de Equipe 2, Entendendo as Necessidades do Usurio, onde apresentaremos uma grande
variedade de tcnicas que podem ser usadas para entender as necessidades dos
stakeholders e de usurios com respeito ao sistema que voc ir construir.
No entanto, ns pensamos que seja importante destacar que as tcnicas descritas
neste livro da anlise do problema at brainstorming podem ser usadas em diferentes
partes do processo de software e no apenas na parte do processo onde ns escolhemos
descrev-las. Por exemplo, a equipe pode usar a anlise de problemas para definir um
problema de sistema de pedidos ou resolver um problema tcnico dentro de sua
implementao. Da mesma forma, a equipe pode usar o brainstorming para determinar as
provveis causas razes num exerccio de anlise de problemas ou determinar as provveis
caractersticas novas de um sistema como fizemos no captulo 5. No faremos nenhuma
tentativa para descrever todas as circunstncias sob as quais uma particular tcnica
poder ser aplicada, mas, ao invs disso, nos concentraremos em fazer com que a equipe
desenvolva habilidades para que possa aplicar essas tcnicas e inclu-las em sua maleta de
dicas e truques para pegar e usar em momentos apropriados do projeto.
37
Captulo 5
Modelagem de Negcio
Pontos chaves
A modelagem de negcio uma tcnica de anlise de problema apropriado
especialmente para ambientes de IS/IT.
A modelagem de negcio usada para ajudar a definir sistemas e suas
aplicaes.
Um modelo use case de negcio, que consiste de atores e use cases, um
modelo das funes pretendidas do negcio.
Um modelo de objetos de negcio descreve as entidades que fornecem a
funcionalidade para realizar os use cases de negcio, e como essas entidades se
interagem.
o contexto de um ambiente de tecnologia de sistemas informao

(IS/IT), o primeiro problema a ser resolvido a sua vasta abrangncia
como descrevemos no Captulo 4. Neste ambiente, a complexidade de
negcio abundante, e normalmente precisamos entender algo sobre
essa complexidade antes de tentar definir um problema especfico importante a
ser resolvido. Esse ambiente possui no apenas de um usurio ou dois com suas
interfaces computacionais, mas de organizaes, unidades de negcio,
departamentos, funes, ampla rede de computadores, intranet e extranet
corporativa, clientes, usurios, recursos humanos, sistemas MRP (Material
Requirement Planning), estoque, sistemas de gerenciamento, entre outros.
Alm disso, mesmo que estejamos concentrados numa aplicao especfica que ser
implementada, devemos constantemente nos lembrar do contexto mais amplo no qual
essa aplicao estar inserida. Talvez isso possa ser realizado com maior sucesso fazendose questes corretas, mas como qualquer tcnica, existem mais coisas que podem ser
feitas num contexto especfico do que nos casos genricos.
No contexto de IS/IT, poderia ser til ter uma tcnica que possibilite determinar as
respostas para as seguintes questes:
Por que construir um sistema dessa maneira?

Onde deve ser alocado?
Como podemos determinar quais funcionalidades devem ser alocadas num
particular sistema?
Quando devemos utilizar o processamento manual ou solues de contorno?
Quando devemos considerar a reestruturao da organizao a fim de solucionar
o problema?
Felizmente, existe uma tcnica que se encaixa perfeitamente para resolver este problema,
e esta tcnica a modelagem de negcio.
38
Propsito da Modelagem de Negcio

No contexto deste volume, podemos pensar nos termos negcio e modelagem de
negcio como algo to amplo quanto possvel. Por exemplo, o nosso negcio pode ser o
negcio de desenvolvimento de software ou de fabricao de robs soldadores, ou voc
pode querer modelar um negcio de filantropia, organizaes de servio, processo
intradepartamental ou fluxo de trabalho interno.
De qualquer forma, o propsito da modelagem de negcio possui duas partes:
Entender a estrutura dinmica da organizao

Assegurar que clientes, usurios finais e desenvolvedores tenham um
entendimento comum da organizao.
Essa abordagem d equipe uma maneira lgica de definir onde a utilizao do software
pode melhorar a produtividade do negcio e ajudar na determinao de requisitos para
essa utilizao.
Usando Tcnicas de Engenharia de Software

para Modelar Negcios
Com a escolha da
tcnica correta para
modelar negcios,
modelos use cases e
modelos de objetos,
se tornaro artefatos
comuns durante a
atividade de solucionar problemas.
Naturalmente, vrias tcnicas podem ser aplicadas para se modelar negcios. No entanto,
seria conveniente que, como desenvolvedores de software, tivssemos nossa disposio
um conjunto rico em ferramentas e tcnicas j usadas na modelagem de nossos softwares.
De fato, ns j sabemos modelar entidades (objetos e classes), relacionamentos
(dependncias, associaes, entre outros), processos complexos (seqncia de atividades,
transies de estados, eventos, condicionais, entre outros) e outros construtores que
ocorrem naturalmente no contexto de nossos projetos de aplicaes de software.
Se ns pudemos aplicar essas mesmas tcnicas para modelar negcios, poderamos falar a
mesma linguagem em ambos os contextos. Por exemplo, uma coisa, tal como o
contracheque da folha de pagamento, descrita no domnio de negcio, pode relacionar-se
com uma coisa que aparece novamente no domnio de software por exemplo, o
registro do contracheque da folha de pagamento. Se ns tivermos sorte o suficiente para
usar as mesmas tcnicas, ou tcnicas muito similares, tanto para a anlise de problemas
quanto para o projeto de software, ambas poderiam se beneficiar compartilhando os
resultados produzidos pelas duas atividades.
Escolhendo a Tcnica Correta

Historicamente, vimos que as tcnicas de modelagem que foram desenvolvidas e
maturadas no domnio do software inspiraram novas maneiras de visualizar uma
organizao. Desde que as tcnicas de modelagem visual se tornaram comuns em
projetos de novos softwares, usar tcnicas similares no domnio de negcio tornou-se
natural. Essa metodologia foi bem desenvolvida por Jacobson, Ericsson e outros em
1994.
Nos anos 80 e 90, houve uma rpida proliferao tanto das tcnicas de modelagem de
negcio quanto de metodologias de desenvolvimento de software. No entanto, eles so
todas diferentes! No centro dessas atividades estavam os vrios mtodos e notaes
orientadas a objetos desenvolvidos por diversos especialistas em engenharia de software e
pesquisadores. Felizmente, a guerra de metodologias foi superada, e a indstria assentou39
se sobre um padro industrial a UML (Unified Modeling Language) para a

modelagem de sistemas de software intensivos.
A Linguagem de Modelagem Unificada

No final de 1997, uma linguagem grfica para visualizar, especificar, construir e
documentar os artefatos de um sistema intensivo de software foi adotado como um
padro industrial (Booch, Jacobson e Rumbaugh). A UML fornece um conjunto de
elementos de modelagem, notaes, relacionamentos e regras de uso que podem ser
aplicados na atividade de desenvolvimento de software. No entanto, a UML pode
tambm ser aplicada para modelar sistemas e negcios. Um tutorial sobre UML est fora
do escopo deste volume. (Para isso, consulte o livro dos trs amigos sobre a UML:
Booch, Rumbaugh e Jacobson (1990), The Unified Modeling Language, User Guide; e
Rumbaugh, Booch e Jacobson (1998), The Unified Modeling Language, Refrence Manual). No
entanto, iremos usar alguns conceitos chaves da UML nesta seo e construir outros a
partir desses conceitos nas sees subseqentes.
Modelagem de Negcio Usando UML

Uma das metas da modelagem de negcio desenvolver um modelo de negcio que
possa ser usado para orientar o desenvolvimento de aplicaes. Os dois construtores
chaves de modelagem que pode ser usado para este propsito so: modelo use-case de negcio
e modelo de objetos de negocio.
Um modelo use-case de negcio um modelo das funcionalidades pretendidas do negcio e
usado como uma das fontes essenciais para identificar papis e produtos da organizao.
Como tal, o modelo use-case de negcio consiste de atores de negcio usurios e
sistemas que interagem com o negcio e os use cases de negcio seqncia de
eventos pelos quais os atores de negcio interagem com os elementos de negcio para
realizar seu trabalho. Juntos, atores de negcio e use cases de negcio descrevem quem
est envolvido nas atividades de negcio e como essas atividades ocorrem. A Figura 5 1
ilustra o modelo use-case de negcio. Note que os cones possuem uma barra, indicando
que o ator e o use case so de negcio ao invs de serem de sistema.
Figura 51
Modelo use-case de negcio
40
Um modelo use-case de negcio, ento, consiste de atores de negcio e use case de

negcio, com atores de negcio representando papis externos ao negcio (por exemplo,
clientes e fornecedores) e use cases de negcio representando processos. Abaixo esto
alguns exemplos de use cases de negcio:
Liberar pagamento de empregados

Negociar os termos do contrato com o cliente
Exemplos de atores de negcio:
Cliente
Fornecedor
Secretaria dos Negcios da Fazenda do Estado
O modelo de objetos de negcio descreve as entidades departamentos,

contadores, sistemas e como eles se interagem para gerar as funcionalidades
necessrias a fim de realizar os use cases de negcio. A Figura 52 representa o
modelo de objetos de negcio. Os cones, com um ator dentro de uma
circunferncia, representam um worker (trabalhador) que aparece dentro do
processo de negcio, tais como secretria, chefe ou diretor. As circunferncias
com as barras representam uma entidade de negcio ou alguma coisa que os
workers de negcio usa ou produz, tais como contratos, cadastro de funcionrios e
produtos.
Figura 52
Modelo de objetos de negcio
Um modelo de objetos de negcio tambm possui realizaes de use-cases de

negcio, os quais mostram como os use cases de negcio so executados em
termos de interaes de workers de negcio e entidades de negcio. Para refletir
grupos de departamentos numa organizao, workers de negcio e entidades de
negcio podem ser agrupados dentro de unidades organizacionais.
Todos juntos, os dois modelos fornecem uma viso geral compreensiva de como o
negcio funciona e permite que a equipe de desenvolvimento concentre-se nas
reas no qual o sistema pode ser fornecido com o objetivo de elevar a eficincia
geral do negcio. Os modelos tambm ajudam a equipe a entender quais
mudanas tero que ser realizadas dentro do processo de negcio a fim de que o
novo sistema possa ser efetivamente implementado.
41
Da Modelagem de Negcio aos Modelos de

Sistemas
Uma das vantagens desta abordagem de modelagem de negcio a maneira clara
e concisa de mostrar dependncias entre modelos do negcio e modelos do
sistema. Esta claridade eleva a produtividades do processo de desenvolvimento de
software e tambm ajuda a assegurar que o sistema que est sendo desenvolvido
resolve as reais necessidades do negcio. Veja a figura 53.
Figura 53
Modelos de negcio/sistema
A transio entre os dois modelos pode ser resumida da seguinte forma:
Workers de negcio iro se tornar atores do sistema que ns desenvolvemos ou

um elemento do prprio sistema. Por exemplo, caixa de um banco e caixa
eletrnico de um banco.
Comportamentos descritos para os workers de negcio so coisas que podem ser
automatizados, de tal forma que eles iro ajudar a encontrar os use cases de
sistema e definir as funcionalidades necessrias.
Entidades de negcio so coisas que queremos que o sistema nos ajude a manter.
Assim, eles podem ajudar a encontrar classes entidades do modelo de anlise do
sistema.
Ao realizar a transio, a modelagem de negcio facilita o processo de ir do

entendimento do negcio e do problema dentro do negcio para potenciais
aplicaes que podem ser implementadas para gerar as solues do problema
identificado.
Quando Usar a Modelagem de Negcio

A modelagem de negcio no algo que recomendamos para todos os projetos de
engenharia de software. Modelos de negcio adicionam valor quando o ambiente
da aplicao complexa e multidimensional, e quando muitas pessoas esto
diretamente envolvidas no uso do sistema. Por exemplo, se voc estiver
construindo uma caracterstica adicional para um componente de chaveamento de
telecomunicaes, voc no deveria usar a modelagem de negcio. Por outro
lado, se voc estiver construindo um sistema de pedidos para o GoodsAreUs, ns
42
recomendamos que utilize a modelagem de negcio para ganhar vantagem na

anlise do problema.
Sumrio
Neste captulo, ns descrevemos uma tcnica especfica de anlise de problema, a
modelagem de negcio. Ao fazer isso, definimos:
Porque voc precisa modelar o negcio.

Como, usando a UML, ns transpomos as tcnicas de desenvolvimento da
engenharia de software e a usamos para a modelagem de negcio.
Os principais artefatos da modelagem de negcio, o modelo use-case de negcio
e o modelo de objetos de negcio.
Como voc pode definir aplicaes de software e gerar requisitos de software a
partir dos modelos de negcio.
Vislumbrando o Futuro
No prximo captulo, veremos a engenharia de sistemas para sistemas de
software, uma outra tcnica de anlise de problemas, a qual ir ajudar a formatar a
aplicao de sistemas do tipo embutido.
43
Captulo 6
Engenharia de Sistemas de Software

Intensivos
Pontos chaves
A engenharia de sistemas uma tcnica de anlise de problemas especialmente
apropriada para desenvolvimento de sistemas embutidos.
A engenharia de sistemas nos ajuda a entender requisitos impostos aplicaes
de software que executam dentro da soluo sistmica.
O flowdown1 de requisitos antes de tudo, uma questo de assegurar que todos
os requisitos de sistema estaro cobertos por um subsistema ou pela
colaborao de um conjunto de subsistemas.
Atualmente, o sistema deve ser otimizado para reduzir custos de software ao
invs de reduzir custos de hardware.
o Captulo 5, vimos a modelagem de negcio, uma tcnica de anlise de

problemas para aplicaes de sistemas de informao (IS/IT). A
modelagem de negcios nos ajuda a determinar quais aplicaes devem
ser construdas e onde devem ser executadas, dentro do ambiente
computacional da empresa e departamentos, edifcios, e construes polticas e
fsicas da empresa. Em outras palavras, essa anlise pode nos ajudar a determinar
por que e onde uma aplicao dever existir. Ao fazer isso, naturalmente, fizemos
uma sutil mudana do espao do problema para uma viso inicial do espao da
soluo, onde a funcionalidade que resolve o problema ir existir em uma ou mais
aplicaes que atendem as necessidades finais do usurio.
No negcio de sistemas embutidos, no entanto, o domnio do problema e o
domnio da soluo parecem totalmente diferentes. Ao invs de departamentos,
pessoas e processos, o domnio consiste de conectores, fontes de energia, racks de
equipamentos, componentes eletrnicos e eltricos, perifricos de controle de
fluidos, outros sistemas de software, subsistemas mecnicos e pticos, entre
outros. Aqui, a modelagem de negcio no pode ajudar muito. Ao invs disso,
devemos adotar uma estratgia diferente para responder o por que e onde a
aplicao deve existir.
O que Engenharia de Sistemas?

De acordo com o conselho internacional de engenharia de sistemas (INCOSE International Council on Engineering Systems, 1999):
A engenharia de sistemas uma abordagem interdisciplinar e pretende
viabilizar a realizao de sistemas de sucesso. O foco est em definir as
1
o processo de derivar e alocar requisitos a todos os nveis da decomposio sistmica.
44
necessidades dos clientes e funcionalidades solicitadas no incio do ciclo de

desenvolvimento, documentando requisitos e ento, procedendo com a sntese
do projeto e validao do sistema considerando, como um todo, o problema
de:
Operao
Desempenho
Teste
Manufatura
Custo e Cronograma
Treinamento e suporte
Disponibilizao.
A engenharia de sistemas integra todas as disciplinas e grupos de

especialidades dentro de um esforo de equipe, formando assim, um
processo de desenvolvimento estruturado que progride do conceito, para a
produo e chegando na sua operao. A engenharia de sistemas
considera tanto o negcio quanto as necessidades tcnicas de todos os
clientes com o objetivo de fornecer um produto de qualidade que atenda
as necessidades dos usurios.
Ufa! Essa definio muito longa! No entanto, pela definio, a engenharia de
sistemas pode ser considerada uma tcnica de anlise de problemas, embora que,
neste volume, no esperamos cobri-la em sua totalidade. Para maiores detalhes,
veja Rechtin (1997).
No escopo deste volume, a engenharia de sistemas pode nos ajudar a entender as
necessidades do espao do problema e os requisitos que so impostos soluo.
Nesse contexto, a engenharia de sistemas nos ajuda a entender os requisitos que
so impostos s aplicaes de software e que executem dentro da soluo
sistmica. Em outras palavras, ns aplicamos a engenharia de sistemas como uma
tcnica de anlise de problemas para nos ajudar a entender os requisitos de nossas
aplicaes de software, se elas executarem sobre um microprocessador embutido
ou num sistema UNIX dentro do contexto de um sistema mundial de
telecomunicao.
Princpios Pragmticos da Engenharia de Sistemas

Se considerarmos que a engenharia de sistemas uma tcnica de anlise de
problemas, os passos especficos, ou pelo menos os princpios bsicos da
disciplina, devem nos fornecer os passos necessrios para aplicar a engenharia de
sistemas para analisar o problema dentro do nosso contexto de requisitos. O
INCOSE definiu um conjunto bsico de 8 princpios de engenharia de sistemas
(1993):
Conhecer o problema, conhecer o cliente e conhecer o consumidor.

Usar critrios efetivos com base nas necessidades para tomar decises sistmicas.
Estabelecer e gerenciar requisitos.
Identificar e avaliar alternativas de forma a convergir para um soluo.
Verificar e validar requisitos e performance da soluo.
Manter a integridade do sistema.
Usar um processo articulado e documentado.
Gerenciar frente a um plano.
45
Esta lista identifica alguns princpios pragmticos da engenharia de sistemas. No

entanto, a verdade que um subconjunto da disciplina de engenharia de sistemas
fundamenta-se num outro processo, o da decomposio sucessiva de sistemas
complexos em sistemas mais simples.
A Composio e Decomposio de Sistemas Complexos

Com este processo, um problema complexo, o sistema (Figura 61),
decomposto em problemas menores subsistemas (Figura 62). Cada subsistema
pode ser pensado, projetado e manufaturado com sucesso, e ento integrado para
produzir a soluo sistmica.
O ambiente do sistema
Sistema
Figura 61
Um sistema em seu ambiente
A disciplina de engenharia que suporta a abordagem da decomposio sistmica

utiliza atributos da definio anterior, tal como o entendimento da caracterstica
operacional, manufatura, teste, entre outras.
Sistema
Subsistema
A
Figura 62
Subsistema
B
Um sistema composto por dois subsistemas
Este processo de decomposio, ou refinamento sucessivo, prossegue at que o

engenheiro de sistemas atinja os resultados corretos, de acordo com as medidas
quantitativas especficas do domnio da engenharia de sistemas. E muitos casos,
os subsistemas definidos na composio inicial so, por sua vez, decompostos em
outros subsistemas, como ilustra a Figura 63.
46
Sistema
Subsistema A
Subsistema
A-1
Figura 63
Subsistema
A-2
Subsistema
B
Um subsistema composto por dois subsistemas
Em muitos sistemas complexos, esse processo continua at que um grande

nmero de subsistemas tenha sido desenvolvido. Dizem que a aeronave F22, por
exemplo, composta de 152 subsistemas.
O engenheiro de sistemas descobre que o trabalho realizado est correto quando:
A distribuio e particionamento das funcionalidades estiverem otimizadas para

atingir a funcionalidade global do sistema com o mnimo de custo e mxima
flexibilidade.
Cada subsistema puder ser definido, projetado e construdo por uma equipe de
tamanho pequeno, ou ao menos modesto.
Cada subsistema puder ser manufaturado dentro das restries fsicas e
tecnolgicas do processo de manufatura disponvel.
Cada subsistema puder ser seguramente testado como um subsistema, com
disponibilidade de acessrios e peas apropriadas que simulem as interfaces com
outros sistemas.
Consideraes apropriadas do domnio fsico o tamanho, peso, localizao, e
distribuio dos subsistemas tiverem sido otimizados no contexto global do
sistema.
Alocao de Requisitos na Engenharia de

Sistemas
O processo flowdown de requisitos
aloca
funcionalidades do
sistema aos
subsistemas.
Mesmo que a engenharia de sistemas tenha propiciado realizar um bom trabalho

de definir os requisitos do sistema, o problema de gerenciamento de requisitos
ainda no est resolvido. O que se passa com esses subsistemas? Quais requisitos
so impostos para cada subsistema? Em muitos casos, o processo o de associar
os requisitos do nvel de sistema aos subsistemas (Subsistema B ir executar o
algoritmo de velocidade instantnea e monitorar diretamente o display de alerta).
Este processo distribuir requisitos (flow-down) o principal meio de assegurar
que todos os requisitos do sistema sero atendidos por um subsistema em algum
lugar ou por um conjunto de subsistemas que se colaboram.
47
Sobre Requisitos Derivados

Algumas vezes, descobrimos que ns criamos uma nova classe de requisitos
requisitos derivados que podem ser impostos aos subsistemas. Tipicamente,
existem duas subclasses de requisitos derivados.
1. Requisitos de subsistemas so aqueles que devem ser impostos apenas
a subsistemas, mas no necessariamente fornece um benefcio direto ao
usurio final (Subsistema A deve executar o algoritmo que computa a
velocidade instantnea da aeronave).
2. Requisitos de interface podem aparecer quando os subsistemas
necessitarem se comunicar uns com os outros para atingir um resultado
global. Eles precisaro compartilhar dados, fonte de energia, ou um
algoritmo computacional de uso comum. Nesses casos, a criao de
subsistemas tambm propicia a criao de interfaces entre subsistemas
(veja a Figura 64).
Subsistema
A
Subsistema
B
Interface de
A-para-B
Figura 64
Interface entre dois subsistemas
Mas existem mesmo requisitos derivados? Ns tratamos os requisitos derivados

como qualquer outro requisito? Eles no parecem atender as definies do
Captulo 2 (embora possa atenda definies sobre restries de projeto que iremos
falar mais adiante).
importante reconhecer que esses requisitos, embora cruciais para o sucesso do
projeto, so derivados do processo de decomposio do sistema. Dessa forma,
decomposies alternativas criam requisitos alternativos, e esses requisitos no
so cidados de primeira classe no sentido de que eles no refletem requisitos
originados de nossos clientes. No entanto, a partir do ponto de vista de um
fornecedor de um subsistema, eles so cidados de primeira classes porque
refletem requisitos impostos pelo cliente (o desenvolvedor do sistema).
No existe resposta mgica. O como tratar esses requisitos baseado no papel da
equipe de desenvolvimento no projeto, na decomposio de sistemas, bem como
em outros fatores tecnolgicos. Assim, importante saber como chegar aqui e
tratar os requisitos de forma apropriada. importante reconhecer que a
especificao de requisitos derivados ir, no final, afetar a habilidade do sistema
de fazer seu trabalho, bem como a manutenibilidade e robustez do sistema.
48
Uma Revoluo Silenciosa
Na indstria, a
inteligncia, antes
existente nos
componentes de
hardware, foram
alocadas aos
componentes de
software.
A engenharia de sistemas tem sido, tradicionalmente, uma disciplina aplicada

principalmente a sistemas fsicos, tais como sistemas de aeronaves, sistemas de
freios de automveis, sistemas de fontes de energia e aparelhos de consumo de
energia, entre outros. No entanto, durante os ltimos 20 anos, uma revoluo
silenciosa vem ocorrendo na engenharia de sistemas de sistemas complexos.
Gradualmente, nas indstrias de transportes, telecomunicaes, equipamentos
industriais, equipamentos mdicos, instrumentos cientficos, e em muitas outras
indstrias, os sistemas e equipamentos vm se tornando cada vez menores. Para
atender a elevao da complexidade e sofisticao, mais e mais funcionalidades
esto sendo alocadas aos subsistemas de software ao invs de serem alocadas aos
componentes de hardware. Afinal de contas, o software flexvel; muitos
algoritmos de medio, anlise e deteco so mais fceis, ao menos muito mais
baratos, de serem implementados em software do que em hardware. O mais
importante que so muito mais fceis de serem mudados.
Assim, na indstria, a inteligncia, antes existente nos componentes de hardware,
viabilizada atravs da combinao de sistemas eltricos e eletrnicos, sistemas
mecnicos, e sistemas qumico-fsicos; encontram-se hoje, implementadas em
componentes de software, imersos dentro de microprocessadores ou subsistemas.
Quando as Geraes se Colidem: os Ancies Encontram os Jovens

Arrogantes
Por dcadas, engenheiros de sistemas ocuparam, na indstria, os principais cargos
de engenheiro de projeto snior. Marcado por ferimentos e testados em campo,
vrios desses engenheiros de sistemas seniores eram especialistas em disciplinas
especficas, tais como: engenharia mecnica e eletrnica; e muitos eram alguns
dos melhores generalistas da equipe. Eles eram testemunhas de grandes desastres
e haviam conquistado muitas vitrias. Agora, velhos e experientes, eles possuem,
incrivelmente bem, o conhecimento especfico do domnio da aplicao rdios,
aeronaves, refrigerao, robtica, equipamentos de controle de materiais e
sabem tambm diferenciar facetas tcnicas, econmicas e polticas envolvidas na
tecnologia de implementao.
Mas, de repente, uma nova gerao de indivduos invadiu a sua rea. Esses
recm-chegados os programadores, ou nos bons dias, engenheiros de software
relativamente inexperientes em sistemas complexos, no sabiam diferenciar o
peso, da balana, ou a otimizao sistmica de seu prprio umbigo; mas eles
podiam fazer um microprocessador cantar em linguagem assembly. Alm disso,
pareciam que eram formados por genes diferentes ou, pelo menos, por uma
gerao diferente, o qual adicionava complexidade do conflito cultural e de
geraes ao processo de engenharia de sistemas. Muitas situaes interessantes
ocorreram.
Por algum tempo, a batalha estava equilibrada: engenheiros de sistemas atendiam
as solicitaes de particionar e alocar funcionalidades finais para o sistema. Mas
em muitas indstrias, a tecnologia de software assumiu gradualmente o controle, e
a engenharia de sistemas havia sido dominado, pelo menos em parte, devido
necessidade de atribuir ao sistema, funcionalidades flexveis de software. Existem
inmeras razes tcnicas e slidas para essa transio. Com o tempo, vrios fatos
ficaram bvios:
49
o software, no o hardware, que ir determinar as funcionalidades finais do

sistema, bem como o sucesso do sistema nas mos de usurios e no mercado.
o software, no o hardware, que ir consumir a maior parte dos custos de
pesquisa e desenvolvimento do sistema.
o software, no o hardware, que estar no caminho crtico e ir, dessa forma,
determinar finalmente quando o sistema ir para o mercado.
o software, no o hardware, que ir absorver a maioria das mudanas ocorridas
durante o desenvolvimento de sistemas e que ser evoludo, no passar dos anos,
para atender as necessidades por mudanas do sistema.
E, talvez o mais surpreendente:
Agora, muitos
sistemas devem
sofrer otimizaes
de software, no de
hardware.
Os custos do desenvolvimento e manuteno de software definem os custos

agregados e amortizados durante o ciclo de vida do produto, tornando-se o
principal componente na formao dos preos de venda dos produtos, em alguns
casos igual ou maior que o do hardware, tal que se tornou o santo gral dos
fabricantes de sistemas: custo total de fabricao.
Este ltimo fato deu o golpe de misericrdia, pois indica que voc deve
considerar para otimizao dos custos do sistema, no o hardware ou manufatura,
mas o desenvolvimento, manuteno, evoluo e aprimoramento de software
contidos no sistema. Isso mudou significativamente o jogo. Por agora, a
engenharia de sistemas deve ser realizada considerando o computador a ser
utilizado. Isso significa que a engenharia de sistemas deve, normalmente:
Maximizar a habilidade de executar software, fornecendo mais do que recursos

adequados de computao, mas adicionando mais microprocessadores, RAM,
ROM, memria de armazenamento de massa, largura de banda, ou quaisquer
recursos que o sistema necessite para executar seu software e ajudar a reduzir o
custo de venda de produtos.
Fornecer interfaces de comunicao adequadas entre subsistemas e assegurar que
o mecanismo de comunicao escolhido (Ethernet, Firewire, porta serial, ou
single data line) seja extensvel, via mecanismos de software e no de hardware.
Um aps o outro, essas mudanas afetaram os desafios do gerenciamento de

requisitos de duas maneiras:
Cada uma dessas dimenses ir criar novos requisitos que o sistema hardware
dever preencher a fim de satisfazer a soluo a ser construda.
A maior parte do problema de requisitos se deslocou para a aplicao de
software.
Felizmente, para menos para a segunda maneira, este o objetivo deste volume, e
ns esperamos prepar-lo muito bem para este particular problema.
50
Evitando o problema do sistema de chamins

Isso tudo bom, ao menos, na maioria das vezes. Lidar com sistemas complexos
requer abordagens no-triviais, e o sistema de subsistemas um meio para este
fim. Certamente, as alternativas so piores, ns poderamos chegar ao final com
um sistema incrivelmente complexo e que ningum conseguisse entender, com
comportamentos indeterminados e projeto baseado em funcionalidades
compartilhadas, particionamento pobre, e cdigos concorrentes que nunca sero
desatados. A engenharia de sistemas parece ser a melhor alternativa.
Como isso afeta o gerenciamento de requisitos? Quando feita a contagem final,
descobrimos que os requisitos de subsistemas so muito mais numerosos do que
os requisitos externos, ou daqueles que afetam o comportamento do sistema no
ambiente do usurio. No fim, ns investimos mais na priorizao, gerenciamento,
e identificao de requisitos de subsistemas do que naqueles que afetam o usurio
final. Isso no parece ser uma coisa completamente positiva.
E o que acontece se ns no fizermos um bom trabalho de engenharia de
sistemas? O sistema se tornar frgil e resistir a mudanas porque o peso das
propriedades de requisitos ir amarrar nossa implementao. Os nossos
requisitos de subsistemas tomaro o controle da flexibilidade de projeto, e uma
mudana num subsistema afetar outros subsistemas. esse o sistema de
chamins da legenda, e como tal, resistente a mudanas. Em interfaces de
subsistemas, o problema pode ser pior. Se as interfaces no forem especificadas
apropriadamente, o sistema se tornar frgil e no estar apto a evoluir para
atender as necessidades de mudanas; a menos que sejam feitas substanciais
alteraes nas interfaces e em todos os subsistemas dos quais dependem dessas
interfaces.
Quando Subsistemas So Subcontratos

Surge mais uma outra complicao. Uma vez que subsistemas so, normalmente,
desenvolvidos por diferentes equipes a final de contas, esta uma das razes de
criarmos subsistemas os requisitos de subsistemas e interfaces tendem, por sua
vez, a se tornarem contratos entre as equipes. (Meu subsistema apresenta os
resultados da computao de velocidade instantnea neste exato formato...). De
fato, em alguns casos, um subsistema pode ser desenvolvido por um
subcontratado, cuja nota fiscal possui um logotipo diferente do seu. Neste caso, o
nosso desafio de requisitos deixa o contexto tcnico e sistmico e passa a ser a da
poltica do futebol. (Darn. Os requisitos no podem ser mudados a menos que
o contrato seja renegociado). Em breve, o projeto pode estar intimamente
amarrado suas calas. Uma forte advertncia: Muitas tentativas de se
construir grandes sistemas encontraram sua morte nas mos deste problema.
Fazendo o Trabalho de Corretamente

O que devemos fazer? Bem, fazer um bom trabalho de engenharia de sistemas o
objetivo principal. Como participante dessa atividade de desenvolver sistemas de
software intensivos, voc precisar considerar as seguintes recomendaes:
Desenvolver, entender e manter os requisitos e use cases que permeiam os

subsistemas e que descrevem a funcionalidade global do sistema em alto nvel.
Tais use cases fornecem o contexto de como o sistema dever trabalhar e
51
assegurar que voc no se perdeu na floresta entre as rvores Eles tambm

ajudaro a assegurar que a arquitetura do sistema foi projetada para sustentar os
principais cenrios.
Faa o melhor trabalho possvel de particionar e isolar funcionalidades de
subsistemas. Use princpios da tecnologia de objetos: encapsulamento e
ocultamento de informaes, interface por contrato, mensagens ao invs de
compartilhamento de dados em seu trabalho de engenharia de sistemas.
Se possvel, desenvolva o software como um todo, no como um monte de peas
individuais, um para cada subsistema fsico. Uma das caractersticas do sistema de
chamins que em ambos os lados da interface (bem ou mau definidas), o
software precisa reconstruir o estado dos elementos chaves (objetos) que so
necessrios para tomar decises em ambos os lados; diferentemente do hardware,
cuja alocao dos requisitos em ambos os lados no representa uma diviso clara.
Quando codificar interfaces, use cdigos comuns em ambos os lados da
interface. Caso contrrio, surgiro variaes sutis, freqentemente provocados
pelas otimizaes, isso far com que a sincronizao de estados torne-se muito
difcil. Assim, se a fronteira entre os dois subsistemas fsicos posteriormente
desaparecerem isto , se a engenharia de sistemas achar que os processadores
so suficientes para suportar ambos os subsistemas A e B o engenheiro de
software ir ter um momento difcil para consolidar as duas peas de software (se
forem diferentes, claro!).
Definir especificaes de interface que possam fazer mais do que o necessrio, ou
seja, mais do que simplesmente atender as condies conhecidas. Investir numa
largura de banda um pouco maior, portas de entrada/sada extras, ou adicionar
alguns slots a mais para permitir futuras expanses.
Finalmente, veja se voc pode encontrar alguns daqueles ancies para lhe ajudar
com a engenharia de sistemas. Eles estiveram aqui antes, e sua experincia pode
ser muito valiosa para voc. Alm disso, voc poderia assim, a ajudar a por um
fim nesse conflito de geraes!
52
Uma estria: Particionando Grandes Sistemas de Software em Subsistemas

para Equipes Distribudas de Desenvolvimento
Numa aula, Rusty, um gerente de software experiente, nos abordou e definiu o
seguinte problema, descrito como um dilogo:
Rusty: Estamos construindo uma grande aplicao que ser executada num
nico sistema servidor. Nosso possumos duas equipes separadas,
contendo cada uma 30 pessoas; uma das equipes vive no lado leste do
rio da cidade de Nova York, e o outro vive no lado oeste. As duas
equipes possuem gerentes diferentes e competncias diferentes. Como
dividir o trabalho e criar um sistema que funcione?
Ns:
Bem, Rust, uma maneira de pensar sobre este problema como um

problema de engenharia de sistemas. Isto , estabelecer a forma de
particionar o sistema em dois subsistemas lgicos. Vamos chamar de
Leste e Oeste, e alocar os requisitos para os subsistemas como se eles
fossem sistemas fsicos separados. Defina uma interface, complete com
as definies de classes e servios comuns a serem usados, isso
permitir que os dois subsistemas (aplicaes) se cooperem para atingir
a funcionalidade global do sistema.
Rusty: Mas eu no estaria criando um sistema arbitrariamente, que no esteja

sendo dirigido pelos verdadeiros conceitos arquiteturais?
Ns:
Verdade, no sentido tcnico. Mas separar conceitos entre equipes de

projeto alinhado logstica e especificar competncias mais
importante.
Rusty: Mas eu no estaria criando interfaces artificiais e potencialmente, um

sistema de chamins?
Ns:
Sim, faz sentido, mas ns recomendamos que voc mantenha o mesmo

cdigo de interface em ambos os lados e desenvolvidos por uma nica
equipe. Caso contrrio, as duas equipe realizaro trabalhos
redundantes. Voc ir, sem dvida, criar novos requisitos para o
sistema, incluindo interfaces que provavelmente no seriam necessrias.
E, sim, importante ter conscincia do problema da chamin e fazer
tudo que puder para minimizar o acoplamento entre os sistemas e
minimizar as questes polticas que surgiro como resultado.
53
O Caso de Estudo
Enfim, aps uma breve introduo engenharia de sistemas, deixe nos aplicar o
que aprendemos no sistema HOLIS, nosso Sistema de Automao de Iluminao
Residencial. Neste momento, no gastaremos muito tempo tentando entender os
requisitos do HOLIS. Ns faremos isso nos prximos captulos. Nesse sentido, a
engenharia de sistemas prematura. Por outro lado, ns provavelmente entendemos o
suficiente para tomar as primeiras decises sobre o projeto do sistema, com base em
nossa experincia, e em nosso entendimento do que sejam esses requisitos. Em muitos
casos, ns no nos comprometemos ainda com qualquer coisa de hardware ou
software; podemos retomar essas questes posteriormente. No processo iterativo que
ser descrito posteriormente, ns veremos a arquitetura de sistemas e requisitos de
sistemas interativamente, de tal forma que este no uma hora ruim para comear.
Necessidades Preliminares do Usurio

Deixe-nos assumir que j definirmos e entendemos, razoavelmente bem, algumas
das necessidades do usurio do sistema HOLIS.
O HOLIS precisar suportar chaves soft chaves individualmente

programveis usadas para ativar as caractersticas de luminosidade nos diversos
espaos da casa.
O proprietrio solicitou que houvesse algo para programar o HOLIS a partir de
uma central remota, de tal forma que ele pudesse simplesmente chamar quando
precisasse ao invs de ter que perder tempo em programar o HOLIS.
Outros futuros compradores solicitaram que o HOLIS pudesse ser programado a
partir de seus computadores pessoais e que fosse fornecida a habilidade de fazer,
eles mesmos, todas as instalaes, programaes e manutenes.
Outros, ainda, requisitaram que o sistema fornecesse um painel de controle
simples um tipo de interface simples onde eles pudessem mudar no HOLIS, a
programao, configurar atividades de frias, entre outras, sem ter que usar o PC.
O HOLIS precisa fornecer um sistema de contato para emergncias de algum
tipo.
Anlise do Problema
Ao analisar o problema, a equipe decidiu, inicialmente, desenvolver trs
declaraes do problema, um dos quais estabelece, aparentemente, o problema
bvio sob a perspectiva da empresa.
54
Elementos
O problema
afeta
devido
Os benefcios desse
Descrio
do baixo crescimento apresentado na principal rea de
atuao da empresa: iluminao profissional de teatros
a empresa, seus empregados e seus acionistas,
ao desempenho inaceitvel e substancial falta de
oportunidades de crescimento em rendimento e
lucratividade.
novo produto e desse novo mercado em potencial para os
produtos e servios da empresa so:
Revitalizao da empresa e de seus empregados
Elevao da lealdade e conservao dos
distribuidores da empresa
Alto rendimento e lucratividade
Tendncia de valorizao das aes da empresa
Ento a equipe tambm decidiu ver se podiam entender o problema a partir da

perspectiva de um futuro cliente (usurio final) e potenciais distribuidores/
construtores (clientes da Lumenations):
Elementos
O problema
afeta
devido
Os benefcios desse
Elementos
O problema
afeta
devido
Os benefcios desse
Descrio
da falta de opes de escolha de produtos, da
funcionalidade limitada, e alto custo dos sistemas de
iluminao de residncias
os proprietrios de sistemas residenciais de ltima
gerao
ao desempenho inaceitvel dos sistemas adquiridos ou,
com maior freqncia, a deciso por no automatizar sua
residncia.
sistema de automao para correta de iluminao so:
Alta satisfao dos proprietrios e orgulho de possulo.
Elevada flexibilidade e usabilidade da residncia.
Melhoria na segurana, conforto e convenincia.
Descrio
a falta de opes para escolha de produtos, da
funcionalidade limitada, e alto custo dos sistemas de
iluminao de residncias
os distribuidores e construtores de sistemas residenciais
de ltima gerao
a poucas oportunidades de diferenciao no mercado e
nenhuma nova oportunidade para aumentar a margem de
lucro.
sistema de automao para correta de iluminao so:
Diferenciao.
Alto rendimento e alto lucro.
Aumento na participao de mercado.
55
HOLIS: O Sistema, Atores e Stakeholders

Deixe-nos voltar ao nosso projeto de engenharia de sistemas. Da perspectiva do
sistema, a nossa primeira impresso do sistema HOLIS simplesmente de um
sistema dentro da residncia do proprietrio. A Figura 65 ilustra um simples
diagrama mostrando o HOLIS no contexto da residncia do proprietrio.
HOLIS
Figura 65
Contexto do sistema: HOLIS no seu ambiente
O passo 3 da anlise do problema requer que ns identifiquemos os stakeholders e

usurios do sistema. O passo 4 da anlise do problema diz para definir a fronteira
da soluo sistmica. Dado que as informaes sobre as necessidades do usurio
foram apresentadas, podemos agora aprimorar nosso entendimento do contexto do
sistema HOLIS identificando os atores que iro interagir com o HOLIS. A Figura
66 ilustra 4 atores:
1. O proprietrio que usa o HOLIS para controlar a luminosidade.
2. As vrias lmpadas que o HOLIS, por sua vez, controla.
3. Servios da Lumenations, o fabricante que tem a habilidade para
remotamente conectar-se ao HOLIS e realizar programaes
remotamente.
4. Receptor de Emergncias, um ator indefinido que ir receber
mensagens de emergncia.
HOLIS
Lm padas
Proprietrio
Servios da
Lum enations
Figura 66
Recebedor de
Em ergncias TBD
HOLIS com atores

56
Naturalmente, a equipe tambm descobriu vrios stakeholders no-atores, tanto

internos quanto externos empresa, preocupados com os requisitos do HOLIS,
como mostra a Tabela 61.
Tabela 61
Stakeholders no-atores do HOLIS
Nome
O Distribuidor
Externo
Construtores
Eletricistas
Contratados
Comentrios
Clientes diretos da Lumenations.
Clientes dos Clientes da Lumenations: o contratado
geral responsvel pela construo da residncia.
Responsvel pela instalao e suporte.
Equipe de
Desenvolvimento
Interno
Equipe da Lumenations.
Gerente de
Marketing/Produto
Ser representado pela Cathy, gerente de produto.
Gerente Geral da
Lumenations
Financiamento e contabilidade dos resultados.
Engenharia de Sistemas do HOLIS

Agora que ns entendemos os atores externos do HOLIS, permita-nos fazer
algumas consideraes, em nvel sistmico, para ver como podemos particionar
HOLIS em subsistemas. Este processo pode ser bem dirigido pelos seguintes tipos
de pensamentos da engenharia de sistemas:
Seria bom se ns pudssemos ter software comuns tanto nos dispositivos de

controle quanto no PC do proprietrio; ns iremos pegar uma implementao
baseada no PC para ambos os elementos do sistema.
Ns ainda no estamos certos quanto flexibilidade que estamos precisando nas
chaves soft remotas, mas claro que iro existir muitos deles, e que alguns iro
estar distantes da unidade de controle principal, e que ns provavelmente
precisaremos de alguma comunicao inteligente entre eles e a unidade de
controle.
Com este pensamento minimalista, ns podemos surgir com uma nova

perspectiva do sistema, aquela em que o HOLIS, o sistema, seja composto de trs
subsistemas: Chaves de Controle, o dispositivo de chaveamento remoto
programvel; Unidade de Controle Central, o sistema de controle de computador
central; e o Programador PC, o sistema PC opcional que alguns proprietrios
requisitaram. Agora, o diagrama de bloco apresentado na figura 67.
57
Lm padas
HOLIS 2000
Proprietrio
Chave de
Controle
Unidade de
Controle Central
Recebedor de
Em ergncias TBD
HOLIS 2000
Proprietrio /
Programador
Figura 67
Servios da
Lum enations
Programador PC
(opcional)
HOLIS com subsistemas e atores
Note que ns acabamos de identificar cinco atores o proprietrio novamente

mas que desta vez, usa o PC para programar o HOLIS ao invs de ligar e desligar
lmpadas. Este ator Proprietrio/Programador possui, neste papel, diferentes
necessidades para o sistema e assim um ator distinto do sistema. Ns iremos
ver, mais tarde, os diversos comportamentos que o ator espera do HOLIS.
Os Subsistemas do HOLIS
A partir da perspectiva da engenharia de sistema e de requisitos, o problema
torna-se um pouco mais complexo. Alm da necessidade de entender os requisitos
do HOLIS, o sistema, ns iremos agora precisar, tambm, entender os requisitos
nicos para cada um dos trs subsistemas. Ns podemos usar nosso paradigma de
ator novamente, no prximo nvel de decomposio do sistema. Ao se fazer isso,
surgem trs novos diagramas de blocos: Figuras 68, 69, e 610.
HOLIS 2000
Proprietrio
Figura 68
Chave de
Controle
Unidade de
Controle Central
Subsistema Chave de Controle com seus atores
58
Na Figura 68, quando vemos sob a perspectiva da Chave de Controle,

encontramos um outro ator: Unidade de Controle Central (UCC), um outro
subsistema. Em outras palavras, da perspectiva do subsistema Chave de Controle,
o UCC um ator, e precisaremos entender mais tarde quais tipos de requisitos e
use cases a Chave de Controle ter que ter em funo da UCC. Este conjunto de
requisitos derivado da nossa decomposio do sistema.
HOLIS 2000
Proprietrio /
Programador
Figura 69
Programador PC
(opcional)
Unidade de
Controle Central
Subsistema Programador PC com seus atores
Na Figura 69, a perspectiva do sistema sob o ponto de vista do Programador PC,

ns vemos que no aprendemos qualquer coisa nova, ao menos em termos de
atores e subsistemas, eles foram todos identificados anteriormente. A Figura 6
10, no entanto, apresenta-se uma viso um pouco mais rica, e ns vemos que
UCC possui mais atores do que qualquer outro. Isso parece fazer sentido, se ns
pensarmos que a UCC o crebro do HOLIS, e faz sentido pensar que ele tem
muitas coisas a fazer e muitos atores a atender.
Proprietrio /
Programador
Programador PC
(opcional)
Lm padas
HOLIS 2000
Recebedor de
Em ergncias TBD
Unidade de
Controle Central
Chave de
Controle
Figura 610
Servios da
Lum enations
Subsistema Unidade Controle Central com seus atores
59
Tabela 62
Restries do projeto HOLIS
Nome
Lgica
A verso 1.0 dever ser liberada

para manufatura em 5 de Janeiro
de 2000.
A nica oportunidade de
lanamento do produto neste ano.
A equipe deve adotar a

modelagem UML, mtodos
baseados em OO, e o Processo de
Desenvolvimento Unificado.
Ns acreditamos que estas

tecnologias fornecem aumento de
produtividade e produzem sistemas
robustos.
Devido consistncia e, tambm,

O software para a Unidade de
Controle Central e o Programador manutenibilidade, pois a equipe
PC devem ser escritos em C++. A conhece estas linguagens.
linguagem Assembly ser usada na
Chave de Controle.
Um prottipo do sistema deve ser

apresentado numa exposio
comercial de Automao
Residencial em Dezembro.
Para obter pedidos de distribuidores

do Q1 FY 2000.
O subsistema de
microprocessamento da Unidade
de Controle Central deve ser
copiado da diviso profissional de
projetos de sistemas de iluminao
avana (ALSP).
um projeto existente e uma pea

existente em estoque.
Apenas o Programador PC dever

ser compatvel com o Windows
98.
Faz parte do escopo de

gerenciamento para a liberao da
verso 1.0.
Contratar no mximo dois

empregados, de tempo integral,
somente aps o trmino da fase de
concepo, quando as habilidades
necessrias ao projeto estaro
determinadas.
Contratao mxima permitida para

expanso da equipe.
O microprocessador KCH5444
deve ser usado na Chave de
Controle.
J em uso pela companhia.
Aquisies de componentes de
software possvel, contanto que
no exista nenhuma obrigao de
pagamentos contnuos de royalty
pela empresa.
Nenhum custo de longo prazo

poder causar impacto no custo de
software.
#ID
Por agora, isto o suficiente para a anlise do problema e engenharia de sistemas

do HOLIS. Ns iremos retornar a este caso de estudos nos prximos captulos.
60
Sumrio da Habilidade de Equipe 1

A Habilidade de Equipe 1, Analisando o Problema, introduziu um conjunto de
habilidades que sua equipe pode aplicar para entender o problema a ser resolvido
antes de comear o desenvolvimento da aplicao. Ns introduzimos de forma
simples, os cinco passos da tcnica de anlise de problemas que podem ajudar a
sua equipe a conseguir obter melhor entendimento do problema a ser resolvido.
1.
2.
3.
4.
5.
Chegar ao acordo sobre a definio do problema.

Entender a causa raiz do problema o problema por detrs do problema.
Identificar os stakeholders e usurios.
Definir a fronteira da soluo sistmica.
Identificar as restries que sero impostas soluo.
A anlise do problema desta forma sistemtica, ir aperfeioar a habilidade de sua

equipe em atacar futuros desafios fornecendo uma soluo do problema a ser
resolvido.
Ns tambm apontamos as vrias tcnicas que podem ser usadas na anlise do
problema. Em especial, vimos modelagem de negcios, a qual funciona bem
para sistemas de informao complexos que sustentam as principais infraestruturas do negcio. A equipe pode usar a modelagem de negcios tanto para
entender como o negcio funciona, quanto para definir onde o sistema, dentro do
negcio, pode ser aplicado de forma mais produtiva. Reconhecemos tambm que
o modelo de negcio que definimos possui construtores paralelos aos das
aplicaes de software, e usamos esta semelhana para reproduzir as fases de
projeto de software. Ns iremos usar os use cases de negcio que descobrimos
para ajudar a definir os requisitos da aplicao.
Para a classe de aplicaes de software a qual denominamos de sistemas
embutidos, usamos o processo de engenharia de sistemas como uma tcnica de
anlise de problemas que nos ajuda a decompor sistemas complexos em
subsistemas. Este processo nos ajuda a entender onde as aplicaes de software
devero estar e qual o seu principal propsito. Ao fazer isso, aprendemos que
complicamos o assunto de requisitos devido o surgimento de novos subsistemas,
os quais devemos entender os requisitos a serem impostos.
61
Entendendo as Necessidades dos
Usurios
Captulo 7: Os Desafios da Elucidao de Requisitos

Captulo 8: As Caractersticas de um Produto ou Sistema
Captulo 9: Entrevistando
Captulo 10: O Workshop de Requisitos
Captulo 11: Brainstorming e Reduo de Idias
Captulo 12: Storyboarding
Captulo 13: Aplicando Use Cases
Captulo 14: Role Playing
Captulo 15: Prototipao
62
O fator mais comum

entre os desafios de
projetos foi falta de
informaes de
usurios (Standish
Group, 1994)
Um estudo publicado pela Standish Group citou a Falta de informaes de usurios

como o fator mais comum entre os desafios de projetos. Embora 13% dos
entrevistados tivessem citado as causas razes como o principal fator, 12% citaram as
especificaes e requisitos incompletos como fator principal. A partir disso, tornou-se
aparente que a falta de entendimento das reais necessidades dos usurios (e
provavelmente de outros stakeholders) representava mais de um quarto de todos os
desafios de projeto, e era o problema mais srio que interferia para o sucesso do projeto.
A menos que, num belo dia, todos os usurios do mundo acordassem repentinamente, e
comeassem dispostos a entender, e a comunicar seus requisitos, a equipe de
desenvolvimento ter que tomar sua iniciativa. Em outras palavras, nossa equipe
precisar desenvolver a habilidade necessria para elucidar esses requisitos.
Needs
Problema
Na Habilidade de Equipe 1, ns desenvolvemos a habilidade que ajudar a entender o

problema a ser resolvido. Na Habilidade de Equipe 2, ns descrevemos vrias tcnicas
que a equipe de desenvolvimento pode usar para obter e entender as reais necessidades
na perspectiva de usurios e stakeholders. Fazendo isso, comeamos a ganhar
compreenso dos potenciais requisitos do sistema que pretendemos desenvolver para
satisfazer essas necessidades. Enquanto estivermos fazendo isso, ns iremos nos
concentrar principalmente nas necessidades dos stakeholders, que vivem no topo da
pirmide de requisitos.
As tcnicas que iremos ver variam desde a simples, inexpressivas, e extremamente
simples, tal como a tcnica de entrevista, at s mais modestas e caras tal como a tcnica
de prototipao. Embora nenhuma das tcnicas seja perfeita para todas as situaes, a
exposio dessas vrias tcnicas ir fornecer um rico conjunto de habilidades a partir das
quais a equipe poder escolher. A cada projeto especfico, a equipe poder escolher entre
as vrias tcnicas, aquela que achar mais apropriada e aplic-la de acordo com a
experincia e conhecimentos obtidos anteriormente na elucidao de requisitos em
outros projetos. Desta forma, a equipe ir desenvolver um conjunto de habilidades que
podero contribuir ativamente para aperfeioamento dos resultados.
63
Captulo 7
Os Desafios da Elucidao de
Requisitos
Pontos chaves
A elucidao de requisitos influenciada por trs sndromes endmicas.
A sndrome Sim, mas origina-se da natureza humana e da incapacidade dos
usurios de perceberem o software da mesma forma que eles percebem os
dispositivos de hardware.
Procurar requisitos como procurar por Runas Desconhecidas; quanto mais
voc encontra, mais voc conhece.
A sndrome do Usurio e o Desenvolvedor reflete a profunda diferena entre
os dois, tornando difcil comunicao.
os prximos captulos, ns veremos uma variedade de tcnicas para

elucidar requisitos do sistema a partir de seus usurios e outros
stakeholders2. Este processo extremamente simples. Sente-se com os
futuros usurios do sistema e com outros stakeholders e pergunte o que
eles querem que o sistema faa.
Ento, por que to difcil? Por que precisamos de tantas tcnicas? Alis, por que
precisamos desta habilidade de equipe, afinal de contas? A fim de apreciar por
completo este particular problema, deixe nos mostrar as trs sndromes que
parecem complicar imensamente esta matria.
Obstculos da Elucidao
A Sndrome do Sim, Mas
Um dos mais frustrantes, impregnantes e sinistros problemas do desenvolvimento
de aplicaes o que ns conhecemos como a sndrome do Sim, Mas, sendo
observado nas reaes de usurios para todas as peas de software que
desenvolvemos. Qualquer que seja a razo, sempre observamos duas reaes
imediatas, distintas e separadas quando o usurio v a implementao do sistema
pela primeira vez:
Uau, que legal! Podemos realmente fazer isso! Fantstico; parabns!, e

assim por diante.
Sim, mas, hummmmm, como eu vejo isso? Para que serve esse ...? No
seria melhor se ...? O que acontece se ...?
Ns usamos o termo usurio genericamente neste contexto. As tcnicas para elucidar requisitos do sistema se
aplicam a todos os stakeholders, sejam usurios ou no-usurios.
64
As razes da sndrome Sim, Mas parece repousar profundamente na natureza do

software como um processo intelectual intangvel. Para piorar ainda mais as
coisas, nossa equipe de desenvolvimento normalmente contribui com o problema
deixando de fornecer precocemente o cdigo produzido aos usurios, para que
eles possam interagir e avaliar os resultados.
A reao dos usurios faz parte da natureza humana e ocorre em vrias outras
circunstncias do dia-a-dia. Os usurios que no viram o seu sistema ou qualquer
outro similar, no entendero o que voc pensou quando descreveu o sistema, e
agora que esto na frente do sistema agora, pela primeira vez, depois de meses
ou anos de espera eles tem a oportunidade de interagir com o sistema. Agora,
adivinhe o acontece? O sistema no exatamente o que eles esperavam que fosse!
Por analogia, deixe-nos comparar este processo de software com o
desenvolvimento de dispositivos mecnicos cujas tecnologias e processos de
desenvolvimento antecedem o software por uns meros cem anos. Sistemas
mecnicos possuem uma disciplina razoavelmente bem definida dos modelos de
prova de conceitos, moldes, modelos, prototipao incremental, dispositivos de
produo piloto, entre outros, todos eles possuindo aspectos tangveis e a maioria
visvel, perceptvel e atua como dispositivos que est sendo desenvolvido.
Os usurios podem ver os dispositivos precocemente, toc-los, pensar sobre eles,
ou mesmo interagir com eles antes mesmo dos detalhes de implementao
estarem finalizadas. verdade que tecnologias especficas, tal como a litografia,
onde um rpido prottipo construdo durante a noite a partir da injeo de um
lquido viscoso a alta temperatura, foram desenvolvidas exclusivamente com o
propsito de fornecer o feedback imediato e precoce da definio conceitual do
produto. Apesar disso, no software, com sua enorme complexidade, esperamos
fazer direito logo na primeira vez!
Embora possa ser frustrante, aceitar a sndrome Sim, Mas como uma realidade
pode ajudar a discernir a realidade e auxiliar os membros da equipe a reduzirem
esta sndrome em futuros projetos.
A sndrome Sim, Mas faz parte da natureza humana e parte integral do

desenvolvimento de aplicaes.
Podemos reduzir drasticamente esta sndrome aplicando tcnicas que
busquem os Mas desde o incio. Ao fazer isso, elucidamos as respostas
do Sim, Mas no incio, e ento podemos comear a investir a maior
parte dos esforos de nosso desenvolvimento no software que j tenha
passado pelo teste do Sim, Mas.
A Sndrome das Runas Desconhecidas

Uma vez, um de nossos amigos foi ser guia de um nibus de turismo na Four
Corners area, uma rea definida por fronteiras comuns dos estados do Colorado,
Novo Mxico, Utah e Arizona. A rota do nibus de turismo inclua o majestoso
pico da cadeia de montanhas La Plata, a extenso das antigas runas Anasazi do
Mesa Verde e reas prximas. As perguntas dos turistas so uma constante fonte
de divertimento entre as equipes de guias tursticos e criam certos folclores no
negcio de turismo. Numa estao de vero, nosso amigo nos contou qual era a
65
pergunta mais estpida, realizada por um turista estpido, da qual ele mais
gostava: Bem, hummmmm, quantos runas desconhecidas existem?.
De certa forma, a busca por requisitos como uma busca por runas
desconhecidas: Quanto mais os encontramos, mais os conhecemos. Voc nunca
sentir que encontrou todos, e talvez voc nunca encontre. De fato, as equipes de
desenvolvimento de software, de todas as partes do mundo, esforam-se
continuamente em determinar quando finalizar a elucidao de requisitos, isto ,
determinar o momento em que eles tero encontrado todos os requisitos essenciais
ou, ao menos, encontrado o suficiente.
A fim de auxiliar a equipe a atacar esse problema, ns fornecemos vrias tcnicas,
tanto no captulo Habilidade de Equipe 2 quanto nos posteriores. Naturalmente,
como descrevemos no Captulo 1, muito importante gastar tempo em o analisar
problema para identificar todos os stakeholders do sistema, porque muitos desses
stakeholders no-usurios so normalmente detentores de requisitos
desconhecidos. No entanto, da mesma forma que o problema de encontrar todas
as runas desconhecidas, devemos adverti-lo de que estamos numa misso que
pode nunca terminar. Mas entendemos tambm que em algum ponto, estaremos
aptos a dizer com segurana, Ns descobrimos o suficiente.
A Sndrome Usurio e o Desenvolvedor

Tcnicas de elucidao de requisitos no so novas. Desenvolvedores de
aplicaes tm as perseguido por mais de 40 anos para fazer um bom trabalho.
Ento, o que poderia explicar o fato de que entender as necessidades do usurio
permanece um de nossos maiores problemas? Bem, considerando o fato de que
alguns poucos desenvolvedores de aplicao tiveram treinamento em tcnicas de
elucidao, isso talvez no seja uma grande surpresa.
A terceira sndrome surge da lacuna de comunicao entre usurios e
desenvolvedores. Chamamos esta sndrome de Usurio e o Desenvolvedor.
Usurios e desenvolvedores so, normalmente, de mundos diferentes, falando
linguagens diferentes e tendo diferentes experincias, motivaes e objetivos.
De certo modo, ns devemos aprender a nos comunicar mais efetivamente com
esses usurios de outras tribos. Num artigo sobre essa matria, Laura Scharer
(1981) descreve esta sndrome e fornece algumas orientaes para ajudar a
reduzir o problema. Combinando suas palavras com as nossas experincias, a
Tabela 71 sumariza tanto as razes para este problema quanto sugere algumas
solues.
A esperana que com um melhor entendimento, tanto da natureza desses
problemas quanto das abordagens para mitig-los, desenvolvedores possam estar
melhores preparados para os futuros trabalhos de interesse.
66
Tabela 71
A sndrome Usurio e o Desenvolvedor
Problema
Soluo
Usurios no sabem o que querem,

ou sabem o que querem, mas no
sabem dizer.
Reconhecer e apreciar o usurio como

especialista do domnio; tentar tcnicas
alternativas de comunicao e elucidao.
Usurios pensam que sabem o que

querem at que os
desenvolvedores lhes digam o que
eles disseram que queriam.
Fornecer tcnicas de elucidao

alternativas o quanto antes: storyboarding,
role playing, prottipos descartveis, entre
outros.
Analistas pensam que entenderam

o problema do usurio melhor do
que os prprios usurios.
Coloque o analista no lugar do usurio.

Faa com que o analista interprete o papel
do usurio durante uma hora ou um dia.
Todos acreditam que todos esto

politicamente motivados.
Sim, faz parte da natureza humana, ento

vamos continuar com o programa.
Tcnicas de Elucidao de Requisitos

Alcanar melhor entendimento das necessidades do usurio leva-nos do domnio
de bits e bytes, onde muitos desenvolvedores esto mais confortveis, para o
domnio das pessoas reais e problemas do mundo real. Da mesma forma que
vrias tcnicas podem ser usadas para analisar e projetar solues de software,
vrias tcnicas podem ser usadas para entender necessidades de usurios e
stakeholders. Algumas tcnicas so seguidas por equipes de projeto em
circunstncias particulares.
Nos Captulos 4, 5 e 6, ns iniciamos nosso passeio com a anlise do problema,
um conjunto de questes que podemos fazer sobre as restries que sero
impostas ao sistema, a tcnica de modelagem de negcio que podemos usar para
vrias aplicaes, e a tcnica de engenharia de sistemas que podemos aplicar para
sistemas complexos. Nos captulos seguintes, descreveremos tcnicas que
provaram ser efetiva em atacar as trs sndromes que acabamos de discutir. Entre
as tcnicas que iremos discutir esto:
Entrevistas e questionrios
Workshops de requisitos
Brainstorming e reduo de idias
Storyboards
Use cases
Role playing
Prototipao.
A escolha de uma tcnica especfica varia, dependendo do tipo de aplicao, a

habilidade e sofisticao da equipe de desenvolvimento, a habilidade e
sofisticao do cliente, a escala do problema, urgncia da aplicao, a tecnologia
usada, e da exclusividade da aplicao.
67
Captulo 8
As Caractersticas (Features) de um
Produto ou Sistema
Pontos chaves
A equipe de desenvolvimento deve interpretar um papel mais ativo na
elucidao dos requisitos do sistema.
As caractersticas (features) do produto ou sistema so expresses de alto nvel
do comportamento desejado do sistema.
Caractersticas do sistema devem estar limitadas a 25-99, com menos que 50
preferivelmente.
Atributos fornecem informaes adicionais sobre as caractersticas.
ps apresentar alguns problemas nos captulos anteriores, ficou claro que

a equipe de desenvolvimento raramente, se no nunca, tem em mos uma
especificao perfeita, ou talvez razovel, que possa ser usada como base
para o desenvolvimento do sistema. No Captulo 7, aprendemos sobre as
razes disso. Uma concluso que chegamos foi que, se ns no nos prepararmos
para dar as melhores definies, ns no iremos colher os resultados. Em outras
palavras, a fim de obter sucesso, a equipe de desenvolvimento ter que interpretar
mais ativamente seu papel na elucidao de requisitos. Como descobrimos,
embora possamos delegar a maioria das responsabilidades para um lder snior,
analista, ou gerente de produto, no final, toda a equipe estar envolvida com um
ou mais pontos do processo.
Stakeholders e Necessidades do Usurio

Needs
Parece bvio, mas a equipe de desenvolvimento somente ir construir sistemas

melhores quando eles entenderem as reais necessidades (needs) dos stakeholders.
Esse entendimento dar equipe a informao que necessita para tomar melhores
decises na definio e implementao de sistemas. Esse conjunto de
informaes, o qual chamamos de necessidades (needs) de stakeholders, ou
simplesmente de necessidades do usurio, fornece a pea central do quebracabea.
Normalmente, as necessidades do usurio so vagas e ambguas. Por exemplo,
seu stakeholder pode dizer: Eu preciso de algo fcil para saber o estado do meu
estoque ou Eu gostaria de ver um grande aumento de produtividade nas
entradas dos pedidos de venda. Mesmo assim, essas declaraes definem o
contexto mais importante de todas as outras atividades que viro. Por serem to
importantes, gastaremos algum tempo e energia tentando entend-los. Ns
definimos uma necessidade (needs) do stakeholder como:
68
uma reflexo de negcio, pessoal ou de problema operacional (ou de oportunidade) que deve ser
atendida a fim de justificar a considerao, compra ou uso de um novo sistema.
Caractersticas (Features)
Uma coisa interessante que ocorre, quando entrevistamos stakeholders para
conhecer suas necessidades ou os requisitos para um novo sistema, que
normalmente, esses stakeholders no falam nada disso, ao menos em termos das
definies que fornecemos anteriormente. Esses stakeholders no dizem a voc
nenhuma de suas reais necessidades Se eu no aumentar a produtividade deste
departamento, eu no ganharei meu bnus este ano ou Eu quero reduzir a
velocidade deste veculo o mais rpido que puder sem derrapar nem os reais
requisitos do sistema Eu preciso reduzir o tempo de processar as transaes de
entrada dos pedidos de venda em 50% ou O veculo deve ter um sistema de
controle computadorizado para cada roda. Ao invs disso, eles descrevem o que
acham ser uma abstrao de algo como Eu necessito de uma nova tela de entrada
de pedidos baseado em GUI e Eu quero um veculo com ABS.
Denominamos essas expresses de alto nvel sobre o comportamento desejado do
sistema de caractersticas (features). Essas caractersticas no so, normalmente,
bem definidos e podem at, serem conflitantes entre si. Eu quero aumentar a
mdia de processamento de pedidos e Eu quero fornecer uma interface
amigvel para ajudar os novos empregados aprenderem a usar o sistema mas
eles so, no entanto, uma representao das reais necessidades.
O que est acontecendo nesta discusso? O stakeholder j traduziu a necessidade
real (produtividade e segurana) no comportamento do sistema o qual ele acha
que ir atender s suas necessidades (veja Figura 81). Ao fazer isso, o o que (Eu
necessito) foi substitudo pelo como (O que eu penso que o sistema deva fazer
para satisfazer esta necessidade). Isso no uma coisa ruim, nas vezes quando o
usurio tem real especialidade do domnio e real percepo do valor da
caracterstica. Tambm, por causa da facilidade de se discutir tais caractersticas
em linguagem natural, document-las e comunic-las aos outros, adicionam
tremenda riqueza ao esquema de requisitos.
Need
Necessidade?
Features
Caracterstica?
Requisitos de
Software
Figura 81
As necessidades e caractersticas esto intimamente relacionadas
69
Caractersticas so
formas convenientes
de descrever as
funcionalidades sem
ter que se atolar em
detalhes.
No entanto, existe uma interrupo no processo desta discusso, qual seja: Se a

equipe abandonar a discusso sem um entendimento das reais necessidades por
detrs das caractersticas, ento haver um real risco. Se as caractersticas no
resolverem as reais necessidades por alguma razo, ento o sistema poder falhar
em atender os objetivos dos usurios, mesmo que a implementao tenha sido
derivada das caractersticas que foram exigidas.
Em qualquer caso, ns encontramos esta abstrao de alto-nvel essas
caractersticas so formas teis e convenientes de descrever funcionalidades de
um novo sistema sem se atolar em detalhes. De fato, ns dirigimos a maior parte
de nossas atividades de requisitos a partir desta idia de caracterstica.
No comeo, definimos uma caracterstica como:
um servio que o sistema fornece para atender um ou mais necessidades dos stakeholders.
Com esta definio, caractersticas de usurios no podem estar to longe das
necessidades e temos uma maneira cmoda de iniciar a definio do sistema.
Nosso foco est em entender as necessidades dos usurios a fim de elucidar e
organizar as necessidades e caractersticas do sistema proposto. Algumas vezes,
obtermos todas as necessidades e nenhuma caracterstica. Algumas vezes obtemos
todas as caractersticas e nenhuma necessidade. Algumas vezes ns no somos
capazes de perceber a separao. Mas, desde que tomemos cuidado em distinguilos em nossas mentes, poderemos, a todo o momento, aprender informaes
valiosas sobre o que o sistema deve fazer.
A caractersticas so facilmente descritas em linguagem natural e consiste de uma
frase curta; alguns exemplos so mostrados na Tabela 81. Raramente, ou nunca,
caractersticas so elaboradas em maiores detalhes. Caractersticas so tambm
construtores muito teis para dar incio do gerenciamento do escopo do projeto,
para estabelecer negociaes e processos de acordo. A declarao de
caractersticas no exige uma grande quantidade de investimento, e so fceis de
descrev-las e relacion-las.
Tabela 81
Exemplos de caractersticas
Domnio da Aplicao
Exemplo de uma Caracterstica (Feature)
Sistema de controle de elevador

Sistema de controle de estoque
Controle manual de portas durante incndios.

Fornecer o estado de todos os itens de
estoque.
Fornecer informaes de tendncia e
qualidade do produto
Relatrio de dedues por data e por
categoria.
Configurao para longos perodos de
ausncias.
Obrigatoriedade de no mnimo duas
confirmaes de ataque.
Compatibilidade com o Windows 2000.
Sistema de rastreamento de
defeitos
Sistema de pagamento
HOLIS (Sistema de automao
de iluminao de residncias)
Sistema de controle de armas
Aplicao de uma copiadora
70
Gerenciando a Complexidade Escolhendo o Nvel de Abstrao

Caractersticas do
sistema devem estar
limitadas a 25-99,
com menos que 50
preferivelmente.
O nmero de caractersticas que consideramos para ns mesmos ir efetivamente

determinar o nvel de abstrao da definio. Para gerenciar a complexidade de
sistemas que estamos vislumbrando, seja de um novo sistema ou incremento de
um sistema existente, recomendamos que existam entre 25 a 99 caractersticas,
abstradas em nvel suficientemente alto, sendo melhor pouco menos de 50.
Desta forma, uma quantidade relativamente pequena e gerencivel de
informaes fornecem a base compreensiva e completa para a definio do
produto, a comunicao com os stakeholders, o gerenciamento de escopo, e o
gerenciamento de projeto. Com 25 a 99 caractersticas convenientemente
categorizadas e organizadas, podemos estar aptos a descrever e comunicar a
estrutura: do sistema, do nibus espacial (reentrada e reuso) ou de uma
ferramenta de software (tendncia automtica de defeitos).
Em Habilidade de Equipe 5, tais caractersticas sero transformadas em requisitos
especficos, suficientemente detalhadas para permitir a implementao. Ns
iremos chamar aqueles de requisitos de software para diferenci-los de outras
caractersticas de alto-nvel. Ns iremos lidar com estas necessidades para
incrementar a especificao posteriormente. Por agora, no entanto, ns iremos
manter nosso pensamento em nvel de caractersticas.
Atributos das Caractersticas do Produto

A fim de ajudar a melhor gerenciar esta informao, introduzimos a noo de
atributos de caractersticas, ou elementos de dados que fornecem informaes
adicionais sobre o item. Atributos so usados para associar a caracterstica ou
dados de requisitos a outros tipos de informaes de projeto. Ns podemos usar
atributos para rastrear (nome ou identificador nico, estado, dados histricos,
alocao, rastreado para, entre outros), para priorizar (campo de prioridade), e
para gerenciar (estado) as caractersticas propostas para a implementao. Por
exemplo, o atributo prioridade pode ser usado para capturar os resultados da
votao cumulativa numa sesso de brainstorming; o atributo nmero da verso
pode ser usado para registrar as liberaes de software especficas com as
caractersticas especficas que pretendemos implementar.
Por anexar vrios atributos s caractersticas, voc pode gerenciar melhor a
complexidade da informao. Embora no existam limites para os tipos de
atributos que voc pode ter, a experincia tem demonstrado que alguns atributos
comuns de caractersticas se aplicam a muitas circunstncias de projeto (Tabela 8
2). No restante deste volume, usaremos esses atributos para ajudar a gerenciar a
complexidade dos dados de caractersticas e requisitos e para gerenciar
relacionamentos, tais como as dependncias entre os vrios tipos de requisitos do
sistema.
Assim, deixe-nos prosseguir com algumas habilidades de equipe que ir nos
ajudar a obter as informaes que ns precisamos. Ns comearemos com a
entrevista (Captulo 9).
71
Tabela 82
Atributo
Atributos de caractersticas
Descrio
Estado
Rastreia o progresso durante a definio do baseline do

projeto e desenvolvimento subseqentes. Exemplo:
Proposto, Aprovado e Incorporado.
Prioridade / Benefcio Nenhuma caracterstica criada da mesma forma.
Classificao por prioridade relativa ou beneficio para o
usurio final abre um dilogo entre stakeholders e
membros da equipe de desenvolvimento. Usado no
gerenciamento de escopo e determinao de prioridade.
Exemplo: Crtico, Importante e til.
Esforo
Estimar o nmero da equipe ou pessoas-ms, linhas de
cdigo ou pontos de funo, ou apenas o nvel geral do
esforo ajuda configurar expectativas de o que pode e
no pode ser executado num dado quadro de tempo.
Exemplo: Baixo, Mdio e Alto.
Risco
Uma medida de probabilidade que a caracterstica ir
causar eventos indesejveis, tais como exceder custo,
atrasar o cronograma, ou mesmo cancelamento.
Exemplo: Alto Mdio e Alto.
Estabilidade
Uma medida de probabilidade de que a caracterstica ir
mudar ou de que o entendimento da equipe sobre as
caractersticas que iro mudar. Usado para ajudar a
estabelecer prioridades de desenvolvimento e determinar
aqueles itens para os quais elucidao adicional a
prxima ao apropriada.
Meta de liberao
Registro das verses pretendidas de produtos, onde as
caractersticas aparecero pela primeira vez. Quando
combinado com o campo Estado, sua equipe pode
propor, registrar e discutir vrias caractersticas sem
liber-las para o desenvolvimento.
Associado a
Em muitos projetos, caractersticas estaro associadas a
equipes de caractersticas responsveis em promover a
elucidao, escrever os requisitos de software, e talvez
realizar a implementao.
Razo
Usado para rastrear a fonte das solicitaes de
caractersticas. Por exemplo, a referncia pode ser a
pgina e o nmero da linha de uma especificao do
produto ou um marcador de minuto num vdeo de uma
importante entrevista do cliente.
72
Captulo 9
Entrevista
Pontos chaves
A entrevista uma tcnica simples e direta.
Questes livres de contexto podem nos ajudar a conduzir com tranqilidade as
entrevistas.
Ento, a entrevista pode ser apropriada para encontrar requisitos no
descobertos, por explorar solues.
Convergncias sobre algumas necessidades comuns iro iniciar um repositrio
de requisitos para ser utilizado durante o projeto.
Um questionrio no substitui uma entrevista.
ma das tcnicas mais importantes e mais simples de obteno de

requisitos a entrevista de usurios, uma tcnica simples e direta e que
pode ser usada em, virtualmente, qualquer situao. Este captulo
descreve o processo de entrevista e fornece um modelo genrico para
conduzir a entrevista de usurios e stakeholders. No entanto, o processo de
entrevista no fcil, pois nos fora a uma convivncia prxima e pessoal e a
enfrentar a sndrome Usurio e o Desenvolvedor.
Alm disso, uma das metas chaves da entrevista assegurar que a propenso e a
predisposio do entrevistador no interfira com a livre troca de informaes.
Este um problema sutil e pernicioso. Professores de sociologia (opa, uma outra
classe de profissional que ns evitamos!) nos ensinam que impossvel haver
relacionamentos entre pessoas sem o filtro do mundo, que o resultado de nosso
prprio ambiente e experincias acumuladas.
Alm disso, como fornecedores de soluo, raramente nos encontramos numa
situao em que no temos idia alguma sobre os tipos solues possveis que
possam atacar o problema. De fato, em muitos casos, operamos dentro de um
domnio ou contexto recorrente onde certos elementos da soluo so bvios, ou
ao menos nos parecem bvios. (Ns j resolvemos esse tipo de problemas antes,
e esperamos que nossa experincia se aplique totalmente neste caso. Afinal,
estamos apenas construindo casas, e martelos e pregos atendero bem a esse
propsito). Naturalmente, isso no ruim, porque o nosso contexto parte do
que temos de valor. Nosso ponto que no devemos deixar que o contexto
interfira no entendimento do real problema a ser resolvido.
O Contexto da Entrevista
As Questes livres de contexto
Ento, como evitar que nossas questes prejudiquem a resposta do usurio? Ns o
fazemos formulando questes sobre a natureza do problema do usurio, livre de
73
Uma questo livre

de contexto nos
ajuda a entender os
reais problemas sem
influenciar o
usurio.
qualquer contexto da potencial soluo. Para tratar deste problema, Gause e

Weinberg (1989) introduziram o conceito de questes livres de contexto. So
exemplos de tais questes:
Quem o usurio?
Quem o cliente?
As necessidades so diferentes?
Onde mais podemos encontrar solues para este problema?
Estas questes nos foram a ouvir antes de tentar inventar ou descrever uma
possvel soluo. Enquanto ouvimos, entendemos melhor o problema do cliente,
bem como quaisquer problemas por detrs dos problemas. Tais problemas afetam
a motivao e o comportamento do nosso cliente e devem ser atacados antes que
possamos apresentar uma soluo.
Questes livres de contexto possuem um paralelo com as questes ensinadas aos
vendedores como parte de uma tcnica chamada solues de venda. Nas
solues de venda, os vendedores usam uma srie de questes focalizadas sobre a
obteno inicial do entendimento do problema do cliente e quais solues, se
existe algum, o cliente j anteviu. A inteno dessas questes permitir que o
vendedor entenda totalmente o real problema do cliente, tal que solues efetivas
possam ser sugeridas e determinadas de acordo com os seus mritos especficos.
Este processo ilustra o valor das tcnicas de venda como um dos ingredientes da
soluo completa para o real problema do cliente.
A Importncia do Contexto da Soluo

Depois que as
questes livres de
contexto forem
formuladas, sugira
solues que possam
ser exploradas.
Em nossa busca por descobrir requisitos, pode tambm ser apropriado fazer
questes sobre o domnio onde as solues so exploradas depois que as questes
livres de contexto tiverem sido realizadas e respondidas. Afinal de contas, a
maioria de ns, normalmente, no nos satisfazemos somente em entender o
problema, mas em fornecer solues apropriadas para o problema a ser resolvido.
Esta adio do contexto da soluo pode dar ao usurio, novas percepes e
talvez at uma viso diferente do problema. E, naturalmente, nossos usurios
dependem de ns para ter o contexto; caso contrrio, eles teriam que nos ensinar
todas as coisas que eles conhecem sobre o assunto.
Como um auxlio construo desta habilidade dentro da equipe de
desenvolvimento, ns combinaremos essas tcnicas dentro da nossa entrevista
livre de contexto genrica, uma entrevista estruturada que pode ser usada para
elucidar solicitaes de usurios e stakeholders em muitos contextos da aplicao
de software. O modelo para esta entrevista fornecido na Figura 91. A entrevista
consiste tanto de sees livres de contexto quanto de sees no-livres de
contexto. Tambm fornece questes designadas para nos assegurar que todos os
aspectos dos requisitos, incluindo alguns daqueles requisitos te enganei de
segurana, suportabilidade, entre outros, tenham sido perfeitamente explorados.
74
Parte I: Estabelecendo o Perfil do Cliente ou Usurio

Nome:
Empresa:
Indstria:
Ocupao:
(As informaes acima podem, normalmente, ser preenchidas antecipadamente).
Quais so as suas responsabilidades?
Quais so os produtos do seu trabalho?
Para quem voc gera esses produtos?
Como medido o seu sucesso?
Quais so os problemas que interferem para o sucesso de seu trabalho?
O que, se existe, facilita ou dificulta o seu trabalho?
Parte II: Avaliando o Problema
Para quais problemas faltam boas solues (tipo de aplicao)?
Quais so? (Dica: Continue perguntando, Mais algum?).
Para cada problema, pergunte:
y Por que esse problema existe?
y Agora, como resolv-lo?
y Como voc poderia resolv-lo?
Parte III: Entendendo o Ambiente do Usurio
Quem so os usurios?
Qual a sua formao?
Qual a sua experincia em computao?
Os usurios so experientes nesse tipo de aplicao?
Quais plataformas so usadas?
Quais so os planos para a futura plataforma?
Outras aplicaes usadas so relevantes para essa aplicao? Se sim, fale um pouco sobre elas.
Quais so as suas expectativas para a usabilidade do produto?
Quais so as suas expectativas para o tempo de treinamento?
Que tipo de auxlio ao usurio voc precisa (p.ex., cpia impressa ou documentos on-line).
Parte IV: Recapturando para Entender
Voc me disse que:
(Liste os problemas que o cliente descreveu com suas prprias palavras).
y
y
y
Eles representam adequadamente os problemas que voc est tendo com a soluo existente?
Quais outros problemas, caso exista, voc est enfrentando?
Parte V: Suposies do Analista sobre o Problema do Cliente
(Valide ou invalide suposies).
(Se no foi discutido) Quais problemas, se houver, esto associados: (Liste quaisquer
necessidades (needs) ou problemas adicionais que voc acha que est preocupando o cliente ou o
usurio).
y
y
y
75
Para cada problema sugerido, pergunte:

y Esse um problema real?
y Quais so as razes deste problema?
y Como voc gostaria de resolv-lo?
y Qual o peso da soluo desse problema, comparado aos outros que voc mencionou?
Parte VI: Avaliando a sua Soluo (se aplicvel)
(Resuma as principais capacidades da soluo que voc props).
O que aconteceria se voc conseguisse:
y
y
Como voc classificaria cada uma dessas capacidades, por ordem de sua importncia?
Parte VII: Avaliando a Oportunidade
Quem na sua organizao precisa dessa aplicao?
Quantos usurios desse tipo usariam a aplicao?
O que voc considera que seja uma soluo bem sucedida?
Parte VIII: Avaliando Necessidades (needs) de Segurana, Desempenho e Suportabilidade
Quais so suas expectativas sobre a segurana?
Quais so suas expectativas sobre o desempenho?
Voc ir dar suporte ao produto ou sero outras pessoas que faro isso?
Voc tem necessidades (needs) especiais de suporte?
O que voc pensa sobre a manuteno e servios de rede?
Quais so os requisitos de segurana?
Quais so os requisitos de instalao e configurao?
Existem requisitos especiais de licenciamento?
Como o software ser distribudo?
Existem requisitos de etiquetagem ou de empacotamento?
Parte IX: Outros Requisitos
Existe algum requisito legal, de regulao, ambiental ou de padronizao que deva ser atendido?
Voc acha que existem outros requisitos que devemos conhecer?
Parte X: Fechamento
Existe alguma outra questo que eu deveria ter feito?
Se depois, eu tiver alguma dvida, posso ligar para voc? Voc concorda em participar de uma
reviso de requisitos?
Parte XI: Resumo do Analista
Depois da entrevista, e enquanto as informaes estiverem frescas em sua mente, resuma as trs
necessidades (needs) ou problemas de maior prioridade identificados pelo usurio/cliente.
1.
2.
3.
Figura 91
A entrevista livre de contexto genrica
76
O Momento da Verdade: A Entrevista

Com um pouco de preparao e com a entrevista estruturada no bolso, qualquer
membro da equipe pode fazer um trabalho adequado de entrevistar um usurio ou
cliente. (Mas, seria melhor escolher membros da equipe que sejam mais
extrovertidos). Aqui esto algumas dicas para o sucesso da entrevista.
Preparar uma entrevista livre de contexto apropriadamente, e anotar numa

agenda para servir de referncia durante a entrevista. Revise as questes
um momento antes da entrevista.
Antes da entrevista, pesquise o histrico dos stakeholders e da companhia
a ser entrevistada. No sonde as pessoas sendo entrevistadas com questes
que voc poderia ter respondido antecipadamente. Por outro lado, no ser
prejudicial fazer uma breve verificao dessas respostas com o
entrevistado.
Anote respostas numa agenda durante a entrevista. (No tente coletar os
dados eletronicamente nesse momento!).
Consulte o modelo durante a entrevista para se assegurar que as questes
corretas esto sendo perguntadas.
O entrevistador deve garantir que o roteiro no crie constrangimento ao

entrevistado. Depois que a aproximao tenha sido bem sucedida, a entrevista
provavelmente seguir o seu prprio curso. Os clientes podem cair num dilogo
de fluxo-de-conscincia, descrevendo com detalhes sangrentos, o horror da
situao atual. esse, exatamente, o comportamento que voc est procurando.
Se acontecer com voc, no interrompa prematuramente com outras questes; ao
invs disso, escreva tudo o mais rpido possvel, permita que o usurio
descarregue esse fluxo de pensamento em particular! Siga formulando perguntas
sobre as informaes que acabaram de ser fornecida. Ento, depois que essa linha
de pensamento tenha alcanado o seu final lgico, retorne a outras questes da
sua lista.
Depois de algumas entrevistas desse tipo, o desenvolvedor/analista ter obtido
algum conhecimento do domnio do problema e ter chegado ao entendimento
tanto do problema a ser resolvido quanto das percepes do usurio sobre as
caractersticas de uma soluo efetiva. Alm disso, o desenvolvedor pode
sumarizar as principais necessidades (needs) do usurio ou caractersticas
(features) do produto que foram definidos na entrevista. Essas necessidades
(needs) do usurio vivem no topo de nossa pirmide de requisitos e serviro de
guia para nos orientar em todas as tarefas seguintes.
Compilando os Dados de Necessidade (Needs)

A sua anlise do problema ter identificado os principais stakeholders e usurios
que voc precisar para entrevistar e para obter o entendimento das necessidades
(needs) dos stakeholders. Normalmente, no precisamos fazer muitas entrevistas
para obter um bom e slido entendimento sobre o assunto.
77
O Resumo do Analista: 10 + 10 + 10 30
1
2
3
etc.
A ltima seo do formulrio de entrevista, Resumo do Analista, usada para

registrar as trs necessidades (needs) ou problemas mais importantes
descobertas na entrevista. Em muitos casos, aps algumas entrevistas, tais
necessidades (needs) de alta prioridade comearo a se repetir. Isso significa que
voc comeou a encontrar convergncia sobre algumas necessidades (needs)
comuns. Isso esperado, especialmente entre aqueles usurios e stakeholders que
compartilham das mesmas perspectivas. Ento, em dez entrevistas, normalmente,
so criados apenas 1015 necessidades (needs) diferentes. Este o incio do seu
repositrio de requisitos, um conjunto de recursos que voc ir construir e usar
com grandes vantagens no decorrer do projeto. Esses dados simples e
inexpressivos, por si s, ajudaro voc e a sua equipe a construir uma base mais
slida para dar incio ao seu projeto.
O Estudo de Caso
1
2
3
etc.
Needs do usurio
do HOLIS
A equipe do HOLIS decidiu que a equipe de marketing (Eric e Cathy)

desenvolveria as questes para a entrevista, mas procura algum da equipe para
experimentar o processo e ter a oportunidade de encontrar clientes face-a-fase e
assim ver o problema e uma provvel soluo sob a perspectiva do cliente.
Assim, a equipe dividiu a lista de clientes e distribuidores e cada membro da
equipe teve que entrevistar duas pessoas. A equipe usou o Resumo do Analista
para sumarizar as necessidades (needs) que foram fornecidas e duplicidades
foram extradas. Depois de quinze entrevistas, a equipe identificou 20 algumas
necessidades (needs) que preenchero o topo de nossa pirmide de requisitos.
Da Perspectiva dos Proprietrios:
Controle de iluminao residencial modificvel e flexvel.

prova do futuro (Como as tecnologias mudam, eu gostaria que
houvesse compatibilidade com novas tecnologias que possam emergir.).
Atrativo, discreto e ergonmico.
Independncia total e chaves programveis ou reconfigurveis para cada
cmodo da residncia.
Mais segurana e despreocupao.
Operao intuitiva (Eu quero ensinar minha me tecnofbica).
O sistema com custo razovel, com chaves de baixo custo.
Correo fcil e barata.
Configurao de chaves flexvel (de um a sete botes por chave).
Fora do alcance da viso e observao.
100% confivel.
Configurao de segurana de frias.
Habilidade de criar cenas, como configurao de iluminao para festas.
Nenhum incremento eltrico ou de perigo de incndio na casa.
Habilidade de aps uma falta de energia eltrica, restaurar a iluminao.
Conseguir programar usando o meu PC.
Escurecer onde eu quiser.
Conseguir programar sem o meu PC.
Algum mais ir program-lo para mim.
Se o sistema falhar, eu ainda quero estar apto a ligar algumas luzes.
Interfaces para o meu sistema de segurana residencial.
Interface com outros aparelhos (HVAC, udio/vdeo, entre outros).
78
Da Perspectiva dos Distribuidores:
Um produto que oferea competitividade.

Alguma forte diferenciao do produto.
Facilidade de treinar o pessoal de vendas.
Poder ser demonstrado em minha loja.
Alta margem bruta.
Uma Nota sobre Questionrios

No existe substituto
para a entrevista.
Execute-a
primeiro!
Execute-a, para
cada nova classe
de problemas!
Execute-a, para
cada novo
projeto!
Ns nos perguntamos com freqncia se a equipe pode substituir este processo de

entrevista por um questionrio. Em alguns casos, isso expressa apenas um desejo
de eficincia (Eu poderia fazer 100 questionrios no tempo em que se leva para
fazer uma nica entrevista). Em outros casos, isso pode expressar algum desejo
suspeito (Eu realmente tenho que falar com essas pessoas? Eu no poderia
apenas enviar uma carta?).
Independentemente da motivao, a resposta no. No existe nenhum substituto
para o contato pessoal, construo do entendimento e interao em formato livre
da tcnica de entrevista. Ns lhe asseguramos que aps um ou duas entrevistas,
nossa viso do mundo ter mudado. Mais importante que isso, a viso da soluo
ter mudado junto com ele! Primeiro, executa a entrevista. Execute-a, para cada
nova classe de problema! Execute-a, para cada novo projeto.
No entanto, quando usada apropriadamente, a tcnica do questionrio pode
tambm exercer um papel legtimo na obteno das necessidades (needs) do
usurio. Embora a tcnica do questionrio seja freqentemente usada e parea
cientfico por causa da oportunidade de se fazer anlise estatstica de resultados
quantitativos, a tcnica no substitui a entrevista. Quando aplicada na obteno de
requisitos, a tcnica do questionrio apresenta alguns problemas fundamentais:
Questes relevantes podem no ser levada adiante.

As suposies por detrs das questes influenciam as respostas.
Exemplo: Esta classe atende a suas expectativas? Suposio: Que a
pessoa possui expectativas.
difcil explorar novos domnios (O que voc realmente deveria ter

perguntado ...), e no existe interao para explorar domnios que
precisam ser explorados.
Respostas no claras do usurio so difceis de perseguir.
De fato, alguns concluram que a tcnica do questionrio suprime quase todas as

coisas boas da obteno de requisitos, e assim, ns geralmente no a
recomendamos para este propsito.
Questionrios
podem ser usados
para validar
suposies e obter
dados estatsticos
sobre preferncias.
No entanto, a tcnica do questionrio pode ser aplicada com bons resultados aps
a entrevista inicial e atividades de anlise. Por exemplo, se a aplicao tiver vrios
usurios em potencial ou existente, e se a meta obter informaes estatsticas
das preferncias de usurios ou clientes entre um conjunto limitado de escolhas, o
questionrio pode ser efetivo. Para finalizar, a tcnica do questionrio, como toda
tcnica de elucidao, satisfaz a um conjunto de desafios de requisitos que uma
organizao pode enfrentar.
79
Captulo 10
Workshops de Requisitos
Pontos chaves
Talvez o workshop de requisitos seja a tcnica mais poderosa para se elucidar
requisitos.
Rene todos os principais stakeholders por um breve porm intenso perodo.
O uso de um facilitador externo e experiente em gerenciamento de requisitos
pode ajudar a assegurar o sucesso do workshop.
O brainstorming a parte mais importante do workshop.
Acelerando o Processo de Deciso
m dos esquemas de priorizao que usamos enganosamente simples.

Pergunte ao stakeholder qual caracterstica (feature) ele escolheria caso
tivesse que escolher apenas uma, a qual seria implementada na prxima
liberao (release). Como na mente de algum que vai para a forca, esta
questo faz com que a mente maravilhosamente concentre-se no que realmente
importante.
Quando houver apenas uma nica oportunidade de elucidar requisitos uma que
possamos aplicar em todas as circunstncias, sem se importar com o contexto do
projeto, sem se importar com o perodo de tempo escolha o workshop de
requisitos. O workshop de requisitos pode ser muito bem, ser a tcnica mais
poderosa deste volume e uma das poucas que, quando dominado, pode realmente
ajudar a mudar os resultados do projeto, mesmo que seja a nica tcnica aplicada.
O workshop de requisitos projetado para alcanar consenso sobre requisitos da
aplicao e chegar rapidamente ao acordo sobre o curso das aes, tudo num
perodo de tempo muito curto. Nesta tcnica, os principais stakeholders do projeto
so reunidos por um breve e intensivo perodo, normalmente no mais que 1 ou 2
dias. O workshop facilitado por um membro da equipe ou, melhor ainda, por um
facilitador externo experiente concentrado na criao ou na reviso das
caractersticas (features) de alto-nvel que a nova aplicao deve ter.
Uma execuo apropriada do workshop de requisitos trs muitos benefcios:
Ele ajuda na construo de uma equipe efetiva, comprometida com um

nico propsito comum: o sucesso deste projeto.
Todos os stakeholders tm a sua vez de falar, ningum fica de fora.
Ele produz um acordo entre stakeholders e a equipe de desenvolvimento
sobre o que a aplicao deve fazer.
Ele pode expor e resolver assuntos polticos que esto interferindo para o
sucesso do projeto.
80
O resultado, que uma definio preliminar do sistema em nvel de

caractersticas (features), imediatamente disponibilizado.
Muitas empresas tm alcanado sucesso com a tcnica de workshop. Juntos, ns

participamos em mais de 100 desses workshops, e raramente, se houve algum,
houve insucesso em atingir os objetivos desejados. O workshop fornece
oportunidade nica para stakeholders, de vrias partes da empresa, trabalharem
juntos com o objetivo comum de alcanar o sucesso do projeto.
Neste captulo, voc ir aprender a planejar e executar com sucesso, um workshop
de requisitos. No final do captulo, ns aplicaremos esta tcnica no nosso caso de
estudos HOLIS.
Preparando o Workshop
A preparao apropriada do workshop crtica para o seu sucesso.
Vendendo o Conceito
A preparao
apropriada do
workshop crtica
para o seu sucesso.
Primeiro, pode ser necessrio vender o conceito dentro da empresa, comunicando

os benefcios da abordagem workshop aos futuros membros da equipe. Este
processo normalmente no difcil, mas comum encontrar resistncias: No,
mais uma reunio!; Provavelmente no conseguiremos reunir todas essas
pessoas crticas num nico dia; Voc nunca ser atendido pelo [nome do seu
stakeholder favorito]. No se desencoraje; se voc acreditar, eles viro.
Assegurando a Preparao dos Stakeholders

Corretos
Segundo, a preparao tambm envolve a identificao dos stakeholders que
podem contribuir para o processo e cujas necessidades (needs) devem ser
atendidas para assegurar o sucesso dos resultados. Esses stakeholders j tero sido
identificados se a equipe executou o passo da anlise do problema, mas agora
tempo para uma ltima reviso para garantir que todos os stakeholders crticos
foram identificados.
Logsticas
Terceiro, necessria uma abordagem consciente para a logstica e pagar
dividendos na medida em que um workshop seja miseravelmente organizado;
certamente, os resultados desejados no sero atingidos. A logstica envolve todas
as coisas, desde estruturar apropriadamente os convites, viagens, acomodaes,
at a iluminao da sala de reunies do workshop. Uma crena literal nas leis de
Murphy Se pode dar errado, dar errado deve ser nosso guia aqui. Se voc
abordar a logstica com um alto grau de profissionalismo, bvio que atender
aos propsitos num importante evento, e eles iro atuar de acordo. Voc ter,
tambm, mais sucesso no workshop.
81
Material de Aquecimento
Quarto, envie materiais do workshop antecipadamente para preparar os
participantes e tambm elevar a produtividade nas sesses de workshop. Esses
materiais preparam o estado de esprito dos participantes. Chamamos isso de
atingir um ideal estado de esprito. Uma das mensagens que ns precisamos
passar que esta no mais uma reunio. Esta pode ser a nica chance de dizer
isso de forma correta.
Material de
aquecimento
estimula tanto o
pensamento de
quem faz parte do
contexto, quanto de
fora do contexto
(out-of-box).
Recomendamos que voc fornea dois tipos separados de materiais de

aquecimento:
1. Informaes especficas do projeto, o qual pode incluir o esboo do
documento de requisitos, lista de caractersticas (features) sugeridas,
cpias de entrevistas com os futuros usurios, relatrio do analista
sobre tendncias na indstria, cartas de clientes, relatrio de erros do
sistema existente, novas diretivas de gerenciamento, novos dados de
marketing, entre outros. Embora seja importante no sufocar com
dados os nossos futuros participantes, importante assegurar que eles
recebam os dados corretos.
2. Preparao do pensamento out-of-box. Parte do atingir um ideal
estado de esprito est em encorajar o pensamento out-of-the-box.
Esquea por um minuto o que voc conhece e o que no pode ser feito
devido poltica. Esquea o que voc tentou colocar em atividade na
ltima vez e falhou. Esquea que ns no solidificamos nosso
processo de desenvolvimento. Apenas traga suas sugestes sobre
caractersticas (features) deste novo projeto e esteja preparado para
pensar out of the box. Como lder do workshop, voc pode ajudar
neste processo fornecendo pensamentos provocativos e estimulando o
acordo sobre o processo de criatividade, regras para o brainstorming,
gerenciamento de requisitos, gerenciamento de escopo, entre outros.
Nesta atmosfera, solues criativas sero as mais provveis.
Dica: No envie dados com muita antecedncia. Voc no ir querer que os
participantes leiam e esqueam o que leram, e voc no ir querer que um longo
ciclo de planejamento reduza o sentido de urgncia. Envie os dados entre 2 dias e
1 semana de antecedncia. De qualquer forma, muito provvel que os
participantes s lero o plano no ltimo minuto. Tudo bem; isso ajudar a
preparar o estado de esprito para a sesso.
Para ajudar voc com o pensamento out-of-box e auxiliar a configurar o
contexto das atividades do workshop, ns fornecemos um modelo de um
memorando na Figura 101. Entre parnteses, ns iremos tambm ler entre
linhas partes do texto para entender alguns desafios que voc pode enfrentar em
seu projeto, e sobre como o workshop pretende atac-lo.
82
Memorando:
Para: Stakeholder do projeto _______________________
Assunto: Realizao do Workshop de Requisitos
De: [Nome do Lder de Projeto]
Eu sou o gerente de projeto [produto]. O projeto foi [ou ir ser] iniciado em _______ e ser
finalizado na data de _______.
(Ns sabemos; ns entendemos, e pretendemos finalizar nesse perodo).
Como em muitos projetos, temos dificuldades de chegar a um consenso sobre as novas
caractersticas desta aplicao e em definir uma verso inicial que atenda as necessidades de
nossos diversos grupos de stakeholders.
( muito difcil chegar a um acordo sobre qualquer coisa com este grupo, ento ns estamos
tentando algo um pouco diferente, e aqui est o que isso ...)
A fim de facilitar este processo, ns estamos organizando um workshop de requisitos em
_______.
O objetivo deste workshop de fechar as novas caractersticas para a prxima verso do produto.
A fim de fazer isso, importante ouvir a contribuio de todos os stakeholders. O workshop ser
conduzido pelo ________________, que tem grande experincia como facilitador no
gerenciamento de requisitos.
(Como stakeholder, podemos tambm ter preconceitos, ento chamamos algum de fora da
equipe para nos assegurarmos que o workshop ser gerenciado livre de qualquer preconceito).
Os resultados deste workshop sero disponibilizados imediatamente e sero distribudos para as
equipes de desenvolvimento e marketing no dia seguinte. Convidamos vossa senhoria a
participar deste workshop como representante das necessidades de vossa [equipe, departamento,
cliente]. Se no for possvel a vossa participao, ns solicitamos que envie um membro de sua
equipe que esteja autorizado a tomar decises como representante de suas necessidades.
(Ns iniciaremos o desenvolvimento nos prximos dias; se voc quiser ouvir contribuies para
este projeto, esteja aqui, ou envie algum que possa falar por voc. Em outras palavras, fale
agora ou descanse em paz).
Em anexo, a este memorando, est uma breve descrio antecipada das caractersticas do
produto, bem como algum material de leitura sobre o processo de workshop e brainstorming. O
workshop comear exatamente s 8:30 horas e terminar at as 17:30 horas.
(Este projeto e este workshop sero executados de forma profissional; para demonstrar isso, ns
fornecemos alguns materiais antecipadamente para melhor prepar-lo. Ns precisamos que voc
esteja aqui, para contribuir, e nos ajudar a conduzir este projeto de maneira apropriada)
.
Certo de poder contar com a vossa participao, agradeo antecipadamente.
Cordialmente,
[Nome do Lder de Projeto]
Figura 101
Exemplo de memorando para rpido incio de um workshop de requisitos
83
Papel do Facilitador
Para garantir o sucesso, ns recomendamos que o workshop seja executado por
algum de fora e que tenha experincia em enfrentar os desafios do processo de
gerenciamento de requisitos. No entanto, se isso no for uma alternativa prtica
em seu ambiente, o workshop pode ser facilitado por um membro da equipe,
desde que esta pessoa:
Se possvel, tenha
um facilitador que
no seja da equipe
para executar o
workshop.
Tenha recebido algum treinamento neste processo.

Tenha solidamente demonstrado habilidade de construir consenso ou
equipe.
Seja elegante e bem respeitado tanto pelos membros internos quanto
externos.
Seja forte o suficiente para conduzir a reunio a qual pode ser um encontro
desafiador.
No entanto, se o workshop for facilitado por um membro da equipe, essa pessoa

no deve contribuir com idias e assuntos da reunio. Caso contrrio, o workshop
estar em grave perigo de perder a objetividade que necessria para obter os
fatos reais, e pode no estimular um verdadeiro ambiente onde o consenso possa
emergir.
Em alguns casos, o facilitador tem o papel central para o sucesso do workshop.
Afinal de contas, voc est com todos os principais stakeholders reunidos, talvez
pela primeira vez e ltima vez no projeto, e voc no pode se permitir errar o
alvo. Algumas das responsabilidades do facilitador so:
Estabelecer um tom profissional e objetivo para a reunio.

Iniciar e finalizar a reunio dentro do tempo.
Estabelecer e impingir as regras da reunio.
Introduzir as metas e a agenda da reunio.
Gerenciar a reunio e manter a equipe na trilha.
Facilitar o processo de deciso e o consenso, mas evitar participar do
contedo.
Gerenciar qualquer instrumento e assuntos de logstica para assegurar que
o foco permanea na agenda.
Assegurar que todos os stakeholders participem e sejam ouvidos.
Controlar comportamentos desordeiros ou improdutivos.
Preparando a Agenda
A agenda do workshop ter como base as necessidades do particular projeto e no
contedo que deve ser desenvolvido no workshop. Ningum preenche toda a
agenda. No entanto, workshops de requisitos estruturados podem seguir um
formato padro claro. A Tabela 101 fornece uma agenda tpica.
84
Tabela 101 Exemplo de agenda para o workshop de requisitos

Hora
Item de Agenda
Descrio
8:00 8:30
8:30 10:00
Introduo
Contexto
10:00 12:00
Brainstorning
12:00 13:00
Almoo
14:00 15:00
Definio da caracterstica
15:00 16:00
Reduo e priorizao de
idias
Fechamento
Agenda, recursos e regras.

Estado do projeto, necessidade
do mercado, resultados da
entrevista do usurio, etc.
Caractersticas do brainstorning
da aplicao.
Trabalhar durante o almoo para
evitar perder o momento.
Escrever 2 ou 3 definies de
sentena para as caractersticas
(features).
Priorizar as caractersticas
(features).
Sumrio e itens de ao, atacar
os itens de estacionamento.
16:00 17:00
Executando o Workshop
Problemas e Truques do Ofcio
Voc pode ver que o facilitador interpreta um papel crucial. Para tornar o assunto
mais interessante, esses workshops so caracterizados, normalmente, por uma
atmosfera altamente carregada. Em outras palavras, existem razes para que seja
difcil chegar ao consenso nos projetos; quase todas aparecero no workshop.
De fato, o cenrio pode at estar carregado e conflituoso politicamente. Esta a
outra razo para ter um facilitador; deixar o facilitador aquecer e gerenciar a
reunio de forma que no exacerbe qualquer problema seja do passado,
presente, ou do futuro entre os stakeholders.
Muitos facilitadores carregam uma mala de truques que o auxiliam a gerenciar
esta atmosfera altamente carregada. Na RELA, desenvolvemos um conjunto
muito til de truques de workshop. Embora eles paream estranhamente
bonitos, e at infantil a primeira vista, voc pode acreditar, eles provaram o seu
valor em vrias situaes. Quanto mais difcil o workshop, mais valioso ser! Eles
tambm tendem a estimular o pensamento out-of-box. O mais interessante
que eles so divertidos e contribuem para o tom positivo da sesso. A Figura 102
fornece um exemplo desse conjunto de truque de workshop. Sinta-se livre para
adapt-los e us-los, junto com as instrues de uso.
A Tabela 102 descreve algum dos problemas que podem ocorrer numa
preparao do workshop e tambm fornece sugestes sobre como voc pode usar
os truques de workshop para atacar os problemas. O facilitador deve tambm
introduzir essas regras no incio da reunio e, idealmente, obter aprovao
consensual para aplicar essas tolas regras por um dia.
85
Atraso aps
o intervalo
Regra: Inicialmente, cada participante recebe

um cupom grtis quando chegar atrasado.
Depois disso, o participante contribui com $1
de multa.
1 Ofensa
gratuita e
deliberada
Regra: Inicialmente, cada participante recebe

um cupom para dar um toque sobre uma
pessoa ou departamento. Depois disso, o
participante contribui com $1 de multa.
Objetivo: Fazer com que a pessoa fique ciente
dos assuntos polticos do projeto de forma
divertida.
Que grande
idia!
Que grande
idia!
Regra: Inicialmente, cada participante inicia

com dois cupons. Os participantes do o
cupom para qualquer participante que fornea
uma grande idia. O objetivo gastar seus
cupons.
Objetivo: Incentivar e gratificar pensamentos
criativos.
5 minutos
para falar
5 minutos
para falar
Regra: O participante gasta este cupom em

algum momento. O facilitador d a palavra ao
participante e marca seu tempo. Todos ouvem.
No h interrupo.
Objetivo: Viabilizar a participao organizada.
Assegurar que todos dem sua opinio.
Figura 102
Truques de workshop
86
Tabela 102
Problemas e solues na configurao do workshop de requisitos
Problema
Gerenciamento do tempo
difcil reiniciar as atividades aps
os intervalos.
Os principais stakeholders podem
se atrasar.
Discurso exagerado e dominador,
visando impressionar e receber ovao
do pblico.
Carncia
de
stakeholders.
contribuies
dos
Comentrios negativos, comportamento

de baixo escalo e clima de guerra.
Energia debilitada aps os intervalos.
Soluo
O facilitador mantm controle do
tempo de servios de cozinha em todos
os intervalos. Participantes que
chegarem atrasados devem contribuir
com um cupom Atraso aps o
intervalo ou pagar $1 para a caixinha
de contribuies para caridade.
O facilitador refora a regra 5 minutos
para falar para regular o discurso. Ele
tambm cria uma lista de assuntos
pendentes para, posteriormente, poder
voltar s idias que meream ser
discutida, mas que no so relevantes
ao item do momento de acordo com a
agenda.
O facilitador encoraja os participantes a
usarem seus cupons de 5 minutos para
falar e Que grande idia!. Ele deixa
claro que ningum deve deixar o
workshop sem ter usado os cupons ou
terem recebido um cupom Que grande
idia! de outros. (Sugesto: D uma
pequena premiao para quem usar o
cupom 5 minutos para falar, dandolhe um cupom Que grande idia!).
Use o cupom 1 Ofensa gratuita e
deliberada at que os participantes no
tenham mais nenhum; depois disso, tm
que dar contribuies para a caixinha
de contribuies para caridade. (o
grupo decide quanto).
Almoo leve, cafezinhos rpidos,
rearranjo da sala, rearranjo dos locais
dos
participantes,
alterar
a
luminosidade e temperatura. Faa o que
voc puder fazer para manter as coisas
funcionando.
Brainstorming e Reduo de Idias

A parte mais importante do workshop o processo de brainstorming. Esta tcnica
idealmente adaptada para o ambiente de workshop, e estimula uma atmosfera
criativa e positiva e estimula contribuies de todos os stakeholders. Ns iremos
tratar do brainstorming no prximo captulo.
87
Produo e Continuidade
Depois do workshop, o facilitador distribui os minutos da reunio para registrar
algumas outras informaes. Assim, o trabalho do facilitador est terminado, e a
responsabilidade do sucesso volta novamente para a equipe de desenvolvimento.
Depois disso, o lder de projeto tem a responsabilidade de dar continuidade a
quaisquer itens de ao em aberto que foram registradas na reunio e organiz-los
para distribuir aos participantes. Normalmente, as informaes da reunio
apresentam-se como uma lista de idias ou caractersticas sugeridas para produto
que podem modificar imediatamente as futuras aes da equipe de
desenvolvimento. Em alguns casos, workshops adicionais com outros
stakeholders sero programados, ou esforos adicionais de elucidao sero
necessrios para ganhar melhor entendimento das idias estimuladas no
workshop. A criao dessas idias o centro de todo o processo do workshop. No
prximo captulo veremos mais de perto esta parte do processo.
88
Captulo 11
Brainstorming e a
Reduo de Idias
Pontos chaves
O brainstorming trata tanto da gerao de idias quanto da reduo de idias.
As idias mais criativas e inovadoras normalmente resultam da combinao
mltipla, aparentemente de idias desassociadas.
Vrias tcnicas de votao podem ser usadas para priorizar as idias criadas.
Embora seja prefervel o brainstorming presencial, o brainstorming baseado em
web pode ser uma alternativa vivel em algumas situaes.
e voc est configurando um workshop, como vimos no Captulo 10, ou se

voc procura por novas idias ou solues criativas para problemas, o
brainstorming uma tcnica muito til. simples, fcil e divertido.
Na configurao do workshop, voc provavelmente j ter uma boa idia sobre as

caractersticas do novo produto. Afinal de contas, poucos projetos comeam com
passado totalmente limpo. Dessa forma, alm de revisar as caractersticas
sugeridas do produto, o workshop fornece a oportunidade de solicitar novas
informaes, mudar e combinar essas novas caractersticas com aquelas que j
estavam sob considerao. Este processo ir nos ajudar na nossa meta de
encontrar as runas desconhecidas e atravs disso, assegurar a integridade das
informaes e que todas as necessidades dos stakeholders foram cobertas.
Tipicamente, uma parte do workshop dedicada ao brainstorming de novas idias
e caractersticas da aplicao. O Brainstorming uma coleo de tcnicas que so
teis quando os stakeholders esto lado-a-lado.
Esta tcnica de elucidao tem como benefcios principais:
Encorajar a participao de todas as partes presentes.

Permitir que os participantes engatem uma idia com a outra.
Registro de todas as coisas discutidas pelo facilitador ou secretrio (assim,
nada perdido).
Alta quantidade de informaes.
Normalmente, gera um grande conjunto de possveis solues para
qualquer que seja o problema proposto.
Encoraja o pensamento out-of-the-box, isto , sem as limitaes das
restries normais.
O brainstorming tem duas fases: gerao de idias e reduo de idias. O objetivo

principal durante a gerao delinear tantas idias quanto sejam possveis; o
objetivo ampliar as idias, no necessariamente aprofund-las. O objetivo
89
principal da reduo de idias aparar, organizar, priorizar, expandir, agrupar,

refinar, e assim por diante.
Brainstorming Presencial
Embora o brainstorming possa ser abordado de diferentes maneiras, o processo
simples que descrevemos provou ser efetivo em vrios cenrios. Inicialmente,
todos os stakeholders importantes so reunidos numa sala e recursos so
distribudos. Os recursos distribudos a cada participante podem ser to simples
quanto um bloco de folhas de anotaes e um marcador preto grosso para escrever
as anotaes. As folhas devem ter, ao menos, 3 5 (7 cm 12 cm) e no maior
que 5 7 (12 cm 17 cm). Cada participante deve ter ao menos 25 folhas para
cada sesso de brainstorming. Post-Its ou cartes de ndices funcionam bem. Se
cartes de ndice so usados, so necessrios alfinetes e quadro de isopor ou
cortia.
Ento, as regras do brainstorming so apresentadas (veja a Figura 11-1), e o
objetivo da sesso claramente e concisamente estabelecidos.
Regras do Brainstorming
Figura 111
No se permitem crticas ou debates.

Solte a imaginao.
Gere quantas idias quanto forem possveis.
Mude e combine idias.
Regras do brainstorming
O facilitador tambm expe os objetivos do processo. Embora os objetivos que

estabelecem o processo possam parecer muito simples, no . A maneira como
estabelecido tem grande efeito sobre as conseqncias da sesso. Como exemplo,
as seguintes questes do algumas das formas de estabelecer os objetivos:
Quais caractersticas voc gostaria que o produto tivesse?

Quais servios voc gostaria que o produto fornecesse?
Que informaes voc gostaria que o produto mantivesse?
(Note que os objetivos tambm ajudam voc a decidir quando a sesso est
terminada. Quando os objetivos forem alcanados e no houver mais nada a
acrescentar, fim!)
Depois que os objetivos do processo tiverem sido estabelecidos, o facilitador
convida os participantes para que expressem suas idias em voz alta e escreva-as,
uma em cada folha. Idias so ditas em voz alta para permitir que outros possam
engatar suas idias, isto , pensar em relacionar idias e seguir a regra 4, mudar
e combinar idias. Neste processo, no entanto, a primeira regra sem crticas ou
debates deve estar frente na mente das pessoas. Se esta regra no for
impingida, o processo ser silenciado, muitas pessoas brilhantes, porm, sensveis
s crticas, no se sentiro confortveis em colocar suas idias, uma trgica perda.
90
Dica: Em nossa experincia, as idias mais criativas e inovadoras aquelas que

verdadeiramente revolucionam o conceito do produto no resultaram da idia de
uma nica pessoa, mas, ao invs disso, do resultado de mltiplas combinaes, e
aparentemente no-relacionadas, de idias de vrios stakeholders. Qualquer
processo que estimule este resultado um processo realmente poderoso.
Quando surge uma idia, ela registrada no material fornecido pela pessoa que
teve a idia. Isso importante:
Para assegurar que sejam registradas com as palavras da prpria pessoa.

Para assegurar que no sejam perdidas.
Para permitir que sejam aproveitadas posteriormente.
Para prevenir atrasos no processo criativo que pode ser provocado por um
nico secretrio tentando capturar todas as idias num flipchart ou quadro
branco em frente sala.
Assim que as idias so geradas, o facilitador coleta e as afixa sobre uma parede
da sala de reunies. Novamente, nenhuma crtica s idias pode ser tolerada. No
apropriado dizer, Que idia estpida!, ou mesmo J temos essa idia afixada
na parede!. O nico propsito gerar idias. Mesmo um pacfico comentrio
negativo pode ter o deletrio (danoso) efeito de suprimir futuras participaes da
vtima. Por outro lado, comentrios tais como Que grande idia!, so
apropriados e so normalmente premiados com o cupom Que grande idia!, o
qual pode encorajar futuras participaes de todos os stakeholders. A gerao de
idias deve prosseguir at que todos os participantes sintam que tenham chegado
naturalmente ao seu final.
comum ocorrer calmaria durante a gerao de idias. Isso no motivo para
parar o processo. A calmaria tende a cessar assim que uma nova idia gerada.
Longas calmarias podem fazer com que o facilitador repasse os objetivos ou faa
perguntas associadas. Muitas sesses de gerao de idias duram por volta de uma
hora, mas algumas duram de 2 a 3 horas. Sob nenhuma condio deve o
facilitador finalizar uma sesso que esteja caminhando bem com comentrios
como: Eu sei que estamos todos fazendo grandes progressos, mas precisamos
prosseguir para a prxima fase. Para os participantes, isso soa como Nossas
idias no so to importantes quanto o cronograma. A quantidade de idias
geradas depende de quo frtil foi a discusso, mas comum gerar de 100 a 200
idias.
O processo tende a terminar naturalmente; em algum ponto, os stakeholders
ficaro sem idias novas. Isso caracterizado por um longo e grande intervalo
entre submisses de idias. Nesse ponto, o facilitador finaliza a sesso e pode ser
um bom momento para fazer uma pausa.
Reduo de Idias
Quando a fase de gerao de idias termina, a vez de iniciar a reduo de idias.
Vrios passos esto envolvidos.
91
Expurgando
O primeiro passo o expurgo daquelas idias que no so to valiosas para
merecer maior investimento pelo grupo. O facilitador inicia visitando brevemente
cada idia e solicitando a cooperao do grupo para indicar as idias que acham
serem vlidas. No existe razo para que qualquer participante fique na defensiva
ou reivindique autoria de qualquer idia; qualquer participante pode apoiar ou
refutar qualquer idia.
Dica: A presena de idias que podem ser facilmente expurgadas uma indicao
do processo de qualidade. A ausncia de uma quantidade razovel de idias sem
nexo e malucas indica que os participantes no pensaram no out of the box
suficientemente.
O facilitador apenas pergunta aos participantes se cada uma das idias merece
futura considerao e ento simplesmente remove uma idia invlida, mas se
houver qualquer desacordo entre os participantes, a idia fica na lista. Se
participantes acharem duas anotaes com a mesma idia, agrup-las na parede.
( prefervel fazer isso do que remover uma; seu autor pode se sentir insultado).
Agrupando Idias
Pode ser til durante este processo, iniciar agrupando idias similares. Isso feita
de forma mais efetiva quando participantes voluntrios se dirigem parede e
realizam o agrupamento. Idias relacionadas so agrupadas em regies da parede.
D nomes aos grupos de idias relacionadas. Por exemplo, o grupo pode ser
rotulado como:
Novas caractersticas
Assuntos de desempenho
Evoluo das caractersticas existentes
Interface de usurio e assuntos de usabilidade
Ou, podem concentrar especificamente nas capacidades do sistema e na maneira

como eles suportam os vrios tipos de usurios. Por exemplo, na previso de um
novo servio de transporte e entrega, as caractersticas poderiam ser agrupadas
em:
Roteamento e rastreio de pacotes

Servios aos clientes
Marketing e vendas
Servios baseados na web
Faturamento
Gerenciamento de transporte
A gerao de idias pode ser reiniciada agora para qualquer um desses grupos se
os participantes acharem que o processo de agrupamento tenha estimulado o
desenvolvimento de novas idias ou que algumas reas de funcionalidades-chave
tenham sido deixadas de lado.
92
Definio de Caractersticas
Neste ponto, importante gastar algum tempo para escrever uma breve descrio
sobre o que as idias significam para a pessoa que a submeteu. Isso d ao
contribuidor a oportunidade de apresentar caractersticas adicionais e ajudar a
assegurar que os participantes tenham o mesmo entendimento dessas
caractersticas. Desta maneira, todos entendero o significado da idia, evitando
se assim, uma grande falha no processo de priorizao.
Neste processo, o facilitador visita cada idia que no foi expurgada e solicita ao
contribuidor que fornea uma descrio em uma nica sentena.
Contexto da Aplicao
Caracterstica Obtida
no Brainstorming
Definio da
Caracterstica
Automao de
iluminao residencial
Configurao da
iluminao automtica
O proprietrio pode criar,

previamente,
cronogramas para certos
eventos com base nas
horas do dia.
Sistema de entrada de
pedidos de venda
Rpido
Rpido o suficiente para

que o tempo no interfira
nas operaes normais.
Sistema de rastreamento
de defeitos
Notificao automtica
Todas as partes
registradas sero
notificadas via e-mail
quando algo for mudado.
Uma caracterstica de rob de solda como soldagem automtica, pode ter sido
suficientemente descrita, no necessitando de nenhum trabalho adicional. No
entanto, importante no cair nessa armadilha; a descrio no deve levar mais
do que alguns minutos por idia. Voc precisa capturar apenas a essncia da idia.
Priorizao
Resultados da
votao
acumulativa:
Idia 1 $380
Idia 2 $200
Idia 3 $180
Idia 4 $140
Idia 5 ...
.
.
.
Idia 27 ...
Em algumas situaes, a gerao de idias o nico objetivo, assim, o processo

est completo. No entanto, na maioria dos casos, incluindo o workshop de
requisitos, necessrio priorizar as idias que permaneceram aps o expurgo.
Afinal de contas, nenhuma equipe de desenvolvimento pode fazer tudo o que
todos pensaram. Uma vez que o agrupamento tenha se estabilizado e atingido o
consenso, hora de ir para o prximo passo. Novamente, vrias tcnicas podem
ser usadas; ns iremos descrever duas que usamos rotineiramente.
Votao Acumulativa: Teste dos Cem Dlares. Este simples teste divertido,
legal e fcil de fazer. Cada pessoa recebe 100 notas de idias para gastar na
compra de idias. (Voc pode at mesmo adicionar um kit de notas de idias
no inventrio de cupons do workshop). Cada participante convidado a escrever
em seu bloco de notas, o quanto pagaria para cada idia. Ento, depois que os
participantes tiverem tido a chance de votar, o facilitador ir tabular os resultados
e fornecer a ordem de classificao. Pode tambm ser til fazer um rpido
93
histograma dos resultados para que os participantes possam ver o impacto visual
de suas decises.
Este processo extremamente simples e normalmente funciona bem. No entanto,
voc deve ficar prevenido dos seguintes avisos. Primeiro: isso funcionar bem
apenas uma vez. Voc no pode usar a mesma tcnica duas vezes no projeto,
porque uma vez que os resultados sejam conhecidos, os participantes iro
influenciar os resultados na prxima rodada. Por exemplo, se voc for um
participante e a sua caracterstica favorita for o primeiro da lista, mas se a sua
segunda caracterstica favorita no estiver numa posio honrosa, voc pode
colocar todo o seu dinheiro sobre a sua segunda caracterstica. Voc est
confiante de que os outros eleitores iro ver que a sua caracterstica favorita ainda
faz a diferena.
Da mesma forma, voc pode achar necessrio limitar a quantidade de gastos de
uma caracterstica. Caso contrrio, um participante trapaceiro conhecendo
perfeitamente que outros itens tais como Execuo rpida e Facilidade de
uso fazem o corte para o topo da lista, pode gastar todo o seu dinheiro sobre
Executar na plataforma Mac e elev-la para uma prioridade maior. Por outro
lado, voc pode desejar a permisso de um limite elevado, contanto que voc
queira saber onde estaro os grandes votos. Eles podem representar necessidades
de alta prioridade de uma comunidade restrita de stakeholders.
A Categorizao Crtica, Importante e til. Um colega nos ensinou uma
outra tcnica que tambm bastante efetiva, especialmente com um pequeno
grupo de stakeholders ou mesmo com apenas um stakeholder, tal como quando
voc precisar da opinio do seu chefe de suas prioridades. Nesta tcnica, dado a
cada participante um nmero de votos igual ao nmero de idias, mas cada voto
deve ser categorizado como crtico, importante ou til. O truque nesta
tcnica a regra de que cada stakeholder d apenas um dos trs votos de cada
categoria; assim, apenas um tero das idias podem ser consideradas crticas.
Crtico significa indispensvel, sugerindo que um stakeholder no

poderia estar apto a usar um sistema sem esta caracterstica. Sem a
caracterstica, o sistema no cumpriria a sua misso principal, seu papel e,
assim, digno de liberar.
Importante significa que seria uma significativa perda de utilidade para o
segmento de cliente, mercado, rendimento ou de servios aos novos
clientes. Se esse item no for implementado, alguns usurios no gostaro
do produto e no iro compr-lo.
til significa que seria bom ter. A caracterstica que torna a vida mais
fcil, faz o sistema mais apelativo, mais divertido, ou de grande utilidade.
Nota: Com este esquema, todas as idias que sobreviveram ao processo de expurgo
tero ao menos um voto til, evitando insultar a quem tenha submetido.
Num grupo grande de participantes, cada item ter um misto de categorias, mas
no realmente um problema. O facilitador tem um truque: Apenas multiplique
os votos crticos por 9, importantes por 3 e teis por 1 e some os
resultados! Isto tende a espalhar os resultados pesadamente a favor dos votos
94
crticos, e assim, todas as necessidades crticas dos stakeholders borbulharo

para o topo da lista.
Brainstorming Baseado em Web

At agora, discutimos um processo para que o brainstorming funcione
efetivamente bem quando todos os stakeholders reunidos ao mesmo tempo forem
relativamente pr-ativos e no excessivamente inibidos, quando o facilitador for
experiente e polticas do stakeholder forem gerenciveis. Sem dvida, no existe
substituto para o tempo gasto em conjunto pelos desenvolvedores e stakeholders
externos. Cada um ir se lembrar dos vrios pontos importantes e de assuntos
discutidos por outros; perspectivas e respeito mtuo so normalmente os
subprodutos do processo. Ento, o workshop de requisitos e o brainstorming
presencial so, sem dvida, a nossa abordagem preferida.
Mas, algumas vezes, o brainstorming presencial no possvel. Nessas situaes,
uma das alternativas o uso da Internet ou uma intranet para facilitar o processo
de brainstorming criando-se um grupo de discusso. Esta tcnica pode ser
particularmente adaptada para aplicaes avanadas de desenvolvimento onde so
necessrias pesquisas ou quando uma viso de longo alcance crtica, o conceito
for inicialmente confuso, e uma grande variedade de informaes e significante
nmero de usurios e de outros stakeholders estiverem envolvidos.
Com esta tcnica, o lder de projeto patrocina um servidor de lista ou pgina Web
para registrar e comentar as caractersticas do produto. O registro de idias e
comentrios podem ser feitos tanto de forma annima quanto pela criao de
autores com base nas construes criadas pelo administrador. Uma vantagem
desta tcnica a persistncia; idias e comentrios podem ser circulados por um
longo perodo de tempo, com total registro de todas as ramificaes de cada idia.
Talvez a vantagem mais importante e nica deste processo esteja no fato de que
idias podem crescer e amadurecer com o passar do tempo.
O Caso de Estudos: O Workshop de Requisitos

do HOLIS 2000
Permita-nos retornar ao nosso caso de estudos. Enquanto o processo de entrevista
estava em andamento, a equipe de desenvolvimento reuniu-se com o marketing e
decidiu realizar um workshop de requisitos para o projeto HOLIS 2000.
Participantes
Depois de pensar sobre o assunto, a equipe decidiu no trazer um facilitador
externo, ao invs disso, definiram que Eric, o diretor de marketing, facilitaria o
workshop. A equipe tambm decidiu que haveria a participao de dois membros
da equipe de desenvolvimento: Cathy, a gerente de produto e Pete, o gerente de
desenvolvimento. A equipe sentiu que tanto Cathy quanto Pete poderiam falar
pela equipe e que estavam aptas em contribuir com o contedo, ambas como
novas proprietrias. Os outros membros da equipe no iriam participar, mas iriam
simplesmente assistir o workshop a fim de observar o processo, ouvir os clientes e
ver, diretamente, os resultados.
95
A equipe tambm decidiu incluir a representao de quatro classes de clientes e

convidou os seguintes participantes:
1. Distribuidores: John, diretor executivo da maior companhia de
distribuio, e Raquel, a gerente geral da companhia de distribuio
exclusiva na Europa.
2. David, um construtor de casas local com experincia em comprar e
instalar sistemas concorrentes no mercado.
3. Betty, uma empreiteira eltrica local.
4. As perspectivas de proprietrios, identificadas com a ajuda de Betty,
que passou por um processo de construo, ou considerou a construo
de uma residncia de ltima gerao.
A seguinte lista fornece maiores detalhes sobre os participantes.
Nome
Papel
Ttulo
Comentrios
Eric
Facilitador
Cathy
Participante
Gerente de Projetos do
HOLIS 2000
Defensor do projeto
Pete
Participante
Gerente de
Desenvolvimento de
Software
Responsvel pelo
desenvolvimento do HOLIS
2000
Jennifer
Participante
Perspectiva do proprietrio
Elmer
Participante
Gene
Participante
John
Participante
Diretor Executivo da
empresa Equipe de
Automao
Maior distribuidor da
Lumenations
Raquel
Participante
Gerente da
EuroControls
Distribuidor Europeu da
Lumenations
Betty
Participante
Presidente da Krystel
Eletric
Empreiteira Eltrica local
David
Participante
Presidente da
Construtor de casas
Rosewind Construction personalizadas
Vrios
membros
Observador
Equipe de
desenvolvimento
Todos os membros da
equipe que estiverem
disponveis
96
O Workshop
Antes do workshop, a equipe disponibilizou um pacote de aquecimento contendo:
Um artigo recente sobre tendncias de iluminao em automao de casas

Cpias de entrevistas seletivas que haviam sido conduzidas
Uma lista sumarizada das necessidades que foram identificadas at a data
Eric preparou suas habilidades de facilitador, e Cathy trabalhou na logstica do

workshop.
A sesso
A sesso foi realizada num hotel prximo ao aeroporto e comeou prontamente s
8:00 horas. Eric apresentou a agenda do dia e as regras do workshop, incluindo os
cupons de workshop. A Figura 112 fornece uma viso do workshop.
Pete, Gerente de
Desenvolvimento
de Software
Cathy,
Gerente de
Produto
Perspectiva
dos
proprietrios
Regras do
Workshop
Observadores
Facilitador
Participantes
Eric, Diretor de
Marketing
David,
Presidente da
Rosewind
Construction
Emily,
Gerente Geral
Membros disponveis
da equipe de
desenvolvimento HOLIS
Figura 112
Raquel, Gerente da
EuroControls
(Distribuidor Europeu
da Lumenations)
John, Gerente
Betty da Krystel
Exucutivo da
Eletric
Automation Equip
(maior distribuidor da
Lumenations)
Estrutura do workshop de requisitos do HOLIS 2000
Em geral o workshop caminhou muito bem, e todos os participantes estavam

preparados para dar suas informaes prontamente. Eric fez um bom trabalho de
facilitar a reunio, mas uma situao desagradvel ocorreu quando Eric
argumentou com a Cathy sobre as prioridades de duas caractersticas. (A equipe
decidiu que nos futuros workshops, um facilitador externo seria contratado). Eric
conduziu uma sesso de brainstorming sobre as caractersticas potenciais do
97
HOLIS, e a equipe usou a votao acumulativa para decidir as prioridades

relativas. Os resultados so apresentados na Tabela 111.
Tabela 111 Caractersticas do workshop HOLIS, ordenados por prioridade
ID Caractersticas
Votos
23 Cenas de iluminao personalizadas
121
16 Configurao do tempo automtico de iluminao, etc.
107
4 Caractersticas de segurana pr-definidas, p.ex., lmpadas e alarmes
105
6 100% de confiabilidade
90
8 Fcil de programar, unidade de controle no-PC
88
1 Facilidade de programar as estaes de controle
77
5 Configurao de ausncias
77
13 Toda lmpada pode ser apagada

9 Usar meu prprio PC para programar
74
73
14 Caractersticas de entretenimento
66
20 Portas da garagem fechadas
66
19 Ligar automaticamente as lmpadas quando a porta for aberta
55
3 Interface com o sistema de segurana residencial
52
2 Facilidade para instalar
50
18 Ligar automaticamente as luzes quando algum bate a porta

7 Ligar e desligar instantneo
50
44
11 Poder dirigir cortinas, sombras, bomba dgua e motores
44
15 Controlar a iluminao via telefone
44
10 Interface com o sistema de automao residencial
43
22 Modo gradual: aumento ou reduo da luminosidade lentamente
34
26 Estao de controle principal
31
12 Facilidade de expanso quando remodelado
25
25 Interface de usurio internacionalizado
24
21 Interface com o sistema de udio/vdeo
23
24 Restaurao aps falha no fornecimento de energia eltrica
23
17 Controle HVAC
22
28 Ativao via voz
27 Apresentao no web site do usurio
Anlise de Resultados
Os resultados do processo apresentaram-se como esperado, exceto por dois itens
significativos:
1. Segurana pr-definida surgiu na lista com alta prioridade. Esta
caracterstica havia sido mencionada em entrevistas anteriores, mas
no foi colocada na lista de prioridades de qualquer entrevistado.
Depois de uma rpida reviso, Cathy notou que a segurana prdefinida, tais como a habilidade de flash de luz, a sirene opcional e
98
sistemas de chamada para emergncias, aparentemente no eram

fornecidos pelos sistemas da concorrncia. Os participantes
comentaram que embora tenha sido uma surpresa esta informao, eles
acham que isso deve ser uma diferenciao competitiva e, de acordo
com isso, ser uma caracterstica de alta prioridade. Krys e David
concordaram. Com base nessa concluso, o marketing decidiu incluir
esta funcionalidade e coloc-la como o seu nico diferencial
competitivo no mercado. Esta ser uma das caractersticas que
definem o HOLIS.
2. Alm disso, a caracterstica 25, Internacionalizao da interface do
usurio no recebeu muitos votos. (Isto pareceu fazer sentido
equipe, porque os proprietrios localizados nos Estados Unidos no
podem se preocupar com o como o produto ser vendido na Europa!).
O distribuidor, no entanto, disse sem rodeios de que se o produto no
estiver internacionalizado desde a verso 1.0, ele no seria introduzido
na Europa. A equipe anotou esta posio e concordou em explorar o
esforo necessrio para alcanar a internacionalizao na release 1.03
Este assunto demonstra que um dos problemas com a votao acumulativa. Nem todos os stakeholders so criados
igualmente. Falhas em atingir a internacionalizao, que no havia aparecido no visor do radar da equipe antes do
workshop, poderia se tornar um equvoco de requisitos estratgicos de propores significativas.
99
Captulo 12
Storyboarding
Pontos chaves
O propsito do storyboarding elucidar as reaes iniciais Sim, mas.
Os storyboards podem ser passivos, ativos ou interativos.
Os storyboards identificam os jogadores, explicam o que acontece com eles e
descreve como acontece.
Fazer com que o esboo do storyboard seja fcil de modificar e no disponvel.
Os storyboards iniciais so comuns em todos os projetos que tenham contedos
novos e inovadores.
alvez nenhuma outra tcnica de elucidao tenha recebido tantas

interpretaes quanto o storyboarding. Apesar disso, vrias dessas
interpretaes concordam com o propsito do storyboarding, que o de
descobrir as reaes iniciais dos usurios sobre o conceito proposto pela
aplicao. Ao fazer isso, storyboards oferecem uma das tcnicas mais efetivas de
atacar a sndrome Sim, mas. Com o storyboarding, as reaes dos usurios
podem ser observadas logo no incio do ciclo de vida, bem antes que os conceitos
tenham comprometido o cdigo e, em muitos casos, at antes que as
especificaes detalhadas tenham sido desenvolvidas. Os especialistas em fatores
humanos, por anos, nos tm dito que o poder dos storyboards no deve ser
subestimado. De fato, a indstria do cinema tem usado esta tcnica desde que a
primeira centelha de luz foi projetada na tela.
Os storyboarding efetivos aplicam ferramentas que so baratas e fceis de usar. O
storyboarding:
extremamente barato.
amigvel, informal e interativo.
Fornece uma reviso inicial das interfaces de usurio do sistema.
fcil de criar e modificar.
Os storyboards so tambm uma forma poderosa de facilitar a sndrome da

pgina-branca. Quando os usurios no sabem o que querem, at um storyboard
muito pobre bom para elucidar uma resposta como No, isto no o que eu
queria, deveria ser o seguinte..., e o jogo comea.
Storyboards podem ser usados para acelerar o desenvolvimento conceitual de
vrias diferentes facetas de uma aplicao. Storyboards podem ser usados para
entender a visualizao de dados, para definir e entender as regras de negcio que
sero implementadas numa nova aplicao de negcio, para definir algoritmos e
outras construes matemticas que sero executados dentro de um sistema
embutido, ou para demonstrar relatrios e outras sadas impressas da reviso
inicial. De fato, os storyboards podem e devem ser usados para, virtualmente,
100
qualquer tipo de aplicao onde conhecer as reaes iniciais de usurios seja um

dos fatores chaves de sucesso.
Tipos de Storyboards
Basicamente, um storyboard pode ser qualquer coisa que a equipe quer que seja, e
a equipe deve se sentir livre para usar sua imaginao para pensar num storyboard
de aplicaes especficas. Storyboards podem ser categorizados em trs tipos,
dependendo do modo de interao com o usurio: passivo, ativo ou interativo.
Storyboards passivos contam uma estria ao usurio. Podem ser

consistidos de esboos, figuras, screen shots, apresentaes PowerPoint,
ou amostras de sadas. Num storyboard passivo, o analista interpreta o
papel do sistema e simplesmente conduz o usurio atravs do storyboard,
com uma exposio Quando voc fizer isto, isso acontece.
Storyboards ativos tentam fazer o usurio ver um filme que no foi
produzido ainda. Storyboards ativos so animados ou automatizados,
talvez por uma ferramenta de apresentao seqencial de slides ou de
animao, ou at por um filme. Storyboards ativos fornecem uma
descrio automatizada sobre a maneira de como o sistema de comporta
num cenrio normal de uso ou de operao.
Storyboards interativos permitem que o usurio experimente o sistema
tanto de maneira realstica quanto prtica. Sua execuo necessita da
participao do usurio. Storyboards interativos podem ser simulaes,
maquetes ou ser to sofisticado quanto um cdigo descartvel. Um
storyboards sofisticado construdo com cdigos descartveis pode estar
muito prximo a um prottipo descartvel (discutido no prximo
captulo).
Como ilustra a Figura 121, estas trs tcnicas de storyboarding oferecem um

continuum de possibilidades, variando desde um exemplo das sadas at
demonstraes interativas reais.
Passivo
Ativo
Screen shots
Apresentao
de slides
Interativo
Prototipao
Regras de
negcio
Animao
Demonstraes
reais
Relatrios de
Sadas
Simulao
Apresentaes
interativas
Complexidade e custo
Figura 121
Regras do brainstorming
101
De fato, o limite entre storyboards sofisticados e prottipos iniciais de um produto

algo nebuloso.
A escolha da tcnica de storyboarding varia de acordo com a complexidade do
sistema e dos riscos de enganos sobre o que o sistema precisa fazer.
Um sistema sem precedentes e inovador que tenha uma definio leve e confusa
pode necessitar de mltiplos storyboards, partindo do passivo para o interativo
conforme o entendimento da equipe sobre os aperfeioamentos do sistema.
O que os Storyboards Fazem

A Branca de Neve e os Sete Anes da Disney, o primeiro filme animado ento
produzido, usou storyboards, e eram rotineiramente usados como parte integrante
do processo criativo nos filmes e desenhos animados. Virtualmente, todos os
filmes, com caractersticas animadas ou desenhos animados comeam com
storyboards. Eles representam informaes cruas de criao usadas no
desenvolvimento de personagens e no enredo da estria.
Em software, storyboards so usados com maior freqncia para trabalhar
detalhes de interfaces homem-mquina. Nesta rea, geralmente uma das mais
volteis, cada usurio provavelmente possui diferentes opinies sobre como a
interface deve funcionar. Storyboards para sistemas baseados em usurios lida
com trs elementos essenciais de qualquer atividade:
1. Quem so os jogadores
2. O que acontece com eles
3. Como acontece
O elemento quem define os jogadores, ou usurios do sistema. Num sistema de
software, como discutimos anteriormente, o quem so jogadores tais como
usurios e outros sistemas ou perifricos os atores que interagem com a soluo
sistmica que estamos construindo. Para usurios, a interao tipicamente
descrita via informaes de telas ou de formulrios de entrada de dados, dados e
relatrios de sada, ou via outros tipos de perifricos de entrada e sada, tais como
botes, chaves, displays e monitores. Para perifricos e sistemas, interaes so
realizadas via uma interface de software ou hardware, tais como protocolo de
comunicao ou sinais do drive de controle de motor.
O elemento o que representa o comportamento de como os usurios interagem
com o sistema ou, alternativamente, o comportamento de como o sistema interage
com o usurio. O elemento como representa o estado que o jogador ou o sistema
assume durante a interao.
Por exemplo, ns fizemos um storyboard para um veculo de entretenimento
automtico de passeio no parque.
O quem representa o passageiro que passeia com o veculo.

O o que representa o comportamento do veculo quando vrios eventos so
fornecidos pelo passageiro.
O como fornece futuras descries de como essa interao acontecem
eventos, transies de estados e descreve tanto o estado do passageiro
102
(surpresa, assustado) quanto o estado do veculo (acelerando, freando,

descarregando)
Ferramentas e Tcnicas para o Storyboarding

As ferramentas e tcnicas para o storyboarding podem ser to variadas quanto a
imaginao dos membros da equipe e dos usurios do sistema. A construo de
storyboarding passivos tem sido realizada com ferramentas to simples quanto
papel e lpis ou notas Post-It. Storyboarding passivos sofisticados podem ser
construdos com gerenciadores de apresentao tais como o PowerPoint ou
Harvard Business Graphics. Storyboards interativos com usurios ativos ou
passivos tm sido construdos com HyperCard, SuperCard e com a utilizao de
vrios pacotes que permitem rpido desenvolvimento das telas de usurios e
relatrios de sada. Storyboards interativos podem ser construdos com uma
variedade de pacotes de software especficos para prototipao interativa, tal
como Dan Bricklins Demo It. Ferramentas tais como Director da Macromedia e
Cinemation da Vividus Corp. podem ser usados para criar animaes e
simulaes mais complexas.
Num exemplo simples, ocorrido na RELA, Inc, um membro da equipe tambm
tinha interesse em cartooning. No estgio de conceito de um projeto, ele apenas
esboou meia dzia de desenhos simples que mostravam os vrios aspectos da
interface do produto em seu uso tpico. Esta foi uma maneira simples e barata de
provocar uma reao dos potenciais usurios. Alm disso, a natureza dos cartoons
evitou alguns dos potenciais problemas do storyboards, como veremos mais tarde.
Infelizmente, nenhum outro cartunista foi encontrado depois que ele saiu da
empresa, deixando-nos a procurar tcnicas alternativas de sotryboarding!
Em nosso atual esforo, cujo foco na maioria das vezes so as aplicaes ISV, ns
nos viramos muito bem usando o PowerPoint ou outros gerenciadores de
apresentao de desktop comum, em combinao com amostrar de screen shots
construdos com as mesmas ferramentas usadas para construir GUIs (Graphical
User Interface) de aplicaes. Interessantemente, o incrvel avano na tcnica de
storyboarding pode muito bem ter sido a adio da capacidade de animao ao
PowerPoint. Repentinamente, a nossa habilidade de expressar a dinmica e
interatividade aumentara enormemente.
Dicas do Storyboarding
O storyboarding uma tcnica projetada para obter um feedback inicial do
usurio usando ferramentas inexpressivas. Assim, storyboards so particularmente
efetivos em atacar a sndrome Sim, mas. Eles ajudam tambm a atacar a
sndrome das Runas Desconhecidas elucidando imediatamente o feedback de
usurios tal como o que o sistema parece que no deve fazer. Mas, como em
qualquer tcnica, certas advertncias de aplicam. Aqui esto algumas dicas que
devemos ter em mente quando se pratica a tcnica do storyboarding.
No invista muito tempo no storyboarding. Clientes ficaro intimidados a

fazer mudanas se o storyboard se parecer muito com o produto real ou
eles podem pensar que esto insultando voc, um problema
particularmente difcil em algumas culturas. Tudo bem; mantenha o
103
storyboard deselegante e grosseiro, at mesmo cru. (Veja a estria do

storyboarding no final deste captulo).
Se voc no fizer nenhuma mudana, voc no aprender qualquer coisa.
Faa o storyboard para que seja fcil de modificar. Voc deve estar apto a
modificar um storyboard em algumas horas.
No faa o storyboard muito bom. Se voc fizer isso, os clientes iro
querer lev-lo. (Num projeto real, ns sofremos por anos tendo que dar
suporte num produto Excel/VB que nunca pretendeu ser mais do que um
storyboard). Mantenha o storyboard como rascunho; use ferramentas e
tcnicas que no causem perigo neste campo, especialmente para
storyboards que so codificados. (Dica: Se a aplicao ser implementada
em Java, escreva o storyboard em VB).
Sempre que possvel, faa o storyboard interativo. A experincia do
cliente ao usar a aplicao ir gerar maior feedback e permitir descobrir
mais requisitos novos do que o storyboard passivo.
Sumrio
Neste captulo, ns aprendemos sobre uma tcnica muito simples e barata para
elucidar requisitos. De ser forma, um storyboard qualquer coisa que voc pode
construir rapidamente e economicamente que elucide uma reao Sim, mas do
usurio.
Ns podemos afirmar com certeza que nunca deixamos de aprender alguma coisa
com o storyboard, e nunca houve um caso em que ns tenhamos sado de um
storyboard com exatamente o mesmo conhecimento que tnhamos antes de
entrarmos. Assim, nosso aviso para a equipe de desenvolvimento :
Storyboard no incio.
Storyboard com freqncia.
Storyboard em todos os projetos que possuam contedos novos e
inovadores.
Ao fazer isso, voc ir ouvir o quanto antes o Sim, mas, o qual ir lhe ajudar a
construir sistemas que melhor atenda as necessidades dos usurios reais. E, talvez,
voc ir rapidamente e economicamente ver seu trabalho realizado!
Uma Estria de Storyboarding

(Alguns fatos foram alterados para proteger inocentes e culpados desta quase
verdadeira estria). A estria ocorreu durante o desenvolvimento de um perifrico
eletromecnico complexo para um hospital farmcia. O cliente era um fabricante
da Fortune 1000; o fornecedor, a nossa empresa, havia sido contratada para
desenvolver este novo produto, um sistema eletromecnico ptico complexo para
controle de fludos. O projeto estava com problemas.
Um dia, o chefe dos gerentes do projeto contratado (o chamaremos de autor)
recebeu a seguinte chamada telefnica da gerncia superior do cliente (um vice104
presidente Snior, Sr. Big, uma pessoa poderosa quem ns nunca havamos
conhecido antes.
Sr. Big: Autor, como anda o nosso projeto favorito?
Autor: No muito bem.
Sr. Big: Estou ouvindo direito? Tudo bem, no existe problema grande o
suficiente que no possa ser resolvido. Rena sua equipe evenha at
aqui para uma reunio. Que tal na quarta-feira?
Autor: (afobadamente folheando a agenda da equipe para quarta-feira) Quartafeira est perfeito.
Sr. Big: Excelente. Venha e traga toda a sua equipe. Outra coisa, no se
preocupe com os custos de viagem. Ns cobriremos. Pro inferno!
Compre aquelas passagens s de ida.
Autor: (Engolindo seco) Est bem, obrigado. Ns nos veremos na quarta.
No dia indicado, ns entramos num grande salo de conferncia com a equipe de
projeto do cliente todos sentados na extremidade remota. A equipe claramente
estava reunida j algum tempo. (Questo: Por que a equipe sentiu necessidade de
se reunir antes que a verdadeira reunio comeasse?). O Autor, que no um
marinheiro de primeira viagem, caminhou para a outra extremidade da sala e
sentou-se prximo ao Sr. Big (a teoria diz que ser difcil para o Sr. Big gritar
com o Autor se eles estiver prximo ao Sr. Big; alm disso, se ele golpear o
Autor, existe a chance de venc-lo na justia e recuperar os lucros de projeto!).
Depois de uma breve discusso, o Autor notou que dentre os vrios problemas
importantes que preocupam o projeto, o problema da no convergncia dos
requisitos estava causando atrasos e excedendo os custos. O Sr. Big disse, Dme um exemplo. O Autor lhe deu um exemplo. Os membros da equipe do cliente
imediatamente comearam a argumentar entre si, talvez demonstrando que este
era o real problema. O subcontratado sussurrou um pequeno sinal de alvio. O Sr.
Big observou a equipe por um momento e ento disse, Muito engraado. D-me
mais um exemplo. A equipe do Autor arrancou cinco impresses coloridas, cada
uma realizada com perfeio profissional, do painel frontal proposto e disse: ns
apresentamos todas estas opes de projetos semanas atrs, e no conseguimos
convergir para nenhum desses projetos, e estamos exatamente no momento em
que precisamos disso. O Sr. Big disse, Isso no pode ser to difcil. Equipe,
escolha um. Os membros da equipe do cliente ento brigaram entre si
novamente. O dia passou desse jeito. No houve convergncia. Havia pouca
esperana.
Na manh seguinte, o Autor foi convidado para um caf da manh com um
membro da equipe de projeto (Membro da Equipe). O Membro da Equipe,
tambm um costureiro, arrancou o fundo de feltro de um pano, cortou com a
tesoura, e depois de colori-lo disse Eu gostaria de facilitar a parte da interface
do usurio na reunio usando essas ferramentas.
Autor:
Membro da Equipe:
Voc est brincando; no tem como fazer isso

funcionar. Isso parecer tolo e anti-profissional.
Eu entendo, mas quo efetivo fomos ontem?
105
O Autor, politicamente correto, no disse a primeira palavra que lhe veio mente.
A segunda palavra foi OK.
O prximo dia, o tom na sala de reunies foi muito diferente. A equipe do cliente
tinha, novamente, chegado cedo, mas desta vez estavam silenciosos e carrancudos
ao invs de descomedido e excitado. (Anlise: Agora eles sabem o quanto ns
estvamos atados e sem respostas. Eles haviam planejado nos matar, mas agora
sabem que estvamos sendo injustiados).
Para iniciar a reunio, o Membro da Equipe colocou uma pea de feltro de 3 por
5 (1 2 m) sobre a parede, gerando risos, mas no desinteresse por parte do
cliente.
O Membro da Equipe colocou grandes interruptores para chaves de potncia e
vrios botes de modo-terapia feitos de feltro, sobre o painel frontal e disse
Agora este projeto funciona?.
O cliente olhou para a parede e disse No, mas por que voc no desloca o boto
de parede de emergncia para baixo?.
O Membro da Equipe disse: Aqui, por que voc no faz isso?, e passou uma
tesoura para o cliente.
O cliente pegou a tesoura, e o Membro da Equipe deixou a sala. O cliente
continuou a sesso de projeto interativo com feltros e tesouras. Uma hora mais
tarde, o cliente olhou a parede e disse: Est muito bom; construa-o.
Permita-nos descobrir a moral da estria com uma pequena leitura de pergunta e
resposta:
Pergunta: Por que a loucura do feltro funcionou e a impresso colorida no?
Resposta: Existem duas razes.
Interatividade: O que o cliente pode fazer com cinco desenhos,
dos quais apenas uma parte satisfatria?
Usabilidade: Quo assustador pode ser cortar um grande pedao
de feltro?
O cliente, que tinha o domnio da especialidade, mas no necessariamente o
projeto, projetou uma soluo adequada para o seu prprio problema.
Ns adotamos a casa de feltro como nossa e fixamos na parede como uma
constante lembrana sobre o que ns aprendemos. A interface do usurio, embora
no tenha sido uma soluo tima, nunca mudou e se adequou aos propsitos dos
interessados. Mas, infelizmente, o projeto no foi um grande sucesso de venda,
embora o produto tenha ido para o mercado e alcanado sucesso. Como dissemos
anteriormente, este foi apenas um dos problemas enfrentados neste particular
projeto.
Lio 1: Entender as necessidades do usurio um problema frgil e confuso.

Utilize ferramentas leves e malucas storyboards e feltros, se necessrio
para atac-lo.
Lio 2: A tecnologia difcil. Pense duas vezes antes de voc iniciar um
negcio de terceirizao de perifricos mdicos.
106
Captulo 13
Aplicando Use Cases
Pontos chaves
Os use cases, como storyboards, identificam quem, o que e como do
comportamento do sistema.
Use cases descrevem as interaes entre um usurio e um sistema,
concentrando-se no que o sistema faz para o usurio.
O modelo use-case descreve a totalidade do comportamento funcional do
sistema.
o Captulo 12, descrevemos o storyboarding e discutimos como voc

pode usar storyboards para mostrar quem, o que e como do
comportamento do sistema e do usurio. Use cases so uma outra
tcnica para expressar este comportamento. Ns introduzimos
brevemente esta tcnica no Captulo 2 e 5, onde usamos para nos ajudar a modelar
o comportamento de um negcio.
Neste captulo, ns iremos desenvolver a tcnica use-case descrevendo como
podemos us-los para entender o comportamento do sistema que estamos
desenvolvendo, em oposio ao entendimento do comportamento do negcio que
ir utilizar o sistema. Em outras palavras, usaremos use cases como uma tcnica
de elucidao para entender o comportamento necessrio da aplicao que iremos
desenvolver para resolver o problema do usurio. Use cases so uma tcnica to
importante para capturar e especificar os requisitos do sistema que ns iremos
desenvolv-lo na Habilidade de Equipe 5, Refinando a Definio do Sistema e
Habilidade de Equipe 6, Construindo o Sistema Correto.
A tcnica use-case parte integral do mtodo da Engenharia de Software
Orientado a Objetos, como descrito no livro Object-Oriented Software
Engineering, A Use Case Driven Approach (Jacobson et al. 1992). Este mtodo
de anlise e projeto de sistemas complexos dirigido por use case, uma
maneira de descrever o comportamento do sistema a partir da perspectiva de
como os vrios usurios interagem com o sistema para atingir seus objetivos. Esta
abordagem, centrada no usurio, fornece a oportunidade para explorar o
comportamento do sistema com o envolvimento do usurio desde o incio.
Alm disso, como mencionamos anteriormente, use cases servem como
representaes UML para requisitos de um sistema. Alm de capturar os
requisitos do sistema, os use cases desenvolvidos no processo de elucidao de
requisitos iro ser muito teis durante as atividades de anlise e projeto. De fato, o
mtodo use-case importante durante todo o ciclo de vida do software; como
exemplo, os use cases podem assumir um papel significativo durante o processo
de testes. Nos captulos seguintes iremos desenvolver a tcnica use-case com
maior profundidade, por agora, ns precisamos entender apenas sobre como
aplicar use cases para capturar os requisitos iniciais do sistema.
107
Ns comeamos com uma definio menos formal do que iremos fornecer

posteriormente:
Um use case descreve uma seqncia de aes que um sistema executa
para produzir um resultado de valor a um particular ator.
Controlar lmpada
Em outras palavras, use cases descrevem as interaes entre um usurio e um

sistema, e eles focam sobre o que o sistema faz para o usurio. Alm disso,
como as aes so descritas numa seqncia, fcil seguir as aes e entender
o que o sistema faz para o usurio. Em UML, o use case representado por uma
simples figura oval com um nome abaixo.
Na elucidao de requisitos, use cases podem elucidar e capturar requisitos do
sistema. Cada use case descreve uma srie de eventos nos quais um particular
ator, tal como a Jenny a Modelo, interage com o sistema, tal como o Sistema
de Agendamento de Clientes da Agncia de Modelos Ad Lib, para atingir um
resultado de valor para a Jenny, tal como a localizao do prximo trabalho de
desfile.
Construindo o Modelo Use-Case

O modelo use-case de um sistema consiste de todos os atores do sistema e de
todos os use cases com os quais os atores interagem no sistema. O modelo usecase descreve a totalidade do comportamento funcional do sistema. O modelo
use-case tambm mostra os relacionamentos entre use cases, os quais facilitam
nosso entendimento do sistema.
O primeiro passo na modelagem use-case criar um diagrama do sistema que
descreva a fronteira do sistema e identifique os atores do sistema. Isso apresenta
um belo paralelo com os passos 3 e 4 dos cinco passos da anlise do problema,
onde ns identificamos os stakeholders do sistema e definimos a fronteira do
sistema. Ns tambm aprendemos nos Captulos 4, 5 e 6, como identificar os
atores que iro interagir com o sistema.
Por exemplo, num sistema de gerenciamento de estoques (Jacobson et al. 1992), a
fronteira do sistema pode se parecer como a Figura 131.
Pessoal do Escritrio
Chefe do Estoque
Use Case
Use Case
Sistema de Gerenciamento de
Estoques Acme
Motorista de
Cam inho
Use Case
Estoquista
Operador de
Empilhadeira
Figura 131
O sistema de estoque inicial, com atores identificados
108
Voc pode ver que o sistema usado por alguns usurios, cada um dos quais
interagem com o sistema para tingir um objetivo operacional especfico.
A anlise futura do sistema determina que certas linhas de comportamento do
sistema so necessrias para suportar as necessidades dos usurios. Essas linhas
so os use cases, ou a seqncia especfica pelas quais os usurios interagem com
o sistema para realizar um objetivo especfico. Exemplos desses use cases de
sistema podem incluir:
Distribuio manual dos itens dentro de estoque.

Insero de um novo item no estoque.
Verificar itens de estoque.
Aplicando Use Cases para Elucidao de

Requisitos
A noo de use cases pode ser descrita sob a perspectiva do usurio do sistema de
forma muito simples. Use cases so descritos em linguagem natural. So fceis de
descrever e documentar. Isto fornece um formato estruturado simples, ao redor do
qual a equipe de desenvolvimento e os usurios podem, juntos, trabalhar para
descrever o comportamento de um sistema existente ou para definir o
comportamento de um novo sistema. E, claro, cada usurio individualmente ir,
naturalmente, se concentrar nas capacidades do sistema que sero necessrias para
melhor fazer o seu trabalho. Se, alm disso, o comportamento do sistema for
totalmente explorado com todos os potenciais usurios, a equipe ter realizado um
grande avano em direo aos objetivos de entender por completo o
comportamento desejado do sistema. No final do processo, existiro muito poucas
runas de funcionalidade desconhecidas.
Alm disso, na medida em que o mtodo use-case explora as interfaces de
usurios diretamente, feedbacks iniciais podem ser obtidos sobre este importante
e voltil aspecto da especificao e projeto do sistema.
No entanto, devemos tambm entender que os usurios do sistema, embora
pertenam a uma classe importante, representam apenas uma das classes de
stakeholders. Podemos precisar aplicar outras tcnicas de elucidao para obter os
requisitos de outros stakeholders, tais como clientes no usurios, gerentes,
subcontratados, entre outros. Mais ainda, use cases no so to teis na
identificao de aspectos no-funcionais dos requisitos do sistema, tais como
requisitos de usabilidade, confiabilidade, performance, entre outros. Ns iremos
contar com outras tcnicas para atacar estes assuntos.
Depois que todos os use cases, atores e objetos do sistema tiverem sido
identificados, o prximo passo promover o refinamento dos detalhes de
comportamento funcional de cada use case. Essas especificaes use-case
consistem de descries textuais e grficas do use case, escritos do ponto de vista
do usurio.
As especificaes use-cases podem se entendidas como um repositrio que
descreve uma srie de eventos relacionados, que por sua vez podem ser usados
para deduzir outros requisitos que sero desenvolvidos mais tarde. Assim, uma
109
especificao use case pode incluir o passo O tcnico de manuteno entra com
o seu nome (16 caracteres no mximo), sobrenome, entre outros.
Como os use cases definem as interaes usurio/sistema, pode ser a hora
apropriada de definir, ao menos em conceito, as telas, displays, painis frontais,
entre outras coisas com as quais o usurio interage. Se um sistema de janelas
utilizado para apresentar as informaes, pode ser apropriado fazer uma descrio
grfica de alto-nvel dos dados a serem exibidos; os detalhes de projeto da
interface grfica formal (GUI), tais como definio de dados cores e fontes,
devem ser deixados para as fases posteriores. A Figura 132 ilustra uma poro
exemplo de uma especificao use-case.
Use Case: Redistribuio dos Itens de Estoque
1. O chefe do estoque d um comando para redistribuio do estoque.
2. A janela na Figura xxx apresentada ao chefe do estoque.
3. Os itens podem ser ordenados de vrias formas. A ordem indicada
com a seleo do menu Ordenar:
Ordem alfabtica
Ordem por ndice
Ordem de armazenamento
4. Na tabela Lugar; podemos optar em ver, ou todos os Lugares do
atual estoque ou, se selecionado um item, os lugares onde esse item
existe.
Figura 132
Especificao use-case para a distribuio manual do estoque.
Caso de Estudos: Os Use Cases do HOLIS

Impressionado com o poder dos use cases, a equipe de desenvolvimento do
HOLIS decidiu usar esta tcnica para descrever a funcionalidade do sistema
HOLIS em alto-nvel. A fim de fazer isso, a equipe organizou uma sesso de
brainstorming para definir os use cases significantes os quais sero desenvolvidos
mais tarde nas atividades posteriores. Esta anlise do modelo use-case
identificou 20 use cases, alguns dos quais so os seguintes:
Nome
Descrio
Atores
Criar Cena de Iluminao

Personalizada
Residentes criam uma cena de iluminao

personalizada
Residente,
Lmpada
Iniciar Emergncia
Residentes iniciam ao de emergncia
Residncia
Controlar Iluminao
Residentes ligam ou desligam as lmpadas,

ou reduzem a intensidade desejada de luz
Residentes,
Lmpadas
Trocar Programao
Mudar ou configurar as aes para um

particular boto/interruptor
Proprietrio /
programador
Programar Remotamente
O provedor de servios de iluminao realiza

remotamente a programao com base nas
solicitaes do residente
Servios de
Iluminao
Tirar Frias
Proprietrios configuram a ausncia por um

longo perodo
Proprietrio /
programador
Configurar a Seqncia
de Tempo
O proprietrio programa a seqncia de

iluminao automtica com base no tempo
Proprietrio /
programador
110
Sumrio
Use cases fornecem uma notao estruturada e razoavelmente formal para
capturar um subconjunto mais importante das informaes de requisitos: como o
sistema interage com o usurio para liberar sua funcionalidade. Em muitas
aplicaes, este subconjunto representa a principal carga de trabalho, tal que use
cases podem ser aplicados para expressar os principais requisitos do sistema.
Cada use case identificado define os comportamentos necessrios do sistema sob
a perspectiva de uma classe particular de usurio. Como tal, a tcnica muito til
na elucidao das necessidades do usurio e ajuda a equipe de desenvolvimento
representar tais necessidades de maneira que seja prontamente compreensvel pelo
usurio.
Alm disso, como os use cases podem ser usados, posteriormente, nos processos
de projeto e testes; eles fornecem uma representao consistente e uma linha
consistente atravs das atividades de requisitos, anlise, projeto e testes. Desta
forma, a tcnica constri antecipadamente recursos de projeto reutilizveis que
ajudam a aperfeioar a eficincia global do processo de desenvolvimento de
software. Mais ainda, com a consistncia da representao e o suporte fornecido
pela UML e por diversas ferramentas de desenvolvimento de aplicaes, use
cases podem ajudar na automao de vrios elementos da atividade de
gerenciamento de requisitos. Por estas razes, use cases so notaes to
importantes que ns os aplicamos deste ponto em diante como parte integrante
das atividades de gerenciamento de requisitos de equipe.
111
Captulo 14
Role Playing
Pontos chaves
O role playing permite que a equipe de desenvolvimento experimente o mundo
do usurio a partir da perspectiva do usurio.
Um roteiro de acompanhamento pode substituir o role playing em algumas
situaes, com o script se tornando num storyboard vivo.
Os cartes CRC (Classe-Responsabilidade-Colaborao) freqentemente usados
na anlise orientada a objetos, so um derivado do role playing.
t agora, na Habilidade de Equipe 2, temos discutido uma variedade de

tcnicas para entender as necessidades dos stakeholders com respeito ao
novo sistema que estamos construindo. Ns falamos cara-a-cara sobre
o sistema (entrevista); ns discutimos em grupo sobre o sistema
(workshops); ns apresentamos nossas idias sobre o sistema (storyboard); e ns
analisamos como os atores interagem com o sistema (use cases). Todas essas
tcnicas so boas, elas definem uma estrutura para a nossa compreenso. Mas,
vamos admitir, ns no experimentamos o sistema.
Neste captulo, ns discutimos o role playing, o qual permite a equipe de
desenvolvimento experimentar diretamente o mundo do usurio pela interpretao
do papel do usurio. O conceito por detrs do role playing muito simples.
Embora seja verdade que a observao e o questionamento auxiliam o
entendimento, seria ingenuidade assumir que, apenas atravs da observao, o
desenvolvedor/analista possa chegar verdade, entendendo em profundidade o
problema a ser resolvido ou, atravs disso, entender claramente os requisitos do
sistema que deve solucionar o problema.
Esta uma das causas primrias do problema Sim, mas. Como os socilogos
nos ensinam, todos ns vemos o mundo atravs de nosso nico filtro conceitual.
impossvel separar as nossas experincias de vida e influncias culturais das
observaes que fazemos. Por exemplo, podemos observar uma outra cultura
realizando uma cerimnia ritualstica quando quisermos, mas, provavelmente,
ser impossvel entendermos o que eles significam! O que isso significa para a
nossa busca por entender requisitos?
Devemos entender que muitos usurios no conseguem articular os

procedimentos que eles realizam ou as necessidades que devem ser
atendidas. Mesmo assim o trabalho realizado e eles nunca foram
questionados sobre isso antes. Alm disso, mais difcil descrever do que
ver! Por exemplo, tente descrever o procedimento de calar o seu sapato.
Muitos usurios no tm a liberdade de admitir que eles no seguem os
procedimentos prescritos; ento, o que eles dizem para voc pode ou no
ser o que eles realmente fazem.
112
Cada usurio possui seu prprio padro de trabalho profundamente

impregnado, aplicam quebra-galhos ou caminhos prprios de
implementao, os quais mascaram os problemas reais para quem os
observa.
impossvel para qualquer desenvolvedor antecipar todas as questes que
devem ser perguntadas ou para quaisquer usurios saberem quais questes
que os desenvolvedores deveriam perguntar.
Para atender a essas causas em particular, o simples ato de interpretar papis

(role playing) pode ser extremamente efetivo. barato e normalmente muito
rpido. Normalmente, em uma hora ou meio dia a mgica ter sido realizada.
Como Interpretar o Papel

Na forma mais simples de interpretar papis, o desenvolvedor, o analista, e,
potencialmente, todos os membros da equipe de desenvolvimento simplesmente
tomam o lugar do usurio e executam as atividades de trabalho do cliente. Por
exemplo, no caso do problema de entrada dos pedidos de venda da Habilidade de
Equipe 1, alertamos para o fato de que os pedidos de venda imprecisos era o
principal condutor para o alto custo de desperdcios e, atravs disso, criar
vantagens do problema. Quando ns olhamos para o processo de pedidos de
venda, ns esperamos encontrar uma srie de passos diferentes e fontes de erros.
Existem ao menos duas maneiras de descobrir as razes causas.
1. Use a tcnica da espinha de peixe que descrevemos, junto com a
entrevista de usurios, e analise os pedidos de venda que
reconhecidamente possuem erros. Quantifique os erros por tipos e
ataque os mais graves no projeto de um novo sistema. Isso pode
fornecer um entendimento quantitativo para o problema e
provavelmente ser bastante efetivo.
No entanto, isso no lhe d a impresso qualitativa do problema,
aquela que possa, talvez, mudar tanto a percepo quanto a sua
estratgia de soluo. A fim de conseguir isso, talvez exista uma
maneira mais eficiente para verdadeiramente entender o problema.
2. O desenvolvedor/analista pode experimentar os problemas e
imprecises intrnsecas ao sistema de entrada de pedidos existente,
apenas sentando-se e entrando com alguns pedidos de venda. A
experincia obtida em 1 hora ir mudar, para sempre, o entendimento
da equipe sobre o problema.
Experimente!
Ns podemos dizer que as experincias obtidas no role playing, podem ficar com
os desenvolvedores pelo o resto da vida. Nossa viso pessoal do mundo foi
mudando de acordo com tais experincias, incluindo os simples papis de soldar
uma pea complexa da maneira que se supem que os robs faam, misturar
compostos farmacuticos num depurador de fluxo laminar, identificar uma
televiso comercial com apenas quatro resumos de tela e uma trilha de udio,
usar ferramentas de software para gerenciamento de requisitos imaturos, entre
muitos outros. Ns aprendemos sempre alguma coisa, e desenvolvemos uma
grande empatia com os usurios com os quais estivemos!
113
Tcnicas Similares ao Role Playing

Naturalmente, o role playing no funcionam em todas as situaes. Em muitos
casos, o papel do usurio mnimo, e o problema a ser resolvido
algoritmicamente, ao invs de funcionalmente, intenso. E, em muitos casos,
simplesmente no prtica. Ns no gostaramos de ser o primeiro voluntrio
para fazer o papel de paciente num cenrio de cirurgia auxiliada por
equipamentos eletrnicos ou de operador de uma fbrica nuclear no perodo
noturno ou piloto de um 747. Em muitos casos, outras tcnicas nos aproximam
das experincias de usurios sem ter que sangrar pelos lados.
Roteiro de Acompanhamento
Um roteiro de
acompanhamento
um jogo no papel.
Num roteiro de acompanhamento (scripted walkthrough), cada participante segue

um roteiro que define um papel especfico dentro do jogo. O acompanhamento
ir demonstrar qualquer mal-entendido nos papis, falta de informao disponvel
sobre um ator ou subsistema, ou falta de um comportamento especfico necessrio
para que atores possam ter sucesso em seus esforos.
Por exemplo, certa vez ns construmos um roteiro de acompanhamento que
mostrava como o professor e estudantes deviam interagir com um dispositivo
automtico de prova-pontuao usado na sala de aula. Ns usamos um prottipo
do dispositivo e tnhamos membros da equipe e representantes do cliente
interpretando os papis de alunos e de professor. O roteiro de acompanhamento
continha muitas cenas, tais como pontuao dos estudantes em suas provas e
professor pontuando um grande lote de provas durante a aula. O roteiro de
acompanhamento foi muito til para perceber o ambiente de uma sala de aula, e a
equipe aprendeu algumas coisas novas durante a experincia. Foi muito divertido.
Uma das vantagens do roteiro de acompanhamento que o roteiro pode ser
modificado e reexecutado quantas vezes forem necessrias at que os atores
faam direito. O roteiro pode tambm ser reusado para educar novos membros da
equipe. Ele pode ser modificado e reusado quando o comportamento do sistema
for alterado. Assim, o roteiro se transforma num storyboard vivo do projeto.
Cartes CRC (Classe-Responsabilidade-Colaborao)

Um derivado do role playing freqentemente aplicado como parte de um
esforo de anlise orientado a objetos. Neste caso especial de role playing, dado
a cada participante um conjunto de cartes descrevendo a classe, ou objetos; as
responsabilidades, ou comportamentos; e colaboraes, ou com quem os objetos
se comunicam, de cada entidade sendo modelada. Essas colaboraes envolvem
entidades do domnio do problema, tais como usurios, botes, lmpadas e
elevador de carros, ou objetos que vivem no domnio da soluo, tais como Boto
Indicador de Luz, Windows MDI e Elevador de Carro.
Quando o ator inicia um dado comportamento, todos os participantes seguem o
comportamento definido em seus cartes. Quando o processo falhar devido a uma
falta de informao ou quando uma entidade precisar falar com uma outra e a
colaborao no estiver definida, os cartes so modificados e o jogo recomea.
114
Por exemplo, no caso de estudos HOLIS, existir um momento em que a equipe

precisar entender as interaes entre os trs subsistemas a fim de determinar
como o sistema ir cooperar para atingir os objetivos e entender quais sero os
requisitos derivados criados. Uma forma de fazer isso utilizar os cartes CRC
como roteiro de acompanhamento. Um membro da equipe deve fazer o papel de
um subsistema, ou ator, e ento a equipe deve acompanhar atravs do use case, ou
cenrio. Aqui est como um use case pode ser exercitado:
John
(Chave de
Controle):
O proprietrio acabou de pressionar um boto que controla um

banco de luz. Ele ainda est pressionando a chave. Eu enviarei ao
Bob uma mensagem assim que a chave estiver totalmente
pressionada, e enviarei ao Bob uma mensagem a cada segundo em
que a chave ficar pressionada.
Bob
(Unidade de
Controle
Central):
Quando eu receber a primeira mensagem, mudarei o estado da

sada de Desligado para Ligado. Quando eu receber a segunda
mensagem, sei que o proprietrio est reduzindo a intensidade do
banco de luz. Assim, a cada mensagem recebida, reduzirei a
intensidade da luz em 10%. John, no esquea de me dizer qual
boto est pressionado.
Eu estou fisicamente conectado sada do dimmer. Eu percebo o

Mike
(Lmpada): dimmer como ns falamos.
Nota: Na elucidao das necessidades do usurio, o processo CRC direcionado para

os comportamentos externos que so aparentes aos atores, mas esta tcnica pode
tambm ser usado para projetar sistemas orientados a objetos. Neste exerccio, o
foco estava em entender o trabalho interno do software, no nas interaes com o
ambiente externo. No entanto, at nesses casos, a tcnica ajuda a descobrir erros
ou enganos de requisitos do sistema.
Voc deve ter notado um efeito colateral interessante. Os jogadores
invariavelmente acham que existem falhas ou deficincias no roteiro e os corrigem,
resultando normalmente no aperfeioamento no entendimento do sistema.
Sumrio
O role playing uma excelente tcnica, embora no a tenhamos visto em uso com
muita freqncia. Por que? As razes so muitas. Existe o fator desconforto. Esta
tcnica no nos motiva ao ter que fazer mal feito um simples pedido de venda
enquanto nossos clientes ou pessoas que entram com um pedido de venda nos
observam. Alm disso, existe o fator delicado e confuso: Ser forado a interagir
com pessoas reais ao invs de com um teclado, nos faz sair da nossa zona de
conforto afinal de contas, ns queremos compilar classes tericas, deixem que
nossos colegas participem de um drama!
No entanto, no h dvidas de que, se ns conseguirmos vencer essa pequena
dificuldade, o role playing ser uma das tcnicas mais acessveis e eficazes para
assistir no descobrimento de requisitos.
115
Captulo 15
Prototipao
Pontos chaves
A prototipao especialmente efetiva para atacar as sndromes Sim, mas e
Runas Desconhecidas.
Um prottipo de requisitos de software uma implementao parcial do
sistema de software, construdo para auxiliar os desenvolvedores, usurios e
clientes a melhor entenderem os requisitos do sistema.
Crie prottipos para requisitos confusos: aqueles que, embora conhecidos ou
implcitos, suas definies so pobres e mal compreendidas.
s prottipos de software, como encarnaes de um sistema de software,

demonstram uma poro da funcionalidade de um novo sistema. Dado o
que discutimos at aqui, ns esperamos que fique obvio de que a
prototipao pode ser muito til para descobrir necessidades do usurio.
Usurios podem tocar, sentir e interagir com o prottipo do sistema de maneira
que nenhuma das outras tcnicas pode fornecer. De fato, a prototipao pode ser
extremamente efetivo para atacar tanto a sndrome Sim, mas (Isso no
exatamente o que eu queria), quanto a sndrome das Runas Desconhecidas
(Agora que eu vi, eu tenho um outro requisito a adicionar).
Tipos de Prottipos
Prottipos podem ser categorizados de vrias maneiras. Por exemplo, Davis
(1995a) categoriza os prottipos como descartvel versus evolucionrio versus
operacional, vertical versus horizontal, interface de usurio versus algortmico,
entre outras. O tipo de prottipo que voc escolhe depende do problema que voc
est tentando resolver atravs da construo do prottipo.
Por exemplo, se o risco do seu projeto baseado principalmente na viabilidade da
abordagem tecnolgica isso, simplesmente nunca foi feito antes e voc no est
certo se a tecnologia aplicada pode atingir as metas de desempenho ou de
rendimento voc pode querer desenvolver um prottipo arquitetural que
principalmente demonstre a viabilidade da tecnologia a ser usada. Um prottipo
arquitetural pode ainda ser descartvel versus evolucionrio. Descartvel
implica que o propsito do esforo apenas para provar a viabilidade; assim,
voc poder usar qualquer atalho, tcnicas alternativas, simulaes, ou qualquer
outra coisa para atingir esse propsito. Quando voc tiver terminado, voc
simplesmente o descarta, mantendo apenas o conhecimento apreendido nesse
exerccio. Evolucionrio implica que voc implementou o prottipo na mesma
arquitetura que voc pretende usar no sistema final, e que voc ser capaz de
construir o sistema final a partir da evoluo do prottipo.
116
Se a principal rea de risco de seu projeto a interface do usurio, por contrate,

voc ir querer desenvolver um prottipo de requisitos, usando qualquer
tecnologia que permita a voc, desenvolver interfaces do usurio muito
rapidamente. A Figura 151 ilustra uma rvore de deciso que voc pode usar
para selecionar um tipo de prottipo que faa mais sentido para o seu projeto.
Distncia
do risco
Larga
Evolucionrio
Distncia
do risco
Requisitos
Risco de
projeto?
Distncia
do risco
Descartvel
Estreita
Larga
Distncia
do risco
Evolucionrio
(b)
Estreita
Larga
(a)
Estratgia de
investimento?
Vertical
Descartvel
Estratgia de
investimento?
Tecnolgico
Estreita
Estreita
Larga
Horizontal
Vertical
Horizontal
Vertical
Horizontal
Vertical
Horizontal
Figura 151 rvore de deciso para seleo do tipo de prottipo: (a) prottipos de requisitos; (b)
prottipos arquiteturais
Prottipos de Requisitos
Para propsitos de elucidao de requisitos, ns nos concentramos sobre os tipos
de prottipos sob o ramo superior desta rvore. Definimos um prottipo de
requisitos de software como:
uma implementao de um sistema de software, construda para ajudar
desenvolvedores, usurios e clientes a melhor entender os requisitos do
sistema.
Com o propsito de elucidar requisitos, ns freqentemente escolhemos construir

um prottipo descartvel, horizontal, interface do usurio. Horizontal implica
que ns iremos tentar construir uma grande quantidade de funcionalidade do
sistema; um prottipo vertical, por outro lado, constroem-se apenas alguns
requisitos de maneira qualitativa. Interface de usurio implica que ns iremos
construir principalmente a interface do sistema para seus usurios ao invs de
implementar a lgica e os algoritmos que residem dentro do software ou
117
prototipar interfaces para outros dispositivos ou sistemas. Como uma ferramenta

de elucidao, os prottipos:
Construdos por desenvolvedores, podem ser usados para obter

confirmao de que o desenvolvedor entendeu os requisitos.
Construdos por desenvolvedores, podem ser usados como um catalisador
para encorajar o cliente a pensar em mais outros requisitos.
Construdos pelo cliente, podem comunicar requisitos ao desenvolvedor.
Em todos os trs casos, a meta construir o prottipo de maneira que consuma

poucos recursos. Se ficar muito caro construir, pode ser melhor construir o
sistema real!
Muitos prottipos de software tendem a ser prottipos de requisitos e so usados
principalmente para capturar aspectos da interface do usurio do sistema a ser
construdo. Existem provavelmente duas razes para isso:
1. A emergncia de uma pletora4 de ferramentas baratas e amplamente
disponveis para construir interfaces de usurios rapidamente.
2. Para sistemas cujas interfaces de usurio sejam intensas, um prottipo
de interface de usurio revela, tambm, muitos outros requisitos, tais
como as funes que so fornecidas ao usurio, quando cada funo
est disponvel aos usurios e quais funes no so acessveis aos
usurios.
No entanto, precisamos estar certos de que a disponibilidade de ferramentas no
nos leve a prototipar partes do sistema que no apresentem, inicialmente, riscos
muito altos.
O que Prototipar
Como vamos saber qual poro do sistema devemos prototipar? Numa situao
tpica, nosso entendimento das necessidades dos usurios ir variar desde o bem
conhecido e fcil de verbalizar at o totalmente desconhecido (Figura 152).
Bem conhecido
Figura 152
Confuso
Desconhecido
O sistema de estoque inicial, com atores identificados
Os requisitos bem-conhecidos podem ser bvios no contexto do domnio da

aplicao e a experincia do usurio e da equipe com sistemas desse tipo. Por
exemplo, se estivermos simplesmente estendendo um sistema existente, teremos
claramente a idia de como a maioria das necessidades por novas funcionalidades
deve ser. Os requisitos bem-conhecidos e bem-entendidos no precisam ser
prototipados, a menos que sejam necessrios para ajudar a visualizar o contexto
de outras necessidades de usurios; constru-los ir consumir os j parcos recursos
4
Superabundncia qualquer, que produz efeito nocivo.
118
existentes, e como j esto bem-compreendidos, aprenderemos muito pouco com

eles.
Os requisitos desconhecidos, no entanto, so as Runas Desconhecidas que ns
desejamos conhecer. Infelizmente, ns no podemos realmente prototip-los, se
pudssemos, no seria desconhecido! Assim, sobra como alvo de prototipao as
partes Confusas que esto no meio. Esses requisitos podem ser conhecidos ou
implcitos, mas sua definio e entendimento so pobres.
Construindo o Prottipo
A escolha da tecnologia usada para construo do prottipo depende das decises
tomadas considerando a rvore de deciso da Figura 151. Por exemplo, a escolha
por um prottipo descartvel da GUI nos leva a escolher qualquer tecnologia que
seja barata e rpida para implementar exemplos de GUIs.
Se um prottipo evolucionrio for selecionado, voc deve escolher a linguagem e
o ambiente de desenvolvimento que ser utilizado para produzir a implementao
final. Voc tambm ter que fazer esforos significativos para projetar a
arquitetura de software do sistema, bem como aplicar quaisquer padres de
codificao ou processos de software que voc usar para criar o sistema. Caso
contrrio voc ter que evoluir um sistema que fundamentalmente falha em um ou
mais desses aspetos. Neste caso, voc pode ter criado um prottipo descartvel
por acidente! Ou, pior, a qualidade do sistema implantado estar, para sempre,
comprometida pelo seu prottipo de requisitos bem-intencionado.
Avaliando os Resultados
Depois que o prottipo estiver construdo, ele deve ser exercitado pelos usurios
num ambiente que simule, tanto quanto possvel, o ambiente de produo no qual
o sistema final ser usado. Dessa forma, ambientes e outros fatores externos que
afetam os requisitos do sistema tambm se tornaro bvios. Alm disso,
importante que existam vrios tipos de usurios exercitem o prottipo, caso
contrrio os resultados sero preconceituosos.
Os resultados do processo de prototipao dividem-se em duas partes:
1. Necessidades confusas tornam-se melhor entendidas.
2. Ao exercitar o prottipo, inevitavelmente elucida respostas Sim, mas
do usurio; assim, necessidades anteriormente desconhecidas tornamse conhecidas. Simplesmente por enxergarem um conjunto de
comportamentos, os usurios passam a entender outros requisitos que
devem ser impostos ao sistema.
De qualquer forma, a prototipao virtualmente sempre produz resultados. Assim,
voc deve normalmente prototipar qualquer aplicao nova ou inovadora. O
truque assegurar que o retorno obtido no conhecimento dos requisitos faa valer
o investimento realizado. Isso porque queremos, freqentemente, prototipar ou
ao menos implementar nossos primeiros prottipos rapidamente, utilizando
tcnicas baratas e disponveis. Ao limitar o investimento, ns maximizamos o
retorno sobre o investimento de obter o entendimento dos requisitos.
119
Sumrio
Devido aos prottipos de software demonstrarem uma parte da funcionalidade
desejada de um novo sistema, eles podem ser ferramentas efetivas para ajudar a
refinar os requisitos reais do sistema. Eles so efetivos porque usurios podem
interagir com um prottipo em seu ambiente, o qual to prximo ao mundo real
quanto se puder chegar sem desenvolver o software de produo.
Voc deve selecionar sua tcnica de prototipao com base na probabilidade de
um tipo de risco estar presente em seu sistema. Supe-se que os prottipos de
requisitos sejam baratos e fceis de desenvolver, e que eles ajudem a eliminar
grande parte dos riscos de requisitos de seu projeto.
Entre as vrias possibilidades de investimento, voc deve investir somente o
necessrio em seu prottipo. O uso de vrias tcnicas de prototipao, ou melhor,
o uso combinado de diversas de tcnicas de prototipao, tem se mostrado
extremamente efetivo em auxiliar a equipe de projeto a desenvolver um melhor
entendimento das reais necessidades de um sistema de software.
120

Trs sndromes contribuem com os desafios de entender as reais necessidades
dos usurios e de outros stakeholders. A sndrome do Sim, mas, das Runas
Desconhecidas e do Usurio e o Desenvolvedor so metforas que nos ajudam
a entender melhor os desafios que esto nossa frente e fornecem um contexto
para as tcnicas de elucidao que desenvolvemos para entender as necessidades
dos usurios.
Porm, como so raros os casos onde a equipe recebe especificaes efetivas de
requisitos do sistema que eles tero que construir, eles tm que sair e obter as
informaes que precisam para garantir o sucesso. O termo elucidao de
requisitos descreve este processo, onde a equipe deve assumir um papel mais
ativo.
Para ajudar a equipe nessa misso, uma variedade de tcnicas pode ser usada para
atacar problemas e melhorar o entendimento das reais necessidades dos usurios e
de outros stakeholders:
Entrevistas e questionrios
Workshop de requisitos
Brainstorming e reduo de idias
Storyboarding
Use cases
Role playing
Prototipao
Embora nenhuma das tcnicas seja perfeita para todas as circunstncias, cada um
representa um meio pr-ativo de impulsionar o entendimento das necessidades do
usurio e converter requisitos confusos para requisitos que sejam melhor
conhecidos. Embora todas estas tcnicas funcionem em certas circunstncias, o
nosso favorito a tcnica do workshop/brainstorming.
121
Definindo o Sistema
Captulo 16: Organizando as Informaes de Requisitos

Captulo 17: O Documento da Viso
Captulo 18: O Campeo
122
Na Habilidade de Equipe 1, ns desenvolvemos as habilidades que fazem com que a

equipe concentre-se na anlise do problema. Ao fazer isso, ns conseguimos
compreender totalmente o problema a ser resolvido antes que fossem investidos
quaisquer esforos srios na soluo. Ns estivemos completamente concentrados no
domnio do problema.
Na Habilidade de Equipe 2, descrevemos um conjunto de tcnicas que a equipe pode
usar para entender as necessidades do usurio. Essas necessidades do usurio vivem no
topo da nossa pirmide de requisitos, indicando que so essas as informaes que
devemos entender inicialmente, por serem as mais crticas e dirigirem tudo o que vier
aps esse entendimento.
A quantidade de
informaes que
devemos gerenciar
aumenta
rapidamente
conforme nos
movemos para baixo
da pirmide.
Na Habilidade de Equipe 3, partimos do espao do problema para chegar ao espao da

soluo, sendo que o nosso foco se concentrar na definio do sistema que ser construdo
para atender as necessidades dos stakeholders. Conforme nos movemos para baixo da
pirmide, (veja Figura 1), a quantidade de informaes aumenta. Por exemplo, podem
ser necessrias grandes quantidades de caractersticas do sistema para atender a uma
nica necessidade do usurio. Comeamos, tambm, a fornecer especificidades
adicionais para facilitar a definio do comportamento do sistema; desse modo, a
quantidade de informaes que devemos gerenciar aumenta.
Needs
Domnio do Problema
Features
Domnio da Soluo
Figura 1
Caractersticas na pirmide de requisitos
Alm disso, a equipe deve, agora, tambm se preocupar com vrios outros assuntos que
so nicos no espao da soluo, mas que tm um pouco a ver com o domnio do
problema. Por exemplo, se ns estivermos desenvolvendo um produto de software para
ser vendido ao usurio, devemos nos preocupar com empacotamento, instalao e
licenciamento, cada um dos quais podem ser nicos para a soluo que estamos
fornecendo. Se estivermos desenvolvendo um sistema para atender as necessidades de
IS/IT na empresa do cliente, pode ser que precisemos nos preocupar com os requisitos
de implantao e manuteno, os quais so de pouco ou nenhum interesse ao usurio
que no est usando o sistema.
123
No entanto, devemos ainda manter a abstrao suficientemente alta, para no nos

perdermos em detalhes muito rapidamente, no nos permitindo ver a floresta entre as
rvores. Alm disso, importante parar por um segundo, para organizar as
informaes de requisitos, antes de nos movermos de seo da pirmide de requisitos de
software. Isso ser visto na Habilidade de Equipe 5, Refinando a Definio do Sistema.
Por agora, iremos cobrir a organizao das informaes de requisitos (Capitulo 16), a
definio de uma viso (Captulo 17) e a organizao de nossa equipe para atacar os
desafios de gerenciamento de requisitos para o sistema (Captulo 18).
124
Captulo 16
Organizando Informaes de
Requisitos
Pontos chaves
Para aplicaes no triviais, requisitos devem ser capturados e registrados numa
base de dados de documentos, modelos e ferramentas.
Tipos diferentes de projetos requerem diferentes tcnicas de organizao de
requisitos.
Sistemas complexos exigem especificao de requisitos para cada subsistema.
equisitos devem ser capturados e documentados. Se voc for um

desenvolvedor solitrio de um sistema no qual tambm ser o usurio e o
mantenedor, voc pode pensar em fazer o projeto e a codificao
imediatamente aps identificar suas necessidades. No entanto, poucos
desenvolvimentos de sistemas so assim to simples. muito provvel que
desenvolvedores e usurios sejam mutuamente exclusivos, e que stakeholders,
usurios, desenvolvedores, analistas, testers, arquitetos e outros membros da
equipe estejam envolvidos. Todos devem chegar a um acordo sobre o sistema que
ser desenvolvido.
A realidade do oramento e do cronograma no torna razovel satisfazer todas as
necessidades do usurio em qualquer particular release. Inevitavelmente,
problemas inerentes comunicao, devido ao esforo envolvendo mltiplas
pessoas, iro exigir que um documento escrito seja produzido para que todas as
partes possam concordar e consultar.
Documentos que definem o produto a ser construdo so normalmente chamados
de especificao de requisitos. A especificao de requisitos de um sistema ou
aplicao descreve o comportamento externo desse sistema.
Nota: Por simplicidade e para refletir a conveno histrica, usamos o termo
documento de forma genrica nesta seo, mas requisitos podem estar presentes
num documento, numa base de dados, num modelo use-case, repositrio de requisitos
ou numa combinao desses elementos. Como veremos nos prximos captulos, um
pacote de requisitos de software pode ser usado para conter esta informao.
Mas, os requisitos raramente podem ser definidos num nico documento

monoltico por uma srie de razes:
O sistema pode ser muito complexo.

125
As necessidades dos clientes so documentadas antes da documentao

detalhada dos requisitos.
O sistema pode ser um membro de uma famlia de produtos relacionados.
O sistema a ser construdo satisfaz a apenas um subconjunto de todos os
requisitos identificados.
necessrio que as metas de marketing e de negcio estejam separadas
dos detalhes de requisitos do produto.
Em qualquer um dos casos, voc precisar manter mltiplos documentos e,

naturalmente, considerar vrios casos especiais:
Um documento pai define os requisitos do sistema como um todo,

incluindo hardware, software, pessoas e procedimentos; e um outro define
os requisitos apenas para a pea de software. Normalmente, o primeiro
documento chamado de especificao dos requisitos do sistema,
enquanto que o segundo chamado de especificao dos requisitos de
software, ou SRS para abreviar.
Um documento define as caractersticas (features) do sistema em termos
gerais, e o outro define os requisitos em termos mais especficos. Com
freqncia, o primeiro documento chamado documento da viso, o
segundo chamado de especificao dos requisitos de software.
Um documento define o conjunto total de requisitos para uma famlia de
produtos, e o outro define os requisitos de apenas uma aplicao especfica
e para um release especfico. O primeiro documento normalmente
chamado de documento dos requisitos da famlia de produtos, ou
documento da Viso da famlia de produtos, j, o segundo, chamado de
especificao de requisitos de software.
Um documento descreve os requisitos gerais de negcio e ambiente de
negcio no qual o produto ir residir, e o outro define o comportamento
externo do sistema a ser construdo. Normalmente, o primeiro documento
chamado de documento dos requisitos de negcio, ou documento dos
requisitos de marketing, j, o segundo, chamado de especificao dos
requisitos de software.
As seguintes sees descrevem o que fazer em cada um dos casos. Alguns ou

todos estes casos podem ser combinados; por exemplo, um documento pode
conter o conjunto total de requisitos, a partir do qual subconjuntos selecionados
podem ser usados para gerar releases especficos, bem como todos os requisitos
de negcio.
Organizando Requisitos de Sistemas

Complexos de Hardware e Software
Embora este volume tenha como principal foco os requisitos de software,
importante reconhecer que eles so apenas um subconjunto do processo de
gerenciamento de requisitos na maioria dos esforos de desenvolvimento de
sistemas. Como descrevemos no Captulo 6, alguns sistemas so to complexos
que a nica forma de visualiz-los e constru-los como um sistema de
subsistemas, os quais por sua vez so visualizados como sistemas de subsistemas,
e assim por diante, como ilustra a Figura 161. Num caso extremo, tal como uma
126
aeronave de transportes, o sistema pode ser composto de centenas de subsistemas,

que por sua vez possuem componentes de hardware e software.
O Sistema
Subsistema
Subsistema A-1
Figura 161
Subsistema
Subsistema A-2
Subsistema
Subsistema
Subsistema
Um sistema de sistemas
Nesses casos, criada uma especificao de requisitos ao nvel sistmico que

descreve o comportamento externo do sistema, tais como capacidade de
combustvel, velocidade de decolagem ou altitude mxima, sem conhecer ou
referenciar qualquer de seus subsistemas. Como descrevemos no Captulo 6, uma
vez que se tenha chegado a um acordo sobre os requisitos do sistema, uma
atividade de engenharia de sistemas executada. A engenharia de sistemas refina
um sistema em subsistemas, descrevendo as interfaces detalhadas entre
subsistemas, e alocando cada um dos requisitos do nvel sistmico para um ou
mais subsistemas. A arquitetura do sistema resultante descreve esse
particionamento e interfaces entre sistemas.
Depois, uma especificao de requisitos desenvolvida para cada subsistema.
Estas especificaes devem descrever, por completo, o comportamento externo do
subsistema, sem referenciar quaisquer de seus subsistemas. Este processo provoca
o surgimento de uma nova classe de requisitos, os requisitos derivados. Este tipo
de requisito nem de longo descreve o comportamento externo do sistema, ao invs
disso descreve o comportamento externo do novo subsistema. Assim, o processo
de projeto de sistemas cria novos requisitos para os subsistemas dos quais o
sistema composto. Em particular, as interfaces entre esses subsistemas tornamse requisitos chaves: essencialmente, um contrato entre um subsistema e os
outros, ou uma promessa de desempenho conforme acordado.
Uma vez que se tenha chegado a um acordo sobre os requisitos, o projeto do
sistema novamente executado se necessrio, dividindo cada subsistema em
subsistemas e desenvolver especificaes de requisitos para cada um. O resultado
uma hierarquia de especificaes, como ilustra a Figura 162.
Em todos os nveis, requisitos do nvel anterior so alocados para as
especificaes apropriadas do nvel posterior. Por exemplo, o requisito da
capacidade de combustvel alocado para o subsistema de controle de
combustvel e para o subsistema de armazenamento de combustvel, e novos
requisitos so descobertos e definidos quando apropriado.
Como ilustra a Figura 163, especificaes que por sua vez so refinadas em
especificaes adicionais de subsistema so chamadas de especificaes dos
requisitos de sistemas, ou especificaes dos requisitos ao nvel sistmico. As
127
especificaes do ltimo nvel, isto , aqueles que no sero futuramente

decompostas, normalmente correspondem a subsistemas de software-somente ou
de hardware-somente e so chamados especificaes dos requisitos de software
ou especificaes dos requisitos de hardware, respectivamente. Alm disso, toda
especificao dos requisitos da Figura 163 pode precisar experimentar um
processo evolucionrio conforme os detalhes forem mais bem compreendidos.
Especificao geral
dos Requisitos do
sistema
Especificao dos
requisitos do sistema
para o Subsistema A
Especificao dos
para o Subsistema A-1
Figura 162
Especificao dos
para o Subsistema B
Especificao dos
Especificao dos
para o Subsistema C
Especificao dos
para o Subsistema C-1
Especificao dos
Hierarquia de especificaes resultante do projeto de sistemas
Especificao geral
dos Requisitos do
sistema
Especificao dos
para o Subsistema A
Especificao dos
Especificao dos
para o Subsistema B
Especificao dos
Subsistema A-2
Especificao dos requisitos de hardware
Especificao dos
para o Subsistema C
Especificao dos
Especificao dos
Subsistema A-2
Especificao dos requisitos de software
Figura 163 Hierarquia de especificaes resultante do projeto de sistemas, incluindo

os nveis de software e hardware
128
Requisitos de Organizao para Famlia de

Produtos
Muitas indstrias constroem conjuntos de produtos intimamente relacionados que
contm funcionalidades em comuns, mas com cada um contendo algumas
caractersticas prprias. Exemplos de tas famlias de produtos pode ser: sistemas
de controle de inventrio, mquinas de respostas telefnicas, sistemas de alarme
contra ladres, entre outros.
Como exemplo, suponha que voc esteja construindo um conjunto de produtos de
software, cada um dos quais compartilham algumas funcionalidades, mas que
podem precisar compartilhar dados ou de algum jeito se comunicar com um outro
quando em uso. Em tais casos, voc pode considerar a seguinte abordagem:
Desenvolver um documento da Viso da famlia de produtos que descreva

a maneira como os produtos pretendem trabalhar em conjunto e outras
caractersticas que podem ser compartilhadas.
Para entender melhor o modelo de uso compartilhado, voc pode tambm
desenvolver um conjunto de use cases mostrando como os usurios iro se
interagir com as vrias aplicaes executando em conjunto.
Desenvolver uma especificao dos requisitos de software comuns que
defina os requisitos especficos para funcionalidades compartilhadas, tais
como estruturas de menu e protocolos de comunicao.
Para cada produto da famlia, desenvolver um documento da Viso, a
especificao dos requisitos de software, e um modelo use-case que defina
as funcionalidades especficas.
A organizao resultante mostrada na Figura 164.
Viso
Documento da Viso da
famlia de produtos
SRS
Requisitos de
software comuns
Viso
SRS
Figura 164
Modelo use-case
comuns famlia
Viso
SRS
Viso
SRS
Organizao dos requisitos para uma famlia de produtos de software
129
As especificaes dos requisitos para cada membro individual pode conter

referncias links ou traced from para o documento da famlia de produtos
ou pode reproduzir todos os requisitos a partir desse documento. A vantagem da
primeira abordagem que as mudanas nos requisitos pertencentes a todos os
membros da famlia podem ser realizadas em apenas um lugar. No segundo caso,
voc poder precisar usar uma ferramenta de requisitos para gerenciar essas
dependncias, seno, ser necessrio examinar manualmente cada membro
especfico do documento de requisitos toda vez que o documento pai for alterado.
Sobre os Requisitos Futuros

Poucos esforos de desenvolvimento tm o luxo de ter um conjunto de requisitos
estveis ou estar apto a construir um sistema que satisfaa todos os requisitos
conhecidos. Durante qualquer processo de elucidao de requisitos, surgem
requisitos que no so apropriados para a construo do prximo release.
Pode no ser apropriado incluir tais requisitos numa especificao de requisitos;
no podemos nos permitir fazer qualquer confuso sobre quais requisitos sero e
quais no sero implementados. Por outro lado, no apropriado descart-los,
porque eles representam produtos de um trabalho de valor adicionado5, e
queremos colher tais requisitos para futuros releases. E, o mais importante, os
projetistas de sistemas podem muito bem projetar o sistema de maneira diferente
sabendo que certos tipos requisitos futuros tm grandes chances de serem
considerados no prximo release. A melhor coisa registrar ambos os tipos de
requisitos em algum lugar do documento, mas deixando claramente identificados
aqueles requisitos que esto planejados para o atual release.
Requisitos de Negcio e de Marketing versus

Requisitos de Produto
O planejamento de um novo produto no ocorre num mundo tcnico desprovido
de consideraes de negcio. Devem ser feitas consideraes sobre oportunidades
de mercado, mercado alvo, empacotamento do produto, canais de distribuio,
funcionalidades, custo de marketing, disponibilidade de recursos, margens,
amortizao sobre um grande nmero de cpias vendidas, entre outras.
Tais consideraes devem ser documentadas, mas elas no pertencem s
especificaes de requisitos. Algumas organizaes usam um documento dos
requisitos de mercado (DRM) para facilitar a comunicao entre o pessoal de
gerenciamento, marketing e desenvolvedores, e para auxiliar nas decises de
negcio sobre inteligncia de mercado, incluindo todas as decises importantes de
vamos ou no-vamos em frente. O DRM tambm fornece aos clientes e
desenvolvedores uma rpida verificao da comunicao, para adiantar o
entendimento do produto em seus termos mais gerais, e estabelecer o escopo geral
do produto. O DRM deve responder as seguintes questes:
A diferena entre o valor da mercadoria produzida por um assalariado e o salrio que lhe pago; lucro em longo
prazo que no visto de imediato.
130
Quem o cliente?
Quem so os usurios?
Qual o mercado no qual pretendemos vender?
Como o mercado est segmentado?
Os requisitos do usurio esto nesses diferentes segmentos?
Quais classes de usurios existem?
Quais necessidades o produto satisfaz?
De que tipo o produto?
Quais so os principais benefcios do produto; por que algum deve
compr-lo?
Quem so os concorrentes?
O que diferencia o produto de nossos concorrentes?
Em que ambiente o sistema ser usado?
Qual ser o custo de desenvolvimento?
Com que preo voc pretende vender o produto?
Como o produto ser instalado, distribudo e mantido?
O Caso de Estudos
No Captulo 6, ns executamos algumas atividades da engenharia de sistemas no
sistema HOLIS, o nosso sistema de automao de iluminao residencial. Neste
ponto, no sabemos, ainda, muito sobre o HOLIS, mas provavelmente sabemos o
suficiente para fazer uma primeira tentativa em organizar as informaes de
nossos requisitos.
Viso
Especificao de hardware
dos subsistemas
Documento da Viso do
HOLIS 2000
Modelo use-case de
sistema do
HOLIS 2000
SRS
SRS
SRS
Modelo use-case
do subsistema
Modelo use-case
do subsistema
Modelo use-case
do subsistema
Figura 165
Organizao das informaes dos requisitos do HOLIS
131
A Figura 165 ilustra que a equipe est usando os seguintes elementos para
descrever os requisitos para o HOLIS:
O documento da Viso que ir conter vises de curto e longo prazo do

HOLIS, incluindo requisitos e caractersticas bsicas do sistema que esto
sendo propostos.
O modelo use-case de sistema registra os use cases atravs dos quais os
vrios atores do sistema interagem com o HOLIS.
Aps alguns debates, a equipe decidiu documentar os requisitos de
hardware tamanho, peso, potncia, empacotamento para os trs
subsistemas do HOLIS numa nica especificao dos requisitos de
hardware.
Como cada subsistema do HOLIS intensa em software, a equipe decidiu
desenvolver uma especificao de requisitos de software para cada um dos
trs subsistemas, bem como um modelo use-case de cada subsistema para
mostrar como cada subsistema interage com os vrios atores.
Voc ter a oportunidade de ver esses artefatos de requisitos desenvolvidos

posteriormente conforme avanamos no caso de estudos nos prximos captulos.
Um exemplo de cada um foi includo no Apndice A.
Sumrio
Neste captulo, ns examinamos uma variedade de documentos de requisitos para
sistemas de diferentes complexidades. No entanto, em muitos casos, o
gerenciamento de requisitos eventualmente concentra-se sobre um nico
subsistema de software, produto de software de prateleira, ou aplicaes
standalone. Exemplos desses produtos podem ser o Microsoft Excel, Rational
ClearCase, produtos de fornecedores ISV, ou o sistema de controle de iluminao
HOLIS.
Nos prximos captulos, ns iremos fazer um zoom sobre o processo de
definio de requisitos para uma nica aplicao de software tal que possamos
demonstrar mais claramente como o processo de gerenciamento de requisitos
funciona.
132
Captulo 17
O Documento da Viso
Pontos chaves
O documento da Viso descreve a aplicao em termos gerais, incluindo
descries do mercado alvo, dos usurios do sistema, e das caractersticas da
aplicao.
O documento da Viso define, num alto nvel de abstrao, tanto o problema
quanto a soluo.
Virtualmente, todos os projetos de software iro se beneficiar ao ter um
documento da Viso.
O documento da Viso Delta concentra-se no que foi mudado.
ste captulo concentra-se no documento da Viso. Como nosso colega

Philippe Kruchten disse recentemente, Se me fosse permitido
desenvolver apenas um nico documento, modelo, ou algum outro
artefato para sustentar um projeto de software, a minha escolha, em
resumo, seria o documento da Viso muito bem confeccionado.
Viso
Documento da Viso
para o meu projeto
O documento da Viso combina, dentro de um nico documento, alguns

elementos modestos tanto do documento dos requisitos de mercado quanto do
documento dos requisitos de produto. Ns queremos desenvolver este documento
em particular pelas seguintes razes:
1. Todo projeto precisa de um documento da Viso.
2. O documento da Viso nos ajudar a demonstrar o processo de
requisitos, bem como alguns elementos chaves desse processo
registrados nesse documento.
O documento da Viso descreve a aplicao em termos gerais, incluindo
descries do mercado alvo, dos usurios do sistema e das caractersticas da
aplicao. Por anos, vimos constatando a utilidade deste documento, tanto que o
desenvolvimento deste documento tornou-se, para ns, um padro de melhor
prtica na definio de uma aplicao de software.
Componentes do Documento da Viso

O documento da Viso, talvez o nico documento mais importante de um projeto
de software, captura as necessidades do usurio, as caractersticas do sistema, e
outros requisitos comuns do projeto. Como tal, o escopo do documento da Viso
estende sobre os dois primeiros nveis da pirmide de requisitos, atravs dos quais
define-se, num nvel alto de abstrao, tanto o problema quando a soluo.
133
Needs
Para um produto de software, o documento da Viso tambm serve de base para a

discusso e contrato entre as trs principais comunidades de stakeholders do
projeto:
Features
1. O departamento de marketing, que serve como representante de

clientes e usurios, e que no final ser o responsvel pelo sucesso do
produto aps a sua liberao.
2. A equipe de projeto que desenvolver a aplicao.
3. A equipe de gerenciamento, a qual ser responsvel pelos resultados do
esforo de negcio.
Escopo do
documento da viso
O documento da Viso poderoso porque ele representa a estrutura (gestalt6) do

produto a partir de todas as perspectivas significativas de forma breve, abstrata,
legvel e manejvel. Como tal, o documento da Viso o principal foco nas fases
iniciais do projeto, e muito investimento feito no processo de obter as
informaes que iro satisfazer o conhecido retorno nas fases posteriores.
Uma vez que, virtualmente, todos os projetos de softwares podem se beneficiar do
documento da Viso, ns o descreveremos em detalhes. Embora o nosso exemplo
esteja orientado para um produto especfico de software, no ser difcil modificlo para o seu contexto particular de produto.
A Figura 171 fornece um exemplo do documento da Viso com um breve
comentrio. Estes comentrios foram usados, com personalizaes, em centenas
de produtos de software e numa grande variedade de aplicaes de software. Uma
verso totalmente comentada deste documento consta no Apndice B.
Em resumo, o documento da Viso uma descrio concisa de todas as coisas
que voc considera ser mais importante sobre o produto ou aplicao. O
documento da Viso deve ser escrito, com um nvel de detalhes e de claridade
suficientes, para permitir que seja prontamente lido e compreendido pelos
stakeholders do projeto.
1. Introduo
Esta seo deve fornecer um resumo completo do documento da Viso.
1.1. Propsito do Documento da Viso

Este documento rene, analisa e define as necessidades do usurio e caractersticas do
produto em alto nvel.
1.2. Viso Geral do Produto

Estabelecer o propsito da aplicao, sua verso, e as novas caractersticas a serem liberadas.
1.3. Referncias
Fornecer uma lista completa de todos os documentos referenciados neste documento.
Continua na prxima pgina
Figura 171
6
Modelo de documento da Viso para um produto de software
Corrente na psicologia
134
2. Descrio do Usurio
Descrever brevemente a perspectiva dos usurios do seu sistema.
2.1. Demografia do Usurio/Mercado

Resumir os principais mercados demogrficos que motivaram suas decises de produto.
2.2. Perfil do Usurio

Descrever brevemente os potenciais usurios do sistema.
2.3. Ambiente do Usurio
Detalhar o ambiente de trabalho dos usurios alvo.
2.4. Principais Necessidades do Usurio

Listar os principais problemas ou necessidades que so percebidos pelo usurio.
2.5. Alternativas e Concorrentes

Identificar quaisquer alternativas que o usurio percebam que estejam disponveis.
3. Viso Geral do Produto

Fornecer uma viso de alto nvel das capacidades do produto, interfaces com outras aplicaes
e configuraes do sistema.
3.1. Perspectiva do Produto

Fornecer um diagrama de blocos do produto ou sistema e suas interfaces com o ambiente
externo.
3.2. Declarao da Posio do Produto

Fornecer uma declarao geral sumarizando, em alto nvel, a posio nica que o produto
pretende preencher no mercado. Moore (1991) recomenda que siga o seguinte formato:
Para
Que
O (nome do produto)
Que
Diferente
Nosso produto
(cliente alvo)
(declarao da necessidade ou oportunidade)
um (categoria do produto)
(declarao dos benefcios principais, isto , razes para convencer
a comprar)
(principais alternativas da concorrncia)
(declarao das principais diferenas)
3.3. Resumo das Capacidades

Resumir os maiores benefcios e caractersticas que o produto fornece.
Benefcios do Cliente
Caractersticas Suportadas
Benefcio 1
Benefcio 2
Benefcio 3
Caracterstica
Caracterstica
Caracterstica
Figura 171
Modelo de documento da Viso para um produto de software (continua)

135
3.4. Suposio e Dependncias

Listar as suposies que, se alteradas, iro afetar a viso do produto.
3.5. Custo e Preo

Registrar quaisquer restries de custo e preos que sejam relevantes.
4. Atributos de Caractersticas
Descreva as caractersticas que sero usadas para avaliar, rastrear, priorizar e gerenciar as
caractersticas. A seguir esto algumas sugestes:
Estado
Prioridade
Esforo
Risco
Estabilidade
Release alvo
Associado a
Razo
Proposto, Aprovado, Incorporado

Resultado do voto acumulado; ordem de prioridade,
Importante, til
Baixo, Mdio, Alto; equipe-semana; ou pessoa-ms
Baixo, Mdio, Alto
Baixo, Mdio, Alto
Nmero da verso
Nome
Campo texto
ou
Crtico,
5. Caractersticas do Produto
Esta seo do documento lista as caractersticas do produto.
5.1. Caracterstica #1
5.2. Caracterstica #2
6. Principais Use Cases
Descreve alguns use cases principais, talvez aqueles que so arquiteturalmente significantes
ou aqueles que iro mais prontamente ajudar o leitor a entender como o sistema pretende ser
usado.
7. Outros Requisitos de Produtos

7.1. Padres Aplicveis
Lista todos os padres que o produto deve cumprir.
7.2. Requisitos do Sistema

Definir quaisquer requisitos necessrios para sustentar a aplicao.
7.3. Licenciamento e Instalao

Descreva quaisquer requisitos de instalao que tambm afete a codificao ou que crie a
necessidade para separar o software de instalao.
7.4. Requisitos de Desempenho

Use esta seo para detalhar os requisitos de desempenho.
8. Requisitos de Documentao
Descreva as documentaes que devem ser desenvolvidas para sustentar a implantao da
aplicao com sucesso.
Figura 171
Modelo de documento da Viso para um produto de software (continua)

136
8.1. Manual do Usurio

Descreva o propsito e o contedo do manual do usurio do produto.
8.2. Help Online

Requisitos do help online, dicas de ferramentas, entre outros.
8.3. Guia de Instalao, Configurao e Arquivos Leia-me

8.4. Endereamento e Empacotamento
8.5. Glossrio
Figura 171
Modelo de documento da Viso para um produto de software
O Documento da Viso Delta

O desenvolvimento e gerenciamento do documento da Viso podem representar
papel chave para o sucesso ou fracasso de um projeto de software, pois fornece
um lugar comum para as atividades de stakeholders, clientes, usurios, gerentes
de produto e gerentes de marketing. Freqentemente, at o gerente executivo da
empresa estar envolvido no seu desenvolvimento e reviso. Manter o documento
da Viso compreensvel e gerencivel uma importante habilidade de equipe,
pois ir gerar grandes benefcios produtividade do projeto como um todo.
Para auxiliar nesse processo, til manter o documento da Viso to curto e
conciso quanto possvel. Isso no difcil, principalmente nas primeiras releases
do documento, quando todos os itens do documento so novidades para o projeto
ou quando devem ser reiniciados num novo contexto da aplicao.
No entanto, nos futuros releases, voc pode descobrir que contraproducente
repetir caractersticas e outras informaes que no tenham sido alteradas num
contexto particular do projeto, tais como perfil do usurio e mercado-alvo, e j
tenham sido incorporadas nos releases anteriores.
Documento da Viso para o Release 1.0

No caso de um novo produto ou aplicao, provavelmente todos os elementos do
documento da Viso devem ser desenvolvidos e elaborados. Itens que estiverem
fora do contexto do projeto podem ser removidos do documento e voc no ter
que preench-lo. O documento da Viso deve conter ao menos os seguintes itens
(veja a Figura 172):
Informaes gerais e introdutrias

Uma descrio dos usurios do sistema, mercado-alvo, e caractersticas
pretendidas na verso 1.0
Outros requisitos, tais como de regulao e ambiental
Caractersticas futuras que tenham sido elucidadas, mas que no sero
incorporadas no release 1.0
137
Viso
Documento da Viso
para a verso 1.0
Figura 172
Introduo
Usurios e mercado
Caractersticas do 1.0
Outros requisitos
Caractersticas futuras
Documento da Viso v1.0
Este documento serve de base para o release 1.0 e dirige os requisitos e use cases
mais detalhados do sistema, os quais sero muito mais elaborados.
Documento da Viso para a Verso 2.0
Viso
Documento da Viso
v2.0
Com a evoluo do projeto, caractersticas vo sendo mais bem definidas;

normalmente, isso significa que elas sero mais bem elaboradas no documento da
Viso. Alm disso, novas caractersticas sero descobertas e adicionadas ao
documento. Assim, o documento tende a crescer, tornando-se mais valoroso para
a equipe. Quando chegarmos a abordar a verso 2.0, certamente iremos querer
manter esse documento que to bem nos serviu. O prximo passo lgico na
evoluo do projeto e deste documento extrair as caractersticas futuras que
foram includas na verso 1.0 do documento e no implementadas, e program-las
para a verso 2.0. Em outras palavras, queremos encontrar e promover algumas
caractersticas que sero importantes para o release 2.0. Voc pode, tambm,
querer programar um outro workshop de requisitos ou outros processos de
elucidao a fim de descobrir novas caractersticas que entraro na programao
do release 2.0 e algumas novas caractersticas futuras que precisaro ser
registradas e documentadas. Algumas dessas caractersticas sero bvias, com
base no retorno do cliente (feedback), outras iro ser definidas com base na
experincia da equipe. Em qualquer dos casos, registrar essas novas
caractersticas descobertas na verso 2.0 do documento da Viso, ou como
programadas para ser includas na verso 2.0 ou como novas caractersticas
futuras.
Provavelmente voc descobrir que algumas caractersticas implementadas na
verso 1.0 no liberaram o valor pretendido, seja devido a mudanas ambientais
ocorridas durante o processo, quando tais caractersticas deixaram de ser
necessrias, seja pela substituio por novas caractersticas, ou talvez pelo cliente
que simplesmente no necessitou dessas caractersticas como ele pensava que iria
necessitar. Em qualquer caso, voc provavelmente descobrir que ser necessrio
remover algumas caractersticas no prximo release. Como registrar esses antirequisitos? Simplesmente utilize o documento da Viso para registrar o fato de
que uma particular caracterstica deve ser removida no prximo release.
Conforme a equipe desenvolve seu trabalho atravs do processo, ela descobre que
o documento cresce com o tempo. Isso to natural quanto definir um sistema
que est em crescimento. Infelizmente, voc pode descobrir que, com o tempo, o
documento torna-se mais difcil de se ler e entender. Por que? Porque o as
informaes do documento so mais antigas e contm muitas informaes que
no mudaram desde o ltimo release. Por exemplo, as declaraes do
138
posicionamento do produto e usurios-alvo provavelmente no mudaram, assim

como as caractersticas 25-50 implementadas na verso 1.0 que vivem no
documento da Viso da verso 2.0.
Assim, ns sugerimos o conceito de documento da Viso Delta. O documento da
Viso Delta concentra-se somente em duas coisas: o que mudou e quaisquer
outras informaes que devam ser includas para definir o contexto. Esta ltima
informao includa ou como um lembrete para a equipe da viso do projeto ou
porque novos membros da equipe necessitam do contexto para o seu
entendimento.
O resultado um documento da Viso Delta que agora tem como foco principal
descrever o que novo e descrever o que mudou no release. O foco, apenas nas
coisas que mudaram, uma tcnica de aprendizagem que extremamente
benfica ao tratar com sistemas de informaes complexas. Este modelo
ilustrado na Figura 173.
A verso 1.0 o nosso ponto de partida para o entendimento; o que nos

conta tudo que precisamos para conhecer o nosso projeto.
A verso 2.0 define o que diferente nesse release.
Tomados em conjunto, a viso 1.0 e a viso delta 2.0 definem a definio
completa do produto.
Viso
Viso 1.0
Viso
Viso Delta 2.0
Introduo
+ Caractersticas da verso 1.0
+ Caractersticas futuras
+ Novas caractersticas
+ Caractersticas removidas
+ Caractersticas futuras
=
Figura 173
Ponto de partida
para o
entendimento
Definio completa do produto
O Documento da Viso Delta
A duas verses devem ser utilizadas em conjunto sempre que for necessria a
definio completa do produto, tanto para requisitos de regulao quanto de
clientes, por exemplo, e bvio que isso importante para os novos membros da
equipe. No entanto, quando caractersticas forem removidas, voc ir ler
caractersticas que esto na verso 1.0, mas que no aparecem na verso 2.0.
Assim, se necessrio, siga essa trilha de auditoria sempre que voc precisar
ressuscitar a definio completa.
Se e quando isso se tornar complicado, fcil reunir o contedo da verso 1.0 e o
Delta da verso 2.0 num novo documento da Viso 2.0 que represente um quadro
do projeto compreensivo e completo.
Naturalmente, no precisamos ficar restritos sobre esta definio ou ao que cada
documento contm. Em vrias circunstncias, verificamos que conveniente usar
a Viso Delta apenas para pequenas mudanas tais como para a verso 1.1 ou
1.2 e iniciar com uma declarao completa do produto, rigorosamente
139
revisada a cada grande release tais como nas verses 2.0 ou 3.0. Nesses casos, a
aplicao do documento da Viso Delta deve ajudar a melhor gerenciar o
processo de requisitos por permitir que sua equipe concentre-se o que realmente
interessa em cada momento especfico.
O Documento da Viso Delta num Ambiente de Sistema Legado

Raramente, se no
nunca, prtico
documentar
completamente os
requisitos de um
sistema legado de
larga-escala.
Um dos problemas mais melindrosos do gerenciamento de requisitos est em

aplicar a habilidade de gerenciamento de requisitos para evoluir sistemas legados
do tipo IS/IT. Raramente, se no nunca, existem especificaes de requisitos
completa ou adequada para as milhes de linhas de cdigo de centenas de pessoas
por anos de investimento refletidos nesses sistemas. No prtico parar e
redocumentar o passado. Por vezes, quando voc faz isso, a necessidade passa, e
voc falha em sua misso por escrever requisitos histricos, quando voc deveria
estar escrevendo o cdigo!
Assim, se voc est comeando do zero ou com uma documentao mnima, voc
deve prosseguir com base no melhor esforo, usando qualquer recurso que voc
possa encontrar ao seu redor cdigo, especificaes, membros da equipe com
um conhecimento histrico para chegar a um entendimento do que o sistema faz
agora. Nossa recomendao nesses casos aplicar o processo da Viso Delta e
definir suas caractersticas e use cases ao redor das mudanas que voc estiver
fazendo no sistema legado. Ao seguir esse processo, voc e sua equipe podem se
concentrar naquilo que novo e naquilo que diferente no prximo release, e seu
cliente e sua equipe iro obter os benefcios de um processo de requisitos bemgerenciado. Alm disso, o registro dos requisitos que voc cria ir fornecer um
caminho de documentao para outros que se seguirem.
140
Captulo 18
O Campeo
Pontos chaves
O campeo produto mantm a viso do projeto.
Todo projeto necessita de um indivduo campeo ou de uma pequena equipe
campe para defender o produto.
Nos ambientes do produto de software, o campeo do produto ir
normalmente vir do marketing.
o Captulo 1, ns analisamos os desafios de projetos e descobrimos uma

variedade de causas razes, com o gerenciamento de requisitos
estabelecido prximo ao topo da lista. No Captulo 17, ns definimos o
documento da Viso como um documento embrionrio dentro de um
ciclo-de-vida de software complicado; este documento ataca diretamente os
desafios dos requisitos e um dos documentos que voc pode olhar, em qualquer
momento, para ver o que o produto, aplicao ou sistema faz ou no faz. Enfim, o
documento da Viso representa a essncia do produto e deve ser defendido como
se o sucesso do projeto dependesse disso.
Em algum ponto, a questo com razo se transforma, Mas quem desenvolve e
mantm esse documento to importante? Quem gerencia as expectativas do
cliente? Quem negocia com a equipe de desenvolvimento, o cliente, o
departamento de marketing, o gerente de projeto, e com os executivos da empresa
que tm demonstrado tamanho interesse, entusiasmado com o projeto agora que
se aproxima o prazo final?.
Em virtualmente todos os projetos de sucesso que estivemos envolvidos desde o
projeto de veculos de aventura que colocam borboletas na barriga de todos os
visitantes at projetos de ventiladores de suporte-de-vida que sustentam dez vidas
sem uma nica falha de software tinha um campeo. Ns podemos olhar para o
passado desses projetos e apontar um indivduo, e nos casos de grandes projetos,
uma pequena equipe de pessoas, os quais interpretam um papel maior que as
suas prprias vidas. O campeo mantm a viso do produto (ou sistema ou
aplicao) na frente de suas mentes como se ela fosse a nica coisa mais
importante de suas vidas. Eles comem, dormem e sonham sobre a viso do
projeto.
O Papel do Campeo do Produto

O campeo do produto pode ter uma grande variedade de ttulos: gerente de
produtos, gerente de projeto, gerente de marketing, gerente de engenharia, gerente
de tecnologia da informao, lder de projeto. Mas independente do ttulo, o
trabalho o mesmo. um grande trabalho. O campeo deve:
141
Gerenciar o processo de elucidao e ficar tranqilo quando so

descobertos requisitos suficientes.
Gerenciar as entradas conflitantes de todos os stakeholders.
Fazer as concesses necessrias para encontrar o conjunto de
caractersticas que liberem o mais alto valor para o maior nmero de
stakeholders.
Apropriar-se da viso do produto.
Defender o produto.
Negociar com gerentes, usurios e desenvolvedores.
Defender frente a requisitos estranhos.
Manter uma saudvel excitao entre o que o cliente deseja e o que o a
equipe de desenvolvimento pode liberar dentro do prazo do release.
Ser o representante oficial entre o cliente e a equipe de desenvolvimento.
Gerenciar expectativas dos clientes, gerentes executivos e os
departamentos internos de marketing e engenharia.
Comunicar as caractersticas do release para todos os stakeholders.
Revisar as especificaes de software para assegurar que eles conformam
com a viso representada pelas caractersticas.
Gerenciar as prioridades das mudanas e a adio e remoo das
caractersticas.
Esta pessoa a nica a quem o documento da Viso pode ser realmente confiada,
e encontrar o campeo correto para esse propsito a chave de sucesso ou falha
do projeto.
O Campeo do Produto num Ambiente de

Produto de Software
Certa vez ns conduzimos um workshop para um provedor de servios online
confrontando requisitos desafiadores. Quando ns chegamos na parte do tutorial
enfatizando a noo de campeo do produto, a sala ficou inquieta, e o clima
mudou nitidamente. Ns perguntamos para as 25 pessoas presentes, incluindo os
desenvolvedores, engenheiros seniores e gerentes de marketing, como essas duras
decises eram realizadas em seus ambientes. Depois de alguns momentos, ficou
claro que ningum fazia essas decises. Aps discusses entre eles, o melhor que
o grupo pde descrever foi um grupo cego, seguindo informaes que vem e
vo como as mars. Ningum tinha a responsabilidade de tomar decises.
Ningum decidia quem seria suficientemente bom.
Eventualmente, a equipe voltava-se para trs, para um executivo de marketing,
por respostas, talvez porque esse indivduo tinha mais informaes no processo.
Ele olhou ao redor por um momento e ento disse: Voc sabe o que mais me
apavora nesta equipe? Eu posso pedir que algumas novas caractersticas sejam
adicionadas em algum momento do processo, e ningum nunca me dir no.
Como esperar que consigamos liberar, em algum momento, um produto?.
Ficou claro, aps esta explanao, de que o cliente no sabia quando um produto
seria liberado. verdade tambm que a histria demonstra que houve uma
inabilidade extremamente dolorosa deste cliente. A companhia desenvolveu-se
de uma cultura tradicional de IT e tinha-se transformado num provedor de
142
servios on-line recentemente. A noo de uma aplicao como um produto de

software era novo. Os membros da equipe no tinham precedentes para gui-los
atravs do processo.
Embora no exista uma forma correta de organizar e determinar um campeo do
produto, talvez ns possamos olhar para o nosso caso de estudos para obter
alguma sugesto. Afinal de contas, ns o modelamos de acordo com uma equipe
de projeto viva e efetiva.
Na Figura 181, a Cathy, a gerente de produto; quem faz o papel de campeo
do produto. Note que, neste caso, o gerente de produto se reporta diretamente com
o marketing ao invs de se reportar para a organizao de engenharia. Isso
muito normal em empresas de produtos de software, ao menos em tese, que
gerentes de produto estejam mais prximos aos clientes, pois so eles que
determinaro o sucesso ou a falha do projeto.
Lumenations S.A
Diviso de Automao para Iluminao Residencial
Organizao da Equipe de Software
Emily
VP e GM
Brooke
Diretor de Engenharia
Jack
Lder de QA
Equipe
de
Teste
Louise
Lder de
Doc
Michel
Arquiteto
John
Lder de
Software
Eric
Pete
Gerente de
Desenvolvimento de
Software
Russ
Lder de
Software
Mike
Lder de
Software
Cathy
Gerente de
Produto
Desenvolvedores
Talvez o gerente de produto se reporte gerncia de marketing porque, no final

de contas, ele que tem a responsabilidade pelo Nmero, isto , pela receita
associada com cada produto liberado. assim que deve ser; o marketing , em
ltima anlise, o responsvel pelas vendas e deve assim, ser responsvel pelo
mercado e pelas decises difceis; caso contrrio suas prestaes de contas no
tero sentido.
Como voc classificaria os papis e responsabilidades nessa mescla de requisitos,
tecnologias, clientes e desenvolvedores? Imagine o seguinte dilogo, uma
variao do que ocorreu recentemente numa nova empresa que foi classificar seus
papis:
143
Gerente de Produto
(o Campeo):
Dever possuir as caractersticas A, B e C, e voc

deve construir usando a tecnologia X.
Gerente de
Desenvolvimento:
Eu acho que deveria ter a caracterstica D e no a C,

e nos usar a tecnologia Y.
Gerente de Produto: Eu disse que tem que ter A, B e C. Afinal de contas,

sou eu que tenho que atender s quotas de venda, e
o que preciso para atender s necessidades dos
clientes. Se voc quiser se responsabilizar, voc
pode adicionar a caracterstica D, desde que voc
ainda atenda o cronograma.
Gerente de
Desenvolvimento:
Hummm (pensando melhor no significado de

gastar seu tempo ajudando sua equipe a atender
quota). Eu no tenha certeza se isso uma boa
idia. Ns implementaremos A, B e C. Mas voc se
responsabiliza se, na prtica, isso no funcionar?
Gerente de Produto: (antevendo o conhecimento de como escrever o

cdigo nas prximas 48 horas ao invs de preparar
o lanamento para o mercado) Hummm, no, eu
acho que isso no uma boa idia. Voc pode
construir utilizando a tecnologia que achar mais
apropriada.
Gerente de
Desenvolvimento:
Concordo. Voc decide as caractersticas e ns

escolhemos a tecnologia; essa a melhor
combinao
de
nossas
habilidades
e
responsabilidades.
Gerente de Produto: Est combinado.
Esse dilogo no tem nada de mais; apenas explana o senso comum, mas
incrvel o quo freqente encontrar empresas que no tm claro esta
responsabilidade, como no caso da empresa provedora de servios on-line.
De alguma forma, o ambiente de fornecimento de software independente (ISV)
simples: O cliente externo, e ns normalmente temos uma organizao de
marketing razoavelmente sofisticada a qual usamos para elucidar os requisitos e
determinar quem o responsvel pelo equilbrio de todas as necessidades
conflitantes. Um cliente cujas necessidades no so atendidas, simplesmente no
ser um cliente. Embora isso no seja uma boa coisa, ao menos eles no vo
perder tempo blasfemando.
144
O Campeo do Produto numa Empresa de IS/IT

Este no o caso em empresas de IS/IT. No existe departamento de marketing,
todos os seus clientes trabalham com voc, e certamente se tornaro preguiosos
depois que constatar que o release satisfaz seus desejos.
Onde encontrar nosso campeo em tal ambiente? Talvez ns possamos
novamente aprender com um exemplo. Numa empresa, um novo sistema de apoio
empresarial foi desenvolvido para prover acesso global, 24 horas do dia, aos
clientes registrados para suporte a vendas e gerenciamento de licenas. O
exerccio de anlise do problema identificou os seguintes stakeholders: marketing
corporativo, televendas, licenciamento e suporte, marketing de unidade de
negcio, gerncia financeira da unidade de negcio, execuo de pedidos, e
garantia. Cada um destes departamentos tinha fortes necessidades, mesmo assim,
estava claro que nem todas as necessidades poderiam ser atendidas. A questo
Quem o dono do documento da Viso?, apresenta-se como uma metfora para
a questo Quem gostaria de fazer uma grande mudana em sua carreira limitada
tentando gerenciar este projeto?.
Na anlise, ficou claro que nenhuma das lideranas da equipe de desenvolvimento
tinha autoridade para fazer tais decises, mas ainda necessrio um campeo.
Neste caso, a equipe decidiu chamar Tracy, a lder de projeto atual, como a
campe do produto, dando-lhe autoridade para produzir e organizar os requisitos.
Ela se apropriou do documento da Viso. Ela entrevistou os usurios, estabeleceu
suas prioridades relativas, e coletou dados num formato orientado-a-caracterstica.
Mas um comit diretor especial, ou comisso de controle de mudanas (CCM) de
projeto, fora tambm imediatamente estabelecida para o projeto. A CCM foi
constituda de trs executivos seniores, cada um com a responsabilidade numa
rea funcional.
Inicialmente, Tracy facilitou o processo de tomada de deciso da CCM
estabelecendo prioridades relativas para as releases iniciais. Desde ento, a CCM,
e somente a CCM, tem a autoridade de adicionar ou remover caractersticas, com
recomendaes realizadas pela campe do produto. Desta maneira, existe apenas
uma campe, Tracy, e os resultados da elucidao e a viso do projeto existem em
sua cabea e no Documento da Viso, mas a responsabilidade de tomar as
decises difceis foi delegada CCM. A campe tinha apenas que ver que as
caractersticas acordadas tinham sido apropriadamente elaboradas e comunicadas
equipe de desenvolvimento.
Desde que Tracy foi delegada para dirigir o processo em conjunto com a CCM, a
qual inclua membros da gerncia snior, obtendo respaldo necessrio para tomar
decises, o projeto alcanou seu sucesso e foi usado como um modelo
organizacional para novos projetos. Alocou-se um novo campeo para cada novo
projeto. Isso criava a oportunidade para que as pessoas pudessem crescer e se
desenvolverem individualmente. O papel de campeo do produto tornou-se muito
importante dentro da empresa. No podemos nos esquecer, naturalmente, da
CCM. Para cada novo projeto, estabelecia-se uma nova CCM, com base nos
temas de cada nova release e na organizao que poderia ser mais afetada
diretamente.
145
Embora no existam prescries que possam ser seguidas para criar um

campeo de projeto, extremamente importante para a sua equipe identificar um,
promov-lo, ou delegar para algum que j esteja, aparentemente, liderando o
processo. Ento, responsabilidade da equipe assisti-lo de todas as maneiras
possveis no gerenciamento de requisitos da aplicao. Isso ir ajudar a atingir o
sucesso. Alm disso, se voc no ajudar essa pessoa a atingir o sucesso, ela
poder convid-la para que voc seja o campeo do projeto num prximo
projeto.
146

Na Habilidade de Equipe 3, ns nos movemos do entendimento das necessidades
do usurio para iniciar a definio da soluo. Ao fazermos isso, ns demos a
engatinhada inicial para sairmos do domnio do problema, a ilha do usurio, e
entrarmos no domnio da soluo, o lugar onde ns trabalhamos para definir um
sistema que solucione o problema que temos em mos.
Ns tambm aprendemos que sistemas complexos necessitam de estratgias claras
para gerenciar informaes de requisitos, e algumas maneiras de organizar
informaes de requisitos. Ns reconhecemos que ns realmente temos uma
hierarquia de informaes, comeando pelas necessidades dos usurios, passando
pelas caractersticas, chegando finalmente aos requisitos de software mais
detalhados representado pelos use cases ou formas tradicionais de expresses.
Notamos tambm que a hierarquia reflete o nvel de abstrao com o qual ns
enxergamos o espao do problema e o espao da soluo.
Ns, ento, ampliamos a nossa viso do processo de definio utilizando como
exemplo uma aplicao de software standalone e investimos algum tempo na
definio de seu Documento da Viso. crucial que todos os projetos mantenham
o Documento da Viso, modificando-o para atender s particularidades de uma
aplicao de software da companhia.
Ns reconhecemos que sem um campeo algum que defenda os requisitos da
aplicao e atenda s necessidades dos clientes e da equipe de desenvolvimento
no temos como garantir que decises difceis sejam tomadas. Decises difceis
provavelmente sero as de abandonar, postergar ou relaxar requisitos por presses
de cronograma. Assim, decidimos indicar um, sacramentar algum: algum que
ficasse responsvel pelo Documento da Viso e pelas caractersticas que ele
contm. Por sua vez, o campeo e a equipe iro delegar as decises difceis para
uma comisso de controle de mudanas, assegurando que as mudanas de
requisitos sejam pensadas antes de serem aceitas.
Tendo uma estratgia organizacional de gerenciamento de requisitos em mos e
um campeo no leme, estaremos mais bem preparados para prosseguir com o
nosso trabalho. Mas, primeiro, devemos dar uma olhada no problema de escopo,
o assunto da Habilidade de Equipe 4.
147
Gerenciando o Escopo
Captulo 19:
Captulo 20:
Captulo 21:
Captulo 22:
O Problema do Escopo de Projeto

Estabelecendo o Escopo de Projeto
Gerenciando seu Cliente
Modelos de Gerenciamento de Escopo e Processos de
Desenvolvimento de Software
148
At agora neste volume, introduzimos as Habilidades de Equipe para analisar o

problema, entender as necessidades dos usurios, e definir o sistema. Todas as trs
Habilidades de Equipe tinham o foco nas causas razes dos problemas de
desenvolvimento de software: preparar a equipe para entrar no espao da soluo sem o
conhecimento adequado do problema a ser resolvido. Embora os membros da equipe
precisem praticar estas habilidades a fim de desenvolv-las, isso no demandar muito
esforo. Recomendamos fortemente que gaste um pouco mais de tempo nestas
atividades iniciais; o conjunto total de atividades descritas at aqui deve consumir apenas
uma pequena frao do oramento do projeto, talvez apenas 5% ou mais do custo total.
Embora os assuntos sejam complexos, apenas alguns membros da equipe analistas,
gerentes de projeto, lder tcnico, campeo de projeto ou gerente de produto precisam
estar fortemente envolvidos neste ponto.
No futuro, no entanto, o jogo muda dramaticamente conforme o tamanho da equipe se
eleva significativamente. Cada membro adicionado equipe deve participar do esforo
coordenado da equipe, comunicando-se efetivamente uns com os outros. Alm disso, o
investimento, ou a taxa de gastos, do projeto se eleva dramaticamente. Criamos
documentos dos planos de testes, construmos modelos, refinamos requisitos de
projeto, elaboramos use cases, desenvolvemos cdigos para que, atravs disso,
possamos criar condies favorveis de trabalho coordenado e que pode ser mudado se
a definio no for bem entendida ou se os requisitos ambientais mudarem.
A pirmide de requisitos, pela sua forma larga na base corretamente sugere que
muito mais trabalho nos espera pela frente. A Habilidade de Equipe 4 desenvolve uma
estratgia para uma das atividades mais cruciais: gerenciar o escopo. De acordo com
dados do Standish Group (1994), 53% dos projetos iro custar 189% do estimado. Os dados
de nossa experincia so um pouco pior: quase todos os projetos de softwares se
atrasam em 50% a 100%. Assumindo que as outras causas razes do desenvolvimento de
software no sero solucionados do dia para a noite, fica claro que a nossa indstria ou
incompetente ou est tentando fazer muito com muito poucos recursos, habilidades e
ferramentas. Ns estamos tentando encher dez pontos de funcionalidades desejadas
numa sacola que cabe apenas cinco. Embora a fsica do desenvolvimento de software
no seja clara, bvio que este elemento de nossa estratgia digno de ateno e que a
qualidade tanto dos produtos de nosso trabalho quanto de nossa reputao esto em
jogo.
Assim, antes de aumentar o tamanho da equipe, antes de desenvolver especificaes mais
detalhadas, antes de aplicar as idias tecnolgicas ao projeto, e antes de construir scripts de
testes, devemos parar e aprender como gerenciar o escopo do projeto. A psicologia, a
tecnologia e o bom gerenciamento de projeto so partes poderosas que esta Habilidade
de Equipe ir fornecer para elevar a probabilidade de atingir sucesso em projetos.
149
Captulo 19
O Problema do Escopo de Projeto
Pontos chaves
O escopo de projeto uma combinao de funcionalidade de produto, recursos
de projeto e tempo disponvel.
A lei de Brooks estabelece que adicionar trabalhadores ao projeto de software j
em atraso torna-o ainda mais atrasado.
Se o esforo necessrio para implementar as caractersticas do sistema for igual a
recursos sobre o tempo disponvel, o projeto ter um escopo atingvel.
Projetos alm do escopo so normais na indstria.
Em muitos projetos, a fim de fornecer uma razovel probabilidade de sucesso,
ser necessrio reduzir o escopo por um fator de dois.
omo em qualquer atividade profissional, definir compromissos no

desenvolvimento de aplicao envolve fazer avaliaes realsticas dos
recursos de projeto, tempo disponvel e objetivos, antes de iniciar as
atividades. Para o desenvolvimento de software, esses fatores combinados
criam o escopo de projeto. O escopo de projeto uma funo:
da funcionalidade que deve ser liberada para atender as necessidades do

usurio
dos recursos disponveis do projeto
do tempo disponvel para executar a implementao
A Figura 191 fornece uma perspectiva retangular que podemos usar para
representar o escopo de projeto.
Escopo
Recursos
Tempo disponvel
Prazo Final
Figura 191
Escopo de Projeto
Na Figura 191, a rea do retngulo representa o escopo atingvel do projeto. O

Escopo de projeto deriva dos seguintes elementos:
Os Recursos consistem principalmente do trabalho de desenvolvedores,

testers, documentadores, pessoal da garantia de qualidade, entre outros.
150
No incio dos anos de 1970, Fred Brooks (1975) demonstrou que adicionar
recursos aos projetos de software a fim de aumentar o trabalho realizado ,
na melhor das hipteses, uma proposio de risco. De fato, a lei de Brooks
estabelece que adicionar trabalhadores a um projeto de software que est
em atrasado torna-o ainda mais atrasado.
Se a escala de tempo for suficiente longa, tudo bem, o trabalho pode
realmente ser realizado, mas no ser proporcional aos recursos
adicionados, e a eficincia geral do projeto tende a diminuir. Adicionar
recursos pode at reduzir a velocidade do projeto devido necessidade de
treinar e apoiar as novas pessoas, reduzindo a produtividade daqueles que
j estavam no projeto. Como o mercado competitivo nos fora a abreviar o
tempo disponvel, adicionar recursos durante um projeto impraticvel.
Alm disso, como os oramentos de desenvolvimento so geralmente
apertados nesses anos de Internet, adicionar recursos simplesmente no
uma opo possvel.
Com o propsito fazer a anlise do escopo, permita-nos assumir que
recursos, no eixo y da Figura 191, so constantes enquanto durar o
projeto.
O Tempo talvez aqui tenha um limite flexvel, sujeito a mudanas se os

recursos disponveis forem inadequados para atingir a funcionalidade
desejada. Para o propsito de nossa anlise de escopo, o tempo no eixo x,
um fator estabelecido.
Certamente, a histria ir demonstrar que liberar software com atraso
normalmente o esperado. Por outro lado, muitas equipes de
desenvolvimento tm dificuldades de fixar o prazo final. Exemplos disso
incluem um programa para declarao de um novo imposto que ser
liberado definido por lei; apresentao de um novo produto durante uma
exposio; ou o prazo final fixado contratualmente pelo cliente. Alm
disso, se quisermos assegurar nossa credibilidade profissional e ganhar a
confidncia de nossos clientes, importante no errarmos no cronograma.
A funcionalidade total que podemos liberar obviamente limitada pelo tempo

disponvel (fixado) e pelos recursos disponveis (tambm fixados) que temos para
usar, assim o escopo disponvel a rea do retngulo.
Neste volume ns usamos a noo de caractersticas para representar o valor
funcionalmente adicionado que devemos liberar ao usurio. Se o esforo
necessrio para implementar as caractersticas requeridas pelo sistema igual
aos recursos sobre o tempo que temos disposio, o escopo do projeto
atingvel, e no teremos problemas. Salvo circunstncias inesperadas, a equipe de
software ir liberar no tempo sem sacrificar a qualidade.
No entanto, a experincia tem mostrado que existe, com freqncia, uma pobre
relao entre esses fatores presentes na equao do escopo. De fato, na turma de
requisitos que lecionamos, ns sempre perguntamos: No incio do projeto, que
quantidade de escopo so normalmente disponibilizados pelos seus gerentes,
clientes ou stakeholders?. Em resposta, apenas alguns iniciantes respondem
inferior a 100%. Os outros apresentam um nmero que varia de 125% a 500%.
A mdia e a mediana de cada enqute tende mesma concluso:
151
aproximadamente 200%. Este dado tem forte correlao com o que estabeleceu o
Standish Group anteriormente, ou seja, que mais da metade de todos os projetos
iro custar prximo ao dobro de suas estimativas. Talvez possamos agora
entender o por que.
Uma Breve Histria sobre Escopo de Projeto
Uma vez tivemos uma estudante que tinha sido recentemente promovida para
exercer um novo papel, a de gerente de produto para um novo produto de
software. Seu currculo inclua muitos aspectos de desenvolvimento de
produto e marketing de produto, mas no tinha experincia direta no
desenvolvimento de software. Depois de ouvir as respostas para a nossa
questo sobre escopo, ela mostrou-se incrdula. Ela olhou ao redor da sala e
disse, No entendi direito, vocs aprovam projetos com aproximadamente
duas vezes a quantidade de trabalho que pode ser razoavelmente realizado
num perodo de tempo disponvel? Que tipo de profisso esta? Vocs esto
loucos? Os desenvolvedores trocaram olhares tmidos e unanimemente
responderam, sim.
O que acontece se o projeto continuar com os 200% de escopo inicial?
Se as caractersticas da aplicao forem completamente independentes,

no razovel que apenas a metade deles funcionem quando o prazo final
estiver vencido. O projeto est avanando com dificuldades, mas fornece
apenas a metade da funcionalidade pretendida. E no uma metade
holstica. As caractersticas no funcionam em conjunto, e no produzem
quaisquer funcionalidades agregadas que sejam teis. Uma aplicao de
escopo drasticamente reduzido rapidamente remendado e embarcado.
Como conseqncia surgem srias insatisfaes por parte dos clientes
devido s suas expectativas no terem sido atendidas, compromissos de
mercado no poderem ser atendidas, e materiais promocionais e manuais
imprecisos terem que ser rapidamente retrabalhados. Toda a equipe fica
frustrada e desmotivada.
No prazo final, apenas 50% de cada caracterstica funciona. Alm disso,

uma vez que existem certas interdependncias dentro de cada
caracterstica, no caso mais tpico, nada funciona direito quando o prazo
final estiver vencido. O prazo final est comprometido dramaticamente.
Todos os compromissos sero atrasados; um novo prazo final
programado, e uma nova marcha para a morte recomea. No pior caso,
toda a equipe demitida aps realizarem vrias horas-extras durante
meses a fio; na fase final desta primeira tentativa, declarada a fase
chamada promoo dos que no participaram, e um novo gerente
adicionado ao projeto.
O que acontece com a qualidade do software durante uma destas situaes? O

cdigo, que foi finalizado s pressas prximo ao final, tem um projeto pobre e
possuem erros grosseiros; testes foram reduzidos ao mnimo ou foram totalmente
descartados; e as documentaes e sistemas de ajuda foram eliminados. Clientes
realizam tanto os testes funcionais quanto os de garantia de qualidade. Em pouco
tempo, os clientes reagem ao seu extraordinrio esforo da seguinte forma:
152
Embora tenhamos ficado inicialmente desapontados com o seu atraso (ou com
as poucas coisas funcionando comparado s nossas expectativas), agora ns
estamos realmente insatisfeitos porque descobrimos que voc nos entregou um
lixo.
A Difcil Questo
Claramente, para que a equipe de projeto tenha alguma esperana de sucesso, o
escopo deve ser gerenciado antes e durante o esforo de desenvolvimento. No
entanto, o cenrio tpico amedronta: Se comearmos o esforo de desenvolvimento
com, de fato, a expectativa de escopo em 200%, ser necessrio reduzir o escopo
do projeto por um fator de 2 se quisermos obter alguma chance de sucesso.
O dilema da equipe ao enfrentar este problema talvez leve dura questo
enfrentada pela equipe: O que podemos fazer para reduzir o escopo e manter o
cliente satisfeito? Bem, nem tudo est perdido. Ns iremos cobrir algumas
maneiras de lidar com esta questo nos dois prximos captulos.
153
Captulo 20
Estabelecendo o Escopo de Projeto
Pontos chaves
O primeiro passo para estabelecer o escopo de projeto definir um baseline de
requisitos de alto-nvel, um conjunto de caractersticas que se pretende liberar
numa verso especfica do produto.
O segundo passo estabelecer o esboo do nvel de esforo requerido para cada
caracterstica do baseline.
Depois, estimar o risco para cada caractersticas, ou a probabilidade de que ao
implement-las causar um impacto negativo no cronograma e no oramento.
Usando esses dados, a equipe estabelece e assegura que o baseline de liberao
ir conter as caractersticas que so crticas para o sucesso do projeto.
O Baseline de Requisitos
O propsito do gerenciamento de escopo estabelecer um baseline de requisitos
de alto-nvel para o projeto. Definimos baseline como
o conjunto de caractersticas, ou requisitos, que se pretende liberar numa
verso especfica da aplicao.
Veja a Figura 201. Tanto o cliente quanto a equipe de desenvolvimento devem
concordar com o baseline da prxima release. Em outras palavras, o baseline
deve:
Ser ao menos aceitvel para o cliente.

Ter uma razovel probabilidade de sucesso, na viso da equipe.
Caracterstica 1
Caracterstica 2
Verso 1.0
do baseline
Figura 201
Baseline de requisitos
154
O primeiro passo na criao do baseline listar as caractersticas que tero que

ser definidas para a aplicao. Controlar o nvel de detalhes neste processo uma
importante chave de sucesso. Na Habilidade de Equipe 3, sugerimos que
qualquer novo sistema, no importa o quo complexo seja, pode ser descrito por
uma lista de 25 a 99 caractersticas. Com mais do que isso, voc estar
visualizando o projeto num nvel de detalhes muito alto, dificultando a
comunicao efetiva com clientes e equipe de desenvolvimento. Com menos que
isso, o nvel de detalhes pode ser muito baixo para fornecer suficiente
compreenso da aplicao e do nvel necessrio de esforo para a implementao.
Se seguirmos o processo de workshop de requisitos (Captulo 10) ou algum
processo que gere resultados similares, teremos nossa disposio uma lista de 25
a 99 caractersticas. Esta lista fornece uma descrio de alto-nvel das capacidades
de um novo sistema. Esta lista de caractersticas o principal artefato que iremos
utilizar para gerenciar o escopo do projeto, antes que investimentos significativos
sejam realizados no refinamento de requisitos, projeto, codificao, teste, entre
outras atividades.
Por exemplo, considere um produto de software de prateleira com as seguintes
caractersticas:
Caracterstica 1: Suporte a banco de dados relacional externo
Caracterstica 2: Segurana multiusurio
Caracterstica 3: Habilidade de clonar um projeto
Caracterstica 4: Interface para releases de novos sistemas operacionais (SO)
Caracterstica 5: Assistente de novos projetos
Caracterstica 6: Importao de dados externos por estilo
Caracterstica 7: Implementar ferramenta de dicas
Caracterstica 8: Integrar com o subsistema de gerenciamento de verses
Definindo as Prioridades
Como discutimos em Habilidades de Equipe 2, Entendendo as Necessidades de
Usurios, estabelecer as prioridades relativas do conjunto de caractersticas parte
integrante do gerenciamento de escopo. Durante a priorizao, importante que
clientes e usurios, gerentes de produto, ou outros representantes exceto a
equipe de desenvolvimento definam as prioridades de acordo com o mercado
interno de seus departamentos. De fato, esta priorizao inicial deve ser feita sem
muita influncia da comunidade tcnica; caso contrrio, o nvel de dificuldade
para se implementar as caractersticas poder influenciar a priorizao realizada
pelo cliente, e o resultado do processo poder ficar comprometido a ponto de no
atender as reais necessidades do cliente. Existir oportunidade para que as
questes tcnicas sejam consideradas aps o processo de priorizao. No nosso
exemplo de projeto, assumimos que foi realizada uma votao para a priorizao
das caractersticas usando uma escala crtica-importante-til; os resultados deste
exerccio esto apresentados na Tabela 201.
155
Tabela 201 Caractersticas priorizadas

Caracterstica
Prioridade
Caracterstica 1: Suporte a BD relacional externo
Crtica
Caracterstica 4: Interface para releases de novos SO
Crtica
Crtica
Importante
Importante
Importante
til
Caracterstica 8: Integrar com o subsistema de gerenciamento de verses
til
Avaliando o Esforo
A priorizao apenas uma pea do quebra-cabea do escopo. Afinal de contas,
se pudssemos implementar todas as caractersticas de uma s vez, no seria
necessria a priorizao. No entanto, independentemente de termos ou no o
potencial de implementar o conjunto de caractersticas de uma s vez, a verdade
que ainda no temos, nem como imaginar, quanto desse total temos reais
condies de fazer e, conseqentemente, no temos condies de traar o
baseline do projeto.
O prximo passo estabelecer, de maneira aproximada, o esforo necessrio para
implementar cada uma das caractersticas do baseline proposto. Vale lembrar que,
nesta fase, existem poucas informaes disponveis; ns ainda no detalhamos os
requisitos; muito menos definimos algum projeto no qual pudssemos utilizar
para balizar as nossas estimativas. O melhor que podemos fazer determinar, em
ordem de magnitude grosseira, o nvel do esforo de cada caracterstica.
Estimar esforos nesta fase precoce uma Habilidade de Equipe que aprendida.
Naturalmente, a equipe de engenharia relutar em fornecer estimativas sem que
as caractersticas e requisitos tenham sido totalmente entendidos. Porm, este
primeiro corte, durante o gerenciamento de escopo, deve ocorrer antes que esses
detalhes sejam conhecidos.
Permita-nos assumir que o gerente de produto ou de projeto seja o campeo de
nosso projeto e que tenha o seguinte dilogo com os desenvolvedores do projeto7.
A equipe pode querer usar equipe-semanas ou equipe-meses como uma estimativa aproximada do impacto
total de uma caracterstica sobre o projeto. Esta heurstica grosseira serve como substituto para uma estimativa mais
detalhada e comprovadamente melhor do que o resultado deste dilogo. Assim, aos usar estes totais e o total de
tempo disponvel para o projeto, a equipe pode determinar onde traar o baseline inicial. Se o baseline contiver o
conjunto de caractersticas crticas, tudo bem, seno, o projeto estar fora do escopo e um novo projeto, porm
menor dever ser definido.
156
Gerente de Produto:
Qual a dificuldade de implementar esta

caracterstica?
Equipe de Desenvolvimento: Ns no sabemos. Ns ainda no temos quaisquer

requisitos ou o seu projeto.
Gerente de Produto:
Tudo bem; mas a coisa mais fcil que ns j

fizemos?
Equipe de Desenvolvimento: No.

Gerente de Produto:
Certo; a caracterstica mais difcil da lista?
Equipe de Desenvolvimento: No.

Gerente de Produto:
Numa escala de baixo-mdio-difcil, podemos

dizer que mdio?
Equipe de Desenvolvimento: Sim; mdio.

Gerente de Produto:
Certo; agora vamos avaliar a prxima

caracterstica.
Por que ns no permitimos um processo que crie requisitos e informaes

detalhadas de projeto para cada caracterstica a fim de permitir a realizao de
estimativas mais significativas? Isso no seria a maneira profissional de abordar o
problema? Se no cronograma houver tempo para permitir realizar estimativas
mais detalhadas, ento devemos faz-lo!
No entanto, ns acreditamos que seja crucial estarmos prontos para tomar
algumas decises rpidas sobre o escopo da atividade sem que exista uma
estimativa mais detalhada. Por que? Porque caso contrrio poder haver
desperdcio de recursos investidos na especificao de requisitos e obteno de
informaes de projeto que no sero implementados, na confeco de scripts de
teste de caractersticas que estaro fora do escopo desse projeto, na determinao
incorreta do caminho crtico de projeto, entre outros. No podemos nos permitir
investir quaisquer recursos em atividades que produzam sucata, ou falharemos em
otimizar os recursos investidos. Em outras palavras, o gerenciamento de
requisitos ir reduzir o nmero de caractersticas que ser desenvolvido na release
inicial, e desde que recursos so extraordinariamente escassos, ns no podemos
nos dar ao luxo de investir recursos adicionais em caractersticas que no sero
implementados no baseline corrente. A Tabela 202 ilustra a adio da
informao de esforo nossa lista de caractersticas.
157
Tabela 202 Lista de caractersticas com adio do esforo

Caracterstica
Prioridade
Esforo
Crtica
Mdio
Crtica
Alto
Crtica
Baixo
Importante
Alto
Importante
Baixo
Importante
Baixo
til
Baixo
Caracterstica 8: Integrar com o subsistema de gerenciamento

de verses
til
Alto
Adicionando o Elemento Risco

Um outro aspecto do gerenciamento de escopo a estimativa do risco associado
a cada caracterstica. Neste contexto, iremos considerar o risco como sendo a
probabilidade de que a implementao de uma caracterstica provocar impacto
imprevisvel no cronograma e no oramento. O risco nos d uma medida relativa
do potencial impacto de incluir uma particular caracterstica dentro do baseline de
projeto. Uma caracterstica de risco alto tem potencial para gerar impacto
negativo no projeto, mesmo se todas as outras caractersticas possam ser
realizadas dentro do tempo designado.
A equipe de desenvolvimento estabelece o risco com base em alguma heurstica
conveniente, usando a mesma escala baixo-mdio-alto usada para avaliar o
esforo. A Tabela 203 ilustra a lista de caractersticas revisada de nosso
exemplo.
Tabela 203 Lista de caractersticas com adio do risco
Caracterstica
Prioridade
Esforo
Risco
Crtica
Mdio
Baixo
Crtica
Alto
Mdio
Crtica
Baixo
Alto
Importante
Alto
Mdio
Importante
Baixo
Alto
Importante
Baixo
Baixo
til
Baixo
Alto
Caracterstica 8: Integrar com o subsistema de

gerenciamento de verses
til
Alto
Baixo
158
A estratgia de reduzir riscos varia de projeto a projeto, e no iremos cobrir esse

tpico aqui. Para o propsito de gerenciamento de escopo, basta ter conscincia
sobre os riscos associados com cada caracterstica, tal que decises inteligentes
possam ser tomadas desde o incio do projeto. Por exemplo, se uma caracterstica
com prioridade crtica tiver um alto risco, ento ser obrigatrio aplicar alguma
estratgia efetiva de reduo desse risco. Se a prioridade for importante e a
caracterstica estiver prxima ao baseline, o item pode ser descartado ou
simplesmente desenvolvido se houver tempo disponvel. No h problemas
nesse processo, contanto que nenhum compromisso tenha sido assumido em
incluir esse item na release. Se o benefcio de um item de alto risco for apenas
til, considere descart-lo completamente.
Reduzindo o Escopo
Ns j fizemos substancial progresso. Ns priorizamos um conjunto de
caractersticas com esforo e risco associados. Note que normalmente no existe
correlao entre a prioridade, esforo e risco. Alm disso, a vrios itens crticos
so de baixo esforo; vrios itens que so teis exigem alto esforo. Isso pode
ajudar a equipe na priorizao de caractersticas. Por exemplo, uma caracterstica
crtica, com esforo mdio e de baixo risco pode ser um candidato para receber
recursos de projeto imediato. Entre esses extremos, podemos encontrar o ponto
ideal, onde podemos aplicar nossos recursos pr-definidos de forma a maximizar
os benefcios que sero disponibilizados ao cliente. A Tabela 204 fornece um
pequeno guia para priorizar o desenvolvimento de caractersticas crticas com
base nesses atributos.
Tabela 204 Tcnicas de priorizao de escopo
Atributos
Considere
Prioridade: Crtica
Alerta! Estabelea imediatamente uma estratgia de reduo de riscos;

aloque recursos; concentre-se na sua viabilidade arquitetural.
Esforo: Alto
Risco: Alto
Prioridade: Crtica
Esforo: Alto
Concentre-se nos provveis item cujos recursos so limitados e crticos;

aloque recursos imediatamente.
Risco: Baixo
Prioridade: Crtica
Esforo: Baixo
Considere alocar recursos s por segurana, ou postergue essa alocao

para uma prxima oportunidade.
Risco: Baixo
Uma Estimativa Inicial Razovel

Se a equipe utilizar uma estimativa baseada em atividades, mesmo que grosseira,
ela poder determinar o baseline apenas adicionando as estimativas de atividades
at que o limite de tempo seja alcanado; assim, a equipe ter estabelecido o
baseline do projeto. Normalmente, no entanto, a equipe no tem, sequer, nenhum
dado disponvel e ainda assim deve fazer um primeiro corte no escopo de projeto.
Neste caso, ns ainda no sabemos onde traar o baseline, mas se a intuio da
159
equipe for de que o escopo est acima de 100%, a lista ter que ser cortada sem
discusso.
O prximo passo complicado. Se ns assumimos, por exemplo, que as
caractersticas esto acima de 200% do escopo, o baseline deve ser cortado pela
metade ou mais. Como fazer isso?
A primeira considerao se podemos realizar somente os itens crticos da lista.
Pergunte ao gerente de projeto, Se tudo falhar, podemos garantir ao menos os
itens crticos no prazo final? Afinal de contas, se ns tivermos aplicado
corretamente o esquema de priorizao, somente mais ou menos um tero dos
itens da lista sero crticos para a release. A menos que algumas caractersticas
crticas representem um nvel de esforo desproporcionalmente alto, a resposta
deveria ser sim, mesmo se o escopo seja de 200%. Se a resposta sim, e em nossa
experincia sempre sim, at mesmo nesse primeiro corte, podemos iniciar um
plano. Se a resposta for no, o projeto est muito acima do escopo (300%-400%
ou mais) , e um projeto de menor escopo deve ser definido e repetido o processo
de priorizao.
Desde que a nossa abordagem foi grosseira, no podemos assegurar quantos item
alm dos crticos podem ser realizados. As estimativas de esforo, com base nos
requisitos mais detalhados e nas estimativas de viabilidade tcnica, podem ser
usados para refinar o prximo baseline. (Alm disso, esta a hora de fazer o
plano detalhado do projeto para validar as suposies que fizemos).
No entanto, pela nossa experincia, traar o baseline contendo apenas os
requisitos crticos e incluir um ou dois itens importantes, suficiente para muitos
projetos do mundo real. Deixe que a equipe de desenvolvimento decida quais
itens importantes iro incluir durante o progresso do projeto. Clora, isso no
cientfico. Porm, funciona!
Se as expectativas forem estabelecidas e gerenciadas corretamente, qualquer coisa
que possa ser executada num futuro baseline ser um bnus. A Tabela 205 aplica
esta simples heurstica ao baseline de nosso projeto exemplo.
Tabela 205 Lista de caractersticas priorizadas
Caracterstica
Prioridade
Esforo
Risco
Crtica
Mdio
Baixo
Crtica
Alto
Mdio
Crtica
Baixo
Alto
Importante
Mdio
Mdio
Baseline (as caractersticas acima desta linha so caractersticas acordadas com o cliente)
Importante
Baixo
Alto
Importante
Baixo
Baixo
til
Baixo
Alto
Caracterstica 8: Integrar com o subsistema de

gerenciamento de verses
til
Alto
Baixo
160
As caractersticas que esto abaixo do baseline so agora, caractersticas futuras e

sero consideradas nas prximas releases. Tais caractersticas podem,
posteriormente, ser promovidas com prioridade maior, levando-se em
considerao os itens que podero ser realizados em mdio prazo e nas futuras
solicitaes do cliente.
Naturalmente, as caractersticas no so sempre independentes. Muitas vezes,
algumas caractersticas abaixo do baseline parte integrante de algumas
caractersticas que esto acima do baseline ou podem ser implementadas mais
prontamente como um resultado de ter realizado uma outra caracterstica. Ou,
quem sabe, a equipe de projeto seja excelente ou esteja com sorte, e realize as
caractersticas alm do cronograma previsto (uma noo concebvel!) ou encontre
uma biblioteca de classes que torne fcil implementar as caractersticas abaixo do
baseline. Nesses casos, a equipe deve estar autorizada a trazer tais caractersticas
para dentro do baseline (incluindo-as na release corrente), refazer a priorizao e
redefinir o baseline, desde que se sujeitem, naturalmente, a comunicar tais
alteraes aos clientes.
Dessa forma, a equipe deveria estar apta a criar um plano de projeto, ao menos
uma primeira verso aproximao. No entanto, em todos os casos, muitas
caractersticas desejadas foram cortadas e ser necessrio gerenciar as
expectativas, seja de dentro ou de fora da empresa. Cobriremos este tpico no
prximo captulo. Mas, primeiro, vamos dar uma olhada no caso de estudos e ver
se o que a equipe planeja para a release v1.0 do HOLIS.
O Caso de Estudos
Depois de executar o workshop de requisitos, a equipe do HOLIS recebeu a
incumbncia de avaliar o nvel de esforo de cada caracterstica e apresentar um
primeiro rascunho do baseline v1.0. Um gerenciamento rigoroso seria aplicado
devido s restries impostas equipe, incluindo a data limite de ter que
disponibilizar um prottipo para uma exposio em Dezembro e a data (rgida) de
uma release que deveria estar pronta em Janeiro8. A equipe estimou o nvel de
esforo de cada caracterstica via a heurstica alto-mdio-baixo e ento adicionou
a sua avaliao de risco para cada caracterstica. A Tabela 206 apresenta a lista
total de caractersticas, com o acrscimo desses atributos.
Para o prximo passo, a equipe forneceu estimativas grosseiras para cada
caracterstica e desenvolveu um plano de projeto detalhado mostrando certas
interdependncias e marcos de projeto crticos. Alm disso, aps a negociao
com o departamento de marketing, o qual, por sua vez, negociou com Raquel (seu
distribuidor internacional), a equipe determinou que, na release 1.0, era adequado
internacionalizar apenas a interface de usurio do UCC, o que reduziu
imensamente o escopo desta caracterstica. A internacionalizao final do
software de interface para Programador PC (opcional) poder esperar at a verso
2.0. Isso fez com que a equipe alterasse a caracterstica 25 de Interface de usurio
internacionalizado para Interface UCC internacionalizado e a adicionasse uma
Durante o desenvolvimento, a equipe decidiu que na prtica, tinha at o final de Fevereiro para liberar a verso 1.0
final. Com isso houve a adio de mais 6 semanas cruciais, pois a equipe estava convencida de que precisava
realizar modificaes finais, com base no feedback obtido na exposio.
161
nova caracterstica, Programador PC internacionalizado, para a lista de

caractersticas futuras.
Tabela 206 Caractersticas do HOLIS 2000, com os atributos de esforo e risco

ID
Caractersticas
Votos
Esforo
Risco
23
Cenas de iluminao personalizadas
121
Mdio
Baixo
16
Configurao do tempo automtico de iluminao, etc.
107
Baixo
Baixo
Caractersticas de segurana pr-definidas, p.ex., lmpadas e alarmes
105
Baixo
Alto
100% de confiabilidade
90
Alto
Alto
Fcil de programar, unidade de controle no-PC
88
Alto
Mdio
Facilidade de programar as estaes de controle
77
Mdio
Mdio
Mdio
Configurao de ausncias
77
Baixo
Toda lmpada pode ser apagada
74
Baixo
Baixo
Usar meu prprio PC para programar
73
Alto
Mdio
Caractersticas de entretenimento
66
Baixo
Baixo
20
Portas da garagem fechadas
66
Baixo
Baixo
19
Ligar automaticamente as lmpadas quando a porta for aberta
55
Baixo
Alto
Interface com o sistema de segurana residencial
52
Alto
Alto
13
9
14
3
2
18
7
Facilidade para instalar
50
Mdio
Mdio
Ligar automaticamente as luzes quando algum bate a porta
50
Mdio
Mdio
Ligar e desligar instantneo
44
Alto
Alto
11
Poder dirigir cortinas, sombras, bomba dgua e motores
44
Baixo
Baixo
15
Controlar a iluminao via telefone
44
Alto
Alto
10
Interface com o sistema de automao residencial
43
Alto
Alto
22
Modo gradual: aumento ou reduo da luminosidade lentamente
34
Mdio
Baixo
26
Estao de controle principal
31
Alto
Alto
12
Facilidade de expanso quando remodelado
25
Mdio
Mdio
25
Interface de usurio internacionalizado
24
Mdio
Alto
Alto
21
Interface com o sistema de udio/vdeo
23
Alto
24
Restaurao aps falha no fornecimento de energia eltrica
23
N/A
N/A
17
Controle HVAC
22
Alto
Alto
28
Ativao via voz
Alto
Alto
27
Apresentao no web site do usurio
Mdio
Baixo
Ento, com base na atividade de estimativa revisada, a equipe props o baseline

apresentado na Tabela 207. Este baseline foi proposto e enviado para todos da
equipe executiva, onde Emily, a VP (vice-presidente), tomar a deciso final.
Entretanto, antes de fazer isso, ela precisa que a equipe apresente os detalhes do
plano de projeto para que ela possa ver as dependncias. (A equipe suspeita de
que, o que ela realmente quer, ver se a lio de casa foi realizada ou se foi
apresentado um saco cheio de lixo para obter algum folga no cronograma). No
final, a deciso foi sim, mas o viso da Emily foi, Ns aceitamos a proposta da
release 1.0 do HOLIS, mas vocs devem estar cientes de que o CEO (diretor
responsvel da empresa), Mark, ordenou ao meu chefe, Jason, o qual me disse: a
senhora no poder falhar na liberao do produto em Janeiro conforme seu
comprometimento. A Emily, alm disso, comentou, No estou segura do que
ele quis dizer com isso. Acho que ele quis dizer que se ns falharmos, eu estarei
comprometida; mas eu no quero descobrir, voc quer?.
162
Ouvindo claramente as palavras de Emily, os membros da equipe se

responsabilizaram em liberar na data e prosseguir com a prxima fase. O prximo
milestone no plano de projeto ser a iterao de elaborao, a qual incluir uma
prototipao rpida do HOLIS que dever estar disponvel para demonstrao at
o dia primeiro de Agosto.
Tabela 207 Baseline v1.0 do HOLIS 2000
ID
Caractersticas
Votos
Esforo
Risco
Comentrios de Marketing
23
Cenas de iluminao personalizadas
121
Mdio
Baixo
To flexvel quanto possvel
16
Configurao do tempo automtico de iluminao, etc.
107
Baixo
Baixo
To flexvel quanto possvel
Caractersticas de segurana pr-definidas, p.ex., lmpadas e

alarmes
105
Baixo
Alto
Fazer mais pesquisas de mercado
100% de confiabilidade
90
Alto
Alto
Fcil de programar, unidade de controle no-PC
88
Alto
Mdio
Fornecer controlador dedicado
Facilidade de programar as estaes de controle
77
Mdio
Mdio
To fcil quanto possvel com o

esforo mdio
Configurao de ausncias
77
Baixo
Mdio
13
Atingir tanto quanto possvel os 100%
Toda lmpada pode ser apagada
74
Baixo
Baixo
Usar meu prprio PC para programar
73
Alto
Mdio
Apenas uma configurao suportada

em na verso 1.0
25
Interface UCC internacionalizado
24
Mdio
Mdio
Conforme combinamos com o

distribuidor europeu
14
Caractersticas de entretenimento
66
Baixo
Baixo
Ligar e desligar instantneo
44
Alto
Alto
(No aplicvel, includa na 23)

Tornar o investimento inteligente
Baseline obrigatrio v1.0: Todas as coisas acima desta linha devem ser includas ou iremos atrasar a release
20
2
Portas da garagem fechadas
66
Baixo
Baixo
Talvez tenha pouco impacto no

software
Facilidade para instalar
50
Mdio
Mdio
Nvel bsico de esforo
11
Poder dirigir cortinas, sombras, bomba dgua e motores
44
Baixo
Baixo
Talvez tenha pouco impacto no

software
22
Modo gradual: aumento ou reduo da luminosidade

lentamente
34
Mdio
Baixo
Seria bom se tivssemos
Opcional da v1.0: Implemente as caractersticas acima o quanto voc puderem (Cathy)

Caractersticas Futuras: As caractersticas abaixo no fazem parte do desenvolvimento corrente
3
Interface com o sistema de segurana residencial
52
Alto
Alto
19
Ligar automaticamente as lmpadas quando a porta for

aberta
55
Baixo
Alto
18
Ligar automaticamente as luzes quando algum bate a porta
50
Mdio
Mdio
15
Controlar a iluminao via telefone
44
Alto
Alto
10
Interface com o sistema de automao residencial
43
Alto
Alto
26
Estao de controle principal
31
Alto
Alto
12
Facilidade de expanso quando remodelado
25
Mdio
Mdio
25
Interface de usurio internacionalizado
24
Mdio
Alto
21
Interface com o sistema de udio/vdeo
23
Alto
Alto
24
Restaurao aps falha no fornecimento de energia eltrica
23
N/A
N/A
17
Controle HVAC
22
Alto
Alto
28
Ativao via voz
Alto
Alto
27
Apresentao no web site do usurio
Mdio
Baixo
Poderamos ter ao menos uma

interface de hardware? (Eric)
163
Captulo 21
Gerenciando o Seu Cliente
Pontos chaves
Gerenciar seu cliente significa engaj-lo no gerenciamento de seus requisitos e no
seu escopo de projeto.
Clientes que so partes do processo sero responsveis pelos resultados.
Fazer o trabalho correto significa fornecer funcionalidade suficiente no tempo
certo para atender as reais necessidades do cliente.
Habilidades de negociao do apoio indispensvel para o desafio de gerenciar
escopo.
Engajando Clientes para Gerenciar Seu Escopo

de Projeto
A reduo do escopo de projeto para adequar ao tempo e recursos disponveis tem
o potencial de criar uma relao antagnica entre a equipe de projeto e seus
clientes, cujas necessidades devem ser atendidas. Deixe-me ser honesto. Todos
ns j passamos por isto. Felizmente, isso no tem que ser assim. Ao invs disso,
podemos engajar ativamente nossos clientes no gerenciamento de seus requisitos
e do seu escopo de projeto para garantir a qualidade e pontualidade na liberao
do software.
Esta concluso baseia-se em algumas percepes importantes:
Os nossos clientes so os principais interessados em atender seus

compromissos financeiros com o seu mercado externo. Assim, liberar uma
aplicao de alta qualidade e, se necessrio, de escopo-reduzido dentro
do cronograma e oramento o maior benefcio que a equipe pode
fornecer.
A aplicao, as suas caractersticas chaves e as necessidades de negcio
pertencem, todos, aos clientes e no equipe de desenvolvimento da
aplicao.
Precisamos que clientes nos dem informaes para podemos tomar
decises; s eles podem verdadeiramente determinar como gerenciar o
escopo e chegar a um resultado til. Ns somos os seus humildes servos
tecnolgicos. O projeto deles.
Comunicando os Resultados
Se o escopo do projeto tiver que ser reduzido, assegure-se que o cliente esteja
participando desse processo ativamente. Um cliente que faa parte do processo ir
se responsabilizar pelos resultados obtidos. Um cliente excludo desse processo
164
no ficar feliz com os resultados e ira, naturalmente, culpar os desenvolvedores

por no terem se empenhado suficientemente.
Engajar o cliente nesse dilogo ajuda a amansar o problema de gerenciar o escopo
de forma extremamente gentil na porta de sua casa. E com a filosofia que
descrevemos no captulo anterior, clientes inteligentes iro se comprometer, junto
ao seu mercado externo, apenas com os itens crticos includos no baseline. As
dificuldades advindas do cronograma atrasado e caractersticas no
implementadas sero evitadas. Quaisquer caractersticas extras, implementadas
alm do baseline, sero recebidas de positivamente, pois estar excedendo as
expectativas.
Algumas vezes, a descoberta do problema de gerenciamento de escopo ocorre
sem que o cliente esteja engajado; nesse caso, h grande chance de termos que
informar o nosso cliente sobre as ms notcias. Informar e/ou gerenciar nossos
clientes um processo delicado, pois requer habilidades de negociao e total
responsabilidade e comprometimento com o cronograma e escopo apresentados.
Aps apresentar as ms notcias, no podemos nos permitir falhar com a nossa
promessa, sob a pena de, no mnimo, perder a nossa credibilidade.
Negociando com o Cliente

Quase todos os processos de negcio requerem negociao. Considere negociar a
postergao da data de liberao com um cliente, negociar um valor maior,
negociar o aumento anual com o seu gerente, negociar uma cota atingvel para a
sua equipe de venda, ou negociar recursos adicionais para o seu projeto.
No interesse do seu projeto e dos objetivos de negcio do cliente, voc pode
precisar negociar o compromisso de escopo para a sua equipe. A equipe deve
tambm, ter em mente que, em muitos casos, que o cliente j pode ter
desenvolvido a habilidade de negociao e ir naturalmente us-la durante as
discusses com voc e sua equipe. Assim, se voc um lder de equipe, gerente
de projeto ou campeo de projeto, voc deve desenvolver muito bem essas
habilidades. A negociao uma atividade de negcio profissional. No um
processo particularmente difcil, e pode ser realizado com integridade, graa e
estilo. Aproveite a oportunidade para ter algum treinamento nesse processo; seu
departamento de recursos humanos provavelmente pode ajud-lo, ou voc pode
querer participar de um seminrio externo. Se isso falhar, voc deve ao menos se
familiarizar com algumas regras do jogo. Por exemplo, uma boa reviso do
processo de negociao pode ser encontrada em Fisher, Ury, e Pattons (1983)
Getting to Yes, o qual pode ser lido em poucas horas. Eles recomendam que
pequeno guia para a sesso de negociao.
O princpio guia
para o
gerenciamento de
escopo: no prometa
o que provavelmente
no possa ser
cumprido e
liberado.
Comece otimista sem ser irracional.

Separe as pessoas do problema.
Concentre-se nos interesses, no nas posies.
Entenda e mantenha sua posio.
Invente opes para ganho mtuo.
Aplique critrios objetivos.
Conforme voc negocia com o seu cliente, seu princpio guia para estabelecer um
baseline deve ser: no prometa o que provavelmente no possa ser cumprido e
165
liberado. Isso assegura que caprichos inevitveis do desenvolvimento de

software, riscos tecnolgico no previstos, mudanas de requisitos, atrasos no
recebimento de componentes adquiridos, dispensa imprevista de um membro
chave da equipe, entre outros, possam ser acomodados dentro do seu cronograma
de projeto. Se acontecer de voc executar um projeto livre dessas circunstncias
indesejveis, tudo bem: no pior caso, voc ter que se preocupar com a liberao
antecipada! Mesmo que seja o de fornecer ao menos alguma festa considervel
dentro de sua companhia!
Gerenciando o Baseline
Gerentes de desenvolvimento de bem sucedidos criam margens de erro na
estimativa de esforo e levam em considerao o tempo para incorporar mudanas
legitimadas durante o ciclo de desenvolvimento. Esses gerentes tambm resistem
s caractersticas desagradveis, as quais o autor Jerry Weinberg (1995) nos
lembra que o escopo pode se elevar at 50-100% depois de iniciar o projeto. Ao
se concentrar no esforo de desenvolvimento de prioridades crticas do cliente
pode aliviar at os ambientes polticos hostis. Com o escopo negociado dentro de
um nvel atingvel, e com o foco de desenvolvimento sempre voltado para o que
deve ter do cliente, a equipe ir alcanar credibilidade por atender o
cronograma com qualidade e, ocasionalmente, com servios que no podiam ser
previstos com antecedncia.
Todavia, seus clientes (internos ou externos), querem, naturalmente, a maior
quantidade de funcionalidade possvel em cada release do sistema de software.
Afinal de contas, so as funcionalidades liberadas que adicionam valor necessrio
para atender a seus objetivos de negcio. De fato, devemos ter um respeito salutar
com os clientes que esto gerando a demanda, pois so essas funcionalidades que
iro, em ltima instncia, garantir o sucesso no mercado. Clientes competentes, na
realidade, so os nicos que merecem ter demanda por funcionalidades.
No entanto, no considerar a demanda por mais e mais funcionalidades pode
comprometer a qualidade e a viabilidade de todo o projeto. O mais torna-se
inimigo do adequado. O melhor torna-se inimigo do suficientemente bom.
Se ns estivermos trabalhando num setor de negcio onde a fsica esteja mais bem
definida, onde a indstria tenha algumas centenas de anos de experincia em
liberar produtos, as coisas poderiam ser diferentes. No entanto, ns trabalhamos
no mundo do software; onde a fsica indeterminada, os processos so imaturos,
e a tecnologia mutvel. Permita-nos focar, inicialmente, em como fazer um
servio direito: funcionalidade suficiente no tempo certo para atender as reais
necessidades do cliente. Ns podemos refinar nosso processo mais tarde para ver
se podemos superar as expectativas, mas por agora, vamos apenas nos concentrar
em atend-los! Para isso, precisamos gerenciar o baseline.
Uma vez estabelecido, o baseline fornece o centro focal de muitas atividades de
projeto. O baseline de caractersticas pode ser usado para avaliar realisticamente o
progresso. Recursos podem ser ajustados com base no progresso relativo do
baseline. As caractersticas dentro do baseline podem ser refinadas em detalhes
suficientes para satisfazer o desenvolvimento do cdigo. A rastreabilidade de
requisitos pode ser aplicada desde as necessidades do usurio passando pelas
166
caractersticas do baseline. A rastreabilidade pode ser posteriormente estendida

das caractersticas at as especificaes adicionais e implementaes.
Talvez o mais importante, o baseline de alto-nvel pode ser usado como parte de
um processo efetivo de gerenciamento de mudanas. As mudanas so parte
integrante de todas as atividades de desenvolvimento. O gerenciamento de
mudanas to crtico que ns dedicamos para tratar desse assunto no Captulo
34. Por agora, iremos ver como podemos aplicar o baseline de caractersticas para
este aspecto importante do gerenciamento de software.
Mudana Oficial
O baseline de caractersticas fornece um excelente mecanismo para gerenciar
mudanas de alto-nvel. Por exemplo, quando o cliente solicita uma nova
capacidade do sistema (uma mudana oficial) e essa capacidade no parte do
baseline de caractersticas, o impacto dessa mudana deve ser avaliada antes de
inclu-la no baseline. Se a equipe de projeto tiver realizado um bom trabalho de
definir o baseline antes de comear, a suposio deve ser a de que qualquer
mudana no baseline deve afetar os recursos, o cronograma, ou o conjunto de
caractersticas a serem liberadas na release.
Se os recursos so fixos e o cronograma no puder ser alterado, a equipe de
projeto deve engajar o cliente no processo de tomada de deciso que priorize a
nova caracterstica em relao a outras caractersticas programadas para a release.
Se a nova caracterstica tiver uma prioridade crtica, ela deve, por definio, ser
includa na release, e o cliente e a equipe de projeto devem em conjunto,
determinar quais caractersticas sero excludas da release ou ao menos reduzidas
em suas prioridades, com a reduo associada das expectativas. Se a caracterstica
importante, mas no crtica, a equipe de projeto pode prosseguir com a
implementao da caracterstica na base de grandes esforos, deixando que o
progresso dite se a caracterstica far ou no parte da release.
Mudana No-oficial
Paradoxalmente, o problema de mudanas iniciadas pelo cliente pode ser o mais
fcil de tratar dentre os desafios do gerenciamento de requisitos. O foco do
problema externo, podemos estabelecer certas salvaguardas, e o impacto das
mudanas podem ser avaliados e apresentados aos stakeholders externos.
No entanto, a experincia mostra que a ameaa de uma outra classe de mudanas
muito mais subversivo ao processo de desenvolvimento. No Captulo 34,
discutiremos os damos obscuros dessas mudanas e adquirir munio adicional
para atacar esse desafio de gerenciamento de escopo.
167
Captulo 22
Gerenciamento de Escopo e Modelos

de Processo de Desenvolvimento de
Software
Pontos chaves
O processo de desenvolvimento da equipe define quem est fazendo o que, quando
e como.
No modelo cascata, as atividades progridem atravs de uma seqncia de
passos, com cada passo apoiado nas atividades do passo anterior.
O modelo espiral inicia com uma srie de prottipos dirigidos pelo risco,
seguido por um processo estruturado similar ao modelo cascata.
A abordagem iterativa, um hbrido dos modelos cascata e espiral, separa as fases
do ciclo-de-vida das atividades de software que ocorrem em cada fase.
Independentemente de qual modelo voc use, voc deve desenvolver ao menos
um prottipo inicial para obter o feedback do cliente.
te agora ns no falamos muito sobre o processo de desenvolvimento de

software como um todo e seu relacionamento com a habilidade da equipe
atingir os resultados desejados. No entanto, o gerenciamento de
requisitos que seja efetivo no pode ocorrer sem o contexto de um
processo de software razoavelmente bem definido que defina o conjunto total de
atividades que sua equipe deve executar para liberar o produto de software final.
Alguns processos de software so relativamente formais, e outros so informais,
mas sempre existe um processo, mesmo que ele no seja rigoroso ou
documentado.
O processo de desenvolvimento de software da sua equipe define quem (quem da
equipe) faz o que (que atividade ser executada), quando (esta atividade
executada em relao a outras atividades), e como (os detalhes e passos na
atividade) normalmente a sua equipe atinge seus objetivos. O processo de
software tem um efeito material na habilidade da equipe desenvolver software no
prazo e dentro do oramento. Neste captulo, ns veremos alguns dos aspectos de
vrios tipos de processos de software, ou seja, fases dependentes do tempo e os
principais tipos de atividades dessas fases e, ento, analisamos como os vrios
processos afetam os desafios do gerenciamento de escopo.
O Modelo Cascata
Boehm (1988a) disse que, j nos anos 50 (1950), a indstria de software,
reconhecendo o custo de descobrir tardiamente defeitos dentro do ciclo-de-vida
de software, adotou um modelo lgico e seqencial, o qual progredia a partir da
fase de requisitos, passando pelas fases de projeto, codificao, e assim por
168
diante. Isso foi o principal avano obtido sobre os modelos anteriores de duas
fases (codificar e corrigir), atravs do qual programadores escreviam um cdigo
inicial e ento o corrigia at que no precisasse mais ser corrigido.
Nos anos 70 (1970), Winston Royce (1970), trabalhando na TRW, definiu o que
ficou conhecido como o modelo cascata de desenvolvimento de software. O
modelo cascata melhorou o modelo estritamente seqencial pelo:
Reconhecimento da necessidade de loops de feedback entre estgios, onde

admitia que o projeto afeta os requisitos, que a codificao do sistema ir
fazer com que visitemos novamente o projeto, e assim por diante.
Desenvolvimento de um prottipo de sistema em paralelo com as
atividades de anlise e projeto.
Como ilustra a Figura 221, no modelo cascata, as atividades de software

progridem logicamente atravs de uma seqncia de passos. O trabalho em cada
passo apia-se em atividades do passo anterior. O projeto segue logicamente os
requisitos, a codificao vem depois do projeto, e assim por diante. O modelo
cascata foi largamente seguido no passado, por durante duas dcadas, e serviu
com sucesso como um modelo de processo para projetos de mdia a larga escala.
Requisitos
Projeto
Codificao e
teste unitrio
Integrao de
sistema
Operao e
manuteno
Figura 221
Modelo cascata de desenvolvimento de software
Note que, como normalmente ocorre, a Figura 221 no referencia a atividades de

prototipao como foi prescrito. Isto um infeliz mistrio da histria que iremos
contar brevemente.
O modelo cascata teve algum sucesso ao reforar a funo dos requisitos como o
primeiro passo necessrio para o desenvolvimento de software, bsico para as
atividades de projeto e codificao. Porm, essa fora tornou-se tambm numa
fonte de dificuldades, pois deu nfase na elaborao completa dos requisitos e
documentaes de projeto, transformando-se numa barreira para sair de cada fase.
Alm disso, talvez esse grave engano das equipes de desenvolvimento, tenha feito
com que esse modelo representasse uma abordagem fixa e rgida de
desenvolvimento, onde os requisitos so congelados durante a execuo do
169
projeto, onde mudanas representam um sacrilgio, e onde o processo de

desenvolvimento impe sua prpria vida. Neste caso, com o tempo, a equipe pode
ficar completamente desligada do mundo real de onde o projeto originalmente foi
concebido.
O modelo cascata encontrou presso adicional quando foi associado aos desafios
do gerenciamento de requisitos (Figura 222). Especificamente, se o modelo
cascata aplicado a um projeto que possui inicialmente 200% de escopo, o
resultado pode ser desastroso. No prazo final, nada realmente funciona; testes de
unidade e de integrao do sistema so interrompidos ou abandonados; foram
realizados investimentos significativos na especificao, projeto e codificao de
caractersticas de sistema que nunca sero liberados. Resultado: no existe nada
que possa ser liberado, existem apenas o caos, a baixa qualidade e sucata de
software.
Devido, principalmente, a essas razes, o modelo cascata tornou-se pouco
popular. Um resultado infeliz de tender a saltar direto para o cdigo, mesmo com
o entendimento inadequado dos requisitos do sistema, foi um dos principais
problemas que estavam tentando resolver no modelo cascata!
Requisitos
Projeto
Codificao
e teste
Integrao
de sistema
Escopo do projeto
Caractersticas a serem liberadas
Operao e
manuteno
Tempo
Prazo final
Figura 222
Aplicando o modelo cascata num projeto com escopo de 200%
O Modelo Espiral
O principal estudo do Barry Boehm (1988a) recomendava uma estrutura diferente
para guiar o processo de desenvolvimento de software. Seu modelo espiral de
desenvolvimento de software um modelo funcional para aqueles que acreditam
que o sucesso segue um caminho de desenvolvimento mais orientado a riscos e
incremental (Figura 223).
170
Custo
acumulativo
Progresso atravs dos passos
Determinar objetivos,
alternativas, restries
Avaliar alternativas:
Identificar e resolver riscos
Anlise
de riscos
Anlise
de riscos
Anlise
de riscos
Prottipo 3
Reviso
Plano de requisitos, plano
de ciclo de vida
Anlise
Prottipo 2
de
riscos Prottipo 1
Simulaes, modelos, avaliao da execuo
Conceito de
operao
Requisito de
software
Plano de
desenvolvimento
Plano de integrao
e teste
Prottipo
operacional
Validao de
requisitos
Projeto de
produto de
software
Projeto
detalhado
Codificao
Teste de unidade
Validao e verificao
do projeto
Teste e integrao
Teste de aceitao
Implementao
Planejar prximas fases
Figura 223
Desenvolver, verificar o
produto do prximo nvel
O modelo espiral de desenvolvimento
No modelo espiral, o desenvolvimento inicialmente dirigido por uma srie de

prottipos orientados a risco; ento um processo similar ao modelo cascata
usado para produzir o sistema final. Naturalmente, quando usado
inapropriadamente, o modelo espiral pode exibir tantos problemas quanto o
modelo cascata usado de forma incorreta. Os projetos algumas vezes caem na
abordagem reduzir-e-tentar, liberando incrementos que devem ser expandidos e
mantidos com chicletes e barbantes. Alguns a referenciam como o processo de
criar instantaneamente cdigos legados. O progresso medido pela nossa recente
habilidade de criar cdigos, incompreensveis e que no podem ser mantidos,
duas ou trs vezes mais rpida do que a tecnologia anterior!
No entanto, quando voc olha o modelo espiral com mais cuidado, ele fornece um
sensvel mapa que ajuda a atacar alguns dos desafios de requisitos apresentados
neste volume. Em especial, o modelo espiral inicia com o planejamento de
requisitos e validao de conceitos, seguido por um ou mais prottipos para
assistir na confirmao precoce de nosso entendimento sobre os requisitos do
sistema. A principal vantagem deste processo a disponibilidade de
oportunidades para mltiplos feedbacks de usurios e clientes, dos quais
pretendemos obter um Sim, mas... logo no incio. Oponentes desta rigorosa
abordagem dizem que nos ambientes atuais, no podemos nos dar ao luxo de
aplicar o tempo para realizar uma validao completa dos conceitos, criar dois ou
trs prottipos, para ento aplicar rigorosamente o modelo cascata.
171
Retornando pergunta, o que acontece no modelo espiral quando um projeto

iniciado com um escopo de 200%? A Figura 224 ilustra o resultado. Ns
podemos dizer que o resultado no muito melhor do que o plano desastroso
quando se utiliza o modelo cascata; outros dizem no prazo final, teremos apenas
um ou dois prottipos operacionais e um feedback do cliente. (Naturalmente, esse
feedback estar focado na inutilidade dos softwares que esto para ser liberado
para produo!).
Prazo Final!
Projeto e
validao de
projeto
Plano de integrao
Prottipo 2
Anlise de
riscos
Validar
Plano de
desenvolvimento
Projeto detalhado
Codificao
Teste de unidade
Integrao
Plano de
requisitos
Conceitos
Validao de
requisitos
Prottipo 1
Requisito de
software
Figura 224
Aplicando o modelo espiral num projeto com 200% de escopo
A Abordagem Iterativa
Na dcada passada, muitas equipes migraram para uma nova abordagem, uma que
combina o que existe de melhor nos modelos cascata e espiral e que um hbrido
desses dois. A nova abordagem tambm incorpora algumas construes
adicionais avanadas da disciplina de engenharia de processos de software. A
abordagem iterativa, introduzida por Kruchten (1995), tem sido bem descrito
em inmeros textos, incluindo Kruchten (1999) e Royce (1998). Esta abordagem
tem provado a sua efetividade em vrios tipos de projetos e pode exibir inmeras
vantagens sobre os modelos de desenvolvimento cascata e espiral.
Nos modelos de desenvolvimento de software tradicionais, o tempo se segue
atravs de uma srie de atividades seqenciais, com o requisito precedendo o
projeto, o projeto precedendo a implementao, e assim por diante. Isso parece ser
bastante lgico. Na abordagem iterativa, as fases do ciclo-de-vida no esto
acopladas s atividades lgicas de software que ocorrem em cada fase,
permitindo-nos revisitar as vrias atividades, tais como requisitos, projetos e
implementao, em vrias iteraes do projeto. Alm disso, como no modelo
espiral, cada iterao projetada para reduzir quaisquer riscos presentes no
estgio de atividade de desenvolvimento.
172
Fases do Ciclo-de-Vida
A abordagem iterativa consiste de quatro fases do ciclo-de-vida: concepo,
elaborao, construo e transio, as quais correspondem claramente aos
estados naturais do projeto ao longo do tempo. (Veja a Figura 225).
Concepo
Elaborao
Construo
Transio
Tempo
Figura 225
Fases do ciclo-de-vida na abordagem iterativa
1. Na fase de concepo, a equipe se concentra em entender o caso de negcio

do projeto, o escopo do projeto, e na viabilidade de uma implementao. A
anlise do problema realizada, o documento da Viso criado, e estimativas
preliminares de cronograma e custos, bem como os fatores de risco de projeto
so definidos.
2. Na fase de elaborao, os requisitos do sistema so refinados, uma arquitetura
inicial executvel estabelecida, e um prottipo de viabilidade inicial
normalmente desenvolvido e demonstrado.
3. Na fase de construo, o foco est na implementao. A maior parte do
cdigo desenvolvido aqui nesta fase, e a arquitetura e o projeto totalmente
desenvolvido.
4. O beta teste normalmente ocorre nesta fase de transio, e os usurios e
pessoal de manuteno do sistema so treinados. O baseline testado da
aplicao implantado para a comunidade de usurios e implantado para uso.
Iteraes
Dentro de cada fase, o projeto normalmente experimenta vrias iteraes (Figura
226). Uma iterao uma seqncia de atividades com um plano e critrios de
avaliao estabelecidos, resultando em algum tipo de executvel. Cada iterao
construda sobre a funcionalidade da iterao anterior; assim, o projeto
desenvolvido de forma iterativa e incremental.
Concep
Iter
li
Elabora
Iter
h
...
S
Release
Figura 226
(
Relea
Constru
Iter
d
...
Iter
d
Transi
Iter
t
...
...
Release
Release
Release
Release
Release
Release
Iteraes de fases, resultando em releases viveis
A seleo das iteraes depende de vrios critrios. As iteraes iniciais devem

ser projetadas para avaliar a viabilidade da arquitetura escolhida contra alguns dos
mais use-cases importantes cercados de riscos.
173
Workflows
Na abordagem iterativa, as atividades associadas ao desenvolvimento de software
so organizadas num conjunto de workflows. Cada workflow consiste de um
conjunto de atividades logicamente relacionadas, cada um definindo como as
atividades devem ser seqenciadas produzir um produto de trabalho ou artefato
vivel. Embora a quantidade de workflows possa variar, dependendo da empresa
ou das circunstncias do projeto, existem normalmente seis workflows, como
ilustra a Figura 227.
Concepo
Elaborao
Construo
Transio
Workflows do
processo
Requisitos
Anlise e Projeto
Implementao
Teste
Implantao
Workflows do
processo
Gerenciamento de
Figura 227
Workflows da abordagem iterativa

Durante cada iterao, a equipe gasta tanto tempo quanto apropriado em cada
workflow. Assim, uma iterao pode ser considerada como uma mini-cascata
atravs de atividades de requisitos, anlise e projeto, e assim por diante, mas cada
mini-cascata dedicada s necessidades especficas daquela iterao. O
tamanho da corcova da Figura 227 indica a quantidade relativa de esforo
investido num workflow. Por exemplo, na fase de elaborao, tempo significativo
gasto em refinar os requisitos e em definir a arquitetura que ir sustentar as
funcionalidades. As atividades podem ser seqenciais (um verdadeiro minicascata) ou podem ser executadas concorrentemente, quando apropriado ao
projeto.
Da perspectiva de gerenciamento de requisitos, a abordagem iterativa trs duas
significativas vantagens:
1. Obter o Sim, mas desde o incio. Cada iterao produz uma release
executvel tal que, logo no incio, clientes tm a oportunidade de ver o
produto do trabalho. Claro que a reao do cliente ser um Sim, mas,
mas nos estgios iniciais, apenas um mnimo de investimento foi
realizado. Conforme as iteraes vo sendo realizados, os tamanhos do
Sim, mas devem decrescer, e voc e seu cliente ir, em algum
momento, convergir para um sistema correto.
174
2. Melhor gerenciamento do escopo. Se a primeira iterao ultrapassar

em 30%, isso uma indicao de que o escopo do projeto pode estar
mal definido, e ajustes podem ser realizados. Mesmo que o escopo no
seja bem gerenciado, mltiplas iteraes foram desenvolvidas e
executadas antes que chegasse o prazo final, e pelo menos foram
implantados. Mesmo que falte alguma funcionalidade, a release ir
liberar algum valor ao usurio, se as caractersticas tiverem sido
selecionadas e priorizadas cuidadosamente, permitindo que seu cliente
atinja seus objetivos, ao menos em parte, at que voc continue com as
prximas iteraes. E, se a arquitetura for robusta e atender as questes
tcnicas, sua equipe ter uma plataforma slida onde funcionalidades
adicionais podero ser construdas.
O que fazer, O que fazer ...

Independentemente
do modelo que voc
utilize, a equipe
deve fornecer ao
menos um prottipo
de avaliao robusto
a fim de obter
feedback do cliente
logo no incio.
Uma das premissas desse volume que obter o Sim, mas desde o incio uma
atividade poderosa e a melhor do processo de software.
Quantas vezes voc tem para fazer isso?

O cliente solicita mudanas em cada prottipo?
Estamos condenados independentemente do processo que seguimos?
Resposta: ao menos uma vez, sim, e no. Sim, clientes iro exigir mudanas toda
vez que ele ver um prottipo. No, voc no est condenado. A razo que a
quantidade de mudanas que ocorrem depois que o cliente tiver a oportunidade de
ver, tocar e interagir com a implementao pretendida pequena comparada
resposta do cliente para o primeiro artefato tangvel do processo.
Assim, independentemente do modelo de processo de desenvolvimento utilizado,
embora a nossa preferncia seja o modelo iterativo em projetos de
desenvolvimento, obrigatrio que a atividade de desenvolvimento fornea ao
menos um prottipo de avaliao robusto para obter o feedback do cliente antes
que a maioria das atividades de projeto e codificao seja executada. (Lembra da
atividade de prototipao que Royce (1970) sugeriu em seu primeiro modelo
cascata?). Devido reduo da quantidade de mudanas ao nvel gerencivel, o
desenvolvedor consegue fazer mudanas (normalmente em interfaces de usurio,
relatrios e outras sadas) incrementalmente no projeto, garantido uma
implementao robusta e de altssima qualidade. A partir da, um processo
rigoroso de finalizar atividades de projeto, codificao, testes de unidade, e
integrao de sistema, ir fornecer um slido fundamento para o produto
enquanto que simultaneamente auxilia enormemente nas atividades de garantia de
qualidade e teste.
175

Na Habilidade de Equipe 4, Gerenciando o Escopo, aprendemos que o problema
do escopo de projeto endmico. Projetos normalmente so iniciados com
aproximadamente duas vezes a quantidade de funcionalidades que a equipe pode
razoavelmente implementar com qualidade. Isso no deveria nos surpreender, isso
faz parte da natureza humana: clientes querem mais, o mercado deseja mais e ns
tambm queremos mais. Ns apenas precisamos garantir que nos impusemos uma
dieta suficiente para assegurar que podemos liberar as coisas dentro do prazo.
Ns vimos vrias tcnicas para estabelecer prioridades e definimos a noo de
baseline um acordo sobre o que o sistema ir fazer um produto chave do
projeto a nossa pedra fundamental e ponto de referncia para deciso e
avaliao. Aprendemos que, se o escopo e a respectiva expectativa exceder a
realidade, em todas as probabilidades, algumas notcias ruins tero que ser dadas.
Decidimos adotar uma abordagem filosfica que engaje nosso cliente nas
decises difceis. Afinal de contas, ns somos apenas os recursos, no os
responsveis por tomar decises; o projeto do cliente. Ento, a questo : Dado
os recursos que esto disponveis para o projeto, o que exatamente deve ser
realizada na prxima release?
Apesar de tudo, esperamos fazer alguma negociao; a vida e, certamente, o
negcio so, num dado sentido, uma negociao e no deveramos ficar surpresos
com isso. Ns mencionamos brevemente algumas habilidades de negociao e
demos dicas de quais dessas habilidades a equipe pode precisar nessas ocasies.
Ns no podemos esperar que este processo elimine os desafios de escopo, muito
mais do que qualquer outro processo sozinho ir resolver os problemas do mundo
do desenvolvimento de aplicaes. No entanto, com os passos que delineamos
podemos esperar ter um efeito material sobre o escopo do problema, permitindo
que desenvolvedores de aplicao concentrem-se nos subconjuntos crticos e
libere incrementalmente sistemas de altssima qualidade e que atendam ou
excedam as expectativas dos usurios. Alm disso, ao engajar o cliente para que
nos ajude a resolver o problema de gerenciamento de escopo, eleva o
comprometimento das partes, estimulando a comunicao e confiana entre o
cliente e a equipe de desenvolvimento. Com uma definio compreensiva do
produto (documento da Viso) sob controle e o escopo num nvel razoavelmente
gerencivel, mesmo que no incio o escopo esteja exagerado, teremos ao menos a
oportunidade de ter sucesso nas prximas fases do projeto.
176
Refinando a Definio do Sistema
Captulo 23: Requisitos de Software

Captulo 24: Refinando Use Cases
Captulo 25: Uma Especificao de Requisitos de Software Moderna
Captulo 26: Sobre Ambigidade e Especificidade
Captulo 27: Medidas de Qualidade de Requisitos de Software
Captulo 28: Mtodos Tcnicos para Especificao de Requisitos
177
Nas Habilidades de Equipe anteriores, ns nos concentramos sobre o processo de

analisar o problema, elucidar necessidade do usurio, coletar, documentar e gerenciar as
caractersticas do produto desejado. Uma vez que as caractersticas do produto tenham
sido especificadas, a prxima tarefa refinar a especificao at atingir um nvel de
detalhes adequado para orientar os processos de projeto, codificao e teste.
Na Habilidade de Equipe 5, examinamos um mtodo organizado para elaborar,
organizar e comunicar os requisitos de software. Iremos finalizar a Habilidade de Equipe
5 com uma viso de um assunto mais intrincado: como estabelecer os requisitos de
forma clara e concisa.
Independentemente do mtodo que voc utilize para coletar os requisitos, crucial que
voc adote a filosofia de que os requisitos coletados e somente esses requisitos iro
dirigir o projeto. Se descobrirmos que eles so insuficientes ou errados, eles devem ser
rapidamente e oficialmente alterados a fim de manter as regras corretas. Desta forma, a
equipe toda ter um alvo no-ambguo e seus esforos podem se concentrar em
descobrir e implementar requisitos, minimizando o tempo gasto em coisas sem
relevncia. Iremos comear examinando a natureza dos prprios requisitos.
Needs
Features
Domnio do Problema
Rastreabilidade
Espao da
Soluo
Produto a
ser
construdo
Procedimentos de Teste
Projeto
Docs
Usurio
178
Captulo 23
Pontos chaves
Um conjunto completo de requisitos pode ser determinado pela definio das
entradas, sadas, funes e atributos do sistema, bem como de seu ambiente.
Os requisitos devem excluir informaes relacionadas ao projeto, tais como
cronograma, planos de projeto, oramento e testes, bem como informaes de
projeto.
O processo de requisitos/projeto iterativo; requisitos conduzem a seleo de
certas opes de projeto, as quais por sua vez, iniciam novos requisitos.
Restries de projeto so restries sobre o projeto do sistema, ou do processo
pelo qual um sistema desenvolvido.
as caractersticas do sistema definidas nas Habilidades de Equipe

anteriores, foram deixadas, propositalmente, em alto nvel de abstrao,
para que:
Pudssemos entender melhor o aspecto e a forma do sistema atravs de

suas caractersticas e de como elas atendem s necessidades do usurio.
Pudssemos avaliar o sistema quanto completeza e consistncia e sua
adequao em relao ao seu ambiente.
Pudssemos usar essas informaes para determinar a viabilidade e
gerenciar o escopo do sistema antes de fazer investimentos significativos.
Alm disso, essa abstrao de alto-nvel nos permite tomar decises sobre
requisitos excessivamente restritivos logo no incio, isto , as pessoas tm a
oportunidade de adicionar suas perspectivas e valor definio do sistema antes
de fecharem a implementao do sistema. Na Habilidade de Equipe 5, Refinando
a Definio do Sistema, nossa discusso muda para a elaborao detalhada das
caractersticas do sistema, o suficiente para assegurar que as atividades de projeto
e codificao resultem num sistema que atendem plenamente as necessidades do
usurio. Desse modo, ns nos dirigimos para o prximo nvel de especificidade e
detalhes, e criamos um modelo de requisitos rico e profundo para o sistema que
ser construdo. Naturalmente, criamos tambm informaes mais detalhadas, as
quais tero que ser gerenciadas e, para isso, teremos que ser mais organizados
para cuidar desses detalhes adicionais.
O nvel de especificidade necessria neste prximo passo depende de vrios
fatores, incluindo o contexto da aplicao e das habilidades da equipe de
desenvolvimento. Em sistemas de software para equipamentos mdicos de alta
segurana, aeronaves, ou comrcio online, o nvel de especificidade
apropriadamente alto. O processo de refinamento pode incluir mecanismos
formais de garantia de qualidade, revises, inspees, modelagem, e outros
similares. Em sistemas cujas conseqncias sejam menos catastrficas frente a
falhas, o nvel de esforo ser mais modesto. Nestes casos, o trabalho envolvido
179
est em simplesmente assegurar que a definio est suficientemente precisa

quanto compreensiva por todas as partes envolvidas e ainda fornea um ambiente
de desenvolvimento eficiente e uma probabilidade suficientemente alta de
sucesso. O foco est no pragmatismo e na economia, fazendo uma especificao
de requisitos que seja apenas o suficiente para garantir que o software
desenvolvido o que o usurio deseja.
Da mesma forma que no existe uma linguagem de programao certa para todas
as aplicaes, no existe nenhuma maneira correta de desenvolver as
especificaes mais detalhadas. Diferentes ambientes clamam por tcnicas
diferentes. Assim, gerentes e engenheiros de requisitos tero que, provavelmente,
desenvolver um misto de habilidades para se adaptarem a diversas circunstncias.
Ns aplicamos inmeras tcnicas em vrias circunstncias, desde documentos de
requisitos rigorosamente precisos, banco de dados personalizado ou repositrio de
requisitos at modelos use-case e mtodos mais formais. No entanto, o lugar
tpico do esforo est na especificao em linguagem natural, escrita com clareza
suficiente para o entendimento de todos os stakeholders, clientes, usurios,
desenvolvedores e testers; mas suficientemente especfico (Os 4 eixos devem ter
uma velocidade mxima de 1 metro/segundo) para permitir a verificao e
demonstrao da conformidade. Antes de comearmos a coletar os requisitos do
sistema, ns iremos inicialmente considerar a natureza dos requisitos que voc
precisar descobrir e definir.
Definio de Requisitos de Software

No Captulo 2, ns apresentamos esta definio de requisito extremamente
simples:
Uma capacidade de software que o usurio precisa a fim de resolver um

problema e atingir seu objetivo.
Uma capacidade de software que deve ser atendida ou possuda por um
sistema ou componentes do sistema para satisfazer um contrato, padro,
especificao, ou outros documentos formalmente impostos.
Requisitos de software so aquelas coisas que o software faz em nome do usurio,

perifrico ou outro sistema. O primeiro lugar a procurar por requisitos de software
ao redor da fronteira do sistema, por coisas que vo para dentro e para fora
do sistema: as interaes do sistema com seus usurios.
Para fazer isso, o mais fcil pensar que o sistema uma caixa-preta e pensar nas
coisas que voc gostaria de ter e definir a descrio completa do que a caixa-preta
faz.
Alm das entradas e sadas, voc tambm precisar pensar em outras
caractersticas do sistema, tais como desempenho e outros tipos de
comportamentos complexos, bem como em outras maneiras de interao do
sistema com o seu ambiente (Figura 231).
Usando uma abordagem similar, Davis (1999) determinou que ns precisamos de
cinco classes principais de coisas para descrever o sistema totalmente:
180
1. Entradas do sistema no apenas o contedo de entrada, mas,

tambm, quando necessrio, os detalhes dos perifricos de entrada, sua
forma, aparncia e aspecto, protocolo de entrada. Como a maioria dos
desenvolvedores sabe, esta rea pode envolver detalhes significativos e
pode estar sujeito volatilidade, especialmente para GUI, multimdia
ou ambientes de Internet.
Figura 231
Elementos do sistema
2. Sadas do sistema uma descrio dos perifricos de sada, tais como

sintetizador de voz ou apresentao visual, que devem ser suportados,
bem como o protocolo e a forma da informao gerada pelo sistema.
3. Funes do sistema o mapeamento das entradas e sadas, e suas
vrias combinaes.
4. Atributos do sistema tais como requisitos no-comportamentais
tpicos como confiabilidade, facilidade de manuteno, disponibilidade
e taxa de transferncia, que os desenvolvedores devem levar em
considerao.
5. Atributos do ambiente do sistema so os requisitos nocomportamentais adicionais como a habilidade do sistema operar
dentro de certas restries de operao, carga e compatibilidade com o
sistema operacional.
Ns usamos esta categorizao h vrios anos e achamos que funciona muito
bem, pois ela nos ajuda a pensar sobre o problema de requisitos de maneira
consistente e completa. De acordo com isso, podemos determinar um conjunto
completo de requisitos de software definindo:
Entradas do sistema
Sadas do sistema
Funes do sistema
Atributos do sistema
Atributos do ambiente do sistema
Alm disso, estaremos aptos a avaliar se uma coisa um requisito de software

confrontando-a com esta definio.
181
Relacionamentos entre Caractersticas e

Viso
Documento da Viso
Requisitos
software
No incio, ns gastamos algum tempo explorando as caractersticas de um

sistema. As caractersticas so descries simples de um comportamento desejado
e til. Agora podemos ver que existe um relacionamento entre caractersticas e
requisitos de software. O documento da Viso descreve as caractersticas na
linguagem do usurio. Os requisitos de software, por sua vez, expressam tais
caractersticas em termos mais detalhados, usando um ou mais requisitos de
software especficos descritos pelos desenvolvedores a fim de fornecer as
caractersticas para o usurio. Em outras palavras, as caractersticas nos ajudam a
entender e a nos comunicar num nvel alto de abstrao, mas provavelmente no
teremos condies de escrever o cdigo a partir dessas descries. Elas esto num
nvel muito alto de abstrao para isso.
No entanto, os requisitos de software, so especficos. Podemos codificar a partir
dos requisitos de software. Os requisitos de software devem ser suficientemente
especficos a ponto de podemos test-los; isto , ns devemos estar aptos a testar
um sistema verificando que ele realmente implementa os requisitos. Por exemplo,
suponha que ns tenhamos desenvolvido um sistema de rastreamento de defeitos
para uma empresa de manufatura em linha de montagem ou para uma empresa de
desenvolvimento de software. A Tabela 231 mostra o relacionamento entre uma
das caractersticas identificadas no documento da Viso e um conjunto de
requisitos associados. Esse mapeamento, e a habilidade de rastre-los entre as
vrias caractersticas e requisitos, forma a espinha dorsal de um conceito muito
importante do gerenciamento de requisitos conhecidos como rastreabilidade,
um tpico que ser bem discutido posteriormente.
Tabela 231 Requisitos associados a uma caracterstica do documento da Viso
Documento da Viso
Caracterstica 63: O sistema de

rastreamento de defeitos ir fornecer
informaes de tendncias para ajudar o
usurio a avaliar o status do projeto
RS63.1 A informao de tendncia ser apresentada

num relatrio contendo um histograma informando
o tempo no eixo-x e o nmero de defeitos
encontrados no eixo-y.
RS63.2 O usurio pode entrar com o perodo da
tendncia na unidade dia, semana ou ms.
RS63.3 Um exemplo do relatrio de tendncia
apresentado na Figura 1, em anexo.
O Dilema de Requisitos: O que versus Como

Como podemos ver, os requisitos dizem aos desenvolvedores o que o seu sistema
deve fazer e devem envolver assuntos relacionados s entradas, sadas, funes e
atributos do sistema, alm dos atributos do ambiente do sistema. Mas existe um
monte de outras informaes que os requisitos no deveriam conter. Em
particular, devemos evitar estipular quaisquer detalhes de projeto ou de
implementao ou informaes associadas ao gerenciamento de projeto; e
devemos evitar informaes sobre como o sistema ser testado. Dessa forma, os
182
requisitos focam o comportamento do sistema, e sua volatilidade depende da

volatilidade do comportamento ou da tendncia de mudanas.
Exclua Informaes do Projeto
Cronograma
Planos de
Projeto
Orament
Testes
Informaes relacionadas ao projeto, tais como cronogramas, plano de

gerenciamento de configuraes, planos de verificao e validao, oramento, e
horrios de turnos, so algumas vezes inseridas no conjunto de requisitos por
convenincia do gerente de projetos. Em geral, isso deve ser evitado, uma vez que
mudanas nessa informao, tal como mudana do cronograma, eleva a
volatilidade e a tendncia desses requisitos de ficarem desatualizados. (Quando
os requisitos so datados, eles se tornam menos confiveis, com maior
probabilidade de serem ignorados). Alm disso, debates inevitveis sobre essas
questes deveriam ficar separados da discusso sobre o que o sistema deve fazer.
Existem diferentes stakeholders envolvidos e cada um serve a propsitos
diferentes.
O oramento pode tambm ter sido colocado como um requisito; no entanto, um
outro tipo de informao que no satisfaz a nossa definio e, assim, no deve
fazer parte dos requisitos gerais do sistema ou do software. O oramento pode se
tornar uma pea importante de informao quando o desenvolvedor precisa
decidir qual estratgia de implementao deve escolher, pois algumas estratgias
podem ser muito caras ou podem levar muito tempo de execuo. Porm,
informaes de oramento no so requisitos; da mesma forma, informaes que
descrevem o como saber que os requisitos foram atendidos procedimentos de
teste ou procedimentos de aceitao tambm no atendem a definio e assim,
no fazem parte da especificao.
Normalmente, achamos conveniente ir um pouco mais alm nesse assunto. Em
muitos casos, til que os escritores de requisitos dem dicas de testes
disponveis para requisitos. A final de contas, os escritores de requisitos tm em
mente um comportamento especfico, e razovel dar a ajuda que for possvel.
Exclua Informaes de Projeto

Projeto
Os requisitos tambm no devem incluir informaes sobre o projeto ou

arquitetura do sistema. Caso contrrio voc pode acidentalmente restringir sua
equipe de prosseguir mesmo que as opes de projeto escolhidas faam sentido
para a sua aplicao. (Espere um pouco, temos que projetar isso dessa maneira!
Isso no um requisito!).
Embora a eliminao dos detalhes de gerenciamento do projeto e de testes da lista
de requisitos seja, de certa forma, simples, a eliminao de detalhes de
projeto/implementao normalmente mais difcil e muito mais sutil. Suponha,
por exemplo, que o primeiro requisito da Tabela 231 tenha sido formulada
como: RS63.1 A informao de tendncia ser apresentada num relatrio, escrito
em Visual Basic, contendo um histograma informando o tempo no eixo-x e o
nmero de defeitos encontrados no eixo-y (veja a figura 232).
183
Figura 232
Diagrama de Pareto
Embora a referncia linguagem Visual Basic parea ser uma violao bastante
grosseira das orientaes recomendadas (pois no representa uma entrada, sada,
funo, ou atributo comportamental), til perguntar: Quem decidiu impor o
requisito de que o histograma deve ser implementado em Visual Basic, e por que
foi tomada essa deciso?. As possveis respostas para esta questo podem ser:
Um dos membros do grupo, com alguma orientao tcnica e que est

definindo o documento da Viso, decidiu que o Visual Basic deveria ser
especificado porque a melhor soluo para o problema.
O usurio pode ter especificado. Sabendo que a tecnologia pode gerar
prejuzos, o usurio quis que a tecnologia VB fosse usada. O usurio no
quer que uma outra tecnologia, uma mais cara ou menos disponvel, fosse
adotada pelas pessoas tcnicas, pois ele sabe que o VB est disponvel e
relativamente barato.
Uma deciso poltica, interna da organizao de desenvolvimento, pode
ter forado o uso do Visual Basic para todas as aplicaes que sero
desenvolvidas. Para assegurar a conformidade e prevenir que esta poltica
no seja ignorada, gerentes insistem em colocar Visual Basic sempre que
possvel nos documentos de requisitos.
Se um desenvolvedor tcnico decidiu inserir uma referncia ao Visual Basic

devido a uma preferncia arbitrria por esta linguagem, bvio que essa
referncia no ocupa um local legtimo na lista de requisitos. Se o usurio
forneceu o requisito, a coisa comea a ficar um pouco mais difcil. Se o cliente se
recusar a pagar pelo sistema amenos que seja escrito em Visual Basic, o melhor a
fazer trat-lo como um requisito, mas um requisito de uma classe especial
chamada restries de projeto, de tal forma a ficar separado dos requisitos
normais. No entanto, uma restrio de implementao que foi imposta equipe
de desenvolvimento. (A propsito, se voc achar que esse exemplo no
realstico, considere um requisito comum que o Departamento de Defesa NorteAmericana impunha em seus contratos de software at o final dos anos 90, onde
se exigia o uso da linguagem Ada na construo de sistemas).
A discusso sobre a referncia do Visual Basic neste exemplo pode ter
obscurecido uma anlise de requisitos mais sutil e talvez a mais importante: Por
que a informao de tendncia tem que ser exibida num relatrio com um
histograma? Por que no um grfico de barras, grfico de setores, ou uma outra
forma de representao? Alm do mais, a palavra relatrio significa um
documento impresso em papel, ou tambm significa que a informao pode ser
exibida na tela do computador? preciso capturar a informao de forma que ela
184
possa ser importada por outros programas ou enviadas para uma extranet
corporativa? As caractersticas descritas no documento da Viso podem ser
sempre preenchidas de vrias maneiras, alguma das quais trazem vrias
conseqncias implementao.
Em muitos casos, a descrio de um problema, a partir do qual um requisito pode
ser formulado, influenciada pela percepo do usurio da potencial soluo
disponvel para resolver o problema. O mesmo verdade para os desenvolvedores
que participam com o usurio na formulao das caractersticas que compem o
documento da Viso e de requisitos. Como um antigo provrbio nos lembra, se
sua nica ferramenta um martelo, todos os seus problemas iro se parecer com
um prego. Mas precisamos ficar atentos nas restries de implementao
desnecessrias e inconsistentes infiltradas nos requisitos; sempre que pudermos,
precisamos remov-las.
Mais sobre Requisitos versus Projeto

At agora, ns falamos dos requisitos de software, decises de projeto e restries
de projeto como se eles fossem entidades distintas que podem ser claramente
diferenciados. Isto , ns estabelecemos ou deixamos implcito que:
Requisitos precedem o projeto

Usurios e clientes, por estarem prximos das necessidades, tomam as
decises sobre os requisitos.
Os tcnicos tomam as decises de projeto porque eles esto melhores
preparados para escolher, entre as vrias opes de projeto, qual opo
atende melhor s necessidades.
Requisitos: O
que o sistema
precisa fazer
Este um bom modelo, e o ponto de partida correto para uma filosofia de

gerenciamento de requisitos. Davis (1993) chamou isso de o paradigma o que
versus como, onde o o que representa os requisitos, ou o o que o sistema
dever fazer, e o como representa o projeto que ser implementado para atingir
este objetivo.
Projeto:
Como o
sistema
ir fazer
Ns contamos essa estria dessa maneira por uma razo. melhor entender os
requisitos antes de projet-los, e muitas restries (use a biblioteca de classes
XYZ para acessar o banco de dados) so decises de projeto importantes
registrados nas propriedades dos requisitos, de tal forma que podemos assegurar
que os alcanamos as razes contratuais, ou talvez uma mais legtima, as razes
tcnicas.
Se no pudermos fazer essa diferenciao de alguma forma, o quadro deve ficar
muito confuso, e no poderemos diferenciar os requisitos das informaes de
projeto. Alm disso, no saberamos quem o responsvel por o que no processo
de desenvolvimento. No pior caso, nossos clientes iro ditar o projeto, e nossos
projetistas iro ditar os requisitos.
Mas uma complicao sutil e ainda mais sria fundamenta esta discusso e
camufla esse simples paradigma que apresentamos. Retornando ao nosso exemplo
de estudo de casos, se a equipe toma uma deciso de projeto, tal como a seleo
de uma tecnologia PC para executar o subsistema UCC do HOLIS,
provavelmente traria algum impacto externo ao usurio. Por exemplo, uma tela de
185
aviso ou de logon seria exibida em algum momento no mundo do usurio. Melhor

ainda, provavelmente ns iramos querer tomar vantagens de algumas
capacidades de entrada de dados do SO, e essas bibliotecas de classe certamente
iria exibir seu comportamento externos ao usurio: (Nota para o tcnico dentro de
voc: Sim, ns podemos escond-lo, mas isto est fora de questo).
Dada as definies fornecidas neste captulo, a questo : Uma vez que o impacto
de uma deciso de projeto causa comportamento externo visvel ao usurio, esta
mesma deciso, a qual afeta claramente entradas e sadas do sistema, agora se
torna um requisito? Podemos argumentar que a resposta correta Sim ou
No, ou at isso no realmente importante, dependendo da interpretao
individual das definies e anlises que fizemos at agora. Mas isso acende um
assunto muito importante, dependendo do entendimento sobre o assunto, torna-se
crtico entender a natureza do prprio processo iterativo. Vamos fazer um exame
mais minucioso.
Iterao de Requisitos e Projeto

Na realidade, as atividades de requisitos versus projeto devem ser iterativos. A
descoberta de requisitos, sua definio e decises de projeto so circulares. O
processo um contnuo vai-e-vem, onde:
os requisitos atuais nos fazem considerar a seleo de

certas opes de projeto,
e
as opes de projeto selecionadas podem iniciar
novos requisitos
Ocasionalmente, a descoberta de uma nova tecnologia pode nos fazer abandonar

vrias suposies sobre o que fazem os requisitos; ns podemos ter descoberto
uma abordagem totalmente nova que dispensa a estratgia antiga. (Vamos
abandonar todo o mdulo cliente / acesso a dados / GUI e substitu-lo por uma
interface baseada em browser). Essa uma excelente fonte, e legtima, de
mudana de requisitos.
Este processo como deveria ser; tentar fazer de outra forma seria uma estupidez.
Por outro lado, existe um srio perigo nisso tudo, pois se no entendermos
verdadeiramente as necessidades do cliente e o cliente no estiver ativamente
engajado no processo de requisitos e por que no, em alguns casos, at entender
as nossas atividades relacionadas ao projeto decises erradas podero ser
tomadas. Quando gerenciado apropriadamente, esta reconsiderao contnua de
requisitos e projeto um processo verdadeiramente fantstico, enquanto a
tecnologia dirigir a nossa habilidade de, continuamente, melhor atender as reais
necessidades de nossos clientes. Essa a essncia do que o gerenciamento
efetivo e iterativo. Mas quando gerenciado inapropriadamente, ficaremos
continuamente seguindo a cauda da tecnologia, resultando num desastre. Ns
nunca falamos que seria fcil.
186
Uma Caracterizao Avanada de Requisitos

A discusso precedente sobre requisitos sugeriu que existiam vrios tipos de
requisitos. Especialmente, ns achamos que seja til pensar em trs tipos de
requisitos, como ilustra a Figura 233:
Requisitos funcionais de software

Requisitos no-funcionais de software
Restries de Projeto
Tipos de
Requisitos
Requisitos de
Software
Requisitos
Funcionais
Figura 233
Restries de
Projeto
Requisitos NoFuncionais
Tipos de Requisitos
Requisitos Funcionais de Software

Como seria de se esperar, requisitos funcionais expressam o como se comporta o
sistema. Esses requisitos so normalmente orientados a ao (Quando o usurio
faz x, o sistema far y). Muitos produtos e aplicaes, concebidas para fazer algo
til, so ricos em requisitos funcionais de software. O software usado para
implementar as principais funcionalidades.
Quando voc estiver definindo requisitos funcionais, voc deve encontrar um bom
equilbrio entre o quo especifico e o quo genrico ou ambguo voc quer que
seja esse requisito. Por exemplo, normalmente no til ter um requisito
funcional declarado na forma: Quando voc pressionar o boto, o sistema
ativado e inicia a operao. Por outro lado, uma declarao de requisito que
ocupe vrias pginas de texto , provavelmente, muito especfico, mas pode estar
correto em vrios casos especiais. Ns iremos retornar a essa discusso no
Captulo 26.
Ns achamos que a maioria dos requisitos funcionais pode ser descrita de forma
declarativa ou na forma de use cases, a qual iremos descrever no prximo
captulo. A experincia nos tem mostrado que uma ou duas sentenas
declarativas de um requisito normalmente a melhor maneira de satisfazer as
necessidades do usurio com um nvel de especificidade que o desenvolvedor
pode lidar.
187
Requisitos No-Funcionais de Software

At aqui neste captulo, a maioria dos exemplos de requisitos envolvia requisitos
comportamentais, ou funcionais, de um sistema, concentrando-se nas entradas,
sadas, e detalhes de processamento. Os requisitos funcionais nos dizem como o
sistema deve se comportar quando apresentado a certas entradas ou condies.
Mas isso no suficiente para descrever todos os requisitos de um sistema. Ns
devemos considerar, tambm, coisas que Grady (1992) chamou de requisitos
no-funcionais:
Usabilidade
Confiabilidade
Desempenho
Suportabilidade
Esses requisitos so usados com maior freqncia para expressar alguns

atributos do sistema ou atributos do ambiente do sistema, elementos de nossa
definio elaborada. Esta classificao conveniente nos ajuda a entender mais
sobre o sistema que estamos construindo. Vamos ver cada um desses atributos em
detalhes.
Usabilidade: importante descrever o quo fcil o sistema pode ser aprendido e
operado pelos pretensos usurios. Alm disso, podemos precisar identificar as
vrias categorias de usurios: iniciantes, usurios normais, usurios experientes,
usurios analfabetos, usurios que no so fluentes na linguagem nativa dos
usurios normais, entre outros. Se voc quer que o seu cliente revise e participe
desta discusso o que seria muito bom voc tem que estar ciente de que,
independentemente do requisito que voc esteja escrevendo nesta rea, ter que
ser escrito em linguagem natural; voc no deveria querer uma mquina de estado
finito para descrever a usabilidade!
Desde que a usabilidade tende a estar nos olhos de quem a v, como faremos para
especificar esse conjunto de requisitos to confuso? Seguem algumas sugestes.
Especifique o tempo requerido de treinamento para o usurio se tornar

ligeiramente produtivo apto a realizar tarefas simples e
operacionalmente produtivo apto para realizar tarefas normais do dia-adia. Como pode se notar, podemos precisar descrever posteriormente em
termos de usurios novatos, aquele que nunca viu um computador antes,
at usurios normais e usurios especialistas.
Especificar o tempo de tarefas
188

GerenciamentoRequisitos PDF

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

GerenciamentoRequisitos PDF

Enviado por

Direitos autorais:

Formatos disponíveis

1

UNIFIED PROCESS & UNIFIED MODELING LANGUAGE

LABORATRIO DE ENGENHARIA DE SOFTWARE

LABORATRIO DE ENGENHARIA DE SOFTWARE

Traduo e Reviso Tcnica

Aplicao das Tcnicas de Gerenciamento de Requisitos ..................................................................13

O Mapa da Mina ...........................................................................................................................................................14

HABILIDADE DE EQUIPE 1 .................................................................................................................................23

Passo 2: Entender a causa raiz do problema o problema por detrs do problema...............28

Passo 3: Identificar Stakeholders e Usurios..............................................................................................30

Da Modelagem de Negcio aos Modelos de Sistemas ............................................................................42

ENGENHARIA DE SISTEMAS DE SOFTWARE INTENSIVOS ...........................................................................44

Alocao de Requisitos na Engenharia de Sistemas...............................................................................47

HOLIS: O Sistema, Atores e Stakeholders.....................................................................................................56

SUMRIO DA HABILIDADE DE EQUIPE 1.......................................................................................................61

A Sndrome das Runas Desconhecidas......................................................................................................65

A Importncia do Contexto da Soluo ..........................................................................................................74

Uma Nota sobre Questionrios ...........................................................................................................................79

Assegurando a Preparao dos Stakeholders Corretos.........................................................................81

Papel do Facilitador ..................................................................................................................................................84

REDUO DE IDIAS .......................................................................89

Brainstorming Presencial .......................................................................................................................................90

Brainstorming Baseado em Web.........................................................................................................................95

SUMRIO DA HABILIDADE DE EQUIPE 2.....................................................................................................121

SUMRIO DA HABILIDADE DE EQUIPE 3.....................................................................................................147

O Caso de Estudos ...................................................................................................................................................161

O que fazer, O que fazer ......................................................................................................................................175

SUMRIO DA HABILIDADE DE EQUIPE 4.....................................................................................................176

O Problema da Pedra (por Ed Yourdon)

m de meus estudantes resumiu o assunto discutido neste volume como o

pedra, fornecedores, concorrncia, e todas as outras informaes que so necessrias para

Vale ressaltar que, estamos discutindo aplicaes de software neste volume, no

Assim, diagramas tcnicos associados ao sistema de software tambm podem ser

ma das 6 Melhores Prticas da Engenharia de Software, Gerenciamento de

Uma capacidade que o software que o usurio precisa a fim de resolver um

O que o Gerenciamento de Requisitos?

Uma abordagem sistemtica de elucidar, organizar e documentar os requisitos do sistema; e

Qualquer um que j tenha se envolvido com o desenvolvimento de sistemas de

Mas o que isso tm a ver com o gerenciamento de requisitos? O tamanho e a

Quais membros da equipe de projeto so responsveis pelo requisito (#278), e

As atividades associadas e que respondem a estas e outras questes so as que constituem

Aplicao das Tcnicas de Gerenciamento de

Sistemas de informao e outras aplicaes desenvolvidas para serem utilizadas

A natureza das aplicaes desenvolvidas nestes trs tipos de sistemas extremamente

Isso uma necessidade ou um requisito?

Dentro do domnio do problema, usamos um conjunto de habilidades de equipe como o

estivermos aqui, precisaremos adquirir um entendimento do problema e as necessidades

Necessidades dos Stakeholders

tambm de nossa responsabilidade entender as necessidades dos usurios e de outros

Caminhando em Direo ao Domnio da Soluo

O carro ter quadros de potncia

So descries simples, na linguagem do usurio, as quais sero utilizadas como rtulos

Tendo estabelecido o conjunto de caractersticas em comum acordo com o cliente, ns

Uma Introduo aos Use Cases

Figura 2-1 Viso global dos domnios do problema/soluo

s pessoas optam pela profisso de desenvolver software por razes variadas.

Desenvolvimento de Software como uma

a histria do desenvolvimento de software revela o aumento em escala. Inicialmente, alguns

Habilidades da Equipe de Requisitos para o Gerenciamento

Na Habilidade de Equipe 1, Analisando o Problema, ns desenvolvemos um

Membros da Equipe possuem Habilidades Distintas

A Organizao da Equipe de Software

equipe hipottica considerando uma equipe de desenvolvimento de software existente no