Artigo Historias de Usuarios

A Utilizao de Histrias de Usurios no Levantamento de
Requisitos geis
Hugo Estevam Romeu Longo*
Madalena Pereira da Silva**
Resumo
A partir da popularizao dos mtodos geis, surgem discusses sobre o que so
histrias de usurio, porque utilizar histrias de usurio e como se deve descrever da
melhor maneira o comportamento de um sistema atravs da engenharia de requisitos. O
objetivo deste artigo analisar se a utilizao de histrias de usurio suficiente durante
a fase de levantamento de requisitos, abordando as diferentes maneiras de descrever,
compreender e utiliz-las atualmente. Para ilustrar as fases de desenvolvimento da
histria de usurio apresentado um estudo de caso que visou aplicar tcnicas deste
mtodo comparadas s tcnicas de levantamento de requisitos dirigidas por casos de
uso.
Palavras-Chave: Mtodos geis. Desenvolvimento de Software
Professor do Curso de Sistemas de Informao na Universidade do Planalto Catarinense, Arquiteto de

Software da Empresa NDD Digital. hugoestevamrl@hotmail.com
**
Professora da Universidade do Planalto Catarinense e Orientadora de monografias da Ps Graduao
em Engenharia de Software da referida instituio. madalena.silva@posgrad.ufsc.br
Int. J. Knowl. Eng. Manag., ISSN 2316-6517, Florianpolis, v.3, n.6, p. 1-30, jul/nov, 2014
1 Introduo
Durante dcadas a proposta de utilizar casos de uso, introduzida em 1986 por Ivar
Jacobson, conhecido como o principal contribuidor para o surgimento da UML (Unified
Model Language) e o UP (Unified Process) foi amplamente utilizada para descrever
requisitos funcionais.
A ideia de Jacobson (1992) de introduzir o caso de uso foi muito apreciada, tendo como
principais virtudes a simplicidade e utilidade. Os cenrios originais de Jacobson para
utilizao dos casos de uso foram intencionalmente informais. Ele constatou que
quando as pessoas precisam escrev-los, criam uma resistncia sempre que se tornam
mais formais.
Porm ao deixar os casos de uso completamente informais, Jacobson (1992) constatou
que apresentavam-se outras dificuldades. Surgiam questionamentos das pessoas sobre
como fariam para vincular um grande nmero de casos de uso ou ento, como saberiam
se aquela escrita informal estava sendo executada da maneira correta.
Outras pessoas, mais especificamente ligadas ao desenvolvimento de ferramentas CASE
(Computer Aided Software Engineering), consideram esta forma de trabalho informal
como incompleta, necessitando de uma base matemtica e de apoio de uma ferramenta
CASE. Eles criam notaes, relacionamentos e artefatos para fazer casos de uso mais
"rigorosos".
Mesmo com as definies acima e com bom nmero de aceitao, os casos de uso ainda
no eram formais o suficiente para os formalistas, que continuaram a procurar por um
modelo totalmente formal. Ao mesmo tempo em que era muito formal para aqueles que
gostavam de pensar em casos de uso informais, sem estrutura.
A atividade de pesquisa por dcadas tentou resolver o impasse na definio dos casos de
uso. Cada nova abordagem era apontada como uma bala de prata, para solucionar a
indefinio. Porm, pouco a pouco houve um convencimento geral de que no havia tal
soluo mgica. Ferramentas CASE, especificao formal, processos, componentes etc.
eram boas tcnicas que ajudaram a Engenharia de Software a evoluir, mas
correntemente no se acredita mais em uma soluo nica e salvadora para os

complexos problemas envolvidos com a produo de software.
Nos anos 2000, o crescimento da demanda por software em organizaes de pequeno e
mdio porte levou ao surgimento de solues mais simples e efetivas para o
desenvolvimento de software para essas organizaes. Assim surgiram os mtodos
geis, que so caracterizados como informais e minimamente documentados. Alm
disso, esses processos do mais destaque comunicao verbal e social, na equipe de
desenvolvimento. Em contraste, os processos tradicionais que so sequenciais, possuem
fases que enfatizam a formalidade, o trabalho de escrita e a comunicao.
Nos ltimos anos, os processos com base no Manifesto gil explicado por Highsmith e
Fowler (2001) foram ganhando aceitao entre os praticantes. Os princpios por trs
deste manifesto sugerem que a mudana deve ser acolhida em todas as fases do ciclo de
desenvolvimento de software, que o software de trabalho deve ser entregue com
frequncia, e que a transmisso de informaes por meio de uma conversa face a face
mais eficiente do que atravs de documentao escrita.
O processo gil de software, Extreme Programming (XP), Beck (2000) introduziu a
prtica de expressar requisitos de software na forma de histrias de usurio, descries
curtas de funcionalidade contadas a partir da perspectiva de um usurio. Quando os
mtodos geis so utilizados, nota-se que os requisitos so baseados nos valores da
simplicidade, comunicao, coragem e feedback. Funciona, trazendo toda a equipe para
trabalhar unida na utilizao de prticas simples, com comunicao suficiente para
permitir que a equipe veja quais so as melhores prticas para cada situao. Esta
disciplina o ponto chave para compreender o conceito de histrias de usurios e
comunicar esses conceitos para os usurios de negcios, tendo a chance de entregar um
produto que estes usurios corporativos vo aprovar dentro do tempo e oramento
previstos.
No processo de design iterativo e gil de software, as histrias de usurio so
fundamentais para a criao de requisitos nas subdisciplinas geis de XP e SCRUM,
mas as histrias de usurio tambm so teis como ferramenta para provocar o
envolvimento do cliente. Nesse sentido, este artigo visa demonstrar, atravs de um
estudo de caso, de que forma as histrias de usurio podem ser usadas nos processos
geis de software, bem como se as mesmas so promissoras e suficientes para substituir
os casos de uso durante a etapa de levantamento de requisitos.
O artigo est organizado em sees, sendo que a seo 2 descreve os requisitos geis e
as histrias do usurio. A seo 3 apresenta o estudo de caso. A seo 4 cita os trabalhos
correlatos, seguida pela concluso e referncias bibliogrficas.
2 Requisitos geis Atravs de Histrias do Usurio

