O documento discute como os requisitos são especificados em metodologias ágeis. Apresenta user stories como uma forma de descrever requisitos de maneira sucinta, focada no valor para o usuário, e discute técnicas como modelagem de casos de uso para requisitos complexos.

1. COMO ESPECIFICAR REQUISITOS PARA DESENVOLVIMENTO DE
SOFTWARE EM METODOLOGIAS ÁGEIS?
Priscilla Gualiberto Aguiar 1
Orientador: Gilmar Luiz de Borba 2
Resumo
Os Profissionais de TI muitas vezes buscam por novas competências e qualificações
para atender as metodologias e modelos de desenvolvimento de software. Elaborar
um requisito que reflita a necessidade de um cliente e ao mesmo tempo seja claro
para os desenvolvedores é o objetivo de grande parte dos analistas de requisitos.
Porém entender, descrever e gerenciar requisitos em um projeto não é uma tarefa
fácil para os analistas e isso afeta diretamente a qualidade na entrega de um
software. O manifesto ágil valoriza software funcionando que agregue valor ao
cliente, mas isso requer a um mínimo de documentação para o desenvolvimento do
software. O objetivo desse artigo é apresentar como os requisitos são especificados
em processos de metodologias ágeis. Serão descritos nesse artigo, tópicos como
técnicas de elaboração, boas práticas para elaboração e características de um
requisito de qualidade.
Palavras-chave:Metodologias Ágeis. Especificação de Requisitos. Engenharia de
Software.Boas Práticas.
1. Introdução
Muitas empresas têm adotado métodos ágeis que propõem, segundo o Manifesto
Ágil (2001), “[...] satisfazer o cliente, através da entrega adiantada e contínua de
software de valor.”.
O desenvolvimento de software é baseado nos requisitos especificados e priorizados
no início de um projeto. Normalmente os requisitos expressam as necessidades dos
usuários, ou ainda, as funcionalidades do sistema, assim esclarece Dennis et al
(2009) e Sommerville (2007):
1
Aluna concluinte do curso de Pós-Graduação em Engenharia de Software Centrada em
Metodologias Ágeis, Centro Universitário UNA.
E-mail:pricaguiar@gmail.com
2
Mestre em Gestão Social, Educação e Desenvolvimento Local pelo Centro Universitário
UNA,especialista (nível Lato Sensu): Educação Tecnológica (CEFET-MG); Engenharia de Software
(PUC-MG); Análise de Sistemas (UFMG) e Engenharia de Segurança do trabalho (FUMEC).
Professor do Centro Universitário UNA, Belo Horizonte - MG.

2. Os requisitos são as informações do que o sistema fará, ou a funcionalidade que irá
conter. Eles precisam ser explicados em um alto nível, para que seja aprovado, e
finalmente, a equipe do projeto entenda quais são as expectativas de negócio do
produto final. (DENNIS, WIXOM e TEGARDEN 2009, p.43, tradução minha)
[...]as definições de requisitos de sistema especificam o que o sistema deve fazer
(suas funções) e suas propriedades essenciais e desejáveis. [...]Esses requisitos
refletem as necessidades dos clientes de um sistema que ajuda a resolver algum
problema.
(SOMMERVILLE 2007,p.18 ;p.79)
Estas necessidades e funcionalidades são inseridas em um documento próprio,
denominado Documento de Requisitos. MORAIS (2011, p.11) explica que
“documentos de requisitos têm como objetivo registrar o que os usuários esperam
da aplicação independente da solução técnica. Isso faz com que esses documentos
sejam simples e rápidos de serem elaborados.”
AMBLER (2004-2007) revela que quando começou a trabalhar com modelagem ágil
rapidamente descobriu que deveria considerar a efetividade na criação e
manutenção de documentos.
DENNIS, WIXOM e TEGARDEN (2009) e MORAES (2009) descrevem sobre a
relevância dos requisitos em um ciclo de vida de desenvolvimento e das possíveis
consequências vindas de requisitos mal definidos.
Em muitos aspectos, a etapa de definição dos requisitos é a única etapa mais crítica
de todo ciclo de vida de desenvolvimento de software porque é aqui que os
principais elementos do sistema começam a surgir. Durante a definição dos
requisitos, o sistema é fácil de mudar porque ainda foi feito pouco trabalho. Como o
sistema muda através das outras fases no ciclo de vida de desenvolvimento de
software, torna-se mais e mais difícil para retornar à definição dos requisitos e fazer
grandes mudanças, porque envolve o retrabalho. Vários estudos têm mostrado que
mais da metade de todas as falhas do sistema são devido a problemas com os
requisitos.
(DENNIS, WIXOM e TEGARDEN 2009, p. 111, tradução minha)
Segundo MORAES (2009, p.55), o levantamento de requisitos inadequados pode
impossibilitar o rastreamento das causas de problemas, custos maiores que o
planejado, prazos acima do estimado e processos fundamentais ao cliente omissos.
Visto o fator criticidade, vimos que os requisitos estão relacionados diretamente à
qualidade do software: “A qualidade de um software pode ser definida como a
conformidade aos requisitos.” (KOSCIANSKI,1992 apud CROSBY, 2007, p.12)

