1. O documento discute engenharia de requisitos para métodos ágeis. 2. A ER tradicional e ágil são comparadas, com foco nas técnicas e abordagens da ER aplicadas a métodos ágeis. 3. O papel de stakeholders como clientes, desenvolvedores e gerentes em métodos ágeis também é discutido.

1. UNIVERSIDADE FEDERAL DE PERNAMBUCO
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CENTRO DE INFORMÁTICA
EEEENGENHARIA DENGENHARIA DENGENHARIA DENGENHARIA DE RRRREQUISITOS PARAEQUISITOS PARAEQUISITOS PARAEQUISITOS PARA
MMMMÉTODOSÉTODOSÉTODOSÉTODOS ÁÁÁÁGEISGEISGEISGEIS
AutorAutorAutorAutor
Fernanda Rodrigues dos Santos d’Amorim
OrientadorOrientadorOrientadorOrientador
Prof. Jaelson Freire Brelaz de Castro
Recife, julRecife, julRecife, julRecife, julho 2008ho 2008ho 2008ho 2008
Universidade Federal de Pernambuco
Centro de Informática

3. FERNANDA RODRIGUES DOS SANTOS D’AMORIM
ENGEHARIA DE REQUISIOS PARA MÉTODOS ÁGEIS
Monografia apresentada ao Curso de pós-graduação
em Ciência da Computação, Centro de Informática,
Universidade Federal de Pernambuco, como
requisito parcial para conclusão da disciplina
Engenharia de Requisitos.
Prof. Jaelson Brelaz de Castro
Recife
15 de Julho de 2008

5. RESUMO
Coletar, entender, e gerenciar requisitos é um aspecto crítico em todos os métodos de
desenvolvimento. Para métodos ágeis isto também é importante. Em particular, várias
abordagens ágeis lidam com requisitos a fim de implementá-los corretamente e
satisfazer as necessidades do cliente. Estas práticas focam numa interação contínua com
o cliente para dar suporte a evolução dos requisitos, priorizá-los e entregar, de maneira
progressiva, as funcionalidades mais importantes. Este trabalho tem como objetivo
prover uma visão geral de como técnicas da Engenharia de Requisitos são aplicadas a
desenvolvimento ágeis a fim de garantir a qualidade do produto final, bem como,
entender como e porque a Engenharia de Requisitos ágil difere da Engenharia de
Requisitos tradicional.
Palavras-chave: Engenharia de Requisitos, Métodos Ágeis, Processos Ágeis,
Gerenciamento de Variabilidade.

7. 7
ABSTRACT
Collecting, understanding, and managing requirements is a critical aspect
in all development methods. This is important for Agile Methods too. In particular,
several agile approaches deal with requirements in order to implement them correctly
and satisfy the needs of the customer. These practices focus on a continuous
interaction with the customer to address the requirements evolution over time,
prioritize them, and deliver the most valuable functionalities first. The main goal of
this work is to provide a general view of how the Requirement Engineering techniques
have been applied to agile development in order to assure the quality of the final
product, as well as, to understanding how and why agile Requirement Engineering
differs from traditional Requirement Engineering.
Keywords: Requirement Engineering, Agile Methods, Agile Process, Variability
Management.

8. 8
SUMÁRIO
1. Introdução ..............................................................................................................10
2. Métodos Ágeis.........................................................................................................13
3. Engenharia de Requisitos Tradicional e Ágil......................................................19
3.1 O Processo da Engenharia de Requisitos Tradicional .............................20
3.1.1 Elicitação ...............................................................................................20
3.1.2 Análise e Negociação.............................................................................20
3.1.3 Documentação.......................................................................................21
3.1.4 Validação ...............................................................................................21
3.1.5 Gerenciamento de Requisitos ..............................................................21
3.2 Processos de ER e o seu Impacto em Métodos Ágeis................................21
4. Técnicas e Abordagens da Engenharia de Requisitos para Métodos Ágeis .....23
4.1 Envolvimento do Cliente .............................................................................23
4.2 Elicitação ......................................................................................................24
4.3 Modelagem ...................................................................................................25
4.4 Documentação..............................................................................................25
4.5 Validação ......................................................................................................25
4.6 Gerenciamento .............................................................................................26
4.7 Requisitos Desnecessários ...........................................................................28
4.8 Falha de Comunicação ................................................................................29
4.9 Requisitos Não Funcionais..........................................................................30
5. O Papel e Responsabilidades de Stakeholders em Métodos Ágeis .....................32
5.1 Clientes..........................................................................................................32
5.2 Desenvolvedores...........................................................................................32
5.3 Gerentes........................................................................................................33
6. Conclusão................................................................................................................34
7. Referências Bibiográficas......................................................................................37

9. 9
LISTA DE FIGURAS
Figura 1: Ciclo de Desenvolvimento Ágil [1]............................................... 15
Figura 2: Custo de Mudanças [1]................................................................... 27
LISTA DE TABELAS
Tabela 1: The Crystal Family [1]................................................................... 17
Tabela 2: Principais Causas de Falhas de Projetos [1].................................. 19

10. 10
1. Introdução
Mudanças cada vez mais rápidas no ambiente de negócio, no qual a maioria das
organizações opera, estão desafiando as abordagens da Engenharia de Requisitos (RE)
tradicional. As empresas de desenvolvimento de software precisam saber tratar, de
forma consistente e eficiente, requisitos que tendem a evoluir rapidamente e se tornam
obsoletos mesmo antes dos projetos serem finalizados. Dentre os fatores que
contribuem para esta variabilidade estão a rápida mudança de ameaças competitivas,
de preferências dos stakeholders, da tecnologia de desenvolvimento e a pressão para o
produto entrar no mercado [3]. Isto, tem tornado a pré-especificação de requisitos
inapropriada para projetos que possuem tais características.
Métodos Ágeis (MAs), que procuram atacar os desafios emergentes destes contextos
dinâmicos, têm ganho bastante interesse de pesquisadores e engenheiros de softwares
[3]. MAs constituem uma família de processos de desenvolvimento de software que
se tornou popular durante os últimos anos [1,7,14]. O objetivo principal desta
abordagem é garantir a entrega de produtos em um menor prazo, com maior qualidade
e satisfazendo às necessidades dos clientes através da aplicação dos princípios da
produção enxuta para desenvolvimento de software [25].
Produção enxuta foi concebida durante a década de 50 pela Toyota [23]. Esta
abordagem envolve várias práticas como desenvolvimento just-in-time,
gerenciamento de qualidade total e processo de melhoria contínuo. O princípio da
produção enxuta é a constante identificação e remoção de perdas, isto é, de tudo que
não agrega valor para o cliente do produto final. Baseados no princípio da produção
enxuta, MAs focam em [1]:
• Agregar valor para o cliente
• Garantir que o cliente entenda este valor e que o projeto satisfaça suas
necessidades.
MAs colocam muita ênfase em produzir e entregar ao cliente somente features que
são úteis. Produzir algum outro artefato que não é requerido é considerado um erro.

