Colaborao Colaborao no significa necessariamente que os requisitos so definidos por uma comisso.

Em muitos casos, os interessados colaboram dando seu ponto de vista dos requisitos, mas um forte campeo do projeto (por exemplo, o gerente de negcio ou o tcnico snior) pode tomar deciso final sobre quais os requisitos que passam pelo corte. Formulao das Primeiras questes J mencionamos que as questes formuladas na concepo do projeto devem ser livres de contexto. O primeiro conjunto de questes livres de contexto focaliza o cliente e outros interessados, os objetivos globais e os benefcios. Por exemplo, o engenheiro de requisitos poderia perguntar: Quem est por trs da solicitao deste trabalho? Quem vai usar a soluo? Qual ser o benefcio econmico de uma soluo bem-sucedida? H outra fonte para a soluo que voc necessita?

Essas questes ajudam a identificar todos os que tem interesse no software a ser construdo. Alm disso, as questes identificam o benefcio mensurvel de uma implementao bem-sucedida e possveis alternativas para o desenvolvimento de software sob encomenda. O conjunto de questes a seguir possibilita equipe de software obter um melhor entendimento do problema e permite que o cliente verbalize sua percepo de uma soluo: Como voc caracteriza boas sadas, que seriam geradas por uma soluo bem-sucedida? Que problema (s) essa soluo enfrentaria? Voc pode demonstrar (ou descrever) o ambiente de negcios no qual a soluo ser usada? Tpicos ou restries especiais de desempenho afetaro o modo pelo qual a soluo abordada? Voc a pessoa certa para responder a essas questes? Suas respostas so oficiais? As questes so relevantes ao problema que voc tem? Muitas questes esto sendo formuladas? Algum mais pode fornecer informaes adicionais? Devemos perguntar mais alguma coisa? Essas questes (e outras) vo ajudar a quebrar o gelo e iniciar a comunicao, que essencial para o levantamento bem-sucedido. Entretanto, uma reunio de perguntas e respostas no uma abordagem que tem sido sempre um sucesso.

Coleta colaborativa de requisitos A fim de encorajar uma abordagem colaborativa e orientada a equipes para a coleta de requisitos, uma equipe de interessados e desenvolvedores trabalha em conjunto para identificar o problema, propor elementos da soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo. Muitas abordagens diferentes da coleta colaborativa de requisitos tm sido propostas. Cada uma faz uso de um cenrio ligeiramente diferente, mas todas aplicam alguma variante das seguintes diretrizes bsicas: As reunies so conduzidas e assistidas por engenheiros de software e por clientes (juntamente com outros interessados). So estabelecidas regras para a preparao e a participao. sugerida uma agenda suficientemente formal para cobrir todos os pontos importantes, porm suficientemente informal para encorajar o livre fluxo de idias. Um facilitador (que pode ser um cliente, um desenvolvedor ou uma pessoa de fora) controla a reunio. Um mecanismo de definio usado (podem ser folhas de rascunho, flip chart ou papel auto-adesivo, ou um quadro de avisos eletrnico, salas de conversa ou frum virtual). A meta identificar o problema, propor elementos da soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo em uma atmosfera que propicie que a meta seja alcanada. Para entender melhor o fluxo de eventos medida que eles ocorrem, vamos ver um cenrio resumido que delineia a sequncia de eventos que provocam a reunio de coleta de requisitos e que ocorrem durante e aps a reunio. Durante a concepo , perguntas e respostas bsicas estabelecem o escopo do problema e a percepo geral de uma soluo. Como resultado dessas reunies iniciais, os interessados redigem uma solicitao de produto de uma ou duas pginas. So selecionadas um local, data e hora de reunio e escolhido um facilitador. Membros da equipe de software e de outros departamentos interessados so convidados a comparecer. A solicitao de produto distribuda a todos os participantes antes da data da reunio. Enquanto rev a solicitao nos dias que precedem a reunio, solicitado a cada participante que faa uma lista dos objetos que fazem parte do ambiente que cerca o sistema, outros objetos que devem ser produzidos pelo sistema e objetos que so usados pelo sistema para desempenhar suas funes. Alm disso, solicitado a cada participante que faa outra lista de servios (processos ou funes) que manipulam ou interagem com os objetos. Finalmente, so tambm desenvolvidas listas de restries (por exemplo, custo, tamanho e regras de negcio) e de critrios de desempenho (velocidade, preciso). Os participantes so informados de que no se espera que as listas sejam exaustivas, mas espera-se que elas reflitam a percepo do sistema de cada um. Como exemplo, considere um extrato de documento de pr-reunio redigido por uma pessoa de marketing envolvida no projeto CasaSegura. Essa pessoa