Em um ambiente gil, a histria de usurio um instrumento de escrita utilizado no
processo de levantamento de requisitos para descrever a especificao de uma
funcionalidade do software, afirmam Beck e Fowler (2001). Normalmente, uma histria
de usurio breve, pois consiste em apenas uma ou duas frases.
2.1 Protocolos da Histria de Usurio
A histria de usurio uma declarao informal de um requisito de usurio em vez de
um grande documento de requisitos. A inteno real da histria de usurio fornecer
equipe uma capacidade para responder rapidamente o que o usurio quer e precisa. A
histria de usurio cria menos sobrecarga de documentao e mostra de forma rpida a
evoluo das necessidades do mundo real ou a descoberta de novos requisitos baseados
no trabalho em andamento. No especificamente a descrio de um requisito de
software, o problema do mundo real subjacente que o componente de software
projetado para resolver adversidades enfrentadas pelo usurio final.
As descries da histria do usurio so tradicionalmente escritas mo, em cartes de
papel, Jeffries (2001) nomeou estes trs aspectos para esta descrio: o carto, a
conversa e a confirmao. O carto pode ser a manifestao mais visvel de uma histria
do usurio, mas no a mais importante. Enquanto o carto pode conter o texto de uma
histria, os detalhes so trabalhados na conversa e, em seguida, registrada e verificada
atravs da confirmao.
Uma histria de usurio contm tudo o que necessrio para movimentar as memrias e
inspiraes da equipe de desenvolvimento, que mais tarde pode explorar a histria com
maior profundidade. Durante o processo, uma srie de conversas ter lugar entre o
cliente e a equipe de desenvolvimento. Essas conversas capturadas como documentao
adicional, sero anexadas ao carto juntamente com todos os critrios descobertos nos
testes de aceitao, servindo para concretizar os detalhes e o aspecto da conversa.
Testes de aceitao segundo Cohn (2004) esto associados s histrias do usurio para
especificar os requisitos de software. So descritos como os comportamentos que o
sistema em desenvolvimento necessita para atender s regras de negcio do cliente.
um requisito do sistema de software formulado como uma ou duas frases na linguagem
cotidiana do usurio de negcios. Idealmente, as histrias de usurio so escritas pelo
cliente e so o seu principal mtodo de influncia no desenvolvimento dos sistemas. Os
testes de aceitao fazem parte do aspecto de confirmao e do origem aos casos de
teste do sistema.
A escrita da histria do usurio deve ocorrer sem o uso de qualquer jargo tcnico. Elas
devem ser compreensveis pelos homens de negcios e seu contedo deve caber em um
carto de ndice. Deve ser possvel explic-los em 30 segundos e implement-los em
menos de uma semana, de acordo com Cockburn (2002).
As histrias de usurio no XP de acordo com Jeffries (2001) tm trs componentes:
Cartes, que so o meio fsico no qual as histrias so escritas; Conversao, que a
discusso em torno das histrias; e Confirmao, que so os testes que verificam as
histrias.
Histrias de usurio so escritas em um carto de nota, com um nome e uma descrio.
Se mais tarde, a histria de usurio est muito grande, complicada ou imprecisa, ela ser
reescrita, at que fique satisfatria para todas as partes. No entanto, salienta-se em Beck
(2000) que as histrias de usurio no devem ser definidas j na primeira vez que elas
foram escritas, devendo-se evoluir medida que as necessidades surgirem.
O formato simples de histria de usurio apresentado por Cohn (2004) auxilia o comeo
da comunicao no mbito de um projeto gil. Devendo-se estar atento para no tratar a
histria como uma especificao de um mini requisito focado na palavra escrita, mas
sim utilizar histrias como ferramenta para a conduo de uma conversa em um

momento posterior.
A sintaxe de uma histria de usurio sugerida por Cohn (2004) deve conter:
Como um... (papel ou ator) (Quem)
Eu quero... (capacidade ou funcionalidades necessrias) (O que)
de modo que... (por que de valor do negcio ou benefcio) (Por que)
Cohn (2004) sugere a escrita de uma histria de usurio como se estivesse na pele do
usurio que deseja a histria. O uso na perspectiva de primeira pessoa torna a histria
mais compreensvel. Nesse caso, deve-se identificar o papel que est assumindo dentro
da histria:
"Como um tipo de usurio eu quero capacidade ou funcionalidade de modo que o
valor do negcio ou benefcio"
O "Quem" e "O que" so essenciais para a histria, j o "Por que" s ajuda com clareza
na configurao dos testes de aceitao. Histrias de usurio ajudam a fazer as
perguntas sobre o contexto e razo para o pedido da pessoa que solicita o requisito.
Tambm possvel verificar o nvel de prioridade e a estimativa inicial de cada histria
de usurio conforme o modelo formal apresentado por Cohn (2004). Abaixo na Figura 1
demonstrado um exemplo de carto de histria.
Figura 1. Exemplo de um carto de histria de usurio adaptado da fonte Kniberg (2008)
No modelo do carto de histria mostrado no trabalho de Kniberg (2008), o autor

menciona que um carto de histria deve possuir alguns campos obrigatrios que
permitam ao menos servir aos objetivos propostos, de maneira geral, o carto de histria
pode ser alterado de acordo com as necessidades, mas recomenda-se inicialmente tentar
utilizar apenas os campos descritos abaixo:
ID - Um nmero sequencial, apenas para identificar a ordem de criao dos
cartes de histria e certificar que nenhum se perdeu.
Nome - Ttulo de poucas palavras, relevante para que o cliente e a equipe
entendam bem do que se trata e distinguir das outras histrias.
Importncia - O mesmo que prioridade. Quanto maior o nmero, mais relevante
a histria. Porm, uma histria considerada mais importante no 2, 3 ou 4 vezes

mais primordial que outra, ela apenas mais importante. interessante que sejam
escolhidos valores bem espaados, de uma histria para a outra, para que seja possvel
acrescentar histrias com valor de importncia intermedirio.
Estimativa inicial - Calculada em pontos por histria.
Como demonstrar - Descrio em alto nvel de como a histria ser
demonstrada ao fim da iterao, isto , como uma especificao de teste de aceitao,

"Faa isso, ento faa aquilo e ento isso dever acontecer."
Notas - Outras informaes, esclarecimentos, referncias a outras fontes de
informao etc. Normalmente breve.

2.2 Distino da Histria de Usurio
As histrias de usurio segundo Cohn (2004) apresentam algumas das caractersticas
dos casos de uso ou das declaraes tradicionais de requisitos, ele afirma que
importante olhar para o que distingue as histrias de usurio das tcnicas anteriores, e
que estas diferenas podem resultar em inmeras vantagens.
Uma das principais diferenas das histrias de usurio est na comunicao verbal. A
linguagem escrita muitas vezes imprecisa, e no h nenhuma garantia de que um
cliente e/ou desenvolvedor ir interpretar uma declarao da mesma forma. Neste
sentido enfatizada a conversa com o cliente em contraste com as palavras escritas.
A segunda vantagem das histrias de usurio que elas podem ser utilizadas
prontamente no planejamento do projeto. Histrias de usurio so escritas de modo que
cada uma possua estimativa de quo difcil ou demorado ser o desenvolvimento, em
contra ponto aos casos de uso, que por outro lado, so geralmente maiores para ser
atribudas estimativas teis. Alm disso, uma histria implementada inteiramente em
determinada iterao de um projeto gil.
Cohn (2004) apresenta como problema, o estilo de especificao de requisitos proposto
pelo IEEE (1998), segundo o autor, quando se consideram as milhares ou dezenas de
milhares de declaraes do tipo (o sistema deve [...]) em uma especificao de
requisitos de software (e as relaes entre eles) para um sistema tpico, fcil perceber a
dificuldade inerente em prioriz-los. Se os requisitos no podem ser priorizados para
alm do comum mdio, alto e baixo, eles so altamente inadequados para um processo
iterativo e de desenvolvimento incremental que vai entregar software funcionando a
cada duas a quatro semanas.
Outra vantagem adicional das histrias de usurio destacada por Beck (2001) que as
histrias de usurio incentivam a equipe a adiar detalhes de coleta. Uma histria inicial
pode ser escrita e, em seguida, substituda com histrias mais detalhadas, uma vez que
torna-se importante conhecer os detalhes. Esta tcnica faz com que as histrias de
usurio se encaixem em projetos com tempo limitado.
Uma equipe pode muito rapidamente escrever algumas histrias para dar-lhes uma
sensao geral do sistema. Podem mergulhar nos detalhes sobre algumas das histrias e
iniciar a codificao muito mais cedo do que uma equipe que se sente compelida a
completar uma especificao de requisitos de software no estilo apresentado pela IEEE
(1998).
2.3 Histrias de Usurio no so Casos de Uso
Os casos de uso introduzidos por Jacobson (1992) so hoje mais comumente associados
com o Processo Unificado. Um caso de uso uma descrio generalizada de um
conjunto de interaes entre o sistema e um ou mais atores, no qual um ator ou um
utilizador ou outro sistema. Os casos de uso podem ser escritos em textos no
estruturados ou para se conformar com um modelo estruturado. Os modelos propostos

