Para complementar o entendimento deste exemplo de uso, foram disponibilizadas duas animações. A primeira apresenta a perspectiva da execução do processo e a segunda apresenta com mais detalhes o protótipo construído.

Essa seção apresenta a utilização prática do protótipo desenvolvido neste trabalho no desenvolvimento de um sistema real. O objetivo desse estudo de caso é demonstrar como equipes distribuídas podem se beneficiar da integração da aplicação com um groupware, através da utilização do processo sugerido.

1. Introdução
2. Analisando um projeto open source
3. O projeto Xplanner
   1. Execução do processo
   2. Interação entre os stakeholders
   3. Gerenciamento de requisitos

Para demonstrar a facilidade de obtenção de requisitos e colaboração, foi usado como estudo de caso um projeto open source. O desenvolvimento no estilo open source é baseado em colaboração e na maioria dos casos as equipes estão distribuídas, formando o cenário ideal para um estudo de caso do protótipo.

Para isso, foi realizada uma busca nos sites que hospedam projetos open source. Os sites pesquisados foram: tigris.org, sourceforge.net e codigolivre.org.br. Para o projeto escolhido, foram coletadas as informações disponíveis e estas foram nseridas no protótipo.

Baseado no estilo de desenvolvimento de software livre, o estudo de caso apresentando aqui também considera os desenvolvedores como clientes, pois eles participam ativamente na definição dos requisitos. No entanto, ao contrário do que acontece na maioria dos projetos open source, os requisitos serão também documentados e servirão como base para o desenvolvimento futuro do projeto.

O objetivo deste estudo de caso é coletar todas as interações disponíveis em um projeto open source maduro. Para demonstrar a aplicabilidade e benefícios, as interações disponíveis foram inseridas no protótipo e um documento de requisitos foi construído para o projeto com base nessas inúmeras informações espalhadas.

O projeto escolhido foi o xPlanner, que além de ser um projeto maduro trata sobre ambientes de desenvolvimento de software, que é um dos temas de interesse desse trabalho.

A seguir será apresentada uma breve descrição do projeto e em seguida será apresentado como as colaborações poderiam ter ocorrido através do ambiente e os benefícios de sua possível utilização para que o sucesso e entendimento do projeto e seus requisitos seja alcançado.

O sistema xPlanner tem como objetivo fornecer suporte a equipes que utilizam processos ágeis, tais como XP (eXtremme Programming) e Scrum. Para isso, disponibiliza mecanismos para que as premissas desses processos possam ser realizadas através do sistema, facilitando a distribuição.

Participam do desenvolvimento do projeto cerca de cinco desenvolvedores (cadastrados no sourceforge ). Foram atribuídos papéis a cada um deles, após análise dos tipos e intensidade de contribuições. Essa atribuição era necessária para facilitar o entendimento. Raquel (engenheiro de requisitos) e Mateus (engenheiro de processo) foram acrescentados devido à inexistência de gerenciamento de requisitos e execução de processo (de forma explícita) anteriormente.

Tabela 1 Participantes do processo

O processo utilizado está descrito no menu a esquerda. Através da aplicação para gestão de conhecimento do eGroupware , o Engenheiro de Processo criou três pastas (Conhecimento Formal, Conhecimento Informal e Informações de Negocio) para disseminar as informações necessárias a todos.

Documentos referentes ao domínio do problema, como artigos sobre eXtreme Programming e questionamentos sobre metodologias de desenvolvimento de software eram constantemente inseridos na pasta de conhecimento informal. Um documento descrevendo o processo com mais detalhes e os templates disponíveis para utilização foram adicionados pelo engenheiro de processo na pasta de conhecimento formal.

O gerente de projetos então construiu o Plano de Gerência de Requisitos e Plano de Comunicação (de acordo com a fase Planejar Atividades) e disponibilizou na pasta de Informações de Negócio. Ficou decidido que a comunicação seria realizada através do ambiente eGroupware , e-mails individuais e ferramenta para mensagem instantânea MSN Messenger . Através do eGroupware, a comunidade de software livre (cliente) poderia sugerir novas funcionalidades e participar das discussões correntes. No entanto, apenas os participantes do projeto teriam poder para decidir o que seria incluído. Ficou estabelecido que os requisitos identificados fossem mantidos através da ferramenta para gerenciamento de requisitos Codipse-Req.

