UNIVERSIDADE FEDERAL DE PERNAMBUCO

PS-GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA

ENGENHARIA DE REQUISITOS PARA

MTODOS GEIS
Autor

Fernanda Rodrigues dos Santos dAmorim

Orientador

Prof. Jaelson Freire Brelaz de Castro

Recife, julho
julho 2008

Universidade Federal de Pernambuco

Centro de Informtica
 FERNANDA RODRIGUES DOS SANTOS DAMORIM

ENGEHARIA DE REQUISIOS PARA MTODOS GEIS

Monografia apresentada ao Curso de ps-graduao

em Cincia da Computao, Centro de Informtica,
Universidade Federal de Pernambuco, como
requisito parcial para concluso da disciplina
Engenharia de Requisitos.

Prof. Jaelson Brelaz de Castro

Recife
15 de Julho de 2008
RESUMO

Coletar, entender, e gerenciar requisitos um aspecto crtico em todos os mtodos de

desenvolvimento. Para mtodos geis isto tambm importante. Em particular, vrias
abordagens geis lidam com requisitos a fim de implement-los corretamente e
satisfazer as necessidades do cliente. Estas prticas focam numa interao contnua com
o cliente para dar suporte a evoluo dos requisitos, prioriz-los e entregar, de maneira
progressiva, as funcionalidades mais importantes. Este trabalho tem como objetivo
prover uma viso geral de como tcnicas da Engenharia de Requisitos so 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, Mtodos geis, Processos geis,

Gerenciamento de Variabilidade.
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.

7
SUMRIO

1. Introduo ..............................................................................................................10
2. Mtodos geis.........................................................................................................13
3. Engenharia de Requisitos Tradicional e gil......................................................19
3.1 O Processo da Engenharia de Requisitos Tradicional .............................20
3.1.1 Elicitao ...............................................................................................20
3.1.2 Anlise e Negociao.............................................................................20
3.1.3 Documentao .......................................................................................21
3.1.4 Validao ...............................................................................................21
3.1.5 Gerenciamento de Requisitos ..............................................................21
3.2 Processos de ER e o seu Impacto em Mtodos geis................................21
4. Tcnicas e Abordagens da Engenharia de Requisitos para Mtodos geis .....23
4.1 Envolvimento do Cliente .............................................................................23
4.2 Elicitao ......................................................................................................24
4.3 Modelagem ...................................................................................................25
4.4 Documentao ..............................................................................................25
4.5 Validao ......................................................................................................25
4.6 Gerenciamento .............................................................................................26
4.7 Requisitos Desnecessrios ...........................................................................28
4.8 Falha de Comunicao ................................................................................29
4.9 Requisitos No Funcionais ..........................................................................30
5. O Papel e Responsabilidades de Stakeholders em Mtodos geis .....................32
5.1 Clientes..........................................................................................................32
5.2 Desenvolvedores ...........................................................................................32
5.3 Gerentes ........................................................................................................33
6. Concluso................................................................................................................34
7. Referncias Bibiogrficas......................................................................................37

8
LISTA DE FIGURAS

Figura 1: Ciclo de Desenvolvimento gil [1]............................................... 15

Figura 2: Custo de Mudanas [1]................................................................... 27

LISTA DE TABELAS

Tabela 1: The Crystal Family [1]................................................................... 17

Tabela 2: Principais Causas de Falhas de Projetos [1].................................. 19

9
1. Introduo

Mudanas cada vez mais rpidas no ambiente de negcio, no qual a maioria das
organizaes opera, esto 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 esto a rpida mudana de ameaas competitivas,
de preferncias dos stakeholders, da tecnologia de desenvolvimento e a presso para o
produto entrar no mercado [3]. Isto, tem tornado a pr-especificao de requisitos
inapropriada para projetos que possuem tais caractersticas.

Mtodos geis (MAs), que procuram atacar os desafios emergentes destes contextos
dinmicos, tm ganho bastante interesse de pesquisadores e engenheiros de softwares
[3]. MAs constituem uma famlia 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 atravs da aplicao dos princpios da
produo enxuta para desenvolvimento de software [25].

Produo enxuta foi concebida durante a dcada de 50 pela Toyota [23]. Esta
abordagem envolve vrias prticas como desenvolvimento just-in-time,
gerenciamento de qualidade total e processo de melhoria contnuo. O princpio da
produo enxuta a constante identificao e remoo de perdas, isto , de tudo que
no agrega valor para o cliente do produto final. Baseados no princpio da produo
enxuta, MAs focam em [1]:

Agregar valor para o cliente

Garantir que o cliente entenda este valor e que o projeto satisfaa suas
necessidades.

MAs colocam muita nfase em produzir e entregar ao cliente somente features que
so teis. Produzir algum outro artefato que no requerido considerado um erro.

10
Segundo a filosofia gil, adicionar uma feature que no necessria no s consome
esforo sem agregar valor, mas tambm produz cdigo extra que pode conter erros,
deixando o sistema mais complexo para manter, corrigir e melhorar [1].

Para garantir tal eliminao de perdas, MAs propem ser [7]:

Mais adaptativos do que previsveis