3. O CHAOS report apresentado em 2010 mostrou que 13 por cento das falhas de
projetos são devidos a requisitos incompletos e representa a maior causa entre os
fracassos. Considerando isso, LEFFINGWELL (2011, p.xxiii) cita que até
desenvolvedores experientes sabem que o gerenciamento de requisitos é um
desafio maior do que o desenvolvimento.
Perante este desafio, como os requisitos devem ser especificados para
desenvolvimento de software em metodologias ágeis?
Serão analisadas neste artigo os métodos, técnicas e modelos para especificação
de requisitos em processo ágeis, e as características que definem a qualidade de
um requisito.
Como material de pesquisa bibliográfica foram explorados livros e artigos já
publicados a respeito de metodologias ágeis e engenharia de requisitos. Para
análise da qualidade de software foi consultada a norma IEEE 29148.
As informações foram coletadas e avaliadas a fim de responder o problema
levantado neste artigo.
2. Manifesto Ágil
Em 2001, os criadores de muitas metodologias de desenvolvimento de software ágil
reuniram-se com outros que também estavam implementando métodos ágeis e
criaram o Manifesto Ágil (LEFFINGWELL 2011, p.12), com o objetivo de identificar
os valores que concedem maior benefício para o processo de desenvolvimento de
software. (SMITH 2009, p.117)
Agile Manifesto (2001) descreve os seguintes valores para o Desenvolvimento de
Software Ágil:
Indivíduos
e
interações maisque
processos
e
ferramentas
Software
em
funcionamento maisque
documentação
abrangente
Colaboração
com
o
cliente maisque
negociação
de
contratos
Responder a mudanças mais que seguir um plano.

4. Quando as pessoas lêem os valores do manifesto, geralmente tem a percepção
equivocada que os itens à direita (processos, ferramentas, documentação, contratos
e planejamento) não fazem parte do desenvolvimento ágil. Porém o manifesto está
dizendo que os itens à direita adicionam valor ao processo de desenvolvimento e os
à esquerda fornecem mais valor ao processo. (SMITH 2009, p.6)
3. Como os requisitos são descritos em metodologias ágeis?
AMBLER(2004-2007) descreve os seguintes conselhos aos Analistas de Requisitos
em projetos de desenvolvimento de software em um ambiente ágil:
1. No início do projeto, compreenda o escopo e gere requisitos de alto nível.
Nesse momento os detalhes não são importantes. Esse levantamento inicial
não deve chegar a durar semanas, apenas dias.
2. Idealmente, os detalhes são modelados e/ou analisados durante o tempo
(just-in-time), através sessões envolvendo poucas pessoas para esclarecer as
questões necessárias para o desenvolvimento.
3. Reconheça que a análise dos requisitos é realizada durante todo o projeto e
não há mais a “fase de análise”.
4. O requisito pode mudar a qualquer momento, o que é normal e aceitável. É
necessário gerenciá-los conforme suas prioridades.
5. Adote modelagens para que os stakeholders3 estejam aptos a entender,
incluindo as modelagens mais técnicas.
6. Analistas de requisitos efetivos sabem aplicar várias técnicas de modelagem
em sistemas complexos.
7. O objetivo é entender os requisitos e não gerar documentos de requisitos,
mas caso o documento seja escrito mantenha-o atualizado e útil para os
envolvidos, tendo uma única fonte de informação.
8. Reconheça que há vários modelos a sua disposição.
9. Modele com os desenvolvedores, para que eles entendam os requisitos e
você entenda o que eles estão tentando construir.
3
Stakeholder, de acordo com SMITH (2009); LEFFINGWELL (2011), é todo indivíduo que tem
interesse ou influência no projeto. Como por exemplo: usuários que usam o sistema; são impactados
pelo desenvolvimento ou operação do sistema; será envolvido na compra, operação, gerenciamento,
etc.

