r

A Engenharia de Requisitos
e o Desenvolvimento gil
colaborativo, just enough, just in time, sustentvel -

Rainer Grau e Kim Lauenroth,

com apoio de Bogdan Bereza,
Erik van Veenendaal
e Sven van der Zee.

Traduo de Paul Tornquist

Em
02 de setembro de 2014

Patrocnio

www.tmtestes.com.br

Todos os direitos reservados. Nenhuma parte desta publicao pode ser reproduzida, armazenada em um sistema de
arquivamento ou transmitida de qualquer forma, ou por qualquer meio, seja eletrnico, mecnico, fotocpia, ou
gravao ou qualquer outro, sem a autorizao prvia e por escrito dos autores ou do IREB e.V.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 1 de 18

 r

Sumrio

1 Introduo....................................................................................................................................................................... 3

1.1 A Engenharia de Requisitos como tcnica especializada ........................................................................ 3

1.2 Sobre este artigo .......................................................................................................................................................... 4

2 A Incerteza um Fato ............................................................................................................................................... 4

2.1 A incerteza uma caracterstica dos modernos mercados orientados ao cliente ....................... 4

2.2 Por que as organizaes insistem no modelo em cascata........................................................................ 5

3 A Engenharia de Requisitos e a Agilidade ....................................................................................................... 6

3.1 A agilidade promove um fluxo contnuo de informaes nas organizaes .................................. 6

3.2 O impacto sobre a Engenharia de Requisitos ................................................................................................ 6

3.3 O impacto das suposies........................................................................................................................................ 8

3.4 Gerenciar a incerteza atravs do feedback e do aprendizado ............................................................... 9

4 A Engenharia de Requisitos Independente do Modelo de Processo ............................................ 10

4.1 A aplicao da disciplina diferente ............................................................................................................... 10

4.2 A Engenharia de Requisitos em projetos geis complexos e extensos .......................................... 12

4.3 A evoluo dos formatos de documentao da Engenharia de Requisitos .................................. 13

5 O Manifesto gil e a Engenharia de Requisitos ......................................................................................... 15

6 Resumo ......................................................................................................................................................................... 17

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 2 de 18

 r

1 Introduo

1.1 A Engenharia de Requisitos como tcnica especializada

As organizaes que trabalham em um ambiente gil comprovadamente entregam produtos ou
servios mais prximos das necessidades e expectativas do cliente. Os benefcios da metodologia
gil incluem maior flexibilidade, rapidez no lanamento do produto ou servio para o mercado e
ganhos de produtividade. Esses benefcios no vm de graa. As organizaes que seguiram
esse caminho realizaram grandes investimentos no desenvolvimento de pessoas, em treinamento
e coaching, em mtodos e tcnicas, bem como em ferramentas de suporte para esses mtodos e
tcnicas (ver [1]).
Um exemplo muito bom para tal investimento o movimento em torno de conceitos como o
desenvolvimento orientado a testes de aceitao (acceptance test driven development) e entrega
contnua (continuous delivery). Por trs desses dois termos h um grande conjunto de tcnicas e
mtodos, complementados por investimentos significativos em ambientes, ferramentas e no
desenvolvimento de pessoas, e por ltimo mas no menos importante, uma mudana de
mentalidade em relao colaborao. As organizaes que conseguiram percorrer esse longo
caminho de melhoria contnua na entrega de testes e no desenvolvimento de software nunca mais
voltaram ao que faziam antes (ver [5]).
No que diz respeito disciplina de Engenharia de Requisitos, a comunidade gil est insastisfeita
com as abordagens tradicionais, com seus documentos iniciais que podem s vezes chegar a
centenas de pginas e criam "Especificaes" que j esto desatualizadas quando a primeira
linha de cdigo est sendo desenvolvida. Essa insatisfao est inclusive expressa no manifesto
para o desenvolvimento gil de software, que afirma valorizar:
Software em funcionamento, mais que documentao abrangente.
Infelizmente, isso teve como resultado que a comunidade de desenvolvimento gil passou a
considerar antiquadas as descries da disciplina de Engenharia de Requisitos: Isso a coisa
de antigamente, intil, agora precisamos fazer de outro jeito.
Neste ponto, no entanto como representantes do International Requirements Engineering Board
(IREB) queremos expressar a nossa posio taxativa: A Engenharia de Requisitos uma
disciplina independente de qualquer modelo de processo ou abordagem de desenvolvimento de
software. A Engenharia de Requisitos definida pelo IREB nos seguintes termos(ver [2]):

A Engenharia de Requisitos uma abordagem sistemtica e disciplinada para a especificao e o

gerenciamento de requisitos, com os seguintes objetivos:
[1] Conhecer os requisitos relevantes, alcanar um consenso entre os stakeholders sobre esses
requisitos, document-los de acordo com determinadas normas, e gerenci-los de forma
sistemtica.
[2] Compreender e documentar os desejos e necessidades dos stakeholders.
[3] Especificar e gerenciar os requisitos para minimizar o risco de entregar um sistema que no
atende os desejos e necessidades dos stakeholders.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 3 de 18

 r

Alm disso, acreditamos que a disciplina da Engenharia de Requisitos constitui uma competncia
central em qualquer processo de desenvolvimento de software, uma vez que ela responsvel
pela comunicao contnua e a confirmao do que precisa ser feito (e por que) para atender as
necessidades de stakeholders e usurios. A Engenharia de Requisitos uma tcnica
especializada essencial e necessria no mundo complexo do desenvolvimento de produtos e
servios.
Nossa resposta para a objeo "Isso a coisa de antigamente, intil, agora precisamos fazer de
outro jeito" a seguinte: "Coisa de antigamente? Sim. Intil? No! Fazer de outro jeito? Tudo
bem, sem problema! Muitos membros do IREB esto envolvidos ativamente no movimento gil e
compartilham a mentalidade das organizaes geis, buscando aumentar a flexibilidade, a
produtividade e a rapidez de entrega de produtos e servios para o mercado.

1.2 Sobre este artigo