11. 11
Segundo a filosofia ágil, adicionar uma feature que não é necessária não só consome
esforço sem agregar valor, mas também produz código extra que pode conter erros,
deixando o sistema mais complexo para manter, corrigir e melhorar [1].
Para garantir tal eliminação de perdas, MAs propõem ser [7]:
• Mais adaptativos do que previsíveis
• Mais orientados a pessoas do que orientados a processos.
Para garantir a satisfação do cliente, procura-se uma colaboração estreita entre a
equipe de desenvolvimento e o cliente, a fim de que [1]:
• Requisitos sejam totalmente identificados.
• O produto final reflita exatamente as necessidades do cliente.
Engenharia de Requisitos, por outro lado, é um processo tradicional da engenharia de
software com o objetivo de identificar, analisar, documentar e validar requisitos para
o sistema que será desenvolvido. Freqüentemente, Engenharia de Requisitos e
Métodos Ágeis são vistos como incompatíveis: tradicionalmente, ER é fortemente
baseada em documentação para compartilhar conhecimento enquanto que MAs são
focados em colaboração face-a-face entre desenvolvedores e clientes para atingir
objetivos similares[2].
Porém, uma análise de vários processos ágeis mostra que a ER está presente em todos
eles [2]. As atividades e fases é que diferem de acordo com a peculiaridade de cada
processo. Mostra-se então, que a engenharia de requisitos tem grande importância
para métodos ágeis, podendo-se destacar como pontos fundamentais [1]:
• A maioria das técnicas de elicitação de requisitos não muda muito entre um
ambiente tradicional e um ambiente ágil.
• A priorização de requisitos é essencial, visto que o foco principal de MAs é a
implementação das features mais valiosas para o cliente.

12. 12
• A identificação de interação entre features e o desacoplamento entre elas é
também de extrema importância para a implementação de, exclusivamente,
features de alta prioridade.
• A identificação dos requisitos inclusos numa mesma iteração é baseada na
negociação entre os clientes e a equipe de desenvolvimento.
Este trabalho tem como objetivo principal expor quais técnicas e abordagens da
Engenharia de Requisitos estão sendo utilizadas dentro do contexto ágil, bem como,
entender como e porque a Engenharia de Requisitos ágil difere da Engenharia de
Requisitos tradicional.
O restante deste trabalho está organizado da seguinte forma: a seção 2 introduz
brevemente Métodos Ágeis. A seção 3 descreve os objetivos e os problemas comuns
da Engenharia de Requisitos. A seção 4 se aprofunda nas técnicas e abordagens da
Engenharia de Requisitos aplicadas a Métodos Ágeis. A seção 5 discute o papel e
responsabilidades de stakeholders no Processo Ágil. E na seção 6 discutem-se
conclusões sobre a aplicabilidade da Engenharia de Requisitos para Métodos Ágeis.

13. 13
2. Métodos Ágeis
Métodos Ágeis são uma família de técnicas de desenvolvimento projetadas para
entregar produtos no prazo correto, com alto grau de qualidade e satisfação do cliente
[1]. Esta família inclui métodos bastante variados e diferentes. Os mais populares
são:
• eXtreme Programming (XP) [6]
• Scrum [28]
• Dynamic Systems Development Method (DSDM) [32]
• Adaptive Software Development (ASD) [17]
• The Crystal family [12]
Os promotores de MAs se deram conta que a grande variedade destes métodos
poderia afastar pessoas interessadas em adotá-los, já que estas poderiam ter
dificuldades em escolher o que aplicar em seus próprios processos[9,15]. Como
resultado, definiram um documento contendo um conjunto de valores básicos e
comuns a todos os métodos ágeis. Este documento é chamado de “Agile Manifesto”
[7]. Sendo baseado em gerenciamento enxuto, estes valores focam em recursos
humanos e gerenciamento de processos [1]:
• Indivíduos e Interações X Processos e Ferramentas: a abordagem ágil dá
muito mais ênfase à importância das pessoas e suas interações do que a
processos estruturados e ferramentas.
• Colaboração dos Clientes X Contratos: o relacionamento entre a equipe de
desenvolvimento e o cliente é regulado através do envolvimento do cliente no
processo de desenvolvimento e não através de contratos fixos e detalhados.
• Software Funcionando X Documentação: o objetivo da equipe de
desenvolvimento é entregar código funcionando corretamente, visto que este é
o artefato que provê valor ao cliente. Código bem escrito é auto-documentado
e uma documentação formal é reduzida ao mínimo.

14. 14
• Resposta à Mudança X Planejamento: a equipe de desenvolvimento tem
que reagir rapidamente à variação nos requisitos. As decisões de binding que
afetam esta habilidade são postergadas o máximo possível e o tempo gasto na
atividade de planejamento é limitado ao que o cliente precisa. Qualquer
tentativa para prever necessidades futuras é proibida. A partir destes valores,
um conjunto de práticas e comportamentos comuns são identificados. Este
tipo de abordagem não é uma inovação da Comunidade Ágil, elas são
resultantes de experiências de sucessos e falhas no desenvolvimento de
software. Algumas destas práticas estão listadas a seguir [1]:
• Adaptabilidade: as metodologias têm que ser adaptadas às
necessidades específicas para ambos, a equipe de desenvolvimento e os
clientes.
• Desenvolvimento Incremental: as diferentes etapas do
desenvolvimento de software (análise, projeto, implementação e teste)
são comprimidas em iterações muito curtas (de 2 semanas a 2 meses),
a fim de focar em um conjunto de problemas pequenos e bem definidos
que irá prover um valor real ao cliente (Figura 1).
• Releases freqüentes: no fim de cada iteração, é liberado um release
para o cliente testá-lo e prover feedbacks. Esta abordagem traz vários
benefícios como: (1) o cliente pode usar a aplicação bem cedo,
permitindo a identificação de potenciais problemas em tempo de
melhorar o produto e limitando o impacto no cronograma; (2) o cliente
se sente no controle do processo de desenvolvimento, visto que a
evolução do projeto está sempre visível; (3) a confiança entre o cliente
e a equipe de desenvolvimento aumenta já que a equipe é considerada
confiável porque ela é capaz de entregar versões da aplicação que
funcionam logo no início do processo.

15. 15
• Priorização de requisitos antes de cada iteração: antes de cada
iteração, o cliente e a equipe de desenvolvimento identificam novos
requisitos e reorganizam as prioridades dos antigos baseados nas atuais
necessidades dos clientes.
• Alto grau de envolvimento do cliente: o cliente está envolvido no
processo de desenvolvimento através de uma constante requisição de
feedbacks, a fim de identificar potenciais problemas logo no início do
desenvolvimento. Em alguns casos, o cliente se torna um membro da
equipe de desenvolvimento e está sempre disponível para interagir com
a equipe e clarificar questões relacionadas aos requisitos.
Figura. 1 - Ciclo de desenvolvimento Ágil [1]
Como mencionado, os valores básicos e práticas de todos os MAs são bastante
parecidos. Mesmo assim, o termo “Métodos Ágeis” identifica uma família diversa de