Mais orientados a pessoas do que orientados a processos.

Para garantir a satisfao do cliente, procura-se uma colaborao 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. Freqentemente, Engenharia de Requisitos e
Mtodos geis so vistos como incompatveis: tradicionalmente, ER fortemente
baseada em documentao para compartilhar conhecimento enquanto que MAs so
focados em colaborao face-a-face entre desenvolvedores e clientes para atingir
objetivos similares[2].

Porm, uma anlise de vrios 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 ento, que a engenharia de requisitos tem grande importncia
para mtodos geis, podendo-se destacar como pontos fundamentais [1]:

A maioria das tcnicas de elicitao de requisitos no muda muito entre um

ambiente tradicional e um ambiente gil.
A priorizao de requisitos essencial, visto que o foco principal de MAs a
implementao das features mais valiosas para o cliente.

11
 A identificao de interao entre features e o desacoplamento entre elas
tambm de extrema importncia para a implementao de, exclusivamente,
features de alta prioridade.
A identificao dos requisitos inclusos numa mesma iterao baseada na
negociao entre os clientes e a equipe de desenvolvimento.

Este trabalho tem como objetivo principal expor quais tcnicas e abordagens da
Engenharia de Requisitos esto 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 seo 2 introduz

brevemente Mtodos geis. A seo 3 descreve os objetivos e os problemas comuns
da Engenharia de Requisitos. A seo 4 se aprofunda nas tcnicas e abordagens da
Engenharia de Requisitos aplicadas a Mtodos geis. A seo 5 discute o papel e
responsabilidades de stakeholders no Processo gil. E na seo 6 discutem-se
concluses sobre a aplicabilidade da Engenharia de Requisitos para Mtodos geis.

12
2. Mtodos geis

Mtodos geis so uma famlia de tcnicas de desenvolvimento projetadas para

entregar produtos no prazo correto, com alto grau de qualidade e satisfao do cliente
[1]. Esta famlia inclui mtodos bastante variados e diferentes. Os mais populares
so:

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 mtodos

poderia afastar pessoas interessadas em adot-los, j que estas poderiam ter
dificuldades em escolher o que aplicar em seus prprios processos[9,15]. Como
resultado, definiram um documento contendo um conjunto de valores bsicos e
comuns a todos os mtodos geis. Este documento chamado de Agile Manifesto
[7]. Sendo baseado em gerenciamento enxuto, estes valores focam em recursos
humanos e gerenciamento de processos [1]:

Indivduos e Interaes X Processos e Ferramentas: a abordagem gil d

muito mais nfase importncia das pessoas e suas interaes do que a
processos estruturados e ferramentas.

Colaborao dos Clientes X Contratos: o relacionamento entre a equipe de

desenvolvimento e o cliente regulado atravs do envolvimento do cliente no
processo de desenvolvimento e no atravs de contratos fixos e detalhados.

Software Funcionando X Documentao: o objetivo da equipe de

desenvolvimento entregar cdigo funcionando corretamente, visto que este
o artefato que prov valor ao cliente. Cdigo bem escrito auto-documentado
e uma documentao formal reduzida ao mnimo.

13
 Resposta Mudana X Planejamento: a equipe de desenvolvimento tem
que reagir rapidamente variao nos requisitos. As decises de binding que
afetam esta habilidade so postergadas o mximo possvel 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 prticas e comportamentos comuns so identificados. Este
tipo de abordagem no uma inovao da Comunidade gil, elas so
resultantes de experincias de sucessos e falhas no desenvolvimento de
software. Algumas destas prticas esto listadas a seguir [1]:

Adaptabilidade: as metodologias tm que ser adaptadas s

necessidades especficas para ambos, a equipe de desenvolvimento e os
clientes.

Desenvolvimento Incremental: as diferentes etapas do

desenvolvimento de software (anlise, projeto, implementao e teste)
so comprimidas em iteraes 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 freqentes: no fim de cada iterao, liberado um release

para o cliente test-lo e prover feedbacks. Esta abordagem traz vrios
benefcios como: (1) o cliente pode usar a aplicao bem cedo,
permitindo a identificao 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
evoluo do projeto est sempre visvel; (3) a confiana entre o cliente
e a equipe de desenvolvimento aumenta j que a equipe considerada
confivel porque ela capaz de entregar verses da aplicao que
funcionam logo no incio do processo.

14
 Priorizao de requisitos antes de cada iterao: antes de cada
iterao, 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 atravs de uma constante requisio de
feedbacks, a fim de identificar potenciais problemas logo no incio do
desenvolvimento. Em alguns casos, o cliente se torna um membro da
equipe de desenvolvimento e est sempre disponvel para interagir com
a equipe e clarificar questes relacionadas aos requisitos.

Figura. 1 - Ciclo de desenvolvimento gil [1]

Como mencionado, os valores bsicos e prticas de todos os MAs so bastante

parecidos. Mesmo assim, o termo Mtodos geis identifica uma famlia diversa de

15
metodologias de desenvolvimento com focos diferentes e pontos fortes e fracos
peculiar a cada uma delas. Existem diferentes nveis de agilidade em MAs. Uma
metodologia de desenvolvimento mais gil do que outra se ela requer menos
overhead (o que significa no produzir valor para o cliente) [1].