por Cockburn (2000) esto entre os mais usados.
Uma das mais bvias diferenas entre as histrias de usurio e casos de uso o seu
alcance. Ambos so dimensionados para agregar valor ao negcio, mas as histrias so
mantidas num tamanho menor, porque no desenvolvimento gil, conforme descrito em
Cockburn (2002) so definidas restries ao seu tamanho (nenhuma histria pode levar
mais de 10 dias de trabalho de desenvolvimento) para que possam ser utilizadas na
programao. Um caso de uso quase sempre abrange um escopo muito maior do que
uma histria.
As histrias de usurio e casos de uso tambm diferem no nvel de completude.
Grenning (2011) observou que os textos em um carto de histria de usurio que
descrevem os testes de aceitao possuem os mesmos dados que um caso de uso. Por
isso, Grenning (2011) sugere que a histria do usurio corresponde ao cenrio do caso
de uso principal, e que os testes de aceitao da histria correspondem aos fluxos
alternativos do caso de uso.
Outra importante diferena entre casos de uso e histrias de usurio citada por Cohn
(2004) a sua longevidade. Os casos de uso so muitas vezes artefatos permanentes que
continuam a existir, desde que o produto mantenha-se em desenvolvimento ativo ou
manuteno. Histrias de usurio, por outro lado, no se destinam a sobreviver
iterao em que eles so adicionados ao software. Embora seja possvel guardar os
cartes de histrias em arquivo, muitas equipes simplesmente inutilizam os cartes.
Os casos de uso e as histrias de usurios so escritos para diferentes fins. Os casos de
uso so escritos em formato aceitvel para os clientes e desenvolvedores, para que cada
um possa ler e concordar com o caso de uso. O propsito do caso de uso documentar
um acordo entre o cliente e a equipe de desenvolvimento. Histrias de usurio, por
outro lado, so escritas para facilitar a liberao e planejamento da iterao, e para
servir como espaos reservados para conversas detalhadas sobre as necessidades dos
usurios.
2.4 Histrias de Usurio no so Requisitos

A Sociedade de Computao do Instituto de Engenheiros Eltricos e Eletrnicos (IEEE)
publicou um conjunto de orientaes sobre como escrever especificaes de requisitos
de software em IEEE (1998). Este documento, conhecido como padro IEEE 830, traz
recomendaes que abrangem temas como a forma de organizar o documento de
especificao de requisitos, o papel dos prottipos, e as caractersticas dos bons
requisitos. A caracterstica mais distintiva do padro IEEE 830 na especificao de
requisitos o uso da frase "O sistema deve [...]", que a maneira recomendada pelo
IEEE para escrever requisitos funcionais.
Enquanto os requisitos sugerem o que deve ser feito, histrias de usurio focam nos
objetivos, e isso torna a viso do produto completamente diferente. Ao se concentrar
nos objetivos do usurio para o novo produto, ao invs de uma lista de atributos do novo
produto, segundo Beck (2001) pode-se projetar uma melhor soluo para as
necessidades do usurio.
A diferena final entre as histrias de usurio e o padro IEEE 830 de requisitos que foi
abordada em Cohn (2004) em relao ao custo do requisito que no visvel at que
todos os requisitos sejam escritos. O cenrio tpico que um ou mais analistas passam
dois ou trs meses escrevendo um documento de requisitos. Este documento ento
entregue aos programadores, que detectam que o projeto levar 24 meses, invs dos seis
meses previstos.
Neste caso, o tempo de escrita do documento foi desperdiado por que a equipe no ter
tempo para desenvolver, e mais tempo ser dispendido com os desenvolvedores e
analistas, que devero iterar com o cliente sobre quais funcionalidades podem ser
desenvolvidas no tempo desejado. Com histrias de usurio, uma estimativa est
associada com cada histria imediatamente. O cliente sabe a velocidade da equipe e o
custo de cada histria.
2.5 Envolvendo o Cliente no Processo de Desenvolvimento
Um dos poucos requisitos de XP apresentado por Beck (2001) ter o cliente disponvel
para ajudar a equipe de desenvolvimento e ser uma parte do mesmo processo. Todas as
10
fases de um projeto XP requerem comunicao com o cliente, de preferncia face a face

in loco.
Ao fazer o processo de levantamento das histrias de usurio da forma mais simples
possvel, fornece-se aos usurios de negcios uma ferramenta para reunir histrias de
usurios e, portanto, requisitos do sistema e decidir quais sero os requisitos que tero
maior benefcio com a implementao imediata no projeto e quais podero ter
implementao posterior. Segundo Cockburn (2002) o usurio de negcio e a equipe de
desenvolvimento podem, ento, priorizar as histrias e implementar uma soluo dentro
do prazo estipulado. Esse nvel de envolvimento de negcio d ao cliente um
sentimento de confiana no projeto e um forte senso de que sua contribuio vital para
uma implementao bem sucedida.
Com pequenas entregas e histrias facilmente digerveis em cartes ao invs de um
documento de requisitos de cem pginas, faz com que o cliente sinta-se como parte do
negcio e que a sua colaborao contribui para a entrega final do projeto.
2.6 Testes de Aceitao
Como parte do planejamento, histrias de usurio definem o que se quer construir no
projeto. As histrias de usurio so priorizadas para indicar quais so as mais
importantes para o sistema, como so divididas em tarefas e estimadas pela equipe de
desenvolvimento. Quando uma histria de usurio implementada, de acordo com
Kniberg (2008), um teste de aceitao mais formal, dever ser escrito para assegurar
que os objetivos da histria sejam cumpridos.
Testes de aceitao so criados a partir de critrios de aceitao que segundo Cohn
(2004) so descritos no verso do carto da histrias de usurio. Os critrios de aceitao
definem os limites de uma histria de usurio, so usados para confirmar quando uma
histria concluda e est funcionando conforme o esperado e so escritos em
linguagem simples, assim como a histria do usurio. Quando a equipe de
desenvolvimento concluir a histria do usurio dever demonstrar a funcionalidade para
o cliente, mostrando como cada critrio est satisfeito. A Figura 2 apresenta um
exemplo dos critrios de aceitao.
11
Figura 2. Exemplo de template dos Critrios de Aceitao. Fonte Cohn (2004)
Cada teste de aceitao representa algum resultado esperado a partir do sistema. Devese verificar a correo dos testes de aceitao e resultados, para decidir quais so os de
maior prioridade que falharam. Uma histria de usurio no considerada completa at
que seus testes de aceitao tenham sidos aprovados.
3 Estudo de Caso
Esta seo descreve o escopo do sistema que ser usado como fonte de estudo para
aplicao dos mtodos geis no levantamento de requisitos e apresenta os diagramas de
caso de uso, atividade e classe, utilizando-se a UML. A seo apresenta tambm a
aplicao dos requisitos geis no sistema proposto, com o objetivo de verificar a
possibilidade de substituio dos casos de uso, atravs da utilizao das histrias de
usurio durante o levantamento de requisitos, identificando e mapeando as
funcionalidades.
3.1 Descrio do Projeto
O estudo de caso trata de um sistema de rede de locao de veculo, que tem como
principal objetivo controlar a locao dos veculos da empresa. Os veculos so
divididos em grupos, o que possibilita a escolha por parte do cliente. Para a realizao
da reserva, os funcionrios da rede de locao fazem suas respectivas anlises tendo
como base o cadastro dos seus clientes. Caso haja restrio de acordo com as regras, o
funcionrio preenche formulrio na Internet com todas as informaes da restrio da
12
reserva. Na rede de locao, o funcionrio responsvel pela entrega e recebimento dos