16. 16
metodologias de desenvolvimento com focos diferentes e pontos fortes e fracos
peculiar a cada uma delas. Existem diferentes níveis de “agilidade” em MAs. Uma
metodologia de desenvolvimento é mais ágil do que outra se ela requer menos
overhead (o que significa não produzir valor para o cliente) [1].
Em cada metodologia, a equipe de desenvolvimento tem diferentes prioridades,
processos, níveis de overhead para a interação dos membros da equipe, etc. Apesar
disso, não existe uma solução única para todos os contextos. Métodos Ágeis
fornecem diretrizes e um conjunto básico de práticas e comportamentos que têm que
ser adaptados ao problema específico [6,9]. A aplicabilidade de MAs é ainda uma
preocupação de pesquisa [4,34]. Várias questões ainda estão sendo discutidas, dentro
delas estão: (1) o tamanho do problema que pode ser tratado; (2) como as pessoas são
gerenciadas; (3) os domínios de aplicação no qual MAs são lucrativos [1].
• Tamanho da equipe em Métodos Ágeis
A maioria dos MAs têm como alvo específico equipes de desenvolvimento
pequenas, com até 16 desenvolvedores (ex., XP). Contudo, existem MAs dando
suporte a um grande intervalo de tamanho de equipes (ex.. The Crystal Family).
O grau de agilidade está frequentemente relacionado ao tamanho da equipe.
Comunicação direta e documentação limitada só tornam-se possível com uma
equipe pequena. Quando uma equipe cresce, o nível de overhead é proporcional a
este crescimento. Este overhead inclui: (1) documentação e (2) comunicação
mediada. Maior quantidade de documentação é requerida para compartilhar
conhecimento e verificar o status do projeto porque, uma interação entre várias
pessoas (many-to-many) não é mais possível [12]. Além disso, a importância da
documentação cresce e se torna uma maneira de melhorar a forma como o
conhecimento é compartilhado. Neste caso, só o código já não é suficiente e a
comunicação direta entre a equipe de desenvolvimento e o cliente não é possível
quando estas equipes são muito grandes [1].

17. 17
Tabela 1 – The Crystal Family [1]
Por estas razões, equipes pequenas são mais ágeis do que equipes grandes.
Contudo, os princípios básicos do gerenciamento enxuto ainda são válidos e a
maioria deles são escaláveis. Um deles é a melhoria contínua do processo através
da redução de perdas. Este princípio é válido independentemente do tamanho da
equipe de desenvolvimento.
A família Crystal é um exemplo de como a melhoria contínua do processo pode
combater estas dificuldades [12]. A metodologia ágil Crystal inclui diferentes
MAs que se adéquam às necessidades das equipes com diferentes tamanhos
(Tabela 1). Os diferentes níveis da The Crystal Family focam em diferentes
práticas a fim de gerenciar a escalabilidade. Uma escalabilidade limitada é
alcançada reduzindo-se o nível de agilidade.
Desenvolver grandes sistemas usando MAs é difícil ou mesmo impossível.
Atualmente, o esforço de pesquisa em MAs focam em projetos de tamanho
pequeno e médio, visto que mesmo nesta área a sua efetividade continua sendo
investigada. Algumas práticas ágeis simplesmente não são escaláveis [1].
• Gerenciando Pessoas em Métodos Ágeis
MAs focam no valor das pessoas para solucionar problemas e compartilhar
informação [11], e não no processo e numa grande quantidade de documentação
[24]. Contudo, a orientação à pessoas pode representar um ponto negativo
bastante relevante para MAs, visto que, para se construir uma boa equipe ágil os
conhecimentos e habilidades requeridas tem que ser profundos e diversificados
[11]. Os membros da equipe têm que ser excelentes desenvolvedores, serem
capazes de trabalhar em equipe, se comunicarem e interagirem com colegas e

18. 18
clientes, etc. Todas estas habilidades são obrigatória, na medida que os times são
auto-organizáveis e não podem se basear em um processo pré-determinado e
detalhado para solucionar problemas e compartilhar conhecimento [10].
• Aplicabilidade de Métodos Ágeis em Diferentes Domínios de Aplicação
Uma questão chave é se MAs podem ser aplicados em todos os domínios de
aplicação. Isto ainda é uma tema que está sendo investigado[4,9,34]. Em
particular, como e quando a utilização de alguma prática específica resulta em
benefícios [24, 8, 27]. Em geral, MAs são eficientes para construir aplicações
não críticas e com tamanho limitado. Pesquisadores estão estudando outras áreas
como sistemas embarcados (ex. Telefones celulares e PDAs) onde performance,
comportamento de tempo real e restrição de memória são problemas inerentes [1].
MAs focam em produzir somente o que traz valor ao cliente, o que significa não
construir artefatos reusáveis como por exemplo componentes. Se o objetivo do
projeto é desenvolver um artefato reusável, o time de desenvolvimento irá focar
neste problema e usar MAs para atacá-lo. Porém, artefatos reusáveis não são
construídos em projetos cujo objetivo não seja exatamente este, porque os
desenvolvedores tem que incluir features que não são úteis ao projeto em
andamento[1].
MAs não são a solução para desenvolver todos os tipos de produtos. Sua aplicação é
extremamente difícil e às vezes impossível para muitas áreas, como sistemas críticos
de segurança, projetos muito grandes e aplicações complexas [1]. Um dos grandes
desafios desta área é de se determinar em que contexto e sob quais características a
aplicação de abordagens ágeis será mais lucrativa e eficiente em relação a um método
tradicional.

19. 19
3. Engenharia de Requisitos Tradicional e Ágil
Requisitos são a base de todos os produtos de software e sua elicitação,
gerenciamento e entendimento são problemas comuns a todas as metodologias de
desenvolvimento [1].
Em particular, a variabilidade de requisitos é o maior desafio para todos os projetos de
software [29]. De acordo com um estudo do Standish Group [31], cinco dos oito
principais fatores de falhas em projetos tem haver com requisitos (Tabela 2), Estes
são: requisitos incompletos, baixo envolvimento do cliente, expectativas não realistas,
mudanças nos requisitos e requisitos desnecessários [1].
Problema %
Requisitos incompletos 13.1
Baixo envolvimento do cliente 10.6
Falta de recursos 12.4
Expectativa não realista 9.9
Falta de suporte gerencial 9.3
Mudanças nos requisitos 8.7
Falta de planejamento 8.1
Requisitos desnecessários 7.5
Tabela 2 - Principais Causas de Falhas de Projetos [1]
Engenharia de requisitos é um dos fatores mais importante para o sucesso de um
projeto de desenvolvimento de software. Ela está preocupada com a identificação,
modelagem, comunicação e documentação dos requisitos de um sistema, bem como,
com o contexto no qual o sistema estará inserido [2]. Requisitos descrevem quais
funcionalidades estarão disponíveis e sob quais limitações o sistema irá funcionar.
Eles dizem o que deverá ser feito, mas não especificam como serão implementados.
Existem diversas técnicas disponíveis que são usadas para dar suporte ao processo da
ER com o objetivo de garantir que os requisitos coletados sejam completos,
consistentes e relevantes. O objetivo principal da ER tradicional é descobrir o que se
deve fazer antes de se iniciar o desenvolvimento do sistema. Esta meta é baseada em
duas suposições [2]:

20. 20
• Quanto mais tarde erros forem descobertos maiores são os custos para corrigi-los.
• É possível determinar um conjunto de requisitos estáveis, antes de se começar a
projetar e implementar o sistema.
3.1 O Processo da Engenharia de Requisitos Tradicional
O processo da Engenharia de Requisitos consiste em cinco atividades principais:
Elicitação, Análise e Negociação, Documentação, Validação e Gerenciamento [2].
3.1.1 Elicitação
Elicitação de Requisitos tenta descobrir os requisitos e identificar fronteiras do
sistema consultando os stakeholders (clientes, desenvolvedores, usuários). As
fronteiras definem o contexto do sistema. Durante esta atividade, é essencial o
entendimento do domínio da aplicação, das necessidades do negócio, das restrições do
sistema, dos stakeholders e do problema a ser resolvido. Toda esta aquisição de
conhecimento é fundamental para o correto desenvolvimento do sistema. As técnicas
da elicitação mais utilizadas são: Entrevistas, Cenários/Casos de Uso, Observação e
Análise Social, Grupos Focado, Brainstorming e Prototipagem.
3.1.2 Análise e Negociação
Análise de Requisitos tem como objeto checar os requisitos quanto a sua necessidade
(o requisito é indispensável ao sistema), quanto a sua consistência (o requisito não
deve ser contraditório), quanto a completude (nenhum serviço ou restrição está
faltando) e quanto à realidade (requisitos são realistas no contexto de custo e prazo do
projeto). Os conflitos nos requisitos são resolvidos através da priorização e
negociação com os stakeholders. Soluções para os problemas identificados são
acertadas e um compromisso é firmado considerando um conjunto de requisitos que
foram concordados. As principais técnicas de análise e negociação são: Sessões de
Joint Application Development (JAD), Priorização de Requisitos e Modelagem.

21. 21
3.1.3 Documentação
O objetivo da documentação de requisitos é comunicar os requisitos entre os
desenvolvedores e stakeholders do sistema. O documento de requisitos é a base para
avaliar produtos e processos subseqüentes (projeto, teste, verificação e validação) e
para controle de mudança. Um bom documento de requisitos não pode conter
ambigüidades, tem que ser correto, entendível, consistente, conciso e realista. Em
alguns casos, a especificação dos requisitos pode fazer parte do contrato do projeto.
3.1.4 Validação
O objetivo da validação de requisitos é certificar que os requisitos são uma descrição
aceitável do sistema a ser desenvolvido. As entradas para a atividade de validação são
o documento de requisitos, os padrões e o conhecimento organizacional. As saídas são
uma lista que contem os problemas encontrados e as ações necessárias para resolver
os problemas reportados. As técnicas usadas para validação de requisitos são revisão e
teste de requisitos.
3.1.5 Gerenciamento de Requisitos
O objetivo do gerenciamento é capturar, armazenar, disseminar e gerenciar
informação. Gerenciamento de requisitos inclui todas as atividades preocupadas com
mudanças, controle de versão e rastreamento de requisitos. Rastreamento de requisitos
provê relacionamento entre requisitos, projeto e implementação de um sistema a fim
de gerenciar suas mudanças.
3.2 Processos de ER e o seu Impacto em Métodos Ágeis
Os processos de desenvolvimento tradicionais têm elaborado vários padrões
incluindo: (1) Padrão IEEE 830 – Práticas Recomendadas para Especificação de
Requisitos de Software [18]; (2) Padrão IEEE 1233 – Guia para Desenvolvimento de
Especificação de Requisitos de Sistemas [19]; (3) Padrão IEEE 1362 – Guia para
Tecnologia da Informação – Definição de Sistema – Documento de Conceito de
Operações [20].

22. 22
A importância de se definir padrões reside no fato de se ter um conjunto de diretrizes
previamente definidas por onde toda a equipe de desenvolvimento será guiada.
MAs não se baseiam nestes padrões para elicitação e gerenciamento de requisitos,
porém, eles têm adaptado muitas das idéias básicas ao seu ambiente[1]. Por
exemplo, em MAs toda a equipe de desenvolvimento está envolvida na atividade de
elicitação e gerenciamento de requisitos enquanto em que abordagens tradicionais
somente um subconjunto da equipe de desenvolvimento está envolvida.
MAs entendem que variabilidade de requisitos é um problema constante em
praticamente todos os projetos de software, portanto, o suporte a essas mudanças está
incluso em seu processo como um ponto forte [33]. Além do mais, MAs não tentam
prever mudanças ou necessidades futuras, eles só focam nas features pela quais o
cliente está pagando. Esta abordagem evita o desenvolvimento de uma arquitetura
geral demais que requer esforço extra[6]. O entendimento de variabilidade de
requisitos tem um forte impacto na habilidade de MAs serem “enxutos”. Em geral,
uma arquitetura genérica e mais abrangente é esperada para suportar a variabilidade
nos requisitos que podem ser previstas com antecedência. Contudo, uma arquitetura
mais complexa custa mais, não só para a equipe de desenvolvimento, mas também
para a equipe de manutenção e correção de erros [1].

23. 23
4. Técnicas e Abordagens da Engenharia de Requisitos para Métodos
Ágeis
MAs incluem práticas focadas nos fatores chaves listados na Tabela 2 para reduzir o
risco de falhas. Em particular, o objetivo principal do desenvolvimento incremental,
de releases freqüentes, da priorização de requisitos antes de cada iteração e do
envolvimento total do cliente é atacar os principais fatores de risco de um projeto de
software [1].
4.1 Envolvimento do Cliente
Envolvimento do cliente é tido como a principal causa para um projeto obter sucesso
[14], enquanto que a ausência deste compromisso é a razão fundamental para projetos
não terminarem como planejados, ou seja, são concluídos com atraso e com custos
extras ou simplesmente são abortados. O ponto chave de todas as abordagens ágeis é
ter o cliente sempre acessível [1].
Em MAs, o cliente assume um papel fundamental. Frequentemente o termo “cliente”
identifica um conjunto de stakeholders que pertencem à organização que está pagando
pelo desenvolvimento de um produto de software. Neste caso, a interação entre a
equipe de desenvolvimento e os stakeholders é complexa devido a diferentes
percepções que os stakeholders possuem sobre o problema [5].
Em MAs, o problema de múltiplos stakeholders é resolvido reduzindo-se este número
a apenas um, uma única pessoa que irá representar todos os stakeholders envolvidos
no projeto. Este cliente deve ser um expert no domínio e deve também ser capaz de
tomar decisões importantes como: aceitar o produto, priorizar requisitos, etc. No caso
de produtos de massa, no qual não existe uma organização pagando diretamente por
ele, a equipe de desenvolvimento tem que identificar um expert na área (ex. um expert
no mercado em questão) que seja capaz de agir como um cliente e participar do
desenvolvimento do produto [1].

