Gerenciamento de Requisitos

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
SUMRIO DA HABILIDADE DE EQUIPE 3.....................................................................................................147 HABILIDADE DE EQUIPE 4 ...............................................................................................................................148 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
SUMRIO DA HABILIDADE DE EQUIPE 4.....................................................................................................176 HABILIDADE DE EQUIPE 5 ...............................................................................................................................177 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 Estar
Sala de Jantar
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.
U
Definies

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

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.
NVes eed
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. 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.
Features
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

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.
Controlar lmpada
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.
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.
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.
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
Eric Diretor de Marketing
Jack Lder de QA
Michel Arquiteto
Pete Gerente de Desenvolvimento de Software
Cathy Gerente de Produto
Equipe de Teste
Louise Lder de Doc
John Lder de Software
Russ Lder de Software
Mike Lder de Software
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
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.
Equipes de desenvolvimento tendem a avanar continuamente, fornecendo solues baseadas em entendimentos inadequados do problema a ser resolvido.
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. 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.
O objetivo da anlise de problemas adquirir melhor entendimento do problema a ser resolvido antes de iniciar o desenvolvimento.
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 Elementos O problema afeta devido Os benefcios desse Formato da Declarao do problema 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

Dados de qualidade demonstram que muitas causas razes no valem a pena serem corrigidas.
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 40 30 20 10 0 Contribuies danos no transporte devolues mercadoria obsoleta defeitos de manufatura outros
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 Elementos O problema afeta devido Os benefcios desse Declarao do problema dos pedidos de venda 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 Outros Stakeholders Diretor de SI e equipe de desenvolvimento Diretor Financeiro Gerente de Produo
Usurios Vendedores Supervisor de Vendas Controle da Produo Pessoal de Faturamento
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.
entradas
Sistema
sadas
Ns dividimos o mundo em duas classes: 1. Nosso sistema 2. Coisas que interagem com o nosso sistema
Figura 43
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
Usurios
Nossa soluo
E/S
Outros sistemas
Figura 44
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
Vendedor
Novo Sistema de Pedidos

Sistema legado com os dados sobre preos
Faturista
Transportadora
Gerente de Produo
Figura 45
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 Fonte Econmica
Potenciais restries do sistema 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? 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? A soluo ser construda sobre o sistema existente? Devemos manter compatibilidade com a soluo existente? Que sistemas operacionais e ambientes devem ser suportados? Existem restries ambientais ou legais? Existem requisitos de segurana? Estamos restritos a algum padro? O planejamento est definido? Estamos restritos aos recursos existentes? Podemos utilizar trabalho externo? Podemos aumentar os recursos temporrios ou permanentes?
Poltica Tcnica
Sistmica
Ambiental
De planejamento e recursos
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 Fonte Operacional
Restries, fontes e lgica para o sistema de pedidos Restrio Uma cpia exata dos dados dos pedidos de venda deve permanecer na base de dados legado por um ano. A aplicao no deve utilizar mais que 20 megabytes da memria RAM do servidor. O sistema deve ser desenvolvido no servidor existente; novos hardwares clientes para usurios sero fornecidos. Recursos fixos de pessoal; sem terceirizao. Ser utilizada a nova metodologia orientada a objetos. Lgica O risco de perda de dados muito grande; ns precisamos executar em paralelo durante um ano. Existe limitao de memria no servidor. Controle de custos e conservao do sistema existente.
Sistema e SO
Oramento de equipamentos
Oramento de pessoal
Custos operacionais fixos de acordo com o atual oramento. Ns acreditamos que esta tecnologia ir aumentar a produtividade e elevar a confiabilidade do software.
Tecnologia obrigatria
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

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.
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.
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
Subsistema B
Figura 62
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 Subsistema A-2 Subsistema B
Figura 63
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 Interface de A-para-B Figura 64 Interface entre dois subsistemas
Subsistema B
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

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.
Na indstria, a inteligncia, antes existente nos componentes de hardware, foram alocadas aos componentes de software.
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: 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.
Agora, muitos sistemas devem sofrer otimizaes de software, no de hardware.
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 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.
Elementos O problema afeta devido Os benefcios desse
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
Proprietrio
Lm padas
Servios da Lum enations
Recebedor de Em ergncias TBD
Figura 66
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 Comentrios Clientes diretos da Lumenations. Clientes dos Clientes da Lumenations: o contratado geral responsvel pela construo da residncia. Responsvel pela instalao e suporte.
Nome O Distribuidor Externo Construtores Eletricistas Contratados Equipe de Desenvolvimento Interno Gerente de Marketing/Produto Gerente Geral da Lumenations
Equipe da Lumenations. Ser representado pela Cathy, gerente de produto. 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
HOLIS 2000
Proprietrio / Programador
Programador PC (opcional)
Figura 67
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
Chave de Controle
Figura 68
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
Figura 69
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.
Lm padas
HOLIS 2000