veculos, cadastra nos dados da reserva as informaes obtidas durante a locao.
Para realizao da reserva necessrio que o cliente tenha habilitao para dirigir o
veculo de acordo com o grupo escolhido, deve tambm ser observado o histrico de
outras locaes do cliente. Caso exista alguma restrio, o responsvel pela reserva deve
notificar o cliente atravs do sistema.
O estudo foi iniciado com a fase de explorao, conceituada anteriormente na seo 2,
cujo objetivo foi compreender o que o sistema precisava fazer, bem como analisar o
suficiente para que pudesse ser estimado. Essa estimativa foi preliminar, e partiu dos
primeiros requisitos obtidos no estudo.
Em paralelo s histrias dos usurios, foram avaliadas as diferentes formas de registrar
os requisitos levantados no desenvolvimento de um sistema. Nesta etapa, foram
utilizados os modelos de casos de uso propostos por Cockburn (2000).
O contexto da aplicao sugere que o sistema fique disponvel por meio de servios online, neste sentido foi identificada a necessidade de utilizar os conceitos de SOA
(Service Oriented Architecture), desenvolvendo um Provedor, seguindo os conceitos de
distribuio destes servios e posteriormente o seu uso atravs dos Consumidores.
Diante das informaes supracitadas, os casos de uso apresentados neste estudo de caso
foram criados com base em dados obtidos atravs de entrevistas no estruturadas. Foi
escolhido este formato, devido a gerao espontnea das perguntas no fluxo natural de
uma interao. Este tipo de entrevista apropriado quando o entrevistador quer manter
o mximo de flexibilidade na entrevista para direcionar o questionamento no sentido
que lhe parecer apropriado, explorando as informaes contidas nas respostas ou em
conversas com os indivduos participantes, que descrevem as regras de negcio.
Foram utilizadas algumas atividades bsicas no preparo da entrevista: estudar o domnio
do problema, determinar objetivos e lista de questes, planejar e agendar os encontros.
A Tabela 1 apresenta a aplicao da entrevista no estruturada no estudo de caso.
13
Tabela 1. Dados obtidos na aplicao da entrevista no estruturada

Objetivos da Entrevista
Obter informaes relevantes dos clientes, funcionrios e veculos;
Entender o processo de reserva, identificar informaes necessrias;
Analisar o processo de reserva do cliente;
Entrevistados
Funcionrios;
Clientes;
Perguntas
Quais campos so necessrios para o cadastro do cliente?
Os carros so categorizados por quais grupos?
As reservas sero informadas ao cliente e aos funcionrios?
As reservas possuem descontos ou multas?
Para efetuar a reserva necessrio verificar se o cliente tem alguma restrio?
Na reserva, o cliente deve estar previamente cadastrado?
Quais informaes so necessrias para efetuar a reserva?
Resumo da Entrevista
Informaes dos clientes: nome, cpf/cnpj, inscrio municipal, inscrio estadual, endereo,
bairro, complemento, cidade, estado e cep;
Os grupos so fixos: Econmicos, Utilitrios e Luxo;
O funcionrio necessita visualizar as reservas preenchidas pelos clientes e marcar como lida e
no lida via formulrio na web;
O desconto ou multa informado no momento da efetuao do pagamento, com base nos dados
da locao;
O controle de reserva, inicia com a verificao dos dados do cliente, avaliando se existe alguma
restrio, como carteira de habilitao e histrico de multas;
O modelo de caso de uso proposto foi obtido atravs das informaes fornecidas em
entrevistas com o cliente. um modelo que tenta representar os atores envolvidos no
domnio da aplicao, porm sem maiores detalhes, serve para aprimorar o
entendimento e discusso dos requisitos. Foram utilizados inicialmente neste trabalho
para descobrir e registrar os primeiros requisitos de sistemas que podem ser vistos na
Figura 3.
14
uc Modelo de Caso de Uso
UC05- Retirar Veculo
UC06 - Entregar
Veculo
precedes
(from Locao)
(from Locao)
precedes
UC09 - Manter
informaes dos
Veculos
Atendente
precedes
(from Atores)
precedes
(from Locao)
precedes
UC08 - Visualizar
Reserv as
(from Histrico)
precedes
UC01 - Manter
Informaes do Cliente
A
precedes
(from Locao)
UC04 - Efetuar
Reserv a
include
(from Reserva)
UC07 - Efetuar
Pagamento
(from Pagamento)
UC02 - Verificar
Carros Disponv eis
Cliente
(from Atores)
(from Reserva)
UC03 - Verificar
Preos
(from Reserva)
Figura 3. Modelo de caso de uso do sistema proposto no estudo de caso

preciso ressaltar que as listas de regras de negcio no so equivalentes as de
requisitos. Kulak e Gurney (2005) destacam que os casos de uso no podem retratar
todas as sutilezas de como a empresa gerida. Para isso, precisa-se das regras de
negcio. As regras de negcios so as regras escritas e no escritas que ditam como uma
empresa ou agncia conduz seus negcios. Requisitos relacionam-se com uma aplicao
especfica a ser considerada ou desenvolvida.
A obteno das regras de negcio do sistema (Figura 4) foi facilitada pelo fluxo de
negcio descrito pelo cliente. De acordo com a orientao de Ambler (2012), projetos
geis devem focar nos requisitos com maior nvel de prioridade em cada iterao,
sabendo que preciso considerar as regras de negcio como requisitos separados.
Ambler (2012) ainda afirma "as equipes de desenvolvimento de software geis devem
abraar as mudanas, aceitando a ideia de que as exigncias vo evoluir ao longo de um
projeto".
15
class Regras de Negcio

RN01 - Carro no pode ser
alugado por um Cliente com
menos de 18 anos

o Nivel de Advertncia
maior ou igual a 3
RuleTask
Elegv el

alugado por um Cliente sem
licena para dirigir
(from Modelo Conceitual)
RN03 - Aluguel para carros

do tipo Econmico
R$80,00 por dia

do tipo Utilitrio R$100,00
por dia
RuleTask
Determinar Aluguel a
Pagar
RN10 - Valor do Aluguel

calculado como o produto
de Valor do Aluguel por dia
e o perodo de dias Alugado

do tipo Luxo R$150,00 por
dia
RN06 - Taxa de Multa de 10
% deve ser aplicada nos
clientes que tem o Nvel de
Advertncia igual a 1
RuleTask
Determinar Taxa de
Multa
RN07 - Taxa de Multa de 20
% deve ser aplicada nos
clientes que tem o Nvel de
RN08 - Valor Total a Pagar

calculado com a soma do
Valor do Aluguel e Taxa de
Multa se houver.
RN11 - Taxa de Multa no

pode ser aplicada para
clientes com o Nvel de
RuleTask
Determina o Valor
Total a Pagar
Figura 4. Regras de negcio do sistema proposto no estudo de caso