24. 24
Esta abordagem só é possível se o tamanho do problema é limitado e uma única
pessoa pode agir como o cliente, representando todos os stakeholders. Se o tamanho
do problema não permitir o uso de tal abordagem, a equipe tem que usar outras
técnicas para elicitar e gerenciar os requisitos [1].
Em alguns MAs, a técnica de participação ativa do cliente é bastante comum. Isto
significa que o cliente se torna membro da equipe de desenvolvimento, ele é co-
alocado com a equipe e etá sempre disponível para discutir as questões relacionadas
ao projeto com qualquer membro da equipe[6]. Esta técnica define alguns requisitos
específicos para o cliente [1]:
• Disponibilidade: o cliente tem que estar sempre disponível para responder
questões vindas da equipe de desenvolvimento.
• Conhecimento geral: o cliente é o representante de todos os stakeholders.
Por isso, ele tem que ser capaz de responder qualquer questão vinda da equipe
de desenvolvimento, já que ele é um expert no domínio e sabe como a
aplicação deve se comportar.
• Poder de Decisão: o cliente é capaz de tomar decisões finais. Mudanças de
requisitos, aceitação da features implementadas, etc. podem ser decididas
diretamente por ele, permitindo um processo baseado em tomadas rápidas de
decisões.
Não é fácil ter acesso a um cliente que seja capaz de satisfazer todos estes requisitos
[26]. A disponibilidade deste tipo de cliente é de fundamental importância em MAs,
visto que a maioria de suas vantagens(ex. redução na documentação, entrega
incremental, etc.) estão fortemente acopladas com o grau de envolvimento do usuário
[1].
4.2 Elicitação
Como visto na seção anterior, o envolvimento do cliente é o objetivo principal do
desenvolvimento ágil. A técnica mais comum da ER para elicitação de requisitos
relacionada a isto é a entrevista. Entrevistas provêem acesso direto e não filtrado para

25. 25
a obtenção do conhecimento necessário. É fato conhecido que transferência de
conhecimento em cadeia provoca mal entendidos. Por isso, todas as abordagens ágeis
dão ênfase à conversa direta com o cliente salientando que esta é a melhor maneira de
coletar o conhecimento necessário e preciso para o desenvolvimento do software.
Caso algo não esteja claro ou esteja vagamente definido, a equipe de desenvolvimento
deve procurar a pessoa responsável diretamente. Este relacionamento direto também
ajuda a estabelecer um relacionamento de confiança entre desenvolvedores e clientes,
que é essencial para o bom andamento do projeto. Com base nestes fatos, a entrevista
é a principal técnica de elicitação nos processos ágeis de ER [2].
4.3 Modelagem
Apesar de a modelagem ser usada em MAs, o propósito é diferente quando
comparado a ER tradicional. Em MAs, modelos são usados para comunicar
entendimento de partes pequenas do sistema em desenvolvimento. Estes modelos são
quase descartáveis. Eles são desenhados em quadros ou papéis, sem uma técnica
específica de modelagem, e são apagados depois que atingirem seus objetivos, ou
seja, após a equipe de desenvolvimento adquirir perfeito entendimento sobre a parte
do sistema em questão. A maioria destes modelos não se tornam parte da
documentação persistente do sistema [2].
4.4 Documentação
Em desenvolvimento ágil gerar documentos de requisitos completos e consistentes é
visto como impraticável, ou pelo menos, como não realizável com um custo efetivo.
A maioria dos métodos ágeis possui algum tipo de documentação, ou recomendam o
uso de documentos de requisitos, porém, a decisão de sua extensão, conteúdo e etc., é
deixada nas mãos da equipe de desenvolvimento e não são descritas em detalhes. É
assumido que a documentação é bem menor do que em abordagens tradicionais [2].
4.5 Validação
Abordagens ágeis usam frequentemente reunião de revisões e testes de aceitação para
validação de requisitos. Reuniões de revisão mostram se o projeto está no caminho

26. 26
certo e dentro do cronograma, aumentando assim a confiança do cliente na equipe de
desenvolvimento. MAs usam diversos tipos de reunião de revisões para apresentar o
novo software. Nelas, os clientes podem usar a aplicação, experimentar como o
sistema funciona e determinar que funcionalidades já foram implementadas. As
dúvidas dos clientes podem ser esclarecidas imediatamente pelos desenvolvedores,
podendo discutir a implementação e sugerir mudanças no projeto. Durante a reunião,
eles ainda aprendem sobre os pontos fortes e fracos do projeto e da tecnologia e em
que área existe vantagens e limitações. Os clientes também podem executar um teste
de aceitação para validar se o sistema reage da maneira esperada, caso não, esclarecer
a questão na mesma hora [2].
4.6 Gerenciamento
Métodos ágeis provêem uma boa base para o gerenciamento de requisitos. Eles
assumem que é muito difícil elicitar todos os requisitos do usuário logo no começo de
um projeto de desenvolvimento. Também assumem que estes requisitos evoluem com
o tempo, visto que, o cliente pode mudar de opinião e o ambiente técnico ou sócio-
econômico também pode sofrer mudanças. Por isso, MAs assumem que mudanças
são inevitáveis e incluem o gerenciamento de variabilidade de requisitos como
atividade fundamental nos seus processos de ER. MAs fundamentam a coleta e o
gerenciamento de requisitos em três suposições principais[6]: (1)requisitos não são
bem conhecidos no começo do projeto; (2) requisitos mudam; (3) fazer mudanças não
é tão caro em um contexto ágil.
Em particular, MAs assumem que o custo de introduzir mudanças num produto é
praticamente constante através do tempo(Figura 2), mas esta hipótese não é válida
para todos os contextos. Geralmente, como fundamentado pela ER tradicional, o
custo de se fazer mudanças cresce exponencialmente com o tempo. Por outro lado, se
as fases de desenvolvimento estão agrupadas em iterações bem curtas (Figura 1) e as
decisões de binding são tomadas o mais tarde possível, o crescimento dos custos é
limitado [1, 6].

