SlideShare uma empresa Scribd logo
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.
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)
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.
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.
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.
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)
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
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
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.
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.


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

Mais conteúdo relacionado

Mais procurados

Apresentação CMMi
Apresentação CMMiApresentação CMMi
Apresentação CMMi
Fabio Barnes
 
Cracking the Product Sense Interview by TikTok Product Leader.pdf
Cracking the Product Sense Interview by TikTok Product Leader.pdfCracking the Product Sense Interview by TikTok Product Leader.pdf
Cracking the Product Sense Interview by TikTok Product Leader.pdf
Product School
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
Computação Depressão
 
Fundamentos de arquitetura Web
Fundamentos de arquitetura WebFundamentos de arquitetura Web
Fundamentos de arquitetura Web
Denis L Presciliano
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
Álvaro Farias Pinheiro
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
diha36
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de Software
Aragon Vieira
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
Estudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halanEstudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halan
Halan Ridolphi
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
ETEIT - Escola Técnica da Univale
 
Introdução à Qualidade de Software
Introdução à Qualidade de SoftwareIntrodução à Qualidade de Software
Introdução à Qualidade de Software
Cloves da Rocha
 
Aula 1 - Qualidade de Software - Introdução e História.pptx
Aula 1 - Qualidade de Software - Introdução e História.pptxAula 1 - Qualidade de Software - Introdução e História.pptx
Aula 1 - Qualidade de Software - Introdução e História.pptx
AlexandreLisboadaSil
 
Gestão de Configuração (CM)
Gestão de Configuração (CM)Gestão de Configuração (CM)
Gestão de Configuração (CM)
Mário Pravato Junior
 
Métricas e Indicadores em Projetos Ágeis
Métricas e Indicadores em Projetos ÁgeisMétricas e Indicadores em Projetos Ágeis
Métricas e Indicadores em Projetos Ágeis
Vitor Pelizza
 
Ferramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de softwareFerramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de software
elliando dias
 
Iso 9000 e séries
Iso  9000 e sériesIso  9000 e séries
Iso 9000 e séries
R Gómez
 
Iso9000..
Iso9000..Iso9000..
Iso9000..
rehcah
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
Wagner Zaparoli
 
CMMI
CMMICMMI
[GaragemTalks2019] Cultura de Testes e Qualidade de Software
[GaragemTalks2019] Cultura de Testes e Qualidade de Software[GaragemTalks2019] Cultura de Testes e Qualidade de Software
[GaragemTalks2019] Cultura de Testes e Qualidade de Software
Júlio de Lima
 

Mais procurados (20)

Apresentação CMMi
Apresentação CMMiApresentação CMMi
Apresentação CMMi
 
Cracking the Product Sense Interview by TikTok Product Leader.pdf
Cracking the Product Sense Interview by TikTok Product Leader.pdfCracking the Product Sense Interview by TikTok Product Leader.pdf
Cracking the Product Sense Interview by TikTok Product Leader.pdf
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
Fundamentos de arquitetura Web
Fundamentos de arquitetura WebFundamentos de arquitetura Web
Fundamentos de arquitetura Web
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de Software
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Estudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halanEstudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halan
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
 
Introdução à Qualidade de Software
Introdução à Qualidade de SoftwareIntrodução à Qualidade de Software
Introdução à Qualidade de Software
 
Aula 1 - Qualidade de Software - Introdução e História.pptx
Aula 1 - Qualidade de Software - Introdução e História.pptxAula 1 - Qualidade de Software - Introdução e História.pptx
Aula 1 - Qualidade de Software - Introdução e História.pptx
 
Gestão de Configuração (CM)
Gestão de Configuração (CM)Gestão de Configuração (CM)
Gestão de Configuração (CM)
 
Métricas e Indicadores em Projetos Ágeis
Métricas e Indicadores em Projetos ÁgeisMétricas e Indicadores em Projetos Ágeis
Métricas e Indicadores em Projetos Ágeis
 
Ferramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de softwareFerramenta de apoio a gerência de configuração de software
Ferramenta de apoio a gerência de configuração de software
 
Iso 9000 e séries
Iso  9000 e sériesIso  9000 e séries
Iso 9000 e séries
 
Iso9000..
Iso9000..Iso9000..
Iso9000..
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
 
CMMI
CMMICMMI
CMMI
 
[GaragemTalks2019] Cultura de Testes e Qualidade de Software
[GaragemTalks2019] Cultura de Testes e Qualidade de Software[GaragemTalks2019] Cultura de Testes e Qualidade de Software
[GaragemTalks2019] Cultura de Testes e Qualidade de Software
 

Semelhante a Como especificar requisitos em metodologias ágeis?

Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Fernando Palma
 
ASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOSASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOS
Jaffer Veronezi
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
ECRAYON Tecnologia Criativa
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
José Vieira
 
A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...
André Agostinho
 
Analise essencial 2
Analise essencial 2Analise essencial 2
Analise essencial 2
Gabriela Serpa
 
Processos de software
Processos de softwareProcessos de software
Processos de software
Dann Volpato
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
André Luis Celestino
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Maicon Zerbielli
 
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
Adson Wendel
 
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
Fábio Pio
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
Ivo M Michalick Vasconcelos, PMP, PMI-SP, CPCC
 
Projeto de pesquisa apresentação
Projeto de pesquisa   apresentaçãoProjeto de pesquisa   apresentação
Projeto de pesquisa apresentação
Eduardo Rodriguez
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
Robson Silva Espig
 
Erika questionario pt 1 (Eng Software III).
Erika questionario pt 1 (Eng Software III).Erika questionario pt 1 (Eng Software III).
Erika questionario pt 1 (Eng Software III).
Érika Santos
 
AMSI.pptx
AMSI.pptxAMSI.pptx
AMSI.pptx
AndersonCunha61
 
aula7 software ciclo de vida analise req
aula7 software ciclo de vida analise reqaula7 software ciclo de vida analise req
aula7 software ciclo de vida analise req
patriciaalipiosilva
 
Aula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptxAula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptx
AlexandreLisboadaSil
 
Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitos
Felipe Oliveira
 

Semelhante a Como especificar requisitos em metodologias ágeis? (20)

Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
ASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOSASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOS
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
 
A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...
 
Analise essencial 2
Analise essencial 2Analise essencial 2
Analise essencial 2
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
 
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
 
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
Projeto de pesquisa apresentação
Projeto de pesquisa   apresentaçãoProjeto de pesquisa   apresentação
Projeto de pesquisa apresentação
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Erika questionario pt 1 (Eng Software III).
Erika questionario pt 1 (Eng Software III).Erika questionario pt 1 (Eng Software III).
Erika questionario pt 1 (Eng Software III).
 
AMSI.pptx
AMSI.pptxAMSI.pptx
AMSI.pptx
 
aula7 software ciclo de vida analise req
aula7 software ciclo de vida analise reqaula7 software ciclo de vida analise req
aula7 software ciclo de vida analise req
 
Aula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptxAula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptx
 
Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitos
 

Como especificar requisitos em metodologias ágeis?

  • 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.