3.2 Aplicao do Caso de Uso
Os casos de uso so amplamente utilizados em processos de software baseados em uma
abordagem disciplinada, como o Rational Unified Process (RUP) segundo Kruchten
(2003). Este formato tem o objetivo de descrever o conjunto de interaes e eventos
entre os usurios ou sistemas externos (tambm conhecidos como atores).
Essas descries incluem as funcionalidades do sistema, necessrias para satisfazer as
exigncias do solicitante. H diferentes diretrizes para escrever casos de uso e a eficcia
de um caso de uso depende da capacidade do autor para escrev-los. Um exemplo de
um caso de uso apresentado na Tabela 2.
16
Tabela 2. Descrio do caso de uso "UC04 - Efetuar Reserva"

Nome:
UC04 - Efetuar Reserva
Sumrio:
O sistema deve permitir que os clientes que desejam realizar locaes de carros
efetuem uma reserva. Este caso de uso recebe solicitaes de incluso,
alterao, excluso de reserva.
Ator:
Cliente
Entrada:
Dados do Cliente, Informaes do Veculo, Dados de pagamento, Data da

reserva.
Pr-condies:
Para efetuar reserva o cliente deve possuir um cadastro ativo no sistema.
Fluxo Principal:
1. O Cliente insere as informaes de entrada e solicita a reserva [RF07];

2. O Sistema verifica as informaes de acordo com as regras de negcio
[RN01], [RN02], [RN09]; Se a avaliao das regras de negcio no aprovar a
reserva vai para o [Fluxo Alternativo 1];
3. O sistema registra uma reserva para o Cliente;
4. O Cliente visualiza o nmero da sua reserva gerada pelo sistema;
5. O Cliente pode alterar a sua reserva [Fluxo Alternativo 2];
6. O Cliente pode cancelar a sua reserva [Fluxo Alternativo 3].
Fluxo Alternativo
O sistema retorna uma mensagem avisando que no possvel efetuar a reserva
1:
pois o Cliente no passou na validao da regra de negcio (Exibe as

informaes das regras que o Cliente no atendeu).
Fluxo Alternativo
O Cliente solicita a alterao dos dados da reserva [RF08]. Devem ser
2:
executados os passos do Fluxo Principal novamente.
Fluxo Alternativo
O Cliente solicita o cancelamento da reserva. Aps uma mensagem de
3:
confirmao, o sistema deve cancelar a reserva [RF09].
Requisitos
RF07 - Realizar a reserva de veculo
Relacionados:
O sistema deve permitir que o cliente efetue a reserva de um veculo de acordo

com as regras de negcio [RN01], [RN02] e [RN09]
RF08 - Alterar as informaes da reserva
O sistema deve permitir que o Cliente altere as informaes de uma reserva.
RF09 - Excluir a reserva de veculo
O sistema deve permitir que o cliente exclua uma reserva.
Este caso de uso apresentado corresponde s histrias do usurio que sero apresentadas
na subseo posterior. Como pode ser visto na Tabela 1, um caso de uso contm o
nome, o sumrio, as condies, os dados de entrada, os atores, a descrio de cada passo
no cenrio principal, fluxos de exceo e os requisitos relacionados.
17
Desta forma, o caso de uso contm informaes especficas sobre os passos que o
usurio deve seguir para usar com sucesso a nova funcionalidade do sistema. Tambm
esto includos os detalhes, tais como as regras de negcio, validaes especficas (por
exemplo, o carro no pode ser alugado por um cliente com menos de 18 anos) e as
mensagens de erro.
Na Figura 5 apresentada uma imagem utilizando a notao UML para ilustrar os
processos em ao.
uc UC04 - Efetuar Reserv a
RF08 - Alterar as
informaes da reserva
(from Requisitos Funcionais)
UC04 - Efetuar
Reserv a
Cliente
(from Atores)
RF07 - Realizar a reserva de

veculo

menos de 18 anos
(from Regras de Negcio)

o Nivel de Advertncia
maior ou igual a 3

RF09 - Excluir a reserva de
veculo

alugado por um Cliente sem
licena para dirigir
Figura 5. Digrama de caso de uso "UC004 - Efetuar Reserva"
3.3 Aplicao da Histria de Usurio

Segundo Cohn (2004) as histrias de usurio so criadas pelo cliente, ou com
participao dele e apoio da equipe, no momento do levantamento de requisitos. Com
base na entrevista descrita na seo 3.1 foram descobertas as funcionalidades a serem
implementadas neste estudo de caso. Essas funcionalidades (requisitos ou histrias de
usurio) so mantidas em uma lista chamada de product backlog.
Um dos princpios do manifesto gil usado aqui: adaptao ao invs de planejamento.
O product backlog no precisa ento ser completo no incio do projeto. Pode-se iniciar
apenas com as funcionalidades mais evidentes para depois, medida que o projeto
avana tratar novas funcionalidades que vo sendo descobertas. Isso, porm, no
significa fazer um levantamento inicial excessivamente superficial.
18
Desta forma, foi necessrio junto ao cliente obter o maior nmero possvel de
informaes sobre suas necessidades. Aquelas que efetivamente surgiram nessa
interao tiveram maior relevncia, em relao a outras que forem descobertas mais
adiante. A Tabela 3 apresenta as histrias de usurio no product backlog, estruturadas
segundo definio de Kniberg (2008) detalhada na seo 2.
Tabela 3. Lista de histrias de usurio que representam o caso de uso utilizado no estudo
Product Backlog
ID
Nome
Imp.
PH
Como demonstrar
Notas
Cadastrar Reserva
30
Como um Cliente eu
Necessrio
quero efetuar a reserva
diagrama de sequncia.
ter
um
de um veculo de modo
que possa realizar a
locao
posteriormente.
2
Alterar os dados da
20
reserva
Como um Cliente eu
Usar
bloqueio
de
quero alterar a reserva
persistncia otimista.
que possa alterar as
informaces da reserva.
3
Excluir Reserva
10
Como um Cliente eu
Manter um log com as
quero excluir a reserva
informaes
excluiu a reserva.
de
quem
que possa cancelar a

reserva
anteriormente
criada.
O ideal que seja apenas uma pessoa a criar as histrias e prioriz-las para repassar
equipe de desenvolvimento. As histrias representam a materializao das necessidades
do cliente em relao ao software. Ou seja, so as especificaes detalhadas das
funcionalidades desejadas.
O principal objetivo de serem escritas com o cliente sempre presente manter o foco
em objetivos do negcio. Ainda que o cliente possua algum conhecimento tcnico,
papel da equipe determinar como resolver um problema tecnicamente. O cliente deve
focar nos objetivos do negcio.
19
Os registros das histrias de usurio foram elaborados utilizando o software Team

Foundation Server (TFS), juntamente com um conjunto de templates para a utilizao
do SCRUM (product backlog, sprint, user story, task, acceptance test etc.)
desenvolvidos por Microsoft (2013) e disponibilizados gratuitamente.
A Figura 6 apresenta lista de histrias de usurio registradas no product backlog da
ferramenta TFS.
Figura 6. Lista de histrias de usurio cadastradas no TFS (Team Foudation Server)

Foi elaborada uma estimativa com base nos cartes de histria, na metfora e em uma
soluo simples (ASTELS et al., 2002). O objetivo desta fase foi estimar o menor tempo
e o maior nmero de histrias para a primeira verso (BECK, 2000). O projeto tambm
poderia ser dividido em vrias iteraes, sendo necessrio identificar os seus respectivos
entregveis.
Com base nessas estimativas, a equipe se comprometeu a desenvolver as
funcionalidades, e o cliente se comprometeu a no trazer novas funcionalidades durante
o perodo estipulado. Se novas funcionalidades fossem descobertas, seriam abordadas
em perodos posteriores. Este ciclo de desenvolvimento, com poucas semanas de
durao sobre o qual se estrutura o SCRUM so os chamados sprints.
No incio de cada sprint foi feito uma reunio de planejamento, na qual a equipe
priorizou os elementos do product backlog a serem implementados, e transferiu estes
elementos do product backlog para o sprint backlog, ou seja, a lista de funcionalidades
a serem implementadas no ciclo que iniciou.
20
Durante o sprint, coube ao responsvel manter o sprint backlog atualizado, indicando as