27. 27
Figura 2 - Custo de Mudanças [1]
Com o objetivo de gerenciar a evolução de requisitos, MAs usam contratos com
escopo de custo-variável[25]. Isto significa que tanto as features realmente
implementadas no sistema quanto seus custos evoluem com o tempo. Portanto,
requisitos não são especificados em detalhes em nível de contrato, mas definidos
passo-a-passo durante o projeto através de um processo de negociação entre o cliente
e a equipe de desenvolvimento [1].
Gerenciar variabilidade é um desafio que MAs tentam solucionar de duas técnicas [1]:
• Desacoplamento de Requisitos: requisitos têm que ser o mais independentes
possíveis a fim de claramente identificar o que implementar e tornar
irrelevante a ordem de suas implementações.
• Elicitação e Priorização de Requisitos: no começo de cada iteração, existe
uma atividade de coletar e priorizar requisitos. Durante esta, novos requisitos
são identificados e priorizados. Esta abordagem ajuda a identificar as features
mais importantes dentro do projeto em andamento. Tipicamente, se um
requisito é muito importante sua implementação é fixada para a iteração que
está começando, senão, ele entra na fila de espera. Na próxima iteração, os
requisitos que estão na fila são avaliados e se ainda continuarem válidos, são
inclusos na lista de requisitos candidatos junto com os novos que foram
identificados. Então, esta nova lista é priorizada para identificar as features
que irão ser implementadas. Se um requisito não é importante o suficiente, ele
ficará na lista de espera por um tempo indeterminado.

28. 28
Esta abordagem é capaz de identificar os requisitos mais importantes durante todo o
projeto, e não só no começo. Requisitos que não são considerados muito importantes
no início podem se tornar relevantes em algum estágio do projeto. Além do mais, o
desacoplamento dos requisitos permite a implementação das features em quase
qualquer ordem. Assim, as features são implementadas de a cordo com suas
prioridades e não pela dependência funcional entre algumas delas [1].
São duas as principais diferenças entre uma abordagem de priorização ágil e
tradicional: (1) em ER tradicional, os requisitos são priorizados apenas uma vez,
enquanto que na abordagem ágil existe uma priorização a cada ciclo de
desenvolvimento (Figura 1); (2) Em RE tradicional vários fatores contribuem para o
estabelecimento das prioridades como: valores do negócio, risco, custo, e
dependências de implementação. Já em abordagens ágeis, a priorização é baseada em
somente um fator, valor do negócio definido pelo cliente [3].
4.7 Requisitos Desnecessários
Outro foco de MAs é a identificação e redução de atividades desnecessárias no
processo de desenvolvimento [25]. Em particular, identificar e reduzir os requisitos
desnecessários assume um papel fundamental. Em práticas enxutas, a redução deste
“lixo” é extremamente importante, pois “lixo” sempre gera mais “lixo” no futuro [1,
23, 36].
A Engenharia de Requisitos em MAs focam em [7]:
• Reduzir os requisitos desnecessários
• Gerenciar a evolução de requisitos
Requisitos desnecessários afetam profundamente o processo de desenvolvimento e a
habilidade de entregar um produto capaz de satisfazer às reais necessidades do cliente.
O principal efeito deste “lixo” nesta área inclui [1]:

29. 29
• Mais código fonte para escrever e custo extra
• Maior complexidade do código fonte
• Atrasos na entrega da versão final da aplicação contendo todas as
funcionalidades requeridas.
• Manutenção mais complexa e cara
• Quantidade maior de recursos requeridos pela aplicação, incluindo: uso de
memória, poder de processamento, uso de rede, etc.
• Aumento da complexidade da aplicação do ponto de vista do cliente (ex. GUI
mais completa, mais esforço para aprender a usar a aplicação, etc.)
No final, todo este “lixo” gerado implica em um custo extra que afetará o cliente de
maneira direta e indireta.
No caso de projetos grandes, MAs não provê nenhuma solução específica. Mesmo o
cliente sendo um expert no seu domínio, a tarefa de identificar as features que ele
realmente precisa não é fácil. Em geral, clientes pedem mais do que precisam,
incluindo uma grande variedade de features que não estarão provendo um ganho real
para o seu negócio. Estes requisitos são desnecessários, portanto, são fontes de
“lixo”. Com o objetivo de reduzir este tipo de risco, MAs usam as seguintes técnicas
[1]:
• Priorização de Requisitos: o cliente e a equipe de desenvolvimento atribuem
prioridade para cada requisito a fim de identificar as features mais importantes
que têm que ser implementadas primeiro.
• Releases Incrementais: funcionalidades são lançadas em pequenas, mas
freqüentes releases (de 2 semanas a 2 meses), com o objetivo de estar sempre
coletando feedbacks do cliente.
4.8 Falha de Comunicação
Um mal entendido gerado por alguma falha na comunicação entre o cliente e a equipe
de desenvolvimento gera requisitos errados. A fim de reduzir a probabilidade deste

30. 30
problema, MAs adotam várias técnicas focadas na melhoria da interação entre o
cliente e a equipe de desenvolvimento [1]:
• Toda a equipe de desenvolvimento coleta requisitos junto ao cliente:
elicitação de requisitos é uma atividade na qual toda a equipe está envolvida.
Assim, o uso de documentação para compartilhar conhecimento é reduzido ao
mínimo e a probabilidade de mal entendidos diminui.
• Requisitos são coletados usando uma linguagem comum: requisitos são
coletados usando a linguagem do cliente, e não uma linguagem formal para
especificação de requisitos. Isto significa que os desenvolvedores têm que ser
introduzidos ao domínio de aplicação do cliente a fim de entendê-lo.
• Interação direta entre a equipe de desenvolvimento e o Cliente: não existe
nenhum intermediário entre a equipe de desenvolvimento e o cliente. Esta
abordagem reduz tanto o número de documentos requeridos quanto a
probabilidade de mal entendidos devido à criação de camadas extras de
comunicação.
• Divisão de requisitos: se a equipe de desenvolvimento considerar algum
requisito como sendo muito complexo, esta técnica ajuda o cliente a quebrar o
requisito em outros mais simples. Esta divisão ajuda desenvolvedores s
entender melhor as funcionalidades requeridas pelo cliente.
4.9 Requisitos Não Funcionais
MAs não têm nenhuma técnica específica que seja uma unanimidade para elicitação e
gerenciamento dos requisitos não-funcionais[2]. Estes requisitos são coletados
implicitamente durante a atividade de elicitação de requisitos. A necessidade de se
especificar requisitos não-funcionais é menos importante em MAs do que em
contextos tradicionais devido à contínua interação com o cliente. Depois de cada
iteração, o produto é lançado e o cliente pode testá-lo. Se ele identificar problemas
relacionados a qualidades não-funcionais, a equipe pode adaptar o sistema para atingir
estes requisitos na iteração subseqüente sem ter grande impacto no cronograma [1].

31. 31
Frequentemente, o cliente não consegue enxergar muitos dos requisitos não-
funcionais (ex. escalabilidade, segurança, etc.) como um grande impacto. Isto pode
afetar profundamente o lançamento da versão final da aplicação, por isso, a equipe de
desenvolvimento tem que guiar o cliente a fim de identificar estas necessidades que
não são facilmente visíveis. Esta abordagem para requisitos não funcionais pode
representar um risco muito grande para MAs, à medida que faltam técnicas para o
gerenciamento destes.