Este artigo discute a disciplina de Engenharia de Requisitos sob o ponto de vista de diferentes
modelos de ciclo de vida. O artigo sustenta que a Engenharia de Requisitos um fator essencial
de sucesso em qualquer modelo de ciclo de vida, seja no modelo cascata ou no modelo gil.
No item 2, o artigo reflete sobre o que leva muitas organizaes a substituir modelos de ciclo de
vida sequenciais por modelos iterativos e geis. O objetivo dessa mudana estabelecer um fluxo
contnuo de requisitos entre usurios e clientes em toda a organizao. A incerteza um aspecto
importante nessa reflexo.
No item 3, o artigo discute a aplicao de atividades da Engenharia de Requisitos em ambientes
geis. Veremos que o know-how da Engenharia de Requisitos relevante tanto para modelos de
ciclo de vida em cascata quanto para modelos de ciclo de vida gil.
O item 4 aborda as diferenas de aplicao, a sequncia e o momento adequado das atividades
relacionadas com a Engenharia de Requisitos nos modelos de ciclo de vida em cascata e nos
modelos geis.
O item 5 deste artigo considera se a Engenharia de Requisitos, enquanto tcnica especializada,
compatvel com a mentalidade gil, analisando lado a lado a definio de Engenharia de
Requisitos do IREB e o manifesto gil. Essa validao essencial para determinar se o conjunto
de conhecimentos IREB abrangente em ambientes geis.
Mas, vamos comear com a causa fundamental da maioria dos nossos problemas na engenharia
de software: a incerteza.

2 A Incerteza um Fato
2.1 A incerteza uma caracterstica dos modernos mercados orientados ao cliente
A demanda por maior flexibilidade e produtividade tem suas razes em ciclos de produto
dramaticamente mais curtos e na elevada presso do mercado para entregar produtos e servios
que encantam os clientes. As pesquisas demonstram que os ciclos de produto reduziram-se
drasticamente, passando de uma mdia de seis anos na dcada de 1980, para seis meses em
2010 [6].

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 4 de 18

 r

Isso teve um forte impacto sobre as organizaes. Como os crculos de inovao so muito
rpidos, a presso para encurtar o tempo de entrega para o mercado alta, e os horizontes de
planejamento de longo prazo perdem relevncia frente a um mercado e uma economia em
transformao constante. A confiabilidade do planejamento de mdio e longo prazo baixa devido
ao aumento da incerteza sobre o desenvolvimento do mercado. Uma organizao ser bem
sucedida sempre que conseguir adaptar rapidamente seu modelo de negcio e seu portflio de
produtos e servios em resposta s foras dinmicas do mercado.
O desenvolvimento gil e lean uma abordagem que favorece a performance em condies de
maior incerteza. As empresas que apresentam um bom desempenho nessas condies muitas
vezes adotam mtodos geis e outras tcnicas iterativas em toda a organizao. Em mercados
caracterizados por mudanas rpidas e orientados para o consumidor, os modelos de ciclos de
vida geis e iterativos comprovadamente aumentaram a taxa de sucesso dos projetos [1].

2.2 Por que as organizaes insistem no modelo em cascata

Dada a evidncia de que um modelo de ciclo de vida gil aumenta a taxa de sucesso em
mercados em rpida mudana, por que muitas organizaes ainda insistem com abordagens
clssicas, caracterizadas por grandes fases iniciais de elicitao de requisitos, resultando em
enormes especificaes e terminando em processos em cascata?
Entre outros, os motivos mais importantes so:
A iluso da previsibilidade: A gesto clssica trata a incerteza como uma questo pessoal. Sua
auto-percepo : "Precisamos saber exatamente para onde estamos indo." Nessa mentalidade,
a gesto define as metas. Como resultado, as metas, o plano e o oramento geralmente so fixos.
Quaisquer alteraes nas metas, planos e oramentos so vistas como problemas e riscos para o
atingimento das metas, e no como aspectos "normais" da vida sob as condies de um mercado
dinmico. A gesto orientada a metas, planos e oramentos identifica nos modelos de ciclo de
vida gil um risco adicional para atingir as metas que foram acordadas, em vez de um mecanismo
inteligente de adaptao a mudanas.
Projetos (empresariais) possuem marcos (milestones) fixos: As organizaes que oferecem
produtos e servios no precisam apenas lidar com mercados em constante mudana. Outro
aspecto igualmente importante o cumprimento de normas legais e outros regulamentos. Temos
como exemplo: bancos, seguradoras, servios mdicos, agncias ambientais, distribuidoras de
energia, entre outros setores. Se uma norma muda, a organizao tem um certo prazo para entrar
em conformidade com este regulamento. Assim, tanto a meta (assegurar conformidade com a
norma) quanto o componente de planejamento (at o prazo x) so determinaes externas. Em
organizaes onde grandes investimentos so direcionados para questes de conformidade e
regulamentos, a mentalidade focada em metas, planos e oramentos predominante. A fatia mais
dinmica e orientada para o mercado, do oramento de investimento - muitas vezes por razes de
padronizao - tratada com a mesma mentalidade: metas, planos, oramentos.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 5 de 18

 r

As organizaes com outro histrico ou que operam em um ambiente diferente assumem o risco
de agir de outra forma. As histrias de sucesso da Amazon, Facebook ou Google demonstram
que a adaptao rpida para mercados em constante mudana, com base no feedback do
usurio, uma abordagem vlida para lidar com a incerteza. Muitos servios bem sucedidos do
Google comearam com uma verso beta e surgiram a partir do feedback dos usurios. Os
usurios apreciam esse comportamento. A gesto nessas organizaes do tipo: "No sabemos
exatamente qual a meta. Na verdade, so os nossos usurios que sabem. Mas sabemos como
chegar l o mais rapidamente possvel". Essa uma abordagem muito diferente das organizaes
clssicas, uma abordagem que incorpora princpios geis e lean.

3 A Engenharia de Requisitos e a Agilidade

Seguir a ideia da inovao incremental atravs do desenvolvimento iterativo realizado em
pequenos passos, como a Amazon, o Facebook ou o Google, implica em mudanas fundamentais
no modelo operacional de uma organizao. As coisas que antes eram feitas em sequncia
precisam ser executadas paralelamente. Isso se aplica a todos os diferentes aspectos do
desenvolvimento de produtos e servios, desde o nvel estratgico at o operacional.

3.1 A agilidade promove um fluxo contnuo de informaes nas organizaes