5. 10. Os melhores analistas de requisitos são os especialistas generalizados que
possuem mais de uma especialidade além da de levantar requisitos.
SOMMERVILLE (2007, p. 273) explica que no desenvolvimento iterativo não há
especificação detalhada e o documento de requisitos descreve as características
mais importantes do sistema.
De acordo com SMITH (2009, p.38) uma descrição para requisitos ágil poderia ser
apenas o suficiente. “Dê-me apenas os requisitos suficientes para começar um
projeto”.
SMITH (2009, p.80) descreve que em um processo tradicional de desenvolvimento,
você identifica e descreve todos os requisitos. Em um processo ágil, você descreve
apenas o suficiente, o suficiente para determinar o que será construído, para
posteriormente construir apenas o suficiente para demonstrar os requisitos
implementados ao usuário para que ele verifique se o software está no caminho
certo.
De acordo com a experiência de AMBLER (2004-2007), uma forma de iniciar a
modelagem de requisitos e descrever apenas o suficiente é o modelo de uso, como
casos de uso e história de usuários.
LEFFINGWELL (2011, p. 367) afirma que User Stories tornou-se a forma
predominante de se capturar e expressar requisitos, porém, como os métodos ágeis
começaram a serem aplicados em sistemas maiores, as user stories se tornaram
insuficientes para fazer a análise necessária de sistemas complexos.
Para LEFFINGWELL (2011, p. 368) no caso de sistemas complexos, a indicação
para capturar e expressar os requisitos são os use cases, que nos ajudam a explorar
interações entre usuário, sistemas e sub-sistemas, e a identificar cenários
alternativos que são os cenários que normal afetam de forma negativa o nível de
qualidade do sistema.

6. SMITH (2009, p.156) cita que independente da metodologia usada para o
desenvolvimento, nenhuma dita à documentação necessária para cada recurso: a
equipe faz.
3.1. User Stories
User story ou história de usuário foi originalmente desenvolvimento na metodologia
eXtreme Programming(XP), mas agora está presente em outras implementações
ágeis, como o Scrum4. (LEFFINGWELL 2011, p.37)
História de usuário é uma substituição ágil dos documentos de requisitos, como o
caso de uso, por exemplo, elas possuem breves descrições de algo que o sistema
precisa fazer para o usuário. (LEFFINGWELL 2011, p.57)
As histórias de usuário são ferramentas para definir o comportamento de um sistema
de um jeito que seja compreensível para o desenvolvedor e os usuários e suas
descrições focam no valor definido por ele, fornecendo uma abordagem leve e eficaz
para o gerenciamento dos requisitos.(LEFFINGWELL 2011, p.100)
SMITH (2009, p.161) acredita que as histórias de usuário podem ser definidas como
“descrições exatas”, que ajudam a equipe do projeto a interagir com o cliente e
entender melhor suas necessidades, além de reunir informações o suficiente para
entender o escopo do sistema.
Detalhes do comportamento do sistema não são descritos e são discutidos no
desenvolvimento entre o time e o analista de requisitos e/ou cliente, citado também
como Product Owner. (LEFFINGWELL 2011, p.101)
“Comunicação eficaz é a chave, e precisamos de uma linguagem comum. A história
de usuário fornece uma linguagem comum para construir o entendimento entre o
usuário e a equipe técnica.” (LEFFINGWELL 2011, p.101, tradução minha)
4
Scrum é um método de gerenciamento de projeto ágil que possui uma estrutura leve.
(LEFFINGWELL,2011 apud SCHWABER, 2004, tradução minha)