Chave de Controle
Figura 610
Subsistema Unidade Controle Central com seus atores
59
Tabela 62 #ID 1
Restries do projeto HOLIS Lgica A nica oportunidade de lanamento do produto neste ano. Ns acreditamos que estas tecnologias fornecem aumento de produtividade e produzem sistemas robustos.
Nome A verso 1.0 dever ser liberada para manufatura em 5 de Janeiro de 2000. A equipe deve adotar a modelagem UML, mtodos baseados em OO, e o Processo de Desenvolvimento Unificado.
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. O subsistema de microprocessamento da Unidade de Controle Central deve ser copiado da diviso profissional de projetos de sistemas de iluminao avana (ALSP). Apenas o Programador PC dever ser compatvel com o Windows 98. Contratar no mximo dois empregados, de tempo integral, somente aps o trmino da fase de concepo, quando as habilidades necessrias ao projeto estaro determinadas. O microprocessador KCH5444 deve ser usado na Chave de Controle. Aquisies de componentes de software possvel, contanto que no exista nenhuma obrigao de pagamentos contnuos de royalty pela empresa. Para obter pedidos de distribuidores do Q1 FY 2000.
um projeto existente e uma pea existente em estoque.
Faz parte do escopo de gerenciamento para a liberao da verso 1.0. Contratao mxima permitida para expanso da equipe.
J em uso pela companhia.
Nenhum custo de longo prazo poder causar impacto no custo de software.
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. 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.
Needs Problema
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 Problema
A sndrome Usurio e o Desenvolvedor Soluo Reconhecer e apreciar o usurio como especialista do domnio; tentar tcnicas alternativas de comunicao e elucidao. Fornecer tcnicas de elucidao alternativas o quanto antes: storyboarding, role playing, prottipos descartveis, entre outros. Coloque o analista no lugar do usurio. Faa com que o analista interprete o papel do usurio durante uma hora ou um dia. Sim, faz parte da natureza humana, ento vamos continuar com o programa.
Usurios no sabem o que querem, ou sabem o que querem, mas no sabem dizer. Usurios pensam que sabem o que querem at que os desenvolvedores lhes digam o que eles disseram que queriam. Analistas pensam que entenderam o problema do usurio melhor do que os prprios usurios. Todos acreditam que todos esto politicamente motivados.
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 Features
Necessidade?
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 Exemplo de uma Caracterstica (Feature) 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. 70
Domnio da Aplicao Sistema de controle de elevador Sistema de controle de estoque 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
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 Estado
Atributos de caractersticas Descrio
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: Por que esse problema existe? Agora, como resolv-lo? 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).
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).
75
Para cada problema sugerido, pergunte: Esse um problema real? Quais so as razes deste problema? Como voc gostaria de resolv-lo? 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: 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
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.
1 2 3 etc.
O Estudo de Caso
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
1 2 3 etc.
Needs do usurio do HOLIS
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: 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.
Se possvel, tenha um facilitador que no seja da equipe para executar o workshop.
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 8:00 8:30 8:30 10:00 Item de Agenda Introduo Contexto Descrio 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.
10:00 12:00 12:00 13:00 14:00 15:00
Brainstorning Almoo Definio da caracterstica
15:00 16:00 16:00 17:00
Reduo e priorizao de idias Fechamento
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
1 Ofensa gratuita e deliberada
Regra: Inicialmente, cada participante recebe um cupom grtis quando chegar atrasado. Depois disso, o participante contribui com $1 de multa.
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 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.
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.
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 No se permitem crticas ou debates. Solte a imaginao. Gere quantas idias quanto forem possveis. Mude e combine idias.
Figura 111
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 Automao de iluminao residencial Caracterstica Obtida no Brainstorming Configurao da iluminao automtica Definio da Caracterstica O proprietrio pode criar, previamente, cronogramas para certos eventos com base nas horas do dia. Rpido o suficiente para que o tempo no interfira nas operaes normais. Todas as partes registradas sero notificadas via e-mail quando algo for mudado.
Sistema de entrada de pedidos de venda Sistema de rastreamento de defeitos
Rpido
Notificao automtica
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
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
Resultados da votao acumulativa: Idia 1 $380 Idia 2 $200 Idia 3 $180 Idia 4 $140 Idia 5 ... . . . Idia 27 ...
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 Eric Cathy Pete Papel Facilitador Participante Participante Ttulo Diretor de Marketing Gerente de Projetos do HOLIS 2000 Gerente de Desenvolvimento de Software Defensor do projeto Responsvel pelo desenvolvimento do HOLIS 2000 Perspectiva do proprietrio Perspectiva do proprietrio Perspectiva do proprietrio Diretor Executivo da empresa Equipe de Automao Gerente da EuroControls Presidente da Krystel Eletric Maior distribuidor da Lumenations Distribuidor Europeu da Lumenations Empreiteira Eltrica local Comentrios
Jennifer Elmer Gene John
Participante Participante Participante Participante
Raquel Betty David Vrios membros
Participante Participante Participante Observador
Presidente da Construtor de casas Rosewind Construction personalizadas 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