Em cada metodologia, a equipe de desenvolvimento tem diferentes prioridades,

processos, nveis de overhead para a interao dos membros da equipe, etc. Apesar
disso, no existe uma soluo nica para todos os contextos. Mtodos geis
fornecem diretrizes e um conjunto bsico de prticas e comportamentos que tm que
ser adaptados ao problema especfico [6,9]. A aplicabilidade de MAs ainda uma
preocupao de pesquisa [4,34]. Vrias questes ainda esto sendo discutidas, dentro
delas esto: (1) o tamanho do problema que pode ser tratado; (2) como as pessoas so
gerenciadas; (3) os domnios de aplicao no qual MAs so lucrativos [1].

Tamanho da equipe em Mtodos geis

A maioria dos MAs tm como alvo especfico 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.
Comunicao direta e documentao limitada s tornam-se possvel com uma
equipe pequena. Quando uma equipe cresce, o nvel de overhead proporcional a
este crescimento. Este overhead inclui: (1) documentao e (2) comunicao
mediada. Maior quantidade de documentao requerida para compartilhar
conhecimento e verificar o status do projeto porque, uma interao entre vrias
pessoas (many-to-many) no mais possvel [12]. Alm disso, a importncia da
documentao cresce e se torna uma maneira de melhorar a forma como o
conhecimento compartilhado. Neste caso, s o cdigo j no suficiente e a
comunicao direta entre a equipe de desenvolvimento e o cliente no possvel
quando estas equipes so muito grandes [1].

16
 Tabela 1 The Crystal Family [1]

Por estas razes, equipes pequenas so mais geis do que equipes grandes.
Contudo, os princpios bsicos do gerenciamento enxuto ainda so vlidos e a
maioria deles so escalveis. Um deles a melhoria contnua do processo atravs
da reduo de perdas. Este princpio vlido independentemente do tamanho da
equipe de desenvolvimento.

A famlia Crystal um exemplo de como a melhoria contnua do processo pode

combater estas dificuldades [12]. A metodologia gil Crystal inclui diferentes
MAs que se adquam s necessidades das equipes com diferentes tamanhos
(Tabela 1). Os diferentes nveis da The Crystal Family focam em diferentes
prticas a fim de gerenciar a escalabilidade. Uma escalabilidade limitada
alcanada reduzindo-se o nvel de agilidade.

Desenvolver grandes sistemas usando MAs difcil ou mesmo impossvel.

Atualmente, o esforo de pesquisa em MAs focam em projetos de tamanho
pequeno e mdio, visto que mesmo nesta rea a sua efetividade continua sendo
investigada. Algumas prticas geis simplesmente no so escalveis [1].

Gerenciando Pessoas em Mtodos geis

MAs focam no valor das pessoas para solucionar problemas e compartilhar

informao [11], e no no processo e numa grande quantidade de documentao
[24]. Contudo, a orientao 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 tm que ser excelentes desenvolvedores, serem
capazes de trabalhar em equipe, se comunicarem e interagirem com colegas e

17
 clientes, etc. Todas estas habilidades so obrigatria, na medida que os times so
auto-organizveis e no podem se basear em um processo pr-determinado e
detalhado para solucionar problemas e compartilhar conhecimento [10].

Aplicabilidade de Mtodos geis em Diferentes Domnios de Aplicao

Uma questo chave se MAs podem ser aplicados em todos os domnios de

aplicao. Isto ainda uma tema que est sendo investigado[4,9,34]. Em
particular, como e quando a utilizao de alguma prtica especfica resulta em
benefcios [24, 8, 27]. Em geral, MAs so eficientes para construir aplicaes
no crticas e com tamanho limitado. Pesquisadores esto estudando outras reas
como sistemas embarcados (ex. Telefones celulares e PDAs) onde performance,
comportamento de tempo real e restrio de memria so problemas inerentes [1].

MAs focam em produzir somente o que traz valor ao cliente, o que significa no
construir artefatos reusveis como por exemplo componentes. Se o objetivo do
projeto desenvolver um artefato reusvel, o time de desenvolvimento ir focar
neste problema e usar MAs para atac-lo. Porm, artefatos reusveis no so
construdos em projetos cujo objetivo no seja exatamente este, porque os
desenvolvedores tem que incluir features que no so teis ao projeto em
andamento[1].

MAs no so a soluo para desenvolver todos os tipos de produtos. Sua aplicao

extremamente difcil e s vezes impossvel para muitas reas, como sistemas crticos
de segurana, projetos muito grandes e aplicaes complexas [1]. Um dos grandes
desafios desta rea de se determinar em que contexto e sob quais caractersticas a
aplicao de abordagens geis ser mais lucrativa e eficiente em relao a um mtodo
tradicional.

18
3. Engenharia de Requisitos Tradicional e gil

Requisitos so a base de todos os produtos de software e sua elicitao,

gerenciamento e entendimento so 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
so: requisitos incompletos, baixo envolvimento do cliente, expectativas no realistas,
mudanas nos requisitos e requisitos desnecessrios [1].