7. JEFFRIES(2001), um dos criadores do XP, explica que as histórias de usuário
possuem três aspectos críticos, sendo eles:
1. Cartão: as histórias de usuáriosão escritas em cartões para que o texto seja
apenas o suficiente, não sendo a descrição completa de um requisito. Este
cartão é usado durante todo o ciclo de projeto e devolvido ao usuário quando
for concluída.
2. Conversa: “O requisito em si é comunicado de cliente para programadores
através de conversa: uma troca de pensamentos, opiniões e sentimentos.”
(JEFFRIES 2001, tradução minha)
Essa conversa ocorre principalmente no planejamento da execução e apesar
de ser na maioria das vezes verbal, pode ser complementada com
documentos.
Para LEFFINGWELL (2011, p.103-104) a discussão que ocorre nesse
momento é necessária para determinar o comportamento do sistema de
forma mais detalhada para o desenvolvimento.
3. Confirmação:LEFFINGWELL (2011, p.103) explica que a confirmação
representa o teste de aceitação, uma forma de certificar se a história de
usuário satisfaz os stakeholders e/ou cumpre os requisitos. De acordo com
COHN (2004, p.67) os testes de aceitação são mais bem visualizados na
parte de trás do cartão da história de usuário e podem ser complementadas a
qualquer momento quando um novo teste for pensado.
LEFFINGWELL (2011, p.103) relata que a forma padronizada para descrição de
uma história de usuário é:
“Como um <papel>, eu posso <atividade> para que <valor do negócio>”
Onde:
<papel> representa quem está executando a ação, ou talvez alguém que irá receber
o valor da atividade. Pode até ser outro sistema, se isto é o que está iniciando a
atividade.
<atividade> representa a ação a ser executada pelo sistema.
<valor do negócio> representa o valor alcançado pela atividade.
(LEFFINGWELL 2011, p.103, tradução minha)
Figura 1 – Cartão de história de usuário

8. Fonte: AMBLER, 2004-2007
COHN (1992 apud WAKE, 2003, p.17) relata que precisamos focar em seis atributos
para criar boas histórias de usuário, sugerindo a sigla INVEST:

Independent: Crie histórias de usuário independentes umas das outras o
quanto for possível. As dependências entre elas levam a problemas na
priorização e planejamento.

Negotiable: Os cartões de história de usuário são lembretes, os detalhes são
negociados posteriormente entre o cliente e a equipe de desenvolvimento.

Valuable to users or customers: De acordo com LEFFINGWELL (2011,
p.107), um dos objetivos de um time ágil é entregar valor ao usuário, tornando
este atributo o mais importante no modelo INVEST. LEFFINGWELL (2011)
explica o valor que devemos entregar para o usuário através da seguinte
metáfora:
Acho que de toda a história é como um bolo de camadas múltiplas, por exemplo,
uma camada de rede, uma camada de persistência, uma camada de lógica e uma
camada de apresentação. Quando dividimos uma história [na horizontal], estamos
servindo apenas parte desse bolo. Queremos dar ao cliente a essência de todo o
bolo, e a melhor maneira é cortar verticalmente através das camadas. Os
desenvolvedores muitas vezes têm uma inclinação para trabalhar em uma camada
por vez (e fazer "direito"); mas uma camada de banco de dados completo (por
exemplo) tem pouco valor para o cliente, se não houver nenhuma camada de
apresentação.
(LEFFINGWELL,2011 apud WAKE, s/a, tradução minha)
A priorização é realizada de acordo com o valor das histórias de usuário e o
sucesso da empresa é medido pelo valor que a equipe consegue entregar.
COHN (2003, p.22)ainda ressalta que a melhor maneira de garantir que as
histórias de usuário possuam valor é solicitar que os clientes escrevam essas
histórias.