O fluxo clssico de informao sequencial, comeando com a definio de uma estratgia,
decompondo essa estratgia top-down na definio de um portflio e um plano para desenvolver
um conjunto de produtos com um roteiro fixo, no vai funcionar nesses cenrios. A construo de
um plano de negcios fixo, abrangendo um perodo de um a cinco anos, no existe mais.
Em vez disso, um fluxo de trabalho contnuo, de carter marcadamente paralelo em todos os
nveis de uma organizao, promove a influncia e o feedback recproco. O fluxo de informaes
do nvel estratgico at o operacional to importante quanto o fluxo de feedback dos usurios,
seja a nvel de produto ou do portflio, para as atividades de definio de estratgia, refletindo
mudanas do mercado atual.
Os indivduos em uma organizao trabalham em paralelo na adoo da estratgia (baseado em
feedback bottom-up), no desenvolvimento do portflio de produtos e servios (em alinhamento
com a nova estratgia e para criar o portflio existente com base no feedback dos clientes), bem
como no desenvolvimento e operao (a entrega da prxima verso do produto).

3.2 O impacto sobre a Engenharia de Requisitos

Os modelos de ciclo de vida em cascata ordenam as atividades em sequncia com funes
predefinidas. Cada etapa do processo tem inputs e outputs previamente definidos, e cada etapa
tem durao definida. A experincia industrial1 demonstra que um processo sequencial como esse
geralmente no alcana a meta almejada, pois a equipe de desenvolvimento e os stakeholders
aprimoram a sua compreenso do sistema ao longo de todo o processo de desenvolvimento. As
lies aprendidas com a melhor compreenso do mbito do problema precisam voltar para o
projeto em forma de feedback.

1
Essa experincia j foi apresentada por Winston W. Royce em seu artigo Gerenciando o Desenvolvimento de Grandes Sistemas de
Software" (muitas vezes considerado como a origem do conceito cascata).

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 6 de 18

 r

Nos modelos de ciclo de vida em cascata, esse feedback toma a forma de um processo de
gerenciamento de mudanas, com medidas explcitas para gerenciar o fluxo de informaes que
retornam para os projetos a partir das lies aprendidas, dos problemas encontrados e de
mudanas externas no contexto de trabalho. Em muitas organizaes, o processo de gesto de
mudana uma estrutura pesada, com alto impacto em termos de custo e trabalho.
A ordem das atividades e a forma de colaborao diferente no modelo de ciclo de vida gil. Ao
longo de todo o projeto, a equipe trabalha os requisitos em estreita colaborao com os
stakeholders e usurios, desenvolvendo o sistema produtivo de forma incremental. O objetivo
central do modelo de ciclo de vida gil obter feedback de maneira rpida e direta dos
stakeholders e usurios, de preferncia atravs do uso do prprio sistema. O feedback direto
obtido a partir do uso do sistema mostrou ser a melhor evidncia de que o desenvolvimento do
sistema est seguindo a direo pretendida pelos objetivos do sistema. Na disciplina da
Engenharia de Requisitos, as equipes geis trabalham continuamente com os stakeholders e
usurios:
Na elicitao de requisitos, ou seja, na identificao e especificao de novos picos e histrias de
usurios alinhadas aos objetivos dos stakeholders e dos usurios, ou em atividades de refinamento
do backlog.

No detalhamento maior de picos e histrias de usurios at que sua definio esteja confirmada
como completa, bem como na especificao de critrios de aceitao para que a equipe tenha todas
as informaes necessrias para desenvolver, a partir desses requisitos, uma parte produtiva do
sistema que fornea o valor esperado para o negcio.

No desenvolvimento de requisitos de design, para atender requisitos adicionais implcitos e no-

funcionais provenientes de reas como usabilidade (aspectos como atratividade, facilidade de
aprendizagem, compreensibilidade).

Nos testes de verificao e validao da Engenharia de Requisitos executados nas partes do sistema
desenvolvidas at agora com qualidade e status potencial de entrega.

A equipe executa todas essas atividades em paralelo. Cada membro da equipe atua em mais de
uma funo. Ao discutir a histria do usurio e definir critrios de aceitao com um stakeholder,
um membro da equipe desempenha o papel de engenheiro de requisitos. Ao implementar a
histria do usurio, preferencialmente aps um processo de design orientado por testes de
aceitao, o membro da equipe atua como desenvolvedor e testador.
A diferena entre os dois modelos de ciclo de vida est na maneira em que os papis so
atribudos s pessoas. As organizaes que preferem o modelo em cascata muitas vezes
atribuem a uma pessoa exatamente um papel. O efeito desse engessamento de papis que ao
longo do processo de desenvolvimento, muitos indivduos trabalham em uma funo do produto.
Assim, a responsabilidade pelas funcionalidades do produto distribuda entre vrios indivduos.
A documentao inicial substitui a comunicao direta e o feedback com os stakeholders,
resultando em suposies que podem mais tarde revelar-se equivocadas e acabam gerando
solicitaes de mudana. A organizao de um projeto como esse funciona como uma espcie de
telefone sem fio entre os vrios papis que participam no desenvolvimento de um requisito. Nas
organizaes que preferem o modelo de ciclo de vida gil, cada membro da equipe desempenha
mais de um papel e troca de papis conforme o trabalho exige. A comunicao direta com os
stakeholders e o feedback rpido mantm atualizado e ativo o conhecimento da equipe, o que
reduz a necessidade de documentao.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 7 de 18

 r

3.3 O impacto das suposies

Outro fator importante nos mercados em rpida mudana a confiabilidade e a durabilidade das
suposies. Um requisito que no uma meta predefinida, no uma restrio fixa e no foi
validado ainda pelo usurio pode ser considerado uma suposio. Tal requisito descreve uma
caracterstica do produto ou do sistema que vir a existir no futuro. Em ltima anlise, no entanto,
devemos confessar que todas essas afirmaes so suposies at que tenham sido validadas
pelo produto desenvolvido. Suposies podem ser vlidas, mas podem tambm estar incorretas.
Falhas baseadas em suposies incorretas ocorrem tanto em projetos em cascata quanto em
projetos geis e precisam ser enfrentadas. O importante entender as implicaes do respectivo
modelo de ciclo de vida ao lidar com suposies invlidas:

O perodo entre a formulao inicial da suposio e sua validao pelo sistema desenvolvido
muito maior em projetos em cascata do que em projetos geis. Em projetos em cascata, as
suposies so validadas dentro de uma fase explcita de integrao e testes de aceitao pelo
usurio. Projetos geis, com um ciclo curto de iterao, validam as suposies em cada iterao
a partir de testes de aceitao do usurio e sesses de reviso com os stakeholders.

Quanto maior o perodo para validar uma suposio no confronto com a realidade, maior a
probabilidade de mudanas, especialmente em ambientes onde o contexto em torno do prprio
projeto sofre mudanas. Mesmo estando correta no momento em que foi formulada, mais
provvel que uma suposio venha a se tornar invlida durante o tempo de ciclo mais longo de
um projeto em cascata, do que no curto tempo de ciclo de um sprint em um projeto gil.