Problema %
Requisitos incompletos 13.1
Baixo envolvimento do cliente 10.6
Falta de recursos 12.4
Expectativa no realista 9.9
Falta de suporte gerencial 9.3
Mudanas nos requisitos 8.7
Falta de planejamento 8.1
Requisitos desnecessrios 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 identificao,
modelagem, comunicao e documentao dos requisitos de um sistema, bem como,
com o contexto no qual o sistema estar inserido [2]. Requisitos descrevem quais
funcionalidades estaro disponveis e sob quais limitaes o sistema ir funcionar.
Eles dizem o que dever ser feito, mas no especificam como sero implementados.
Existem diversas tcnicas disponveis que so 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 suposies [2]:

19
 Quanto mais tarde erros forem descobertos maiores so os custos para corrigi-los.
possvel determinar um conjunto de requisitos estveis, antes de se comear 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:

Elicitao, Anlise e Negociao, Documentao, Validao e Gerenciamento [2].

3.1.1 Elicitao

Elicitao de Requisitos tenta descobrir os requisitos e identificar fronteiras do

sistema consultando os stakeholders (clientes, desenvolvedores, usurios). As
fronteiras definem o contexto do sistema. Durante esta atividade, essencial o
entendimento do domnio da aplicao, das necessidades do negcio, das restries do
sistema, dos stakeholders e do problema a ser resolvido. Toda esta aquisio de
conhecimento fundamental para o correto desenvolvimento do sistema. As tcnicas
da elicitao mais utilizadas so: Entrevistas, Cenrios/Casos de Uso, Observao e
Anlise Social, Grupos Focado, Brainstorming e Prototipagem.

3.1.2 Anlise e Negociao

Anlise de Requisitos tem como objeto checar os requisitos quanto a sua necessidade
(o requisito indispensvel ao sistema), quanto a sua consistncia (o requisito no
deve ser contraditrio), quanto a completude (nenhum servio ou restrio est
faltando) e quanto realidade (requisitos so realistas no contexto de custo e prazo do
projeto). Os conflitos nos requisitos so resolvidos atravs da priorizao e
negociao com os stakeholders. Solues para os problemas identificados so
acertadas e um compromisso firmado considerando um conjunto de requisitos que
foram concordados. As principais tcnicas de anlise e negociao so: Sesses de
Joint Application Development (JAD), Priorizao de Requisitos e Modelagem.

20
3.1.3 Documentao

O objetivo da documentao de requisitos comunicar os requisitos entre os

desenvolvedores e stakeholders do sistema. O documento de requisitos a base para
avaliar produtos e processos subseqentes (projeto, teste, verificao e validao) e
para controle de mudana. Um bom documento de requisitos no pode conter
ambigidades, tem que ser correto, entendvel, consistente, conciso e realista. Em
alguns casos, a especificao dos requisitos pode fazer parte do contrato do projeto.

3.1.4 Validao

O objetivo da validao de requisitos certificar que os requisitos so uma descrio

aceitvel do sistema a ser desenvolvido. As entradas para a atividade de validao so
o documento de requisitos, os padres e o conhecimento organizacional. As sadas so
uma lista que contem os problemas encontrados e as aes necessrias para resolver
os problemas reportados. As tcnicas usadas para validao de requisitos so reviso e
teste de requisitos.

3.1.5 Gerenciamento de Requisitos

O objetivo do gerenciamento capturar, armazenar, disseminar e gerenciar

informao. Gerenciamento de requisitos inclui todas as atividades preocupadas com
mudanas, controle de verso e rastreamento de requisitos. Rastreamento de requisitos
prov relacionamento entre requisitos, projeto e implementao de um sistema a fim
de gerenciar suas mudanas.

3.2 Processos de ER e o seu Impacto em Mtodos geis

Os processos de desenvolvimento tradicionais tm elaborado vrios padres

incluindo: (1) Padro IEEE 830 Prticas Recomendadas para Especificao de
Requisitos de Software [18]; (2) Padro IEEE 1233 Guia para Desenvolvimento de
Especificao de Requisitos de Sistemas [19]; (3) Padro IEEE 1362 Guia para
Tecnologia da Informao Definio de Sistema Documento de Conceito de
Operaes [20].

21
A importncia de se definir padres reside no fato de se ter um conjunto de diretrizes
previamente definidas por onde toda a equipe de desenvolvimento ser guiada.

MAs no se baseiam nestes padres para elicitao e gerenciamento de requisitos,

porm, eles tm adaptado muitas das idias bsicas ao seu ambiente[1]. Por
exemplo, em MAs toda a equipe de desenvolvimento est envolvida na atividade de
elicitao 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 mudanas est
incluso em seu processo como um ponto forte [33]. Alm do mais, MAs no tentam
prever mudanas 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 esforo extra[6]. O entendimento de variabilidade de
requisitos tem um forte impacto na habilidade de MAs serem enxutos. Em geral,
uma arquitetura genrica e mais abrangente esperada para suportar a variabilidade
nos requisitos que podem ser previstas com antecedncia. Contudo, uma arquitetura
mais complexa custa mais, no s para a equipe de desenvolvimento, mas tambm
para a equipe de manuteno e correo de erros [1].