Utilizando as informações disponíveis na pasta de conhecimento formal e informal, reuniões realizadas e discussões em fóruns relacionados, o engenheiro de requisitos descreve a visão geral e restrições do sistema (figura 1) e identifica os usuários na ferramenta Codipse-Req, criando links para as informações que a originaram (figura 2)(fase Organizar Conhecimento do processo).

Figura 1 Visão do sistema

Figura 2 Links para informações que deram origem

O processo de Engenharia de Requisitos é essencialmente colaborativo e depende da qualidade das interações realizadas, além da experiência dos envolvidos. Se essas interações estiverem sendo realizadas de forma distribuída, o ambiente deve apresentar diferentes formas de comunicação. As aplicações do eGroupware utilizadas foram: fórum, agenda de eventos, ferramenta de solicitação de mudança e ferramenta de controle de tarefas.

Durante a elicitação de requisitos (fase Elicitar Requisitos), foram marcadas reuniões na agenda de eventos. Após a realização das mesmas, o log da ferramenta MSN Messenger era anexado e eram inseridos registros sobre o que foi decidido ou discutido. O Engenheiro de Requisitos então, cadastra os rascunhos iniciais dos requisitos e termos utilizados na ferramenta Codipse-Req. As atas de reuniões correspondem às anotações feitas na agenda de eventos e ao log (figura 3).

Figura 3 Elicitação de Requisitos

Em paralelo a elicitação de requisitos, ocorre a Analise e Negociação de Requisitos. Nessa fase, ocorrem reuniões para discutir duvidas e inconsistências. Para manter o rationale, as alterações são mantidas, assim como os links dos requisitos iniciais com qualquer interação que tenha levado a sua alteração. As demais fases serão vistas diretamente no protótipo na seção a seguir.

A documentação de requisitos vem ocorrendo desde a fase de elicitação, com a versão rascunho dos requisitos. No entanto, durante a documentação os requisitos se transformam em versões finais, prontos para serem implementados após validação.

A validação ocorre através de reuniões síncronas (onde novamente o log das discussões deve ser mantido), ou através do aceite dos responsáveis (nesse projeto, o gerente de projeto tem a palavra final, pois não há um cliente formal).

Para gerenciamento de requisitos, foi utilizado o protótipo desenvolvido. A responsável pela engenharia de requisitos (Raquel), cadastrou as informações e gerou os artefatos esperados. A figura 4 demonstra os requisitos cadastrados.

Para permitir o rationale de requisitos, foram criados links para as informações de origem conforme. Um exemplo de como esses links são mantidos é mostrado na figura 5.

Figura 5 Tela de edição de caso de uso

Por fim, novos conhecimentos e informações (fase Organizar Conhecimento e Informações) são constantemente inseridos e alimentam a projeto em si, que depende dessas informações e interações. De forma conceitual estão controladas na ferramenta de gestão de conhecimento, mas também estão espalhadas em fóruns e documentos, por exemplo.

A utilização de tecnologias de colaboração tem sido apontada como um dos principais fatores para auxiliar a engenharia de requisitos distribuída (Lloyd et al, 2002) (Damian e Zowghi, 2003) (Prikladnicki et al, 2003) . A realização do estudo de caso utilizando um projeto distribuído real demonstrou a importância e aplicabilidade da proposta.

DAMIAN, D. e ZOWGHI, D. "Requirements Engineering challenges in multi-site software development organizations". Requirements Engineering Journal, 8, pp.149-160, 2003

LLOYD, W. J., ROSSON, M. B., e ARTHUR, J. D. "Effectiveness of Elicitation Techniques in Distributed Requirements Engineering". ICRE Proceedings, 2002

PRIKLADNICKI, R., AUDY, J. L. N., e EVARISTO, R. "Requirements Management in Global Software Development: Preliminary Findings from a Case Study in a SW-CMM context". International Workshop on Global Software Development, 2003