tarefas j concludas e as ainda por concluir. Neste estudo de caso foi escolhida a
ferramenta TFS para atualizar as tarefas diariamente vista de todos. Um exemplo do
quadro de andamento de atividades apresentado na Figura 7.
Figura 7. Quadro Kanban com o controle da lista de histrias de usurio
3.4 Teste de Aceitao do Estudo de Caso

Durante uma iterao, as histrias selecionadas pelo usurio na reunio de planejamento
de iterao foram traduzidas em testes de aceitao com base nos respectivos critrios
de aceitao. Uma histria pode ter um teste de aceitao ou muitos, o que for preciso
para garantir que a aprovao da funcionalidade.
O teste de aceitao foi realizado com o objetivo de verificar se o produto foi
desenvolvido de acordo com as normas e critrios especificados e atende a todos os
requisitos especificados pelo cliente. Neles foram aplicados a metodologia de teste de
caixa preta, onde o usurio no est muito interessado na codificao do sistema, mas
sim, na avaliao do funcionamento global, comparando-o com os requisitos
especificados no incio do projeto.
Com base nos requisitos especificados pelo usurio, a execuo dos casos de teste
ocorreu atravs da maneira iterativa ou sob a forma de um conjunto de parmetros
variveis. O sistema teve que passar a operar num ambiente de computao que imitou
o ambiente operacional real existente no contexto do usurio. Os resultados dos testes
de aceitao foram denominados como: sucesso ou fracasso com base nas condies de
funcionamento crticos e sucesso ou fracasso com base avaliao final do usurio do
sistema.
21
A Figura 8 apresenta a utilizao dos testes de aceitao aplicados no estudo de caso.
Figura 8. Critrios de aceitao cadastrados para a histria de usurio
3.5 Comparao da Histria de Usurio com o Caso de Uso

Casos de Uso so mais representativos que Histrias de Usurio, pois podem variar
entre dois pargrafos e dez pginas. Eles so bons para mostrar os caminhos alternativos
de uma caracterstica especfica. As histrias tambm poderiam conseguir isso, desde
que fossem escritos os caminhos excepcionais em diferentes histrias de usurio, mas
esta abordagem uma adaptao da tcnica ao invs de um planejamento de uso, o que
contrasta com os casos de uso.
Normalmente, as histrias no sero suficientes em uma organizao na qual a
documentao formal obrigatria. Sua principal diferena em relao aos casos de uso
ou cenrios que histrias de usurio tm o objetivo de capturar a perspectiva de que o
usurio tem sobre o sistema. Algumas das diferenas entre os Casos de Uso e as
Histrias de Usurio so apresentadas na Tabela 4.
Tabela 4. Diferenas entre casos de usos e histrias de usurio.
Caso de Uso / Cenrios
Histrias de Usurio
So apresentados usando uma sintaxe restrita
So apresentados usando a linguagem natural em
(semi-formal)
forma de conversa
So especificaes de interaes de objetos
So descritivas e apresentam os desejos do cliente
Contm "como"
Contm "o qu" e "porqu"
22
Outro formato de levantamento de requisitos que amplamente utilizado so os

cenrios. Algumas vezes, os termos de casos de uso e cenrios so usados
alternadamente. No entanto, o presente estudo usar a definio dada por Alessander e
Maiden (2004) de que "Um caso de uso sempre composto de vrios cenrios que
descrevem formas alternativas para tentar atingir a meta".
Do ponto de vista de que os cenrios fazem parte dos casos de uso, possvel avaliar
que cada formato de exigncia tem vantagens e desvantagens. Estudos como o de
Alessander e Maiden (2004) questionam se os casos de usos so complementares s
histrias de usurio ou se as tornam redundantes no desenvolvimento gil.
O presente estudo tem como objetivo apresentar evidncia para orientar equipes de
desenvolvimento de software sobre a existncia de qualquer benefcio na utilizao de
casos de uso em relao s histrias de usurio, mas tambm, deseja apresentar as
histrias como um novo mtodo, alm dos formatos de requisitos que esto sendo
usados atualmente.
Na comparao entre casos de uso e requisitos geis, Alessander e Maiden (2004)
afirmam que os dois mtodos so complementares. Entretanto, outros autores apontam
vrias diferenas entre os dois mtodos. Como principais diferenas destaca-se que a
escrita dos requisitos no formato de casos de uso pode economizar tempo, se as pessoas
lerem os documentos. No entanto, surge como ponto fraco a forte exigncia de formatos
para a escrita de casos de uso em relao aos requisitos geis.
As principais diferenas encontradas neste estudo, entre o levantamento de requisitos
utilizando requisitos geis e casos de uso so apresentados na Tabela 5.
Tabela 5. Comparativos entre casos de uso e histrias de usurio
1
A histria de usurio uma breve descrio da funcionalidade atravs da viso do cliente; A

histria de usurio no uma sequncia de aes. No necessrio modelar a interao entre o
ator e o sistema, como sugerem os casos de uso.
A histria de usurio curta e consiste em uma ou duas frases escritas no idioma do usurio,
focando na meta final da funcionalidade; Um caso de uso mais pesado, mais rico em
informaes: objetivo, resumo, ator, pr-condio, evento de disparo, cenrio de sucesso
23
principal e fluxos alternativos e de erros.

3
Uma histria de usurio menor e, finalmente, pode ser vista como parte de um caso de uso
especfico: o cenrio do fluxo principal ou uma extenso.
Histrias de usurio so usados para o planejamento, desempenham um papel importante no

projeto durante a estimativa e planejamento. Os casos de uso no so utilizados para
planejamento, apesar de poder usar a tcnica "Pontos por caso de uso " para estimar o tamanho
do projeto, no tem esse objetivo.
Histrias de usurio surgem mais rapidamente do que os casos de uso; Casos de uso necessitam
de mais tempo para anlise e escrita.
Histrias de usurio so mais legveis do que os casos de uso; Casos de uso geralmente so
maiores, muitas vezes, difceis de ler, mesmo em um modelo estruturado.
As histrias de usurio so mais fceis de manter do que um documento de 150 pginas com
casos de uso.
As histrias de usurio baseiam-se em comunicao verbal e contam com a colaborao,

discusso e proximidade para esclarecer detalhes; Caso de uso um modelo textual associado
com diagramas UML.
Histrias de usurio so, em teoria, escritas em cartes; Esses cartes no esto destinados a ser
arquivados ao contrrio dos casos de uso.
10
A histria de usurio deve ser implementada e testada em uma iterao; Um caso de uso
especfico pode ser implementado em vrias iteraes.
11
Histrias de usurio podem ser facilmente escritas por um usurio ou cliente; A maioria dos
casos de uso necessitam de mais tempo para serem escritos por usurios.
12
Histrias de usurio contm critrios de aceitao, escrito na parte de trs do carto da histria;
Casos de testes so criados em um documento separado.
3.6 Otimizando a Histria de Usurio