A inteno dos projetos em cascata de gerar inicialmente uma especificao "completa" de

requisitos aumenta o nmero de suposies. Isso agrava ainda mais as dificuldades
mencionadas acima com relao a suposies. Requisitos abstratos so decompostos em um
conjunto de requisitos mais concretos. Caso um requisito abstrato tenha sido baseado em uma
suposio invlida, a cadeia completa de requisitos derivados dessa suposio ser invlida
tambm. Tais cadeias de dependncia podem aumentar consideravelmente o impacto de uma
suposio falsa. O potencial de retrabalho em projetos em cascata maior do que em projetos
geis, resultando em mais pedidos de alteraes relacionados a suposies invlidas.
Modelos de ciclo de vida gil procuram evitar isso, limitando o esforo de Engenharia de
Requisitos realizado em um nico requisito ao mnimo necessrio para entender os requisitos em
um nvel de detalhamento exigido naquele momento. Se o requisito estiver sendo implementado
hoje, o nvel de detalhamento ser alto. Se, por outro lado, a previso de implementao do
requisito dentro de 3 meses, o nvel mais abstrato de detalhes, ou seja, apenas o suficiente para
entender seus atributos centrais, pode ser suficiente. As atividades geis de planejamento do
release e a elaborao de roadmaps, muitas vezes baseados em backlogs, so responsveis pela
organizao e direcionamento do esforo investido na Engenharia de Requisitos.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 8 de 18

 r

3.4 Gerenciar a incerteza atravs do feedback e do aprendizado

Por exemplo: Vamos supor que uma empresa decide oferecer servios de localizao pela
nuvem, acessveis para os usurios atravs de um conjunto de aplicativos em qualquer dispositivo
mvel.
A abordagem clssica sequencial: pesquisa de mercado, segmentao de clientes, definio de
funcionalidades do servio, desenvolvimento das funcionalidades, incio da campanha de
marketing, lanamento. Mas a abordagem provavelmente ir fracassar, pois o mundo se
transformou nesse meio tempo, assim como tambm mudaram os segmentos de clientes e as
funcionalidades exigidas.

Um modelo de ciclo de vida gil iterativo: ter uma viso, dar incio ao marketing, desenvolver
o produto vivel mnimo, lanar no mercado o mais rapidamente possvel, obter feedback,
detectar o prximo conjunto mnimo de funcionalidades exigidas, mais uma vez lanar muito
rapidamente, obter feedback, e assim por diante.
A diferena entre as duas abordagens o fato que um grupo limitado de pessoas no capaz de
representar ou antecipar a demanda de um pblico heterogneo de usurios. Falando em termos
de habilidades cognitivas, um grupo fixo de pessoas apenas tem uma capacidade limitada para
prever desenvolvimentos futuros (veja, por exemplo, [3]). A nica maneira de identificar a
demanda obter feedback de verdade, seja ele fornecido diretamente pelos usurios, ou atravs
de mtodos de anlise embutidos no servio, que medem o comportamento do usurio. O
feedback um tipo de comunicao com a multido. Fazendo um paralelo com a Engenharia de
Requisitos, essa uma atividade de elicitao de requisitos. O mecanismo de avaliao do
aplicativo em uma loja de aplicativos como o iTunes , na verdade, um mecanismo de feedback e
uma forma transparente de anlise.
O feedback qualificado da multido apoia o processo de aprendizagem organizacional. Os
resultados da aprendizagem so os seguintes:
Recebemos feedback real de clientes reais e no as nossas prprias (e potencialmente falsas)
crenas sobre o que o cliente possivelmente pensa
Identificamos os segmentos de clientes com mais preciso
Entendemos as necessidades do segmento de clientes com mais preciso

Podemos aprender a prever o futuro at certo ponto: podemos antecipar a prxima inovao
incremental (funcionalidades) que ir melhorar o nosso produto
Essa abordagem pressupe um processo de desenvolvimento iterativo e incremental. O tempo de
ciclo entre as etapas de fornecimento de um produto depende do mercado. Nos mercados em
transformao constante, esse intervalo pode ser de um dia. Em outros mercados, quatro
implementaes por ano podem ser suficientes. O fato que o tempo de ciclo est se tornando
cada vez mais curto em todos os mercados. Se hoje o ciclo de seis meses, amanh ele poder
ser de seis semanas.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 9 de 18

 r

4 A Engenharia de Requisitos Independente do Modelo de Processo

A constatao fundamental: no importa se o projeto para desenvolver um servio na nuvem
utiliza um processo em cascata ou um processo gil, a Engenharia de Requisitos igualmente
importante em qualquer um dos casos. Porm, no exemplo que mencionamos acima, o
desenvolvimento de um servio de localizao em nuvem, o processo gil muito provavelmente
vai gerar um resultado que melhor atende as necessidades do usurio, e sendo assim, os
objetivos da organizao desenvolvendo o servio.

4.1 A aplicao da disciplina diferente

Em perspectiva global, as atividades de Engenharia de Requisitos em projetos cascata ou em
modelos de ciclo de vida gil so comparveis. Para demonstrar isso, vamos analisar as
atividades centrais, conforme definidas no Syllabus IREB [4]:
Elicitao: Durante a elicitao de requisitos, diversas tcnicas so utilizadas para obter os
requisitos de stakeholders e outras fontes, bem como para definir os requisitos em maior detalhe
[4].
Tanto projetos em cascata quanto projetos geis realizam essa atividade. Os mtodos e tcnicas
utilizados so idnticos. Exemplos de tais mtodos e tcnicas incluem: entrevistas, pesquisas
de campo (apprenticing), elaborao de storyboards. O responsvel pela elicitao exerce o
papel de engenheiro de requisitos. Os projetos geis realizam essa atividade de forma contnua.
Em projetos em cascata, ela realizada principalmente durante uma fase de anlise de
requisitos no incio de um projeto.

Documentao: Durante a documentao de requisitos, os requisitos elicitados so descritos de