32. 32
5. O Papel e Responsabilidades de Stakeholders em Métodos Ágeis
MAs requerem um alto grau de interação entre clientes, gerentes e desenvolvedores.
Usualmente esta iteração não é intermediada e todos os stakeholders se encontram
frequentemente em reuniões a fim de melhorar o entendimento mútuo, a qualidade do
produto final e manter o projeto sob controle (no prazo e custo correto) [1].
Papéis e Responsabilidades de clientes, gerentes e desenvolvedores assumem
fundamental importância e tem um grande impacto na evolução de um projeto de
software [1].
5.1 Clientes
O Cliente está altamente envolvido no processo de desenvolvimento e frequentemente
faz parte da equipe de desenvolvimento. A presença do cliente é extremamente
importante em MAs, visto que a quantidade de documentação é reduzida ao mínimo e
a equipe de desenvolvimento frequentemente pede esclarecimento sobre os requisitos.
A presença constante do cliente substitui a maior parte da documentação requerida
para descrever requisitos em detalhe e sua contribuição é um fator chave para o
sucesso dos projetos. O cliente deve prover sempre feedbacks para a equipe de
desenvolvimento a fim de identificar potenciais problemas cedo no desenvolvimento e
evitar um grande impacto no cronograma do projeto.
Como dito anteriormente a técnica de elicitação de Participação Ativa do Cliente traz
vários benefícios, mas é muito difícil de ser implementada. Uma implementação
equivocada desta prática pode reduzir a efetividade de vários MAs, visto que a
maioria deles esta estreitamente acoplados com o envolvimento do cliente[1].
5.2 Desenvolvedores
Toda a equipe de desenvolvimento está altamente envolvida no gerenciamento de
clientes coletando e negociando requisitos. Os desenvolvedores têm que interagir
bem de perto com o cliente provendo um software que funcione e coletando feedbacks

33. 33
de grande valor. Por isto, as habilidades que são requeridas dos desenvolvedores em
equipes ágeis não são comuns. Eles têm que ser desenvolvedores muito bons, tem que
ser capazes de trabalhar em equipe e interagir com o cliente usando a linguagem
dele[11]. Visto que MAs focam nesta interação, a equipe de desenvolvimento tem a
responsabilidade de educar o cliente. MAs requerem um alto grau de
comprometimento do cliente no projeto devido aos constantes feedbacks que são
sempre requeridos pelos desenvolvedores [1].
A confiança entre a equipe de desenvolvimento e o cliente assume fundamental
importância. A equipe tem que prover um software que funcione e de alta qualidade
em cada iteração a fim de receber um bom feedback do cliente. Esta abordagem é
valiosa para ambos, desenvolvedores e clientes. Enquanto os desenvolvedores podem
coletar informações úteis para evitar a implementação de features desnecessárias,
clientes podem usar (ou ao menos testar) o produto em poucas semanas depois do
início do projeto [1].
5.3 Gerentes
Em MAs gerentes têm que criar e manter um framework para o estabelecimento de
uma interação produtiva entre a equipe de desenvolvimento e o cliente. Eles podem
realizar este objetivo identificando as melhores pessoas para serem incluídas nas
equipes ágeis, promovendo colaboração e negociando contratos com o cliente.
Geralmente, equipes ágeis trabalham com contrato com escopo de preço-variável ao
invés de contrato com escopo de preço-fixo. Esta abordagem está baseada na
habilidade que o gerente tem na definição de contratos para satisfazer o cliente e
permitir uma grande flexibilidade no processo de desenvolvimento, como é requerido
pelos MAs [1].

34. 34
6. Conclusão
Este trabalho apresentou técnicas e abordagens da Engenharia de Requisitos utilizadas
durante os processos de desenvolvimento ágeis. Visto que a metodologia ágil ainda é
muito nova e continua evoluindo, várias das técnicas de RE continuam sendo
estudadas e a efetividade de suas aplicações vem sendo avaliadas. Foi mostrado que a
ER ágil difere da ER tradicional e que os processos ágeis têm uma abordagem
iterativa de descoberta. Desenvolvimento ágil ocorre num ambiente onde coletar e
desenvolver uma especificação de requisitos completa e não ambígua é impossível ou
não apropriada [3]. Estas diferenças levaram a este conjunto de técnicas e abordagens
apresentadas aqui.
Foi mostrado que a intensa comunicação entre os desenvolvedores e os clientes é a
prática mais importante no processo ágil. Ao invés de ser seguido um procedimento
formal para se produzir uma especificação completa que descreve precisamente o
sistema, ER ágil é mais dinâmica e adaptativa. Os seus processos não são
centralizados em uma fase antes do desenvolvimento; eles estão igualmente
espalhados através de todo o desenvolvimento [3].
Como resultado deste trabalho chega-se a algumas conclusões importantes:
• Todas as atividades do processo da Engenharia de Requisitos tradicional estão
presentes nos processos ágeis. As técnicas usadas é que variam nas diferentes
abordagens e as fases não são tão claramente separadas. Esta abordagem
“lazy” à Engenharia de Requisitos tem vantagens em relação a custos, já que
ela adia o esforço/gasto com a apuração de detalhes dos requisitos o quanto
puder, ou seja, minutos antes do requisito ser implementado é que ele tem que
ser entendido pelos desenvolvedores. As técnicas usadas pelos processos ágeis
são algumas vezes descritas vagamente e a sua implementação é deixada nas
mãos dos desenvolvedores. As abordagens tradicionais, por outro lado, se
baseiam na descrição detalhada do que precisa ser feito e conseqüentemente
provê mais direção para como se fazer a coisa correta. Infelizmente,
determinar de frente qual é a melhor abordagem em um dado contexto de

35. 35
projeto ainda é muito difícil e é uma questão que ainda está sendo investigada
[2].
• O envolvimento do cliente é o ponto fundamental para o sucesso dos métodos
ágeis. A principal diferença entre métodos ágeis e tradicionais é o grau deste
envolvimento no processo de desenvolvimento. Porém, em relação a isto, ER
tradicional e ágil têm objetivos similares visto que participação efetiva do
cliente é essencial em qualquer projeto de software.
• Métodos Ágeis são uma boa abordagem para desenvolvimento de software de
um subconjunto relevante de projetos, mas seu limite ainda não está bem
definido [1].
• Métodos Ágeis gerenciam requisitos efetivamente em projetos pequenos, mas
apresentam muitos problemas em projetos grandes. MAs focam na produção
de valor para o cliente, reduzindo ao máximo qualquer coisa que não ofereça
este valor pelo ponto de vista do cliente. Já métodos tradicionais conseguem
gerenciar bem projetos grandes, mas o seu overhead não é bom para projetos
pequenos [1].
• Muitos clientes ainda encontram dificuldades em entender e acreditar em
processos de desenvolvimentos ágeis, visto que, a maioria dos clientes ainda
são mais acostumados a metodologias tradicionais, onde se produz uma
especificação de requisitos detalhada [3]. Porém, a tendência é que a
metodologia ágil ganhe força e se torne dominante para projetos com
características que favoreçam a sua aplicação.
Finalmente, pode-se concluir que apesar das práticas da ER ágil trazerem benefícios
como um melhor entendimento das necessidades dos clientes e a habilidade de
adaptarem-se as necessidades sempre em evolução dos ambientes dinâmicos de hoje,
eles propõem vários e distintos desafios. Portanto, as organizações devem sempre