No processo de anlise de sistemas, ao levantar as informaes referentes ao que tem
que ser feito, so identificados os requisitos necessrios para a completude do projeto.
Estes requisitos identificados podem ter dentro de si, uma quantidade de outros
requisitos implcitos. Pode haver tambm requisitos pequenos, que j permitam um
entendimento e estimativa dos mesmos.
Estas discrepncias entre os requisitos podem ser normalizadas com a tcnica de
INVEST proposta por Wake (2003). Mas normalizar no a nica responsabilidade do
INVEST, ele auxilia a entender melhor os requisitos, a realizar estimativas mais
acertadas, definir critrios de aceite, definir o valor agregado do requisito ao negcio e
priorizar o que realmente deve ser entregue ao cliente. A INVEST igual a:
24
Independent - Independente
Negotiable - Negocivel
Valuable - Avalivel
Estimatable - Estimvel
Sized Appropriately - Dimensionada apropriadamente
Testable Testvel
Deve-se buscar a independncia entre as histrias de usurio, isto , no ter correlao

direta entre elas. Fica mais fcil realizar a estimativa focada a uma histria do que
realizar uma estimativa em um conjunto de histrias.
Uma histria no seu processo de entendimento gera um conjunto de conversas, que so
anotaes realizadas na histria para saber o que tem que fazer para deixar a histria
aderente s necessidades do cliente, isto faz parte do conceito de negociao.
Histrias devem gerar valor ao cliente, uma boa tcnica de buscar este valor o prprio
cliente escrevendo as suas histrias. Nem sempre possvel o cliente escrev-las, no
importando no momento o que leva a esta impossibilidade.
No momento de realizar uma estimativa importante que as histrias de usurio estejam
independentes e negociadas. Se no existe mais dependncia entre histrias a,
estimativa vai ser mais eficiente e sem as funcionalidades desnecessrias para a entrega,
o que melhora cada vez mais a previso.
No existe uma frmula mgica para determinar o tamanho que as histrias de usurio
devem ter, mas este tamanho se normaliza com o processo de levantamento de histrias
e anlise. Quanto menor a histria, mais fcil de estimar.
Uma boa tcnica de descobrir como a histria de usurio deve se comportar, realizar
testes de validao. Conversas e testes de aceitao fecham um ciclo de entendimento
da histria. Qualquer implementao a mais, que no tenha sido identificada nas
conversas ou testes no deve ser realizada na mesma iterao.
25
4 Trabalhos Relacionados
Uma srie de estudos tm comparado Requisitos Tradicionais e Requisitos geis. Em
geral, identificam duas abordagens complementares. Paetsch, Eberlein e Maurer (2003)
realizaram um estudo acerca deste assunto e concluram que ambos tm objetivos em
reas-chave e que a principal diferena entre eles a quantidade de documentao
criada no projeto.
Eberlein e Leite (2002) apresentaram estudo que discutiu a aplicabilidade da engenharia
de requisitos para processos geis. Argumentaram que quatro prticas (Interao com o
Cliente, Anlise de Requisitos No-Funcionais e Gesto de Configurao e Mudana)
devem ser adicionadas aos Requisitos geis, a fim de garantir a qualidade do software
produzido.
Meszaros (2004) escreveu um relato de experincia propondo quatro "storyotypes"
(esteretipos da histria), com base em casos de uso a serem usados como diretrizes
para dividir grandes histrias de usurio. Como os casos de uso so amplamente
utilizados e compreendidos como forma de levantamento de requisitos, Mezaros (2004)
exps sua preocupao de que os membros das equipes que tiveram experincia anterior
com casos de uso, tivessem dificuldade em criar histrias de usurio. Esses
desenvolvedores esto acostumados a trabalhar com modelos que podem ter muitos
cenrios e so mais propensos a criar uma grande histria de usurio baseada apenas em
um caso de uso.
Imaz e Benyon (1999) estudaram como histrias de usurio e casos de uso podem ser
usados em conjunto para melhores interaes durante o levantamento de requisitos.
Concluram que histrias de usurio so eficazes para a captura e interao, mas os
casos de uso so necessrios para a implementao quando a documentao formal
necessria. No entanto, no houve experimento controlado para comparar a utilizao
das histrias de usurio, como o descrito neste artigo.
26
5 Concluso
Baseado na publicao de Kniberg (2008) entende-se que alm da confirmao de que
as histrias de usurio esto se tornando cada vez mais populares, muito provavelmente,
continuaro a crescer at serem amplamente utilizados.
Histrias de usurio descrevem as necessidades do cliente. Quando uma histria de
usurio escrita, o que o autor est descrevendo puramente uma necessidade do
usurio. algo que o usurio precisa fazer no seu trabalho do dia-a-dia. Se nunca foi
construdo qualquer software para o cliente em questo, entende-se que essa
necessidade ainda existe.
Os casos de uso descrevem o comportamento que ser construdo no software para
atender tais necessidades. Um desenvolvedor que precisa construir um software deve ser
capaz de ler um caso de uso e ter uma boa noo do que o software precisa fazer.
Normalmente possui muitos detalhes, e descreve tudo o que o desenvolvedor precisa
para construir, a fim de atender necessidade do usurio. por isso que precisa ter
muito mais detalhes e possuir uma linguagem clara e inequvoca.
Apesar de existir um modelo mais tradicional proposto por Cohn (2004) que est sendo
usado e ensinado, constata-se atravs das palavras de Kniberg que a evoluo continua
e, com ela, diversas mudanas em futuro prximo.
Os fabricantes de ferramentas CASE (Computer-Aided Software Engineering) tendem a
produzir produtos que melhor correspondem teoria, e que permitam criar histrias de
usurio mais fceis de escrever, com facilidade para manter e rastrear. As ferramentas j
evoluram, e evoluiro ainda mais, auxiliando a manter detalhes de UI (User Interface)
fora da descrio dos cartes das histrias. Em breve, poder-se- usar os diferentes
nveis de formalidade para a escrita das histrias de usurio, atravs da gerao
automtica baseada na descrio simples dos artefatos utilizados no desenvolvimento
gil.
Equipes distintas almejam quantidades diferentes de formalidade. Existem outros
mtodos para documentar as histrias de usurio que surgiram para responder
27
diferentes necessidades. Em um extremo, uma organizao pode exigir o uso formal que
defina rigorosamente todos os comportamentos possveis que o cliente deseja, somente
para se aproximar do modelo de requisitos, enquanto no outro extremo, uma
organizao pode exigir histrias de usurio bastante simples. Qualquer dessas
abordagens tende a sofrer mudanas. As organizaes procuraro criar modelos
alternativos que atendam os diversos tipos de necessidade e formalidade, para que os
interessados tenham condies de escolher o modelo de acordo com o nvel de detalhe
consumado com suas necessidades.
Enquanto modelos so teis, usurios tm desejo de preencher todas as caixas expostas
em um carto de histria de uma vez. As pessoas continuaro a fazer mau uso deles,
assim como j fizeram com os casos de uso e culparo a confuso resultante da forma
em que as histrias de usurio foram concebidas. Algumas escolas geis j trabalham na
mudana de comportamento, no deixando que o informal se aproxime do
desenvolvimento irresponsvel ou que volte a burocracia do modelo formal do processo
unificado, embora se evidencia que essa iniciativa tambm tenha sido mal interpretada
pelas pessoas que insistem em atacar ferramentas e processos ao invs do
comportamento humano. Resta esperar que o modelo gil, depois de tanta insistncia,
consiga mudar este comportamento.
Artigo recebido em junho de 2013 e aceito para publicao em abril de 2014
The Utilization of User Stories in Agile Requirements Survey