forma adequada. Diferentes tcnicas so utilizadas para documentar os requisitos, seja por meio
de linguagem natural ou modelos conceituais [4].
Essa atividade a mesma, tanto em projetos em cascata quanto em projetos geis. Os mtodos
e tcnicas para a criao da documentao so idnticos ou semelhantes. Os critrios de
qualidade para requisitos no Syllabus IREB podem ser comparados aos princpios SMART e
INVEST das histrias de usurios [7]. No Syllabus IREB, picos e histrias de usurios
encontram-se na categoria de cenrios para documentao de requisitos em linguagem natural.
O responsvel pela elaborao de picos e histrias de usurio desempenha o papel de
engenheiro de requisitos. Em um modelo de ciclo de vida gil, a ordem das atividades
completamente diferente da documentao de requisitos em um modelo de ciclo de vida em
cascata. Na "Fase Conceitual", os projetos em cascata decompem todos os requisitos
relevantes para um nvel maior de detalhamento (granularidade fina). Os projetos geis
comeam com uma viso consensual representada por um pequeno conjunto de requisitos
globais. A equipe somente decompe um requisito no momento em que ele vai ser
desenvolvido. Os requisitos globais, muitas vezes chamados de "caractersticas do produto" em
projetos geis [8], so decompostos em picos e histrias de usurios. A especificao de
requisitos em um projeto gil um documento vivo enquanto o desenvolvimento estiver ativo.
Comparar o esforo investido na especificao de requisitos nos dois modelos de ciclo de vida
seria uma investigao interessante. Provavelmente os projetos geis investem mais esforo na
Engenharia de Requisitos do que os projetos em cascata, pois sabem que o esforo resulta em
alto valor agregado para o projeto [1].

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 10 de 18

 r

Validao e Negociao: Para assegurar que os critrios de qualidade previamente definidos

sejam cumpridos, os requisitos documentados devem ser validados e verificados em um estgio
inicial. Alm disso, o acordo dos stakeholders um pr-requisito para a aceitao do novo
produto / sistema, portanto, os requisitos precisam ser negociados [4].
Em projetos em cascata, essa atividade se limita s fases relacionadas aos requisitos. Os
requisitos so validados e negociados com base em documentos (por exemplo, a especificao
de requisitos). Uma vez concludas essas atividades, um erro ou um conflito entre requisitos
inicia um processo de mudana que reativa essas atividades para corrigir o erro ou resolver o
conflito. No modelo de ciclo de vida gil, a validao e a negociao de requisitos estendem-se
desde a primeira ideia at a entrega final. A validao e negociao no so realizadas apenas
em requisitos documentados. Em projetos geis, esse um princpio intrnseco, implementado
por um conjunto de meios, entre outros: feedback rpido atravs de iteraes curtas, a
definio de pronto (ready); critrios de aceitao; definio de concludo (done); design
orientado a testes, sesses de reviso com os stakeholders e muitos mais. O IREB codifica essa
abordagem como o quinto princpio da validao: a validao baseada na construo de
artefatos de desenvolvimento [4].

Gerenciamento: O gerenciamento de requisitos independente de todas as outras atividades e

compreende quaisquer medidas necessrias para estruturar requisitos, para prepar-los de modo
que possam ser usados por pessoas desempenhando diferentes papis, para manter a consistncia
entre os requisitos aps suas alteraes, bem como para assegurar sua implementao [4].
Essa atividade executada tanto em projetos em cascata, quanto em projetos geis. Nos
projetos em cascata, essa atividade geralmente atribuda a uma funo (gerente de projetos,
engenheiro de requisitos, ...) desempenhada pelo responsvel pela gesto dos documentos de
requisitos. Em projetos geis, o gerenciamento de requisitos incorporado em vrias
atividades e distribudo entre os membros da equipe. Uma equipe realizando o refinamento do
backlog em uma reunio com os stakeholders est gerenciando os requisitos ao decompor os
requisitos. A priorizao uma atividade importante e requer aes de gerenciamento de
requisitos. Na metodologia Scrum, o Product Owner responsvel por determinar prioridades
entre os requisitos de diferentes fontes, tais como os stakeholders, as organizaes de apoio ou
a arquitetura do sistema. Outro exemplo de gerenciamento de requisitos a referncia a
histrias de usurios no cdigo fonte (o cdigo de produo e o cdigo do teste de aceitao)
para mostrar qual parte do software implementa uma histria de usurio, ou seja, a
rastreabilidade ou o acompanhamento do progresso atravs da atualizao do grfico de burn-
up.
De modo geral, as prticas de Engenharia de Requisitos em modelos em cascata e modelos geis
so comparveis. Quando entramos nos detalhes sobre como a Engenharia de Requisitos
aplicada, os modelos so muito diferentes. Os dois modelos de ciclo de vida so relevantes,
porm para diferentes cenrios. Para o desenvolvimento de um servio em nuvem, como
mencionado acima, o modelo de ciclo de vida gil muito provavelmente a melhor escolha.
Projetos como a transferncia de um centro de dados, ou a construo de um tnel ferrovirio, no
entanto, talvez sempre exigem um modelo de ciclo de vida sequencial em cascata.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 11 de 18

 r

Como reflexo sobre a discusso at agora, as diferenas fundamentais na aplicao da

Engenharia de Requisitos entre os modelos em cascata e os modelos de ciclo de vida gil so:
A ordem das atividades de Engenharia de Requisitos
A atribuio do papel de "engenheiro de requisitos" aos membros de uma equipe multifuncional,
com uma pessoa atuando em mais de uma funo
Um foco maior na colaborao e na comunicao contnua entre os membros das equipes geis e os
stakeholders e usurios, com o objetivo de receber feedback sobre o que foi desenvolvido at agora
e o que est em desenvolvimento.

Assim, em termos de Engenharia de Requisitos, a principal diferena entre o modelo em cascata

e o modelo de ciclo de vida gil a aplicao da disciplina e no seu contudo.

4.2 A Engenharia de Requisitos em projetos geis complexos e extensos