Estimatable: Os desenvolvedores dever ser capazes de estimar o tamanho
das histórias de usuário ou quanto tempo levariam para desenvolvê-la. Caso

9. os desenvolvedores não entendam uma história, esta deverá ser discutida
com quem a escreveu. Lembrando que os detalhes não são importantes
nesse momento.

Small: De acordo com LEFFINGWELL (2011, p.109), as histórias de usuário
devem ser pequenas o suficiente para serem concluídas em uma interação,
caso o contrário podem não agregar valor ao cliente.

Testable: As histórias precisam ser testáveis, caso não sejam, a equipe não
consegue confirmar se a história foi desenvolvida com sucesso.
As histórias de usuário não testáveis, normalmente são requisitos não
funcionais. COHN (2003, p.28) sugere que os testes sejam automatizados
sempre que possível.
3.2. Use Case
Originalmente popularizados no contexto Rational Unified Process (RUP), o Use
Case ou Caso de Uso é a principal forma de representar os requisitos em Unified
Modeling Language (UML) e tem sido a escolha para especificação e análise de
requisitos. (LEFFINGWELL 2011, p.366-367)
“Casos de uso são uma técnica para captar os requisitos funcionais 5 de um sistema.
Eles servem para descrever as interaçõestípicas entre os usuários de um sistema e
o próprio sistema, fornecendo uma narrativa sobre como o sistema é utilizado.”
(FOWLER, 2005, p.101)
Estas interações são abordadas a partir das ações, ou sequências de ações que o
usuário e, eventualmente, o sistema realiza, assim descreve LEFFINGWELL (2011,
p.369, tradução minha): “Um caso de uso descreve uma sequência de ações entre
um ator e um sistema queproduz um resultado de valor para o ator.”.
5
Requisitos funcionais são as descrições de interação do usuário com o sistema eseu
comportamentoperante as regras de um negócio. Já os requisitos não funcionais descrevem as
características técnicas do sistema, as características típicas são: disponibilidade, segurança,
desempenho, interoperabilidade, segurança e confiabilidade.

10. Para esclarecer melhor este conceito, LEFFINGWELL (2011, p.369) define ator
como um indivíduo, outros sistemas (ou aplicações) ou mecanismo que interagem
com o sistema.
FOWLER (2005, p.101) explica que não há um padrão para descrever os casos de
uso, já que eles possuem diferentes formatos que funcionam em diferentes casos.
Porém de acordo com LEFFINGWELL (2011, p.370), na estrutura de um caso de
uso há quatro elementos mandatórios:

Nome: O nome descreve o objetivo do caso de uso em poucas palavras.

Breve descrição:Descriçãodo propósito do caso de uso em uma ou duas
sentenças.

Ator(es): Lista do(s) autor(es)

Fluxo de eventos: Descrições das interações entre ator(es) e sistema. Pode
ser dividido em:
o Fluxo Básico: descreve o caminho principal do caso de uso.
o Fluxo(s) Alternativo(s): ou cenários alternativos, descrevem os eventos
que ocorrem em uma circunstância especifica. É aqui que são
descritos os “se” do fluxo principal: “e se o usuário não preencher essa
informação”; “e se o usuário não acionar esse comando”.
LEFFINGWELL (2011, p.372) explica que além desses elementos, o caso de uso
pode possuir os seguintes elementos complementares opcionais:

Pré condições: descreve as condições que devem estar presentes para a
execução do caso de uso. Normalmente representa as condições que o
sistema deve apresentar.

Condições de saída: descreve as condições em que o sistema se encontrará
após a execução do caso de uso. Inclui:
o Garantia de Sucesso: estado do sistema após execução bem sucedida
do caso de uso.
o Garantia Mínima: estado do sistema caso ocorra uma situação
inesperada que gere falha na execução do caso de uso.

11. 
Sistema ou sub-sistema: Lista de sistemas presentes na execução do caso de
uso. Desejável quando há múltiplos sistemas presentes no mesmo caso de
uso.

Outros stakeholders: Lista de usuários, que não são atores, afetados pela
execução do caso de uso.