Abstract
From the popularity of the agile methods, there are discussions about what are user
stories, why use user stories and how to describe the best way a systems behavior
through the requirements engineering. The purpose of this article is to show the use of
user stories are sufficient during the requirements gathering, approaching the different
ways to describe, understand and use them today. To illustrate the stages of
28
development of the user story is presented a case study which aimed to apply techniques
of this method compared the techniques of gathering requirements use case-driven.
Key Words: User Stories. Software Development
REFERNCIAS
Alexander, I. and Maiden, N., (2004) Scenarios, Stories, Use Cases: Through the
Systems Development Life-Cycle, John Wiley.
Ambler, S., (2012) Agile Requirements change Management. Disponvel em
http://agilemodeling.com/essays/changeManagement.htm
Astels, D; Miller, G; Novak, M. (2002) Extreme Programming Explained: Guia Prtico.
Rio de Janeiro: Ed. Campus.
Beck, K. (2000) Extreme Programming Explained,Embrace Change. AddisonWesley.
Beck, K., Fowler, M., (2001) Planning Extreme Programming. Addison-Wesley. Cohn,
M., User Stories Applied: For Agile Software Development, Addison-Wesley, 2004
Cockburn, A., (2000) Writing Effective Use Cases. Addison-Wesley.
Cockburn, A., (2002) Agile Software Development, Pearson Education.
Eberlein, A. and Sampaio do Prado Leite, J.C., Agile Requirements Definition: A view
from
requirements
engineering,
TCRE02,
2002.
Disponvel
em
http://www.enel.ucalgary.ca/tcre02/papers/Eberlein.pdf
Fowler, M. and Highsmith, J., "The Agile Manifesto", Software Development, 2001,
Vol. 9, pp. 28-32.
Grenning, J., (2011) Test Driven Development for Embedded C. Pragmatic Bookshelf.
IEEE Computer Society, (1998) IEEE Recommended Practice for Software
Requirements Specifications.
29
Imaz, M. and Benyon, D., How Stories Capture Interactions. INTERACT'99, 1999.
Disponvel em http://www.dcs.gla.ac.uk/i99/programme.html.
Jacobson, I. (1992) et al. Object-Oriented Software Engineering: A Use-Case Driven
Approach, Addison-Wesley, Reading, MA.
Jeffries, R., Essential XP: Card, Conversation, and Confirmation, XPMagazine, 2001.
Disponvel em http://xprogramming.com/articles/expcardconversationconfirmation/
Meszaros, G., Using Storyotypes to Split Bloated XP Stories, XP/Agile Universe
Conference, 2004. Disponvel em http://www.informatik.unitrier.de/~ley/db/conf/xpu/xpu2004.html.
Microsoft, Team Foundation
http://tfs.visualstudio.com/.
Service.
Preview,
2013.
Disponvel
em
Paetsch, F., Eberlein, A. and Maurer, F., Requirements Engineering and Agile Software
Development, WETICE 03 2003. Disponvel em
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=8713.
Kniberg, H., Scrum e XP Direto das Trincheiras. InfoQ, 2008. Disponvel em
http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches.
Kruchten, P., (2003) The Rational Unified Process: An Introduction, Addison-Wesley.
Kulak, D. and Guiney, E., (2005) Use Cases - Requirements in Context Second Edition,
Addison-Wesley.
Wake, B., INVEST in Good Stories, and SMART Tasks. XP123, 2003. Disponvel em
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ .
30

Artigo Historias de Usuarios

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Artigo Historias de Usuarios

Hochgeladen von

Copyright:

Verfügbare Formate

A Utilizao de Histrias de Usurios no Levantamento de

Professor do Curso de Sistemas de Informao na Universidade do Planalto Catarinense, Arquiteto de

correntemente no se acredita mais em uma soluo nica e salvadora para os

2 Requisitos geis Atravs de Histrias do Usurio

sim utilizar histrias como ferramenta para a conduo de uma conversa em um

Como um... (papel ou ator) (Quem)

Eu quero... (capacidade ou funcionalidades necessrias) (O que)

de modo que... (por que de valor do negcio ou benefcio) (Por que)

Figura 1. Exemplo de um carto de histria de usurio adaptado da fonte Kniberg (2008)

No modelo do carto de histria mostrado no trabalho de Kniberg (2008), o autor

ID - Um nmero sequencial, apenas para identificar a ordem de criao dos

cartes de histria e certificar que nenhum se perdeu.

Nome - Ttulo de poucas palavras, relevante para que o cliente e a equipe

entendam bem do que se trata e distinguir das outras histrias.

Importncia - O mesmo que prioridade. Quanto maior o nmero, mais relevante

a histria. Porm, uma histria considerada mais importante no 2, 3 ou 4 vezes

Estimativa inicial - Calculada em pontos por histria.

Como demonstrar - Descrio em alto nvel de como a histria ser

demonstrada ao fim da iterao, isto , como uma especificao de teste de aceitao,

Notas - Outras informaes, esclarecimentos, referncias a outras fontes de

informao etc. Normalmente breve.

estruturados ou para se conformar com um modelo estruturado. Os modelos propostos

2.4 Histrias de Usurio no so Requisitos

fases de um projeto XP requerem comunicao com o cliente, de preferncia face a face

Figura 2. Exemplo de template dos Critrios de Aceitao. Fonte Cohn (2004)

reserva. Na rede de locao, o funcionrio responsvel pela entrega e recebimento dos

Tabela 1. Dados obtidos na aplicao da entrevista no estruturada

Obter informaes relevantes dos clientes, funcionrios e veculos;

Entender o processo de reserva, identificar informaes necessrias;

Analisar o processo de reserva do cliente;

Quais campos so necessrios para o cadastro do cliente?

Os carros so categorizados por quais grupos?

As reservas sero informadas ao cliente e aos funcionrios?

As reservas possuem descontos ou multas?

Para efetuar a reserva necessrio verificar se o cliente tem alguma restrio?

Na reserva, o cliente deve estar previamente cadastrado?

Quais informaes so necessrias para efetuar a reserva?

bairro, complemento, cidade, estado e cep;

Os grupos so fixos: Econmicos, Utilitrios e Luxo;

no lida via formulrio na web;

restrio, como carteira de habilitao e histrico de multas;

uc Modelo de Caso de Uso

UC05- Retirar Veculo

Figura 3. Modelo de caso de uso do sistema proposto no estudo de caso

class Regras de Negcio

RN02 - Carro no pode ser

RN09 - Carro no pode ser

(from Modelo Conceitual)

RN03 - Aluguel para carros

RN04 - Aluguel para carros

RN10 - Valor do Aluguel

(from Modelo Conceitual)

RN08 - Valor Total a Pagar

RN11 - Taxa de Multa no

(from Modelo Conceitual)

Figura 4. Regras de negcio do sistema proposto no estudo de caso

Tabela 2. Descrio do caso de uso "UC04 - Efetuar Reserva"

UC04 - Efetuar Reserva

Dados do Cliente, Informaes do Veculo, Dados de pagamento, Data da

Para efetuar reserva o cliente deve possuir um cadastro ativo no sistema.

1. O Cliente insere as informaes de entrada e solicita a reserva [RF07];

O sistema retorna uma mensagem avisando que no possvel efetuar a reserva

pois o Cliente no passou na validao da regra de negcio (Exibe as

O Cliente solicita a alterao dos dados da reserva [RF08]. Devem ser