A unidade tpica para estruturar os projetos geis o sprint, geralmente definido em termos de
semanas, por exemplo, 2 a 4 semanas. A ideia e o conceito de uma equipe gil, tal como definida
na metodologia Scrum, trabalhando em sprints para implementar os itens de um backlog
suficiente para pequenos projetos. Se um projeto requer mais trabalho a ser feito, por duas, trs
ou dez equipes em paralelo, o conceito de Scrum precisa crescer em escala. Alm da
metodologia Scrum, h vrias abordagens no mercado que lidam com essa questo. Uma, por
exemplo, a estrutura SAFe (Scaled Agile Framework) [8], utilizada para gerenciar roteiros de
produtos mais longos, projetos com centenas de desenvolvedores e organizaes inteiras, do
marketing e vendas at entrega e operaes. Essencialmente, essas abordagens ampliam a
escala de conceitos como cadncias, ritmos e cerimnias do nvel de equipe para o nvel da
organizao e aumentam o nvel de abstrao dos artefatos. interessante observar as
consequncias sobre a Engenharia de Requisitos [8].
Histrias de usurios. Planejamento de curto prazo de sprint (no mximo trs sprints para a frente):
a equipe planeja o prximo sprint com base no backlog do produto / nvel de detalhe que pode ser
implementado pela equipe.
Caracterstica do produto (picos). Planejamento de mdio prazo (3 a 6 meses): caractersticas
mais gerais do produto (granularidade grossa). Reflete o planejamento de release do produto. A
decomposio das caractersticas (picos) exige um esforo adicional, o chamado refinamento do
backlog.
Objetivos e metas. Planejamento de longo prazo (3 meses a 1 ano): descreve as aplicaes do
produto e as oportunidades da empresa (business cases). Reflete as atividades de elaborao de
roteiros (roadmaps).

Da perspectiva da Engenharia de Requisitos, essa abordagem utiliza nveis de abstrao

previamente definidos para estruturar o desenvolvimento e a discusso de conceitos de
especificao. A aplicao de nveis de abstrao no de forma alguma limitada a projetos
geis. Nveis de abstrao so um conceito conhecido e bem estabelecido para decompor
informaes. Alistair Cockburn, por exemplo, define vrios nveis de abstrao para casos de uso
(nvel nuvem, nvel pipa, nvel do mar ...) [9]. Outro exemplo o modelo de abstrao de
requisitos [10]. Esses conceitos so vlidos e usados tanto em projetos em cascata quanto em
projetos geis. Existem at mesmo mapeamentos de nomes e conceitos entre esses nveis de
abstrao de requisitos, comparando seu uso em projetos clssicos em cascata e projetos geis
[14].

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 12 de 18

 r

Podemos portanto afirmar que ampliar a escala da agilidade do nvel de equipe para o nvel da
organizao envolve a reutilizao de conceitos da Engenharia de Requisitos sob novos nomes,
j bem estabelecidos no mundo gil.

4.3 A evoluo dos formatos de documentao da Engenharia de Requisitos

O que no difere muito surpreendentemente so os formatos de documentao utilizados na
Engenharia de Requisitos em ambientes cascata e geis. Por formato de documentao,
entendemos o tipo de artefato utilizado para documentar requisitos. Por exemplo, uma histria de
usurio um formato de documentao que rene um conjunto de informaes em uma
combinao muito especfica. Qual mdia usar para manter um documento em um formato de
documentao especfico um aspecto de menor importncia. Uma equipe gil pode decidir
prender cartes sobre um quadro ou usar uma ferramenta de software como Greenhopper para
preservar histrias de usurios de forma permanente. Seja qual for a mdia, do ponto de vista da
Engenharia de Requisitos, o formato da documentao continua sendo uma "histria de usurio".
interessante observar que formatos de documentao de aparncia to radicalmente diferentes
e supostamente inventados pelos mtodos geis, como, por exemplo, "as histrias de usurios",
so na realidade uma evoluo gradual e contnua de conceitos conhecidos da Engenharia de
Requisitos. Os cenrios so um elemento importante na Engenharia de Requisitos h mais de
vinte anos. Os cenrios expressam objetivos abstratos atravs de exemplos concretos [15].
Informaes tipicamente encontradas em cenrios so as pessoas ou sistemas que interagem
entre si; os objetivos que um cenrio expressa; os locais virtuais ou concretos onde um cenrio
ocorre. Se investigamos as histrias de usurios, descobrimos as mesmas informaes: uma
pessoa ("como <papel/funo>") atuando em um ambiente concreto (o local) com o interesse de
alcanar um objetivo ("para que <razo/benefcio>" ). Tambm podemos observar uma evoluo
contnua na definio de atributos de qualidade para os requisitos. As definies de critrios de
qualidade SMART e INVEST so siglas para especificaes de atributos de qualidade para
histrias de usurios.
Muitas vezes em projetos geis complexos e extensos como os discutidos na seo anterior, as
equipes geis ainda trabalham com formatos de documentos que j estavam estabelecidos muito
antes que os modelos de ciclo de vida gil se tornaram to populares. Muitos projetos geis de
grande escala recorrem a formatos de documentao como casos de uso, modelos de dados,
especificaes de regras de negcio, funcionalidades e especificaes de requisitos contendo
requisitos de qualidade e restries, bem como requisitos tcnicos detalhados, tais como a
definio de um algoritmo matemtico. A estrutura SAFe [8], por exemplo, usa os seguintes
formatos de documentao: picos, viso, funcionalidades e histrias de usurios. Esses
conceitos coincidem com os conceitos de objetivos e cenrios na Engenharia de Requisitos [15].
O conceito Scrum, com um objetivo e histrias de usurios para cada sprint, tambm coincide
com os conceitos de objetivos e cenrios na Engenharia de Requisitos. Compreender os
conceitos da Engenharia de Requisitos, portanto, aprofunda a compreenso dos mecanismos de
ao que esto por trs dos conceitos geis equivalentes e suas evolues. Assim, os formatos
de documentao utilizados nos modelos de ciclo de vida gil representam uma evoluo dos
modelos de objetivos e cenrios. A diferena fundamental e inovadora que a comunidade gil
introduziu novos nomes para evolues concretas de conceitos, tais como as histrias de usurios
como uma evoluo dos casos de uso. Isso positivo, pois novos nomes expressam uma
inteno, neste caso, a inteno de usar esses formatos de documentao em modelos de ciclo
de vida gil em uma combinao especfica, com propsitos especficos e movidos por uma
mentalidade diferente.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 13 de 18

 r