22
4. Tcnicas e Abordagens da Engenharia de Requisitos para Mtodos
geis

MAs incluem prticas focadas nos fatores chaves listados na Tabela 2 para reduzir o
risco de falhas. Em particular, o objetivo principal do desenvolvimento incremental,
de releases freqentes, da priorizao de requisitos antes de cada iterao 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 ausncia deste compromisso a razo fundamental para projetos
no terminarem como planejados, ou seja, so concludos com atraso e com custos
extras ou simplesmente so abortados. O ponto chave de todas as abordagens geis
ter o cliente sempre acessvel [1].

Em MAs, o cliente assume um papel fundamental. Frequentemente o termo cliente

identifica um conjunto de stakeholders que pertencem organizao que est pagando
pelo desenvolvimento de um produto de software. Neste caso, a interao entre a
equipe de desenvolvimento e os stakeholders complexa devido a diferentes
percepes que os stakeholders possuem sobre o problema [5].

Em MAs, o problema de mltiplos stakeholders resolvido reduzindo-se este nmero

a apenas um, uma nica pessoa que ir representar todos os stakeholders envolvidos
no projeto. Este cliente deve ser um expert no domnio e deve tambm ser capaz de
tomar decises importantes como: aceitar o produto, priorizar requisitos, etc. No caso
de produtos de massa, no qual no existe uma organizao pagando diretamente por
ele, a equipe de desenvolvimento tem que identificar um expert na rea (ex. um expert
no mercado em questo) que seja capaz de agir como um cliente e participar do
desenvolvimento do produto [1].

23
Esta abordagem s possvel se o tamanho do problema limitado e uma nica
pessoa pode agir como o cliente, representando todos os stakeholders. Se o tamanho
do problema no permitir o uso de tal abordagem, a equipe tem que usar outras
tcnicas para elicitar e gerenciar os requisitos [1].

Em alguns MAs, a tcnica de participao 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 disponvel para discutir as questes relacionadas
ao projeto com qualquer membro da equipe[6]. Esta tcnica define alguns requisitos
especficos para o cliente [1]:

Disponibilidade: o cliente tem que estar sempre disponvel para responder

questes 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 questo vinda da equipe
de desenvolvimento, j que ele um expert no domnio e sabe como a
aplicao deve se comportar.
Poder de Deciso: o cliente capaz de tomar decises finais. Mudanas de
requisitos, aceitao da features implementadas, etc. podem ser decididas
diretamente por ele, permitindo um processo baseado em tomadas rpidas de
decises.

No fcil ter acesso a um cliente que seja capaz de satisfazer todos estes requisitos
[26]. A disponibilidade deste tipo de cliente de fundamental importncia em MAs,
visto que a maioria de suas vantagens(ex. reduo na documentao, entrega
incremental, etc.) esto fortemente acopladas com o grau de envolvimento do usurio
[1].

4.2 Elicitao

Como visto na seo anterior, o envolvimento do cliente o objetivo principal do

desenvolvimento gil. A tcnica mais comum da ER para elicitao de requisitos
relacionada a isto a entrevista. Entrevistas provem acesso direto e no filtrado para

24
a obteno do conhecimento necessrio. fato conhecido que transferncia de
conhecimento em cadeia provoca mal entendidos. Por isso, todas as abordagens geis
do nfase conversa direta com o cliente salientando que esta a melhor maneira de
coletar o conhecimento necessrio e preciso para o desenvolvimento do software.
Caso algo no esteja claro ou esteja vagamente definido, a equipe de desenvolvimento
deve procurar a pessoa responsvel diretamente. Este relacionamento direto tambm
ajuda a estabelecer um relacionamento de confiana entre desenvolvedores e clientes,
que essencial para o bom andamento do projeto. Com base nestes fatos, a entrevista
a principal tcnica de elicitao nos processos geis de ER [2].

4.3 Modelagem

Apesar de a modelagem ser usada em MAs, o propsito diferente quando

comparado a ER tradicional. Em MAs, modelos so usados para comunicar
entendimento de partes pequenas do sistema em desenvolvimento. Estes modelos so
quase descartveis. Eles so desenhados em quadros ou papis, sem uma tcnica
especfica de modelagem, e so apagados depois que atingirem seus objetivos, ou
seja, aps a equipe de desenvolvimento adquirir perfeito entendimento sobre a parte
do sistema em questo. A maioria destes modelos no se tornam parte da
documentao persistente do sistema [2].

4.4 Documentao

Em desenvolvimento gil gerar documentos de requisitos completos e consistentes

visto como impraticvel, ou pelo menos, como no realizvel com um custo efetivo.
A maioria dos mtodos geis possui algum tipo de documentao, ou recomendam o
uso de documentos de requisitos, porm, a deciso de sua extenso, contedo e etc.,
deixada nas mos da equipe de desenvolvimento e no so descritas em detalhes.
assumido que a documentao bem menor do que em abordagens tradicionais [2].

4.5 Validao