Regras do Workshop
Cathy, Gerente de Produto
Perspectiva dos proprietrios David, Presidente da Rosewind Construction
Observadores Facilitador
Eric, Diretor de Marketing
Participantes
Emily, Gerente Geral Raquel, Gerente da EuroControls (Distribuidor Europeu da Lumenations) John, Gerente Betty da Krystel Exucutivo da Eletric Automation Equip (maior distribuidor da Lumenations)
Membros disponveis da equipe de desenvolvimento HOLIS
Figura 112
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 23 Cenas de iluminao personalizadas 16 Configurao do tempo automtico de iluminao, etc. 4 Caractersticas de segurana pr-definidas, p.ex., lmpadas e alarmes 6 100% de confiabilidade 8 Fcil de programar, unidade de controle no-PC 1 Facilidade de programar as estaes de controle 5 Configurao de ausncias 13 Toda lmpada pode ser apagada 9 Usar meu prprio PC para programar 14 Caractersticas de entretenimento 20 Portas da garagem fechadas 19 Ligar automaticamente as lmpadas quando a porta for aberta 3 Interface com o sistema de segurana residencial 2 Facilidade para instalar 18 Ligar automaticamente as luzes quando algum bate a porta 7 Ligar e desligar instantneo 11 Poder dirigir cortinas, sombras, bomba dgua e motores 15 Controlar a iluminao via telefone 10 Interface com o sistema de automao residencial 22 Modo gradual: aumento ou reduo da luminosidade lentamente 26 Estao de controle principal 12 Facilidade de expanso quando remodelado 25 Interface de usurio internacionalizado 21 Interface com o sistema de udio/vdeo 24 Restaurao aps falha no fornecimento de energia eltrica 17 Controle HVAC 28 Ativao via voz 27 Apresentao no web site do usurio Votos 121 107 105 90 88 77 77 74 73 66 66 55 52 50 50 44 44 44 43 34 31 25 24 23 23 22 7 4
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 Screen shots Ativo Apresentao de slides Prototipao Regras de negcio Animao Demonstraes reais Interativo
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. 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.
Controlar lmpada
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 Criar Cena de Iluminao Personalizada Iniciar Emergncia Controlar Iluminao Trocar Programao Programar Remotamente Descrio Residentes criam uma cena de iluminao personalizada Residentes iniciam ao de emergncia Residentes ligam ou desligam as lmpadas, ou reduzem a intensidade desejada de luz Mudar ou configurar as aes para um particular boto/interruptor O provedor de servios de iluminao realiza remotamente a programao com base nas solicitaes do residente Proprietrios configuram a ausncia por um longo perodo O proprietrio programa a seqncia de iluminao automtica com base no tempo Atores Residente, Lmpada Residncia Residentes, Lmpadas Proprietrio / programador Servios de Iluminao Proprietrio / programador Proprietrio / programador
Tirar Frias Configurar a Seqncia de Tempo
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. 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
Experimente!
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. 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.
Bob (Unidade de Controle Central):
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 Estratgia de investimento? Descartvel
Estreita
Vertical
Larga Evolucionrio Distncia do risco (a) Estreita
Horizontal Vertical
Requisitos Risco de projeto? Descartvel
Larga Estreita Vertical
Horizontal
Distncia do risco Estratgia de investimento?
Tecnolgico
Larga Distncia do risco (b) Estreita
Horizontal Vertical
Evolucionrio
Larga
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. 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.
A quantidade de informaes que devemos gerenciar aumenta rapidamente conforme nos movemos para baixo da pirmide.
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
Subsistema
Subsistema A-1
Subsistema A-2
Subsistema
Subsistema
Figura 161
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 requisitos do sistema para o Subsistema B
Especificao dos requisitos do sistema para o Subsistema C
Especificao dos requisitos do sistema para o Subsistema A-1
Especificao dos requisitos do sistema para o Subsistema C-1
Figura 162
Hierarquia de especificaes resultante do projeto de sistemas
Especificao geral dos Requisitos do sistema
Especificao dos requisitos do sistema para o Subsistema A
Especificao dos requisitos do sistema para o Subsistema B
Especificao dos requisitos do sistema para o Subsistema C
Subsistema A-2 Especificao dos requisitos de hardware
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 Modelo use-case comuns famlia
Viso SRS
Viso SRS
Viso SRS
Figura 164
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
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.
E
Viso
Documento da Viso para o meu projeto
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. 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 Features
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: 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. 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.
Escopo 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 Benefcio 1 Benefcio 2 Benefcio 3 Caractersticas Suportadas 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
Introduo Usurios e mercado Caractersticas do 1.0 Outros requisitos Caractersticas futuras
Figura 172
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

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
Viso
Documento da Viso v2.0
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.
Introduo + Caractersticas da verso 1.0 + Caractersticas futuras
Viso
Viso 1.0
Ponto de partida para o entendimento
Viso
Viso Delta 2.0
+ Novas caractersticas + Caractersticas removidas + Caractersticas futuras
=
Figura 173
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
Eric Diretor de Marketing
Jack Lder de QA
Michel Arquiteto
Pete Gerente de Desenvolvimento de Software
Cathy Gerente de Produto
Equipe de Teste
Louise Lder de Doc
John Lder de Software
Russ Lder de Software
Mike Lder de Software
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.
Recursos
Escopo
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 Caracterstica 1: Suporte a BD relacional externo Caracterstica 4: Interface para releases de novos SO Caracterstica 6: Importao de dados externos por estilo Caracterstica 3: Habilidade de clonar um projeto Caracterstica 2: Segurana multiusurio Caracterstica 5: Assistente de novos projetos Caracterstica 7: Implementar ferramenta de dicas Caracterstica 8: Integrar com o subsistema de gerenciamento de verses Prioridade Crtica Crtica Crtica Importante Importante Importante til 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? requisitos ou o seu projeto.
Equipe de Desenvolvimento: Ns no sabemos. Ns ainda no temos quaisquer 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 Caracterstica 1: Suporte a BD relacional externo Caracterstica 4: Interface para releases de novos SO Caracterstica 6: Importao de dados externos por estilo Caracterstica 3: Habilidade de clonar um projeto Caracterstica 2: Segurana multiusurio Caracterstica 5: Assistente de novos projetos Caracterstica 7: Implementar ferramenta de dicas Caracterstica 8: Integrar com o subsistema de gerenciamento de verses Prioridade Crtica Crtica Crtica Importante Importante Importante til til Esforo Mdio Alto Baixo Alto Baixo Baixo Baixo 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 Caracterstica 1: Suporte a BD relacional externo Caracterstica 4: Interface para releases de novos SO Caracterstica 6: Importao de dados externos por estilo Caracterstica 3: Habilidade de clonar um projeto Caracterstica 2: Segurana multiusurio Caracterstica 5: Assistente de novos projetos Caracterstica 7: Implementar ferramenta de dicas Caracterstica 8: Integrar com o subsistema de gerenciamento de verses Prioridade Crtica Crtica Crtica Importante Importante Importante til til Esforo Mdio Alto Baixo Alto Baixo Baixo Baixo Alto Risco Baixo Mdio Alto Mdio Alto Baixo 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 Prioridade: Crtica Esforo: Alto Risco: Alto Prioridade: Crtica Esforo: Alto Risco: Baixo Prioridade: Crtica Esforo: Baixo Risco: Baixo Considere alocar recursos s por segurana, ou postergue essa alocao para uma prxima oportunidade. Concentre-se nos provveis item cujos recursos so limitados e crticos; aloque recursos imediatamente. Considere Alerta! Estabelea imediatamente uma estratgia de reduo de riscos; aloque recursos; concentre-se na sua viabilidade arquitetural.
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 Caracterstica 1: Suporte a BD relacional externo Caracterstica 4: Interface para releases de novos SO Caracterstica 6: Importao de dados externos por estilo Caracterstica 3: Habilidade de clonar um projeto Prioridade Crtica Crtica Crtica Importante Esforo Mdio Alto Baixo Mdio Risco Baixo Mdio Alto Mdio
Baseline (as caractersticas acima desta linha so caractersticas acordadas com o cliente) Caracterstica 2: Segurana multiusurio Caracterstica 5: Assistente de novos projetos Caracterstica 7: Implementar ferramenta de dicas Caracterstica 8: Integrar com o subsistema de gerenciamento de verses Importante Importante til til Baixo Baixo Baixo Alto Alto Baixo 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 23 16 4 6 8 1 5 13 9 14 20 19 3 2 18 7 11 15 10 22 26 12 25 21 24 17 28 27 Caractersticas Cenas de iluminao personalizadas Configurao do tempo automtico de iluminao, etc. Caractersticas de segurana pr-definidas, p.ex., lmpadas e alarmes 100% de confiabilidade Fcil de programar, unidade de controle no-PC Facilidade de programar as estaes de controle Configurao de ausncias Toda lmpada pode ser apagada Usar meu prprio PC para programar Caractersticas de entretenimento Portas da garagem fechadas Ligar automaticamente as lmpadas quando a porta for aberta Interface com o sistema de segurana residencial Facilidade para instalar Ligar automaticamente as luzes quando algum bate a porta Ligar e desligar instantneo Poder dirigir cortinas, sombras, bomba dgua e motores Controlar a iluminao via telefone Interface com o sistema de automao residencial Modo gradual: aumento ou reduo da luminosidade lentamente Estao de controle principal Facilidade de expanso quando remodelado Interface de usurio internacionalizado Interface com o sistema de udio/vdeo Restaurao aps falha no fornecimento de energia eltrica Controle HVAC Ativao via voz Apresentao no web site do usurio Votos 121 107 105 90 88 77 77 74 73 66 66 55 52 50 50 44 44 44 43 34 31 25 24 23 23 22 7 4 Esforo Mdio Baixo Baixo Alto Alto Mdio Baixo Baixo Alto Baixo Baixo Baixo Alto Mdio Mdio Alto Baixo Alto Alto Mdio Alto Mdio Mdio Alto N/A Alto Alto Mdio Risco Baixo Baixo Alto Alto Mdio Mdio Mdio Baixo Mdio Baixo Baixo Alto Alto Mdio Mdio Alto Baixo Alto Alto Baixo Alto Mdio Alto Alto N/A Alto Alto 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 23 16 4 6 8 1 5 13 9 25 14 7 Caractersticas Cenas de iluminao personalizadas Configurao do tempo automtico de iluminao, etc. Caractersticas de segurana pr-definidas, p.ex., lmpadas e alarmes 100% de confiabilidade Fcil de programar, unidade de controle no-PC Facilidade de programar as estaes de controle Configurao de ausncias Toda lmpada pode ser apagada Usar meu prprio PC para programar Interface UCC internacionalizado Caractersticas de entretenimento Ligar e desligar instantneo Votos 121 107 105 90 88 77 77 74 73 24 66 44 Esforo Mdio Baixo Baixo Alto Alto Mdio Baixo Baixo Alto Mdio Baixo Alto Risco Baixo Baixo Alto Alto Mdio Mdio Mdio Baixo Mdio Mdio Baixo Alto Apenas uma configurao suportada em na verso 1.0 Conforme combinamos com o distribuidor europeu (No aplicvel, includa na 23) Tornar o investimento inteligente Comentrios de Marketing To flexvel quanto possvel To flexvel quanto possvel Fazer mais pesquisas de mercado Atingir tanto quanto possvel os 100% Fornecer controlador dedicado To fcil quanto possvel com o esforo mdio
Baseline obrigatrio v1.0: Todas as coisas acima desta linha devem ser includas ou iremos atrasar a release 20 2 11 22 Portas da garagem fechadas Facilidade para instalar Poder dirigir cortinas, sombras, bomba dgua e motores Modo gradual: aumento ou reduo da luminosidade lentamente 66 50 44 34 Baixo Mdio Baixo Mdio Baixo Mdio Baixo Baixo Talvez tenha pouco impacto no software Nvel bsico de esforo Talvez tenha pouco impacto no software 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 19 18 15 10 26 12 25 21 24 17 28 27 Interface com o sistema de segurana residencial Ligar automaticamente as lmpadas quando a porta for aberta Ligar automaticamente as luzes quando algum bate a porta Controlar a iluminao via telefone Interface com o sistema de automao residencial Estao de controle principal Facilidade de expanso quando remodelado Interface de usurio internacionalizado Interface com o sistema de udio/vdeo Restaurao aps falha no fornecimento de energia eltrica Controle HVAC Ativao via voz Apresentao no web site do usurio 52 55 50 44 43 31 25 24 23 23 22 7 4 Alto Baixo Mdio Alto Alto Alto Mdio Mdio Alto N/A Alto Alto Mdio Alto Alto Mdio Alto Alto Alto Mdio Alto Alto N/A Alto Alto 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 Tempo Prazo final
Operao e manuteno
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 Anlise de riscos Anlise de riscos Anlise de riscos Prottipo 3 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 Validao de requisitos Projeto de produto de software Projeto detalhado Prottipo operacional Avaliar alternativas: Identificar e resolver riscos
Reviso Plano de requisitos, plano de ciclo de vida
Codificao
Teste de unidade Validao e verificao do projeto Teste e integrao Teste de aceitao Implementao Desenvolver, verificar o produto do prximo nvel
Planejar prximas fases
Figura 223
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