Com o foco no fluxo contnuo de informaes e a abordagem lean de detalhar requisitos apenas
quando necessrio, a especificao de requisitos est mais para uma documentao que vai
surgindo aos poucos do que o resultado de uma atividade inicial. Assim, uma especificao gil
contm informaes teis apenas para a equipe e os stakeholders. A especificao muitas vezes
est no nvel mais abstrato de metas e objetivos. Essas informaes fornecem subsdios para que
os stakeholders e a equipe possam alinhar o desenvolvimento de mdio prazo com a direo
estratgica, tomar decises fundamentais sobre o roteiro de desenvolvimento e o planejamento do
release do sistema e documentar importantes conhecimentos bsicos (como algoritmos) que de
outra forma poderiam se perder ao longo do tempo. Essa documentao existe sob forma de
artefatos independentes de um backlog.
No conceito mais abstrato de documentao, os testes de aceitao implementados e
automatizados tambm fazem parte da especificao de requisitos. Nas especificaes de
requisitos de estilo clssico, sempre havia um captulo ou documento "testes de aceitao". Hoje,
uma especificao executvel ou uma srie de testes de aceitao podem substituir esse
(captulo do) documento. No entanto, importante observar que a capacidade de entender os
requisitos do sistema e de "escrever" testes de aceitao de alta qualidade continua sendo
necessria. A pessoa que escreve esses testes de aceitao est desempenhando os papis de
engenheiro de requisitos e testador.
Um ponto interessante que a equipe cria essa documentao de forma contnua e no como um
tarefa inicial. A especificao de requisitos em um ambiente gil um objeto vivo, representado
parcialmente em diferentes containers, at mesmo como uma srie de testes de aceitao
executveis. Essa maneira diferente de realizar atividades de Engenharia de Requisitos em um
ambiente gil resulta em uma especificao de requisitos viva, atualizada, correta e til. Uma
equipe gil disciplinada e madura dotada de todos os recursos necessrios desenvolve a
documentao de requisitos do sistema enquanto o prprio sistema desenvolvido. Esse tipo de
especificao de requisitos contm apenas:
as informaes exigidas pela equipe para construir o sistema alinhado a um roteiro de produto

as informaes exigidas pelos novos membros da equipe para compartilhar o conhecimento e

aumentar sua produtividade pessoal o mais rapidamente possvel

as informaes exigidas pela equipe para fazer a manuteno e dar suporte para a capacidade
operacional do sistema

as informaes exigidas pela organizao para melhorar continuamente o produto alinhado com a
estratgia organizacional, ou seja, para desenvolver um roteiro de produto e um planejamento de
release transparente.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 14 de 18

 r

5 O Manifesto gil e a Engenharia de Requisitos

At agora discutimos os valores da Engenharia de Requisitos a partir da perspectiva da
comunidade gil. Constatamos que o know-how da Engenharia de Requisitos importante e
relevante tanto para modelos de desenvolvimento em cascata quanto modelos de ciclo de vida
gil. Tambm constatamos que muitos elementos aparentemente inventados pela comunidade
gil so, na verdade, evolues de conceitos j existentes. Sim, h diferenas fundamentais na
maneira em que esses modelos de ciclo de vida aplicam as atividades. Estamos convencidos, no
entanto, que uma melhor compreenso dos conceitos bsicos da Engenharia de Requisitos
aprofunda a compreenso dos mecanismos nos projetos geis.
Queremos agora, em retrospectiva final, comparar a Engenharia de Requisitos, conforme definida
pelo IREB, com os valores da metodologia gil. O objetivo demonstrar que as declaraes do
IREB no esto em conflito com os princpios geis. Para tal, analisaremos se a definio IREB
de Engenharia de Requisitos contradiz o Manifesto para Desenvolvimento gil de Software:

Engenharia de Requisitos: Uma abordagem Estamos descobrindo maneiras melhores de

sistemtica e disciplinada para a especificao e desenvolver software, fazendo-o ns mesmos e
gerenciamento de requisitos, com os seguintes ajudando outros a fazer o mesmo. Atravs deste
objetivos: trabalho passamos a valorizar:

(1) (a) Identificar os requisitos relevantes,

(b) alcanar um consenso entre os
stakeholders sobre esses requisitos, Indivduos e interaes mais que processos e
ferramentas
(c) documentar os requisitos de acordo com
determinadas normas Software em funcionamento mais que
(d) e gerenci-los de forma sistemtica, documentao abrangente

(2) (a) Compreender Colaborao com o cliente mais que negociao de

(b) e documentar os desejos e contratos
necessidades dos stakeholders
Responder a mudanas mais que seguir um plano
(3) (a) Especificar e gerenciar os requisitos
(b) para minimizar o risco de entregar um
sistema que no atende os desejos e Ou seja, mesmo havendo valor nos itens direita,
necessidades dos stakeholders. valorizamos mais os itens esquerda.
Glossrio IREB

http://manifestoagil.com.br/

Indivduos e interaes mais que processos e ferramentas

Os stakeholders (e os usurios so stakeholders) so a principal fonte de requisitos. Um objetivo
central da Engenharia de Requisitos compreender os desejos e necessidades (2a) dos
stakeholders e para identificar requisitos (1a). Esse processo cognitivo ocorre atravs de intensa
comunicao e interao entre os stakeholders e a equipe. Processos e ferramentas so
importantes para lidar com contedos complexos e oferecem apoio para esse processo cognitivo.
No entanto, processos e ferramentas no so um fim em si mesmos. Eles precisam ser
introduzidos de forma racional e cuidadosa, devendo ser utilizados com ateno e pragmatismo.
IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 15 de 18
 r

Software em funcionamento mais que documentao abrangente

A Engenharia de Requisitos, a implementao e os testes dos requisitos podem ser vistos como
as principais competncias no desenvolvimento de software. A Engenharia de Requisitos
responsvel por compreender as necessidades do usurio (3a) e para transferir essa
compreenso equipe de desenvolvimento, para que a equipe possa desenvolver o que o
usurio necessita (3b). A documentao no um fim em si mesmo. O valor central conhecer
as necessidades dos stakeholders e do usurio (1a). A interao entre os membros da equipe
para compartilhar o conhecimento uma maneira de preservar o conhecimento. Restries de
conformidade e de regulamentao determinam padres de especificao para domnios
especficos (a indstria farmacutica, aeroespacial, automotiva, por exemplo) que exigem uma
documentao escrita em relao aos requisitos. De acordo com o IREB, um membro da equipe,
desempenhando o papel de engenheiro de requisitos, responsvel por conhecer e cumprir as
normas e regulamentos aplicveis no mbito de desenvolvimento de um produto (1c), bem como
criar a documentao para atender as restries de conformidade e de regulamentao.

Colaborao com o cliente mais que negociao de contratos