Abordagens geis usam frequentemente reunio de revises e testes de aceitao para

validao de requisitos. Reunies de reviso mostram se o projeto est no caminho

25
certo e dentro do cronograma, aumentando assim a confiana do cliente na equipe de
desenvolvimento. MAs usam diversos tipos de reunio de revises para apresentar o
novo software. Nelas, os clientes podem usar a aplicao, experimentar como o
sistema funciona e determinar que funcionalidades j foram implementadas. As
dvidas dos clientes podem ser esclarecidas imediatamente pelos desenvolvedores,
podendo discutir a implementao e sugerir mudanas no projeto. Durante a reunio,
eles ainda aprendem sobre os pontos fortes e fracos do projeto e da tecnologia e em
que rea existe vantagens e limitaes. Os clientes tambm podem executar um teste
de aceitao para validar se o sistema reage da maneira esperada, caso no, esclarecer
a questo na mesma hora [2].

4.6 Gerenciamento

Mtodos geis provem uma boa base para o gerenciamento de requisitos. Eles
assumem que muito difcil elicitar todos os requisitos do usurio logo no comeo de
um projeto de desenvolvimento. Tambm assumem que estes requisitos evoluem com
o tempo, visto que, o cliente pode mudar de opinio e o ambiente tcnico ou scio-
econmico tambm pode sofrer mudanas. Por isso, MAs assumem que mudanas
so inevitveis 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 trs suposies principais[6]: (1)requisitos no so
bem conhecidos no comeo do projeto; (2) requisitos mudam; (3) fazer mudanas no
to caro em um contexto gil.

Em particular, MAs assumem que o custo de introduzir mudanas num produto

praticamente constante atravs do tempo(Figura 2), mas esta hiptese no vlida
para todos os contextos. Geralmente, como fundamentado pela ER tradicional, o
custo de se fazer mudanas cresce exponencialmente com o tempo. Por outro lado, se
as fases de desenvolvimento esto agrupadas em iteraes bem curtas (Figura 1) e as
decises de binding so tomadas o mais tarde possvel, o crescimento dos custos
limitado [1, 6].

26
 Figura 2 - Custo de Mudanas [1]

Com o objetivo de gerenciar a evoluo de requisitos, MAs usam contratos com

escopo de custo-varivel[25]. Isto significa que tanto as features realmente
implementadas no sistema quanto seus custos evoluem com o tempo. Portanto,
requisitos no so especificados em detalhes em nvel de contrato, mas definidos
passo-a-passo durante o projeto atravs de um processo de negociao entre o cliente
e a equipe de desenvolvimento [1].

Gerenciar variabilidade um desafio que MAs tentam solucionar de duas tcnicas [1]:

Desacoplamento de Requisitos: requisitos tm que ser o mais independentes

possveis a fim de claramente identificar o que implementar e tornar
irrelevante a ordem de suas implementaes.

Elicitao e Priorizao de Requisitos: no comeo de cada iterao, existe

uma atividade de coletar e priorizar requisitos. Durante esta, novos requisitos
so identificados e priorizados. Esta abordagem ajuda a identificar as features
mais importantes dentro do projeto em andamento. Tipicamente, se um
requisito muito importante sua implementao fixada para a iterao que
est comeando, seno, ele entra na fila de espera. Na prxima iterao, os
requisitos que esto na fila so avaliados e se ainda continuarem vlidos, so
inclusos na lista de requisitos candidatos junto com os novos que foram
identificados. Ento, esta nova lista priorizada para identificar as features
que iro ser implementadas. Se um requisito no importante o suficiente, ele
ficar na lista de espera por um tempo indeterminado.

27
Esta abordagem capaz de identificar os requisitos mais importantes durante todo o
projeto, e no s no comeo. Requisitos que no so considerados muito importantes
no incio podem se tornar relevantes em algum estgio do projeto. Alm do mais, o
desacoplamento dos requisitos permite a implementao das features em quase
qualquer ordem. Assim, as features so implementadas de a cordo com suas
prioridades e no pela dependncia funcional entre algumas delas [1].

So duas as principais diferenas entre uma abordagem de priorizao gil e

tradicional: (1) em ER tradicional, os requisitos so priorizados apenas uma vez,
enquanto que na abordagem gil existe uma priorizao a cada ciclo de
desenvolvimento (Figura 1); (2) Em RE tradicional vrios fatores contribuem para o
estabelecimento das prioridades como: valores do negcio, risco, custo, e
dependncias de implementao. J em abordagens geis, a priorizao baseada em
somente um fator, valor do negcio definido pelo cliente [3].

4.7 Requisitos Desnecessrios

Outro foco de MAs a identificao e reduo de atividades desnecessrias no

processo de desenvolvimento [25]. Em particular, identificar e reduzir os requisitos
desnecessrios assume um papel fundamental. Em prticas enxutas, a reduo 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 desnecessrios

Gerenciar a evoluo de requisitos

Requisitos desnecessrios 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]:

28
 Mais cdigo fonte para escrever e custo extra