36. 36
comparar os custos e benefícios da ER ágil em seus ambientes de projeto antes de
adotá-la.

37. 37
7. Referências Bibiográficas
[1] Aurum, Aybüke; Wohlin, Claes (Eds.) “Engineering and Managing Software
Requirements” 2005, XVIII, 478 p.
[2]. Paetsch F, Eberlein A, Maurer F (2003) Requirements engineering and Agile software
development. In Proceedings of 8th International Workshop on Enterprise Security, Linz,
Austria, 9-11 June.
[3] Lan Cao, Balasubramaniam Ramesh, "Agile Requirements Engineering Practices: An
Empirical Study," IEEE Software, vol. 25, no. 1, pp. 60-67, Jan/Feb, 2008.
[4] Ambler S (2002) When does(n’t) Agile modeling make sense? Accessed on December 5,
2004, http://www.agilemodeling.com/essays/whenDoesAMWork.htm.
[5] Bailey P, Ashworth N, Wallace N (2002) Challenges for stakeholders in adopting XP. In:
Proceedings of 3rd International Conference on eXtreme Programming and Agile Processes
in Software Engineering (XP2002), Alghero, Italy, 26-29 May.
[6] Beck K (1999) Extreme programming explained: Embrace change. Addison-Wesley, UK.
[7] Beck K, Beedle M, Bennekum A, Cockburn A, Cunningham W, Fowler M, Grenning J,
Highsmith J, Hunt A, Jeffries R, Kern J, Marick B, Martin RC, Mellor S, Schwaber K,
Sutherland J, Thomas D (2001) Manifesto for Agile software Development. Accessed on 5th
December 2004, online at: http://www.agilemanifesto.org/.
[8] Cockburn A, Williams L (2000) The costs and benefits of pair programming. In:
Proceedings of 1st International Conference on eXtreme Programming and Agile Processes in
Software Engineering (XP2000), Cagliari, Italy, 21-23 June.
[9] Cockburn A (2000) Selecting a project’s methodology. IEEE Software, 17(4): 64 71.
[10] Cockburn A, Highsmith J (2001) Agile software development: The business of
innovation. IEEE Computer, September, pp.120 122.
[11] Cockburn A, Highsmith J (2001) Agile software development: The people factor. IEEE
Computer, November, pp.131 133.
[12] Cockburn A (2002) Agile software development. Addison-Wesley, London, UK.
[13] Duncan R (2001) The quality of requirements in extreme programming. The Journal of
Defence Software Engineering, June 2001 issue.
[14] Cohen D, Lindvall M, Costa P (2003) Agile software development. DACS State-of-the-
Art Report. Accessed 5th December 2004, http://www.dacs.dtic.mil/techs/agile/agile.pdf.
[15] Cohn M, Ford D (2002) Introducing an Agile process to an organization. Access on 5th
December 2004
http://www.mountaingoatsoftware.com/articles/IntroducingAnAgileProcess.pdf

38. 38
[16] Glass R (2001) Agile versus traditional: Make love, not war. Cutter IT Journal,
December, 6(1): 12 18.
[17] Highsmith JA (1996) Adaptive software development. Dorset House Publishing, UK
[18] IEEE Standard 830 (1998) IEEE recommended practice for software requirements.
[19] IEEE Standard 1233 (1998) IEEE guide for developing system requirements
specifications [20] IEEE Standard 1362 (1998) IEEE guide for information technology:
System definition, concept of operations document.
[21] Lee C, Guadagno L, Jia X (2003) An Agile approach to capturing requirements and
traceability. In: Proceedings of 2nd International Workshop on Traceability in Emerging
Forms of Software Engineering, Montreal, Canada, 7 October.
[22] Nawrocki J, Jasinski M, Walter B, Wojciechowski A (2002) Extreme programming
modified: Embrace requirements engineering practices. In: Proceedings of International
Conference on Requirements Engineering, 9-13 September, Essen, Germany.
[23] Ohno T (1988) Toyota production system: Beyond large-scale production. Productivity
Press Cambridge, Mass.
[24] Ambler S (2001) Agile documentation. Accessed on 5th December 2004.
http://www.agilemodeling.com /essays/agileDocumentation.htm.
[25] Poppendieck T, Poppendieck M (2003) Lean software development: An agile toolkit for
software development managers. Addison-Wesley, London UK.
[26] Rasmusson J (2003) Introducing XP into Greenfield projects: Lessons learned. IEEE
Software, May/June, 20(3): 21 28.
[27] Ronkainen J, Abrahamsson P (2003) Software development under stringent hardware
constraints: Do Agile methods have a chance. In: Proceedings of 4th International Conference
on eXtreme Programming and Agile Processes in Software Engineering (XP2003), Genoa,
Italy, May 2003, pp.25 29.
[28] Schwaber K, Beedle M (2001) Agile software development with scrum. Prentice Hall
PTR, Australia.
[29] Sommerville I, Sawyer P, (2000) Requirements engineering: A good practice guide. John
Wiley & Sons, UK.
[30] Smith J. (2001) A comparison of RUP and XP. Rational software white paper. Accessed
5th December 2005
http://www.isk.kth.se/proj/2003/6b3403/sa3/www/RationalUnifiedProcess/ papers/rupxp.htm.
[31] Standish Group, CHAOS Report 1994.
[32] Stapleton J (1995) DSDM - Dynamic system development method. Addison-Wesley, UK
[33] Tomayko JE (2002) Engineering of unstable requirements using Agile methods. In:
Proceedings of International Conference on Time-Constrained Requirements Engineering,
Essen, Germany, 9-13 September.

39. 39
[34] Turk D, France R, Rumpe B (2002) Limitations of Agile software processes. In:
Proceedings of 3rd International Conference on eXtreme Programming and Agile Processes
in Software Engineering (XP2002), Alghero, Italy, 26 - 29 May.
[35] Wells D (2003) Don’t solve a problem before you get to it. IEEE Software, May/June,
20(3): 44 47.
[36] Womack JP, Jones DT (1998) Lean thinking: Banish waste and create wealth in your
corporation, Simon & Schuster.
[37]Young R (2002) Recommended requirements gathering practices, Accessed 5th
December 2004, http://www.stsc.hill.af.mil/crosstalk/2002/04/young.
[38]. Abrahamsson P, Salo O, Ronkainen J, Warsta J (2002) Agile software development
methods: Review and analysis. EPSOO 2002, VTT Publications 478.