Requisitos especiais: Na maioria das vezes são requisitos não funcionais, que
descrevem alguns requisitos especiais importantes para a execução do caso
de uso em específico.
Figura2 – Exemplo de Caso de Uso
Fonte: LEFFINGWELL, 2011, p.376

12. AMBLER(2004-2007) alerta que é muito fácil uma modelagem de caso de uso tornase un-agile.Para prevenir este acontecimento, crie artefatos bons o suficiente, eles
não precisam ser perfeitos. Lembre-se: faça apenas o que agregue valor.
"Ao trabalhar na análise de requisitos, lembre-se de que o mais importante é a
comunicação com seus usuários e clientes." (FOWLER, 2005, p.48)
3.3. Linguística de Requisitos
Alguns termos vagos ou gerais precisam ser evitados na descrição dos requisitos,
caso contrário podem causar múltiplas interpretações ou não poderão ser
verificados.(INTERNATIONAL STANDARD, 2011)
Abaixo uma lista de tipos de termos vagos ou gerais fornecida pelo
INTERNATIONAL STANDARD(2011):

Superlativos, tais como o “melhor”, “mais”;

Linguagem subjetiva, tais como “amigável”, “fácil de usar”, “econômico”;

Pronomes vagos, tais como “ele”, “isto”, “aquilo”;

Ambíguos advérbios e adjetivos, tais como “quase sempre”, “significativa”,
“mínimo”;

Em aberto, termos nãoverificáveis, tais como “apoio”, “mas não limitado a”,
“no mínimo”;

Frases comparativas, tais como o “melhor”, “melhor qualidade”;

Lacunas, tais como “se possível”, “conforme apropriado”, “como aplicável”;

Referências incompletas, não especificando a referência como sua data e
número de versão; não especificando apenas as partes aplicáveis da
referência para restringir o trabalho de verificação;

Declarações negativas, como declarações de capacidade do sistema não
devem ser fornecidas.
4. Boas práticas de requisitos em metodologias ágeis

13. AMBLER (2004-2007) descreve práticas para auxiliar a modelagem e documentação
dos requisitos serem mais ágil:
1. Os stakeholders participam ativamente: é importante que as partes
interessadas no projeto tenham disponibilidade para além de fornecer os
requisitos, realizar a modelagem junto ao analista. De acordo com a filosofia
de AMBLER(2004-2007), caso os stakeholders sejam incapazes de
participarem do projeto, existe uma forte indicação dele não ter sucesso.
Eles são as pessoas que sabem o que querem e se o analista optar, pode
ensiná-los como modelar um requisito.
“Isto faz sentido do ponto de vista ágil porque ele distribui o esforço de
modelagem para mais pessoas.” AMBLER(2004-2007, tradução minha)
2. Adote modelos abrangentes: para tornar o envolvimento dos stakeholders
na modelagem e documentação mais fácil, utilize ferramentas simples, como
cartões, post-it, papéis ou quadro branco. Isso incentivará a participação
mais efetiva dos stakeholders.
3. Adote uma abordagem ampla: adotando uma abordagem ampla é possível
ter a visão geral do sistema que auxilia a compreender os detalhes quando
apropriado. O ponto é: invista em requisitos de alto nível que lhe proporcione
conhecimento o suficiente para conduzir o projeto.
4. Modele os detalhes Just in Time: “Os requisitos são identificados durante
todo o projeto” AMBLER (2004-2007, tradução minha)
Modelagem ágil inclui práticas diversas de modelagem, que permite uma
modelagem evolutiva.
5. Trate os requisitos como uma pilha de prioridade: Mudanças são aceitas.
Alteração de requisitos já implementados podem ser tratados como novos
requisitos e a priorização reavaliada.
Figura 3 – Processo de Gerenciamento de Mudança de Requisitos Ágeis