Maior complexidade do cdigo fonte
Atrasos na entrega da verso final da aplicao contendo todas as
funcionalidades requeridas.
Manuteno mais complexa e cara
Quantidade maior de recursos requeridos pela aplicao, incluindo: uso de
memria, poder de processamento, uso de rede, etc.
Aumento da complexidade da aplicao do ponto de vista do cliente (ex. GUI
mais completa, mais esforo para aprender a usar a aplicao, 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 no prov nenhuma soluo especfica. Mesmo o

cliente sendo um expert no seu domnio, a tarefa de identificar as features que ele
realmente precisa no fcil. Em geral, clientes pedem mais do que precisam,
incluindo uma grande variedade de features que no estaro provendo um ganho real
para o seu negcio. Estes requisitos so desnecessrios, portanto, so fontes de
lixo. Com o objetivo de reduzir este tipo de risco, MAs usam as seguintes tcnicas
[1]:

Priorizao de Requisitos: o cliente e a equipe de desenvolvimento atribuem

prioridade para cada requisito a fim de identificar as features mais importantes
que tm que ser implementadas primeiro.
Releases Incrementais: funcionalidades so lanadas em pequenas, mas
freqentes releases (de 2 semanas a 2 meses), com o objetivo de estar sempre
coletando feedbacks do cliente.

4.8 Falha de Comunicao

Um mal entendido gerado por alguma falha na comunicao entre o cliente e a equipe
de desenvolvimento gera requisitos errados. A fim de reduzir a probabilidade deste

29
problema, MAs adotam vrias tcnicas focadas na melhoria da interao entre o
cliente e a equipe de desenvolvimento [1]:

Toda a equipe de desenvolvimento coleta requisitos junto ao cliente:

elicitao de requisitos uma atividade na qual toda a equipe est envolvida.
Assim, o uso de documentao para compartilhar conhecimento reduzido ao
mnimo e a probabilidade de mal entendidos diminui.
Requisitos so coletados usando uma linguagem comum: requisitos so
coletados usando a linguagem do cliente, e no uma linguagem formal para
especificao de requisitos. Isto significa que os desenvolvedores tm que ser
introduzidos ao domnio de aplicao do cliente a fim de entend-lo.
Interao direta entre a equipe de desenvolvimento e o Cliente: no existe
nenhum intermedirio entre a equipe de desenvolvimento e o cliente. Esta
abordagem reduz tanto o nmero de documentos requeridos quanto a
probabilidade de mal entendidos devido criao de camadas extras de
comunicao.
Diviso de requisitos: se a equipe de desenvolvimento considerar algum
requisito como sendo muito complexo, esta tcnica ajuda o cliente a quebrar o
requisito em outros mais simples. Esta diviso ajuda desenvolvedores s
entender melhor as funcionalidades requeridas pelo cliente.

4.9 Requisitos No Funcionais

MAs no tm nenhuma tcnica especfica que seja uma unanimidade para elicitao e
gerenciamento dos requisitos no-funcionais[2]. Estes requisitos so coletados
implicitamente durante a atividade de elicitao de requisitos. A necessidade de se
especificar requisitos no-funcionais menos importante em MAs do que em
contextos tradicionais devido contnua interao com o cliente. Depois de cada
iterao, o produto lanado e o cliente pode test-lo. Se ele identificar problemas
relacionados a qualidades no-funcionais, a equipe pode adaptar o sistema para atingir
estes requisitos na iterao subseqente sem ter grande impacto no cronograma [1].

30
Frequentemente, o cliente no consegue enxergar muitos dos requisitos no-
funcionais (ex. escalabilidade, segurana, etc.) como um grande impacto. Isto pode
afetar profundamente o lanamento da verso final da aplicao, por isso, a equipe de
desenvolvimento tem que guiar o cliente a fim de identificar estas necessidades que
no so facilmente visveis. Esta abordagem para requisitos no funcionais pode
representar um risco muito grande para MAs, medida que faltam tcnicas para o
gerenciamento destes.

31
5. O Papel e Responsabilidades de Stakeholders em Mtodos geis

MAs requerem um alto grau de interao entre clientes, gerentes e desenvolvedores.

Usualmente esta iterao no intermediada e todos os stakeholders se encontram
frequentemente em reunies a fim de melhorar o entendimento mtuo, a qualidade do
produto final e manter o projeto sob controle (no prazo e custo correto) [1].

Papis e Responsabilidades de clientes, gerentes e desenvolvedores assumem

fundamental importncia e tem um grande impacto na evoluo 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 presena do cliente extremamente
importante em MAs, visto que a quantidade de documentao reduzida ao mnimo e
a equipe de desenvolvimento frequentemente pede esclarecimento sobre os requisitos.
A presena constante do cliente substitui a maior parte da documentao requerida
para descrever requisitos em detalhe e sua contribuio 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 tcnica de elicitao de Participao Ativa do Cliente traz

vrios benefcios, mas muito difcil de ser implementada. Uma implementao
equivocada desta prtica pode reduzir a efetividade de vrios 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 tm que interagir
bem de perto com o cliente provendo um software que funcione e coletando feedbacks

32
de grande valor. Por isto, as habilidades que so requeridas dos desenvolvedores em
equipes geis no so comuns. Eles tm 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 interao, 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 so
sempre requeridos pelos desenvolvedores [1].

A confiana entre a equipe de desenvolvimento e o cliente assume fundamental

importncia. A equipe tem que prover um software que funcione e de alta qualidade
em cada iterao a fim de receber um bom feedback do cliente. Esta abordagem
valiosa para ambos, desenvolvedores e clientes. Enquanto os desenvolvedores podem
coletar informaes teis para evitar a implementao de features desnecessrias,
clientes podem usar (ou ao menos testar) o produto em poucas semanas depois do
incio do projeto [1].

5.3 Gerentes

Em MAs gerentes tm que criar e manter um framework para o estabelecimento de

uma interao produtiva entre a equipe de desenvolvimento e o cliente. Eles podem
realizar este objetivo identificando as melhores pessoas para serem includas nas
equipes geis, promovendo colaborao e negociando contratos com o cliente.
Geralmente, equipes geis trabalham com contrato com escopo de preo-varivel ao
invs de contrato com escopo de preo-fixo. Esta abordagem est baseada na
habilidade que o gerente tem na definio de contratos para satisfazer o cliente e
permitir uma grande flexibilidade no processo de desenvolvimento, como requerido
pelos MAs [1].

33
6. Concluso

Este trabalho apresentou tcnicas e abordagens da Engenharia de Requisitos utilizadas

durante os processos de desenvolvimento geis. Visto que a metodologia gil ainda
muito nova e continua evoluindo, vrias das tcnicas de RE continuam sendo
estudadas e a efetividade de suas aplicaes vem sendo avaliadas. Foi mostrado que a
ER gil difere da ER tradicional e que os processos geis tm uma abordagem
iterativa de descoberta. Desenvolvimento gil ocorre num ambiente onde coletar e
desenvolver uma especificao de requisitos completa e no ambgua impossvel ou
no apropriada [3]. Estas diferenas levaram a este conjunto de tcnicas e abordagens
apresentadas aqui.

Foi mostrado que a intensa comunicao entre os desenvolvedores e os clientes a

prtica mais importante no processo gil. Ao invs de ser seguido um procedimento
formal para se produzir uma especificao completa que descreve precisamente o
sistema, ER gil mais dinmica e adaptativa. Os seus processos no so
centralizados em uma fase antes do desenvolvimento; eles esto igualmente
espalhados atravs de todo o desenvolvimento [3].

Como resultado deste trabalho chega-se a algumas concluses importantes:

Todas as atividades do processo da Engenharia de Requisitos tradicional esto

presentes nos processos geis. As tcnicas usadas que variam nas diferentes
abordagens e as fases no so to claramente separadas. Esta abordagem
lazy Engenharia de Requisitos tem vantagens em relao a custos, j que
ela adia o esforo/gasto com a apurao de detalhes dos requisitos o quanto
puder, ou seja, minutos antes do requisito ser implementado que ele tem que
ser entendido pelos desenvolvedores. As tcnicas usadas pelos processos geis
so algumas vezes descritas vagamente e a sua implementao deixada nas
mos dos desenvolvedores. As abordagens tradicionais, por outro lado, se
baseiam na descrio detalhada do que precisa ser feito e conseqentemente
prov mais direo para como se fazer a coisa correta. Infelizmente,
determinar de frente qual a melhor abordagem em um dado contexto de

34
 projeto ainda muito difcil e uma questo que ainda est sendo investigada
[2].

O envolvimento do cliente o ponto fundamental para o sucesso dos mtodos

geis. A principal diferena entre mtodos geis e tradicionais o grau deste
envolvimento no processo de desenvolvimento. Porm, em relao a isto, ER
tradicional e gil tm objetivos similares visto que participao efetiva do
cliente essencial em qualquer projeto de software.

Mtodos geis so uma boa abordagem para desenvolvimento de software de

um subconjunto relevante de projetos, mas seu limite ainda no est bem
definido [1].

Mtodos geis gerenciam requisitos efetivamente em projetos pequenos, mas

apresentam muitos problemas em projetos grandes. MAs focam na produo
de valor para o cliente, reduzindo ao mximo qualquer coisa que no oferea
este valor pelo ponto de vista do cliente. J mtodos tradicionais conseguem
gerenciar bem projetos grandes, mas o seu overhead no 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
so mais acostumados a metodologias tradicionais, onde se produz uma
especificao de requisitos detalhada [3]. Porm, a tendncia que a
metodologia gil ganhe fora e se torne dominante para projetos com
caractersticas que favoream a sua aplicao.

Finalmente, pode-se concluir que apesar das prticas da ER gil trazerem benefcios
como um melhor entendimento das necessidades dos clientes e a habilidade de
adaptarem-se as necessidades sempre em evoluo dos ambientes dinmicos de hoje,
eles propem vrios e distintos desafios. Portanto, as organizaes devem sempre

35
comparar os custos e benefcios da ER gil em seus ambientes de projeto antes de
adot-la.

36
7. Referncias Bibiogrficas

[1] Aurum, Aybke; 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(nt) 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 projects 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

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

38
[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) Dont 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.

39