escreve a seguinte narrativa da funo de segurana residencial que deve ser parte do CasaSegura.
Nossa pesquisa indica que o mercado de sistemas de gesto residencial est crescendo a uma taxa de 40% ao ano. A primeira funo do CasaSegura que levaremos ao mercado deve ser funo de segurana residencial. A maioria das pessoas est familiarizada com sistemas de alarme assim essa seria uma venda fcil. A funo de segurana residencial protegeria contra e/ou reconheceria vrias situaes indesejveis tais como entrada ilegal, fogo, inundao, nveis de monxido de carbono e outras. Ela usar nossos sensores sem fio para detectar cada situao, poder ser programada pelo proprietrio e discar automaticamente para a agncia de monitorao sempre que uma situao for detectada.

Na verdade, outros contribuiriam para essa narrativa durante a reunio de coleta de requisitos e muito mais informaes ficariam disponveis. Mas, mesmo com informaes adicionais, a ambigidade estaria presente, omisses provavelmente existiriam e erros poderiam ocorrer. Por enquanto a descrio funcional precedente ser suficiente. A equipe de coleta de requisitos composta de representantes de marketing, da engenharia de software e hardware, e de fabricao. Um facilitador externo deve ser usado. Cada pessoa da equipe desenvolve as listas descritas anteriormente. Os objetos descritos para o CasaSegura poderiam incluir painel de controle, detectores de fumaa, sensores para janelas e portas, detectores de movimento, alarme, um evento (um sensor foi ativado), um mostrador, um PC, nmeros de telefone, uma chamada telefnica e assim por diante. A lista de servios poderia incluir configurar o sistema, ligar o alarme, monitorar os sensores, discar o telefone, programar o painel de controle, ler o mostrador (note os servios agem sobre os objetos). De modo semelhante, cada participante desenvolver listas de restries (por exemplo, o sistema deve reconhecer quando os sensores no esto funcionando, deve ser amigvel ao uso, deve fazer interface diretamente com uma linha telefnica padro) e os critrios de desempenho (por exemplo, um evento de sensoriamento deve ser reconhecido dentro de um segundo, um esquema de prioridade de eventos deve ser implementado). Quando a reunio de coletas de requisitos comea, o primeiro tpico de discusso a necessidade e a justificativa do novo produto, todos devem concordar que o produto justificvel. Uma vez estabelecida a concordncia, cada participante apresenta suas listas para discusso. As listas podem ser penduradas nas paredes da sala usando grandes folhas de papel, grudadas com adesivos na parte de trs ou escritas em um quadro de parede. Alternativamente, as listas podem ser colocadas em um quadro de aviso eletrnico, em um site interno da web ou em ambiente de bate-papo eletrnico para reviso anterior reunio. O ideal que cada entrada em uma lista possa ser manipulada separadamente para que as listas possam ser combinadas, as entradas apagadas e adies possam ser feitas. Nesse estgio, crticas e debates so estritamente proibidos. Depois que as listas individuais sobre um assunto forem apresentadas, uma lista combinada criada pelo grupo. A lista combinada elimina entradas redundantes, adiciona qualquer idia nova que tenha surgido durante a discusso, mas no apaga nada. Depois que as listas combinadas para todos os assuntos tiverem sido criadas, o facilitador coordena a discusso. A lista

combinada reduzida, ampliada ou reescrita para refletir adequadamente o produto/sistema a ser desenvolvido. O objetivo desenvolver uma lista de consenso em cada assunto (objetos, servios, restries e desempenho). As listas so ento postas de lado para ao posterior. Uma vez completadas as listas de consenso, a equipe subdividida em equipes menores, cada uma trabalha para desenvolver mini-especificaes para uma ou mais entradas de cada uma das listas. Cada mini-especificaes um detalhamento da palavra ou frase que consta de uma lista. A miniespecificao para um objeto de controle do CasaSegura poderia ser: O painel de controle uma unidade montada na parede que tem o tamanho aproximado de 22 X 12 centmetros. Ele tem conectividade sem fio a sensores e a um PC. A interao com o usurio ocorre por meio do teclado padro de 12 teclas. Um mostrador LCD de 5 X 5 centmetros, aproximadamente, fornece o feedbeck do usurio. O software fornece prompts interativos, eco e funes similares. Cada sub-equipe apresenta, em seguida, sua mini-especificao a todos os participantes para discusso. Adies, supresses e mais detalhadamente so feitos. Em alguns casos, o desenvolvimento de mini-especificaes descobrir novos objetos, servios, restries ou requisitos de desempenho que sero adicionados s listas originais. Durante todas as discusses, a equipe pode levantar um assunto que no pode ser resolvido durante a reunio. Uma lista de assuntos mantida de modo que essas idias possam ser trabalhadas depois. Depois que as mini-especificaes so completadas, cada participante faz uma lista de critrios de validao para o produto/sistema e apresenta-a equipe. Uma lista de validao criada. Finalmente, atribu-se a um ou mais participantes (ou pessoas externas) a tarefa de redigir o rascunho completo da especificao usando todas as entradas produzidas durante a reunio.