14. Fonte: AMBLER, 2004-2007
6. Prefira requisitos executáveis mais do que documentação estática: times
ágeis detalham requisitos em forma de especificações executáveis, testes de
sistemas ou teste de desenvolvimento.
7. Seu objetivo é efetivamente implementar os requisitos, não documentálos: Documente apenas o suficiente. Mantenha a documentação enxuta e
eficaz, concentre-se em criar soluções consumíveis para os stakeholders.
8. Reconheça que você tem um grande número de stakeholders: existem
muitas pessoas envolvidas no projeto, que possuem opiniões, visões e
definições diferentes em relação ao sistema. Em algumas vezes um não
concordará com o outro. O analista de requisitos, citado também como
Product Owner, precisa possuir a habilidade de negociação estar preparado
para trabalhar com outros analistas de requisitos e saber para quem
direcionar a equipe ao especialista apropriado quando houver dúvidas
pontuais no projeto.
9. Plataforma Requisitos independentes a um ponto: requisitos deveriam ser
tecnologicamente independentes. A especificação tecnológica é realizada na
modelagem de arquitetura.
10. Menor é melhor: Requisitos menores são mais fáceis de estimar, priorizar e
gerenciar.
11. A questão Rastreabilidade:De acordo com AMBLER(2004-2007) vale a
pena investir e manter a matriz de rastreabilidade. O benefício de manter a
matriz é a facilidade em realizar a análise de impacto nas mudanças que
ocorrem nos requisitos, porém quando a equipe possui um conhecimento

15. familiarizado com o sistema, essa rastreabilidade é feita através da
comunicação.
12. Explique as técnicas: Dedique alguns minutos para capacitar os
stakeholders do projeto em relação às técnicas de modelagem, caso
contrário, eles não conseguiram participar ativamente do projeto.
13. Adote a terminologias dos Stakeholder: use termos que todos sejam
capazes de entender, não force o uso de expressões técnicas. Em alguns
casos, surge a necessidade de haver um glossário no projeto.
14. Mantenha-o divertido: A modelagem não precisa ser uma tarefa custosa.
“Conte umas piadas e manter seus esforços de modelagem leves.” (AMBLER,
2004-2007)
15. Obtenha Apoio da Gestão: A participação ativa dos stakeholders no projeto,
muitas vezes, exige uma mudança de cultura da empresa e sem o apoio da
alta gerência, você possivelmente não será bem sucedido.
16. Conecte Stakeholders em Desenvolvedores: Durante a modelagem,
stakeholders desenvolvem habilidades de desenvolvedores, ajude-os nessa
aquisição de novas competências. Isso fará com que a participação deles seja
mais frequentes nesse e nos próximos projetos.
5. Qualidade de requisito
INTERNATIONAL STANDARD, 2011 descreve algumas características individuais
dos requisitos com o objetivo de estabelecer critérios relacionados à boa qualidade,
conforme apresentado na tabela 1.
Tabela 1 - Características de requisitos.
Características
Definição
Necessário
O requisito é atualmente aplicável e não se torna obsoleto com a
passagem do tempo.
Livre
Descreva o requisito sem se preocupar como ele deve ser
Implementação
implementado. A modelagem de arquitetura deve ser evitada nos
requisitos.
Não ambíguo
Requisitos que possuem interpretação única.
Consistente
Requisitos que não possuem conflitos com outros requisitos do

16. sistema.
Completo
Requisitos contêm descrições apenas o suficiente para atender a
necessidade dos stakeholders.
Único
Requisitos são únicos, sem uso que conjunções.
Viável
Risco aceitável e restrições como custo, cronograma, técnico,
legal, regulamentar disponível para o projeto.
Rastreável
Componentes e artefatos relacionados ao requisito podem ser
identificados (rastreados).
Verificável
É possível validar se o requisito foi atendido após implementação.
Fonte: INTERNATIONALSTANDARD, 2011.
6. Considerações finais
A entrega de valor se tornou o objetivo mais importante em projetos ágeis e essa
entrega inicia-se na definição dos requisitos.
Vimos que, nesse processo, os stakeholders participam ativamente durante todo o
ciclo de desenvolvimento e os requisitos são tratados a partir de suas prioridades.
Embora a documentação estática (do processo tradicional) não seja implementada
da mesma maneira, na metodologia ágil, os requisitos são apresentados de maneira
executável e implementável, mas de qualquer forma as práticas ágeis sustentam a
hipótese de documentar apenas o suficiente, ou seja, é necessário manter uma
documentação enxuta e eficaz.
Um dos objetivos do analista de requisitos, citado também como Product Owner, é
descrever apenas o suficiente. Para auxiliá-los perante este desafio, foram descritos
neste artigo os modelos mais utilizados em projetos ágeis, assim como técnicas para
serem utilizadas na descrição e boas práticas, que tornam este objetivo possível de
ser alcançado.
Desta forma conclui-se que, como ressalta SMITH (2009,p.9), nenhuma metodologia
é melhor do que outra, tudo depende de qual funciona melhor em seu ambiente e
dentro de suas limitações.
Sugere-se que o analista utilize a ferramenta principal para este processo: a
comunicação.