Plano de requisitos
Projeto detalhado Codificao Teste de unidade Integrao
Conceitos Validao de requisitos Requisito de software Prottipo 1
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
Tempo
Elaborao
Construo
Transio
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 Elabora Constru Transi
Iter li
...
Release
Iter h ( Relea
...
Iter d
Release
Iter d
Release
...
Iter t
Release Release
...
Release
Release
Figura 226
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
Domnio do Problema Rastreabilidade Espao da Soluo
Features
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 Requisitos de Software

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 Requisitos de Software 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

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.
Cronograma
Planos de Projeto
Orament
Testes
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. 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
Projeto: Como o sistema ir fazer
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
Restries de Projeto
Requisitos Funcionais
Requisitos NoFuncionais
Figura 233
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

Gerenciamento de Requisitos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Gerenciamento de Requisitos

Загружено:

Авторское право:

Доступные форматы

1

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

Traduo e Reviso Tcnica

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

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

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

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

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

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

CAPTULO 8.............................................................................................................................................................68 AS CARACTERSTICAS (FEATURES) DE UM PRODUTO OU SISTEMA ........................................................68

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

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

CAPTULO 11...........................................................................................................................................................89 BRAINSTORMING E A REDUO DE IDIAS .......................................................................89

Brainstorming Baseado em Web.........................................................................................................................95 O Caso de Estudos: O Workshop de Requisitos do HOLIS 2000.........................................................95

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

CAPTULO 22.........................................................................................................................................................168 GERENCIAMENTO DE ESCOPO E MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 168

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

O Problema da Pedra (por Ed Yourdon)

Introduo ao Gerenciamento de Requisitos

O que o Gerenciamento de Requisitos?

Aplicao das Tcnicas de Gerenciamento de Requisitos

Necessidades dos Stakeholders

Caminhando em Direo ao Domnio da Soluo

Uma Introduo aos Use Cases

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

Desenvolvimento de Software como uma Atividade de Equipe

Habilidades da Equipe de Requisitos para o Gerenciamento Efetivo de Requisitos

Membros da Equipe possuem Habilidades Distintas

A Organizao da Equipe de Software

Escopo do Caso de Estudo

A Equipe de Desenvolvimento do Software HOLIS

Brooke Diretor de Engenharia

Eric Diretor de Marketing

Pete Gerente de Desenvolvimento de Software

Cathy Gerente de Produto

Louise Lder de Doc

John Lder de Software

Russ Lder de Software

Mike Lder de Software

Os Cinco Passos da Anlise do Problema

Passo 1: Chegar ao Acordo sobre a Definio do Problema

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

Diagrama espinha de peixe de causa raiz

Atacando a Causa Raiz

Grfico de Pareto das causas razes

Passo 3: Identificar Stakeholders e Usurios

Usurios Vendedores Supervisor de Vendas Controle da Produo Pessoal de Faturamento

Passo 4: Definir a Fronteira da Soluo Sistmica

Nossa nova soluo

Novo Sistema de Pedidos

Passo 5: Identificar as restries que sero impostas soluo

Tabela 44 Fonte Econmica

Tabela 45 Fonte Operacional

Propsito da Modelagem de Negcio

Usando Tcnicas de Engenharia de Software para Modelar Negcios

Escolhendo a Tcnica Correta

A Linguagem de Modelagem Unificada

Modelagem de Negcio Usando UML

Modelo use-case de negcio

Modelo de objetos de negcio