Em uma de suas publicaes [2], o IREB aborda a colaborao com o cliente no captulo sobre
elicitao e consolidao de requisitos. Alm disso, o IREB disponibiliza um mdulo de nvel
avanado [11] especificamente para lidar com a elicitao e consolidao dos requisitos dos
stakeholders e usurios. Esse mdulo de nvel avanado representa a importncia dada pelo
IREB aos valores geis. Os objetivos de aprendizagem apresentados nesse mdulo englobam
importantes princpios e elementos utilizados em projetos geis, tais como a comunicao direta,
personagens, mtodos de criatividade, a investigao contextual, histrias de usurios, o princpio
CCC (carto, comunicao, confirmao) [12] e outros. O mdulo IREB de nvel avanado,
Elicitao e Consolidao de Requisitos, pode ser considerado um mdulo central na abordagem
de tcnicas e mtodos geis assim como outros mdulos IREB cobrem princpios que so
vlidos e importantes tanto para projetos em cascata quanto para projetos geis.

Responder a mudanas mais que seguir um plano

Mtodos geis, tais como Scrum ou Kanban, apresentam a capacidade de responder a mudanas
como um dos principais valores da metodologia gil atravs de tcnicas, cerimnias e mtodos
especficos. Responder a mudanas no um atributo da Engenharia de Requisitos. A
Engenharia de Requisitos oferece mtodos especficos e tcnicas de suporte para responder a
mudanas. Os modelos de ciclo de vida gil fornecem orientaes sobre como e quando aplicar
esses mtodos e tcnicas.
O gerenciamento de mudanas um elemento do know-how IREB [2]. Essa forma de aplicar o
gerenciamento de mudanas claramente voltada para processos em cascata ou para ambientes
regulamentados que exigem uma gesto de mudanas explcita, tais como o desenvolvimento de
um software mdico sujeito s regras da FDA. Entretanto, mesmo os captulos sobre
gerenciamento de mudanas podem ser relevantes no mbito de projetos geis. Uma equipe que
est desenvolvendo um sistema de software mdico pode, como parte das prestaes fornecidas
no quadro do projeto, consultar esses captulos para saber como executar o gerenciamento de
mudanas em conformidade com os regulamentos da FDA. Nada impede que o processo de
desenvolvimento do software propriamente dito seja Scrum.

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 16 de 18

 r

6 Resumo

Este artigo apresenta a convico do International Requirements Engineering Board (IREB) de

que nosso know-how no ficou ultrapassado a partir do advento do desenvolvimento gil. Ao
contrrio, estamos convencidos que as tcnicas e os mtodos promovidos pelo IREB so parte
natural do trabalho dirio em ambientes geis embora provavelmente sejam aplicados de forma
diferente em termos de sequncia e nfases.
Na nossa viso, a Engenharia de Requisitos um conhecimento especializado que utiliza um
conjunto de "ferramentas" apropriadas, a caixa de ferramentas da Engenharia de Requisitos. As
"ferramentas" so os mtodos, as tcnicas e ferramentas (concretas) para executar atividades de
Engenharia de Requisitos. Projetos de todos os tipos podem beneficiar-se dessa caixa de
ferramentas, escolhendo o subconjunto de ferramentas que leva ao sucesso em seu contexto
especfico. Muitas das ferramentas so aplicveis tanto em projetos geis quanto em projetos
clssicos em cascata. Algumas so restritas apenas a projetos geis, outras somente a projetos
em cascata.
Estamos convencidos tambm que a compreenso desses mtodos e tcnicas pode beneficiar
todos os profissionais envolvidos no desenvolvimento de novos produtos e servios, independente
do modelo de ciclo de vida adotado por sua equipe de desenvolvimento. Um objetivo central do
IREB promover a disciplina da Engenharia de Requisitos, para que profissionais altamente
qualificados possam atuar na construo e utilizao de boas prticas de desenvolvimento de
software, baseadas em mtodos e tcnicas estabelecidas de comum acordo e que agregam valor
a seus projetos.

Referncias
[1] Chaos Manifest 2011, Standish Group International
[2] Requirements Engineering Fundamentals; 1st Edition; Klaus Pohl, Chris Rupp; Rocky Nook
Inc. (April 2011); English, 184 pages Paperback; ISBN-13: 978-1933952819
[3] Kahnemann, D.: Thinking, Fast and Slow. PENGUIN Psychology, 2011
[4] IREB Certified Professional for Requirements Engineering, Foundation Level, Syllabus
Version 2.1, 1st March 2011
[5] Supporting Agile Teams of Teams via Test Driven Design; Kris Read; Thesis submitted to
the faculty of graduate studies in partial fulfillment of the requirements for the degree of
Master of Science; Department of Computer Science; Calgary University, Alberta; Feb 2005
[6] Creative Process and Product Life Cycle of High-Tech Firms Creativity and Innovation,
key drivers for success; Verna Lu and Cdric Marjot; Master Thesis; Baltic Business
School, University of Kalmar; Sweden; June 2008
[7] Blog of Bill Wake, 2003: INVEST in Good Stories, and SMART Tasks, see:
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 17 de 18

 r

[8] The Scaled Agile Framework SAFe, http://www.scaledagileframework.com/, as well as the

book: Agile Software Requirements: Lean Requirements Practices for Teams, Programs,
and the Enterprise; Dean Leffingwell; Addison-Wesley Professional; 1st edition (January 6,
2011); ISBN-13: 978-0321635846
[9] Writing Effective Use Cases; Alistair Cockburn; Addison-Wesley Professional; 1st edition
(October 15, 2000); ISBN-13: 978-0201702255
[10] Requirements Abstraction Model; T. Gorschek and C. Wohlin; Requirements Engineering
Journal, Vol. 11, No. 1, pp. 79-101, 2006
[11] Syllabus CPRE Advanced Level Requirements Elicitation and Consolidation; version 1.0;
Dec 2012; see:
http://www.ireb.org/fileadmin/IREB/Lehrplaene/CPRE_Elicitation_and_Consolidation_Syllab
us_Version_1.0.pdf
[12] Three Cs; Ron Jeifries; Aug 30, 2001; card, conversation, confirmation; see:
http://xprogramming.com/articles/expcardconversationconfirmation/
[13] Extreme Programming Explained: Embrace Change; Kent Beck; Addison Wesley; 2nd
edition (November 26, 2004); ISBN-13: 978-0321278654
[14] Agile Requirements Abstraction Model Requirements Engineering in a Scrum
Environment; Richard Berntsson Svensson, Sigurdur rn Birgisson, Christian Hedin, Bjrn
Regnell; Paper published at the Department of Computer Science, Lund University,
Sweden
[15] Requirements Engineering, Fundamentals, Principles, and Techniques; PohI, Klaus; 2010,
XVIII, 814 pages, ISBN 978-3-642-12577-5

IREB e.V. Traduo realizada pela T&M Teste de Software Pgina 18 de 18