grande evolucao nos ultimos anos. Pode-se citar o Rational Unified Process tradicional, os processos ageis como o Agile Unified Process ou o XP (Extreme Programming), cada um com suas caracteristicas proprias em maior ou menor enfase, defendem pontos basicos relacionados a requisitos como: envolvimento constante do usuario e envolvidos, nao especificacao de todos os requisitos no inicio do projeto, mas sim iterativamente e utilizacao de tecnicas apropriadas para facilitar o processo. Scott W. Ambler1 em seu livro Agile Modeling: Effective Practices for Extreme Programming and the Unified Process explica o quao importante e a modelagem e a documentacao de qualquer projeto de software, incluindo os projetos ageis. Ele enfatiza que tecnicas tradicionais como JAD, Casos de Uso, entrevistas, observacao, entre outras, podem ser adaptadas aos processos ageis e a participacao constante dos envolvidos e ponto fundamental de sucesso. O grau de formalismo no uso da tecnica e o tempo dedicado as atividades e que variam de acordo com o processo.Em termos de ferramentas alguns agilistas extremados defendem o uso de papel simplesmente. Outros utilizam algumas tecnicas e ferramentas. Considerando que o sistema e algo que vai existir na organizacao durante anos ou decadas e vai sofrer manutencao, e preciso utilizar recursos que falicitem a documentacao e a alteracao da mesma. Alem do fato de que o desenvolvimento geograficamente distribuido esta se tornando cada vez mais comum, a necessidade de um suporte de ferramental para desenvolvimento colaborativo e premente. Neste ponto o Rational Requirements Composer (RRC)2 e uma excelente opcao seja para desenvolvimento agil em projetos que exijam menos formalismos, seja para projetos tradicionais muitas vezes sujeitos ao cumprimento de regulamentacoes e auditoria. O RRC e construido sobre a plataforma colaborativa Jazz da IBM e possui recursos para suportar as etapas de entendimento do problema, levantamento e definicao dos requisitos. O produto complementa a plataforma Rational que ja possui ferramenta para gerenciamento de requisitos.Em termos de pessoas e preciso primeiramente selecionar analistas que tenham perfil adequado, fornecer treinamento e mentorizacao. Existem tecnicas, e boas praticas que podem aperfeicoar o trabalho da equipe. Donald Gause e Gerald Weinberg3 definem problema como sendo a diferenca ou o gap existente entre a percepcao da situacao atual e a situacao desejada. Dada esta definicao, existem diferentes formas de resolver o problema. Nem sempre a melhor solucao e fornecer a situacao desejada. A mudanca de percepcao da situacao atual pode alterar a definicao do problema. A maioria das solicitacoes de melhoria recebidas pela Microsoft, por exemplo, para produtos como Word, sao de funcionalidades ja existentes no produto. A solucao correta seria entao mudar a percepcao da situacao atual, atraves de um treinamento, por exemplo. A explicacao do custo envolvido ou de outros aspectos de uma solucao pode mudar a percepcao do cliente sobre a situacao desejada. Algumas vezes o cliente solicita funcionalidades que nao resolverao o problema dele e consequentemente nao serao utilizadas, pois sua percepcao da situacao desejada pode estar distorcida. Uma evidencia disto e a estatistica publicada pelo Standish Group: Tipicamente entre 20-40% das linhas de codigo dos sistemas nao sao utilizadas. Tecnicas de analise de