17. 7. Referências
Agile Manifesto.(2001) Manifesto para Desenvolvimento Ágil de Software.
Disponível em: < http://agilemanifesto.org/iso/ptbr/>. Acesso em: 18 jul. 2013.
AMBLER, S.W. Agile/Lean Documentation: Strategies for Agile Software
Development. Agile Modeling. Disponível em:
<http://www.agilemodeling.com/essays/agileDocumentation.htm>. Acesso em: 21
out. 2013
AMBLER, S.W. Agile Requirements Best Practices. Agile Modeling. Disponível
em: <http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm>.
Acesso em: 21 out. 2013
AMBLER, S.W. Agile Requirements Modeling. Agile Modeling. Disponível em: <
http://www.agilemodeling.com/essays/agileRequirements.htm>. Acesso em: 21 out.
2013
AMBLER, S.W. Introduction to User Stories. Agile Modeling.Disponível em:
<http://www.agilemodeling.com/artifacts/userStory.htm>. Acesso em: 21 out. 2013
AMBLER, S.W. Requirements Envisioning: An Agile Best Practice. Agile Modeling.
Disponível em:
<http://www.agilemodeling.com/essays/initialRequirementsModeling.htm>. Acesso
em: 21 out. 2013
AMBLER, S.W.Where Do I Start?.Agile Modeling.Disponível em:
<http://www.agilemodeling.com/essays/whereDoIStart.htm>. Acesso em: 21 out.
2013
COHN, M. User Stories Applied: For Agile Software Development. United States of
America: Addison-Wesley Professional, 2004.
DENNIS, A.; WIXOM, B.H.; TEGARDEN,D. System Analysis Design UML Version
2.0: An Object-Oriented Approach. United States of America: John Wiley & Sons,
Inc., 2009.
FOWLER, Martin. UML Essencial, 3ª Edição, Bookman,2005.
INTERNATIONALSTANDARD.ISO/IEC/IEEE 29148: Systems and software
engineering — Life cycle processes — Requirements engineering. First
edition.Switzerland, 2011.95 p.
JEFFRIES, R.Essential XP: Card, Conversation, Confirmation. XProgramming:
Extreme Programming and Agile Software Development Resources, 2001.
Disponível em: http://xprogramming.com/xpmag/expcardconversationconfirmation/.
Acesso em: 17 out. 2013.

18. KOSCIANSKI, A.; SOARES, M.S. Qualidade de Software: Aprenda as
metodologias e técnicas mais modernaspara o desenvolvimento de software. São
Paulo: Novatec, 2007.
LEFFINGWELL, D. Agile Software Requirements: Lean Requirements Practices for
Teams, Programs, and the Enterprise, 1st edition. Boston: Addison-Wesley
Professional, 2011.
MORAES, J.B.D.Introdução a Abordagens de Identificação de Requisitos.
Engenharia de Software Magazine. Ano 1, 2 ª Ed. Dev Media, 2009.
MORAIS, L. Modelagem em uma Visão Ágil. Engenharia de Software Magazine.
Ano 3,32 ª Ed. Dev Media, 2011.
SMITH, G.;SIDKI,A. Becoming Agile…in an imperfect world. Greenwich: Manning
Publications Co.,2009.
SOMMERVILLE, I. Engenharia de Software, 8ª edição. Tradução: Selma Shin
Shimizu Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa; São Paulo:
Pearson Addison--Wesley, 2007.
The Standish Group International, CHAOS Report 2010.