Analyse a proposal to combine elicitation techniques to write vision document and use cases specifications. The results obtained from this study showed that the combination of selected techniques can generate effectively a vision document and use case specifications and align them to Scrum methodology by product backlog generation and user story derived from use cases.

1. Uma proposta para combinar técnicas de elicitação de requisitos para a
produção do documento visão e especificação de casos de usos alinhados à
metodologia de desenvolvimento ágil Scrum
André Rocha Agostinho <andre@magnadev.com.br>, Herez Moise Kattan
<herez@herez.net> e Nery Signorini Neto <nery.signorini@mac.com>
Abstract
Analisar uma proposta para combinar técnicas de
elicitação de requisitos para serem empregadas na
produção do documento visão e especificação de casos
de uso. Os resultados obtidos neste estudo mostraram
que a combinação das técnicas selecionadas puderam
produzir com eficácia o documento visão e
especificações de casos de usos e alinhá-los à
metodologia ágil Scrum.
Analyse a proposal to combine elicitation techniques
to write vision document and use cases specifications.
The results obtained from this study showed that the
combination of selected techniques can generate
effective vision document and use case specifications
and align them to Scrum methodology.
1. Introdução
Com o aumento da utilização de metodologias ágeis
em projetos de software, analistas e projetistas
necessitam ter um maior conhecimento das técnicas de
elicitação de requisitos, de modo a combinar e adaptar
as técnicas de elicitações utilizadas no modelo de
desenvolvimento sequencial, ou seja, em cascata ou
Waterfall Model [1] com o modelo de
desenvolvimento iterativo e incremental das
metodologias ágeis.
Este artigo propõe uma combinação de técnicas de
elicitações tradicionais para a montagem do
documento Visão (Rational Unified Process - RUP)
[2] e para a especificação de casos de uso alinhadas à
metodologia de desenvolvimento ágil Scrum, tendo
como ponto de estudo inicial dos requisitos e casos de
uso, a análise de um sistema qualquer de
Monitoramento de Estradas, aqui denominado pelas
siglas: SMAAPE (Sistema de Monitoração de
Acúmulo de Águas Pluviais nas Estradas), para a
criação do documento Visão.
2. Motivação
As metodologias ágeis por possuir um framework
aberto e focado em entregar funcionalidades com o
máximo de valor possível ao cliente, preceito este,
declarado no Manifesto Ágil (Agile Manifesto) [3]
exigem a criação de um backlog simplificado e com
requisitos estimados para a entrega em um curto ciclo
de tempo.
Em muitos casos a etapa de elicitação de requisitos
pode ser negligenciada por interferência da filosofia
ágil, que por tratar os requisitos como maleáveis e
passíveis de mudanças a cada iteração pode resultar em
uma partida precoce, ou seja, já se inicia o
desenvolvimento das funcionalidades desejadas
precocemente, sem a existência de um documento de
Visão bem elaborado e com especificações de
requisitos completas, sem ambiguidades, sem erros,
completas consistentes e coerentes como recomenda a
IEEE-830-1998 [4], sejam aos objetivos do produto de
software desejado ou as necessidades dos stakeholders.
Frequentemente analistas de negócios necessitam
aumentar seus esforços em definir os stakeholders do
projeto e elucidar todas as suas necessidades ,
priorizá-las e encaminhá-las a equipe de
desenvolvimento. Para se alcançar o sucesso, a
facilitação em elicitar informação assim como
habilidades em desenhar processos irá assegurar que a
produção dos requisitos de softwares se encontrem
com as necessidades dos stakeholders [5].
Na metodologia ágil Scrum, o mínimo de
planejamento necessário para se iniciar um projeto
consiste em ter um documento de Visão e um Product
BackLog bem definido [6]. No documento Visão,
deve-se constar quais metas o produto de software
necessita atingir, além de especificar todos os
stakeholders do projeto e seus respectivos papéis.

2. O Product Backlog, contendo os requisitos de
software deve corresponder aos objetivos registrados
no documento Visão que por vez devem refletir aos
desejos reais dos stakeholders [4].
Na Metodologia Ágil Scrum, requisitos são
elaborados de forma progressiva em cada iteração
denominada sprint. Em cada sprint, permite-se que
stakeholders possam definir suas necessidades para
garantir maior eficácia no desenvolvimento das
funcionalidades. Com Scrum, frequentemente é
utilizado história de usuário como técnica de elicitação
de requisitos. As histórias de usuários são focadas nas
funcionalidades, portanto indicadas para elicitação de
requisitos funcionais na visão do usuário do sistema,
são muito semelhantes aos casos de uso (Use Cases),
porém, sem riqueza de detalhes importante para o
desenvolvimento. É uma forma de elicitação ágil, onde
costumam participar em sua criação, desenvolvedores
com habilidades na disciplina de engenharia de
requisitos, situação esta, comum em equipes
multidisciplinares que trabalham com métodos ágeis.
Embora casos de uso e histórias de usuários
compartilhem a mesma meta da funcionalidade do
requisito, casos de uso costumam ser rejeitados por
equipes ágeis por estarem associados ao modelo
tradicional de cascata.
O desafio do artigo consiste em combinar técnicas
de elicitação de requisitos para a produção do
documento Visão e especificação de casos de uso
alinhado à metodologia ágil Scrum sem descaracterizar
seu comportamento iterativo e incremental, criando-se
assim uma possibilidade em incorporar técnicas não
ágeis de elicitação em um ambiente ágil.
3. Requisitos de Software
O conjunto de requisitos define um problema do
mundo real que necessita ser resolvido pelo sistema,
esclarecendo o seu propósito e fornecendo todas as
informações necessárias para que possa executar sua
função. Individualmente, cada requisito deve ter um
objetivo único e mensurável, possibilitando a sua
validação [7].
A resolução de um problema cotidiano também é
mencionada, definido um requisito como uma
propriedade que deve estar presente em um software
com o objetivo de resolver algum problema do mundo
real [8]. Sommerville [9] adiciona o conceito de
restrição como limitação das opções para
desenvolvimento da aplicação, definindo requisitos
como o conjunto formado pelas restrições operacionais
de um sistema e pelos serviços por ele fornecidos.
Requisitos de sistema de software são comumente
classificados em funcionais, não funcionais e de
domínio [10].
4. Elicitação de Requisitos de Software
Tendo como objetivo principal a obtenção de
requisitos do sistema a ser desenvolvido, durante a fase
de elicitação de requisitos, a equipe do projeto atua
junto com os clientes, usuários e demais stakeholders
para compreender as necessidades do negócio,
utilizando ferramentas como entrevistas, observação,
cenários e protótipos. Assim os engenheiros de
software procuram entender o domínio da aplicação, as
funcionalidades a serem oferecidas, as interações
existentes com outros sistemas e as restrições impostas
pelo negócio.
Erros no registro dos requisitos funcionais durante o
processo de elicitação, são muito comuns e difíceis de
se corrigirem, chegando a ser estimado que 70% [11]
dos erros identificados são gerados por incompletas e
inconsistentes especificações do sistema [12].
Problemas de elicitação podem ser classificados como:
a) Problemas de Escopo: As fronteiras do
sistema não são definidas ou determinadas,
onde há excesso de informações
desnecessárias e informações essenciais ao
sistema são omitidas ou esquecidas;
b) Problemas de Entendimento: Usuários
desconhecem suas necessidades, analistas
possuem pouco ou nenhum conhecimento do
domínio do problema, usuários e analistas
falam diferentes linguagens (literalmente ou
figuradamente). Informações óbvias podem
ser omitidas, podem haver conflitos entre
usuários pelas respectivas necessidades ou
percepções de suas necessidades; requisitos
são geralmente vagos e imprecisos, como por
exemplo “fácil de usar” ou “robusto”.
c) Problemas de Volatilidade: Requisitos
evoluem no tempo, pelas necessidades de
mudanças pela necessidade de mudanças dos
stakeholders.

3. 5. Técnicas de Elicitação de Requisitos
O levantamento de requisitos desempenha um papel
importante na construção de um sistema de
informação, pois é o início para toda a atividade de
desenvolvimento de software. É onde o analista faz as
primeiras reuniões com os clientes e/ou usuários para
conhecer as funcionalidades do sistema que será
desenvolvido.
Algumas das razões para o baixo grau de satisfação
dos usuários estão na fase de levantamento de
requisitos do projeto, onde não é utilizada uma técnica
adequada para extrair os requisitos do sistema, além
disso, a falha do analista em não descrever os
requisitos de modo claro, sem ambiguidades, conciso e
consistente com todos os aspectos significativos do
sistema proposto [22].
As técnicas de levantamento de requisitos possuem
um conceito próprio e podem ser utilizadas em
conjunto pelo analista. A seguir serão apresentadas de
forma resumida algumas dessas técnicas.
1. Entrevistas:
A entrevista é uma das técnicas tradicionais mais
simples de utilizar e que produz bons resultados na
fase inicial de obtenção de dados. Convém que o
entrevistador dê margem ao entrevistado para expor as
suas ideias. É necessário ter um plano de entrevista
para que não haja dispersão do assunto principal e a
entrevista fique longa, deixando o entrevistado cansado
e não produzindo bons resultados.
Existem dois tipos de entrevistas:
a) Entrevista fechada: onde o engenheiro de
requisitos tem um conjunto pré-definido de
perguntas e está à procura de respostas;
b) Entrevista aberta: sem perguntas pré-
definidas do engenheiro de requisitos, onde há
uma discussão de forma aberta com os
interessados sobre o que eles esperam do
sistema. Na verdade, muitas vezes não há
limite claro entre os dois tipos de entrevistas.
Você começa com algumas questões que são
discutidas e isso leva a novas questões;
A vantagem de entrevistas é que elas ajudam o
desenvolvedor a obter uma rica coleção de
informações. Sua desvantagem é que esta quantidade
de dados qualitativos pode ser difícil de analisar e
poderá haver informações conflitantes das diferentes
partes interessadas [9].
2. Questionários:
Os questionários são indicados, por exemplo,
quando há diversos grupos de usuário que podem estar
em diversos locais diferentes. Neste caso, elaboram-se
pesquisas específicas de acompanhamento com
usuários selecionados, pois não seria prático entrevistar
todas as pessoas em todos os locais. Existem vários
tipos de questionários que podem ser utilizados. Entre
estes podemos listar:
a) Múltipla escolha;
b) Lista de verificação; e
c) Questões com espaços em branco.
O questionário deve ser desenvolvido de forma a
minimizar o tempo gasto em sua resposta. Na fase de
preparação do questionário, deve ser indicado o tipo de
informação que se deseja obter.
Assim que os requisitos forem definidos o analista
deve elaborar o questionário com questões de forma
simples, clara e concisa [4], deixar espaço suficiente
para as repostas que forem descritivas e agrupar as
questões de tópicos específicos em um conjunto com
um título especial. O questionário deve ser
acompanhado por uma carta explicativa, redigida por
um alto executivo, para enfatizar a importância dessa
pesquisa para a organização.
Deve ser desenvolvido um controle que identifique
todas as pessoas que receberão os questionários. A
distribuição deve ocorrer junto com instruções
detalhadas sobre como preenchê-lo e ser indicado
claramente o prazo para devolução do questionário. Ao
analisar as respostas dos participantes é feito uma
consolidação das informações fornecidas no
questionário, documentando as principais descobertas e
enviando uma cópia com estas informações para o
participante como forma de consideração pelo tempo
dedicado a pesquisa.
3. Brainstorming:
Brainstorming é uma técnica para geração de idéias.
Ela consiste em uma ou várias reuniões que permitem
que as pessoas sugiram e explorem diversas
possibilidades.

4. Brainstorming contém duas fases, a fase de
geração, onde as idéias são coletadas, e a fase de
avaliação, onde as idéias coletadas são discutidas.
Na fase de geração, as idéias não devem ser
criticadas nem avaliadas. Cada idéia pode levar a novas
idéias.
A técnica de brainstorming leva a uma melhor
compreensão do problema para todos e um sentimento
de que todos cooperaram para atingir o objetivo.
4. Prototipagem:
Um protótipo de um sistema é uma versão inicial do
sistema que está disponível no início do processo de
desenvolvimento. Protótipos de sistemas de software
são frequentemente utilizados para ajudar a obter e
validar requisitos do sistema.
O protótipo é indicado para estudar as alternativas
de interface do usuário. Problemas de comunicação
com outros produtos; e a viabilidade de atendimento
dos requisitos de desempenho. As técnicas utilizadas
na elaboração do protótipo são várias:
a) Interface de usuário;
b) Relatórios textuais;
c) Relatórios gráficos, entre outras.
Alguns dos benefícios do protótipo são as reduções
dos riscos na construção do sistema, pois o usuário
chave já verificou o que o analista captou nos
requisitos do produto. Para ter sucesso na elaboração
dos protótipos é necessária a escolha do ambiente de
prototipagem, o entendimento dos objetivos do
protótipo por parte de todos os interessados no projeto,
a focalização em áreas menos compreendidas e a
rapidez na construção.
5. Joint Application Design (JAD):
O JAD facilita a criação de uma visão
compartilhada do que o produto de software deve ser.
Através da sua utilização os desenvolvedores ajudam
os usuários a formular problemas e explorar soluções.
Dessa forma, os usuários ganham um sentimento de
envolvimento, posse e responsabilidade com o sucesso
do produto.
O JAD tem quatro princípios básicos:
a) Dinâmica de grupo: são realizadas reuniões
com um líder experiente, analista, usuários e
gerentes, para despertar a força e criatividade
dos participantes. O resultado final será a
determinação dos objetivos e requisitos do
sistema;
b) Uso de técnicas visuais: para aumentar a
comunicação e o entendimento;
c) Manutenção do processo organizado e racional:
o JAD emprega a análise top down e atividades
bem definidas. Possibilita assim, a garantia de
uma análise completa reduzindo as chances de
falhas ou lacunas no projeto e cada nível de
detalhe recebe a devida atenção; e
d) Utilização de documentação padrão: preenchida
e assinada por todos os participantes. Este
documento garante a qualidade esperada do
projeto e promove a confiança dos
participantes.
O JAD é composto de duas etapas principais:
Planejamento, que tem por objetivo elicitar e
especificar os requisitos; e Projeto, em que se lida com
o projeto de software.
Cada etapa consiste em três fases: adaptação,
sessão e finalização. A fase de adaptação consiste na
preparação para a sessão, ou seja, organizar a equipe,
adaptar o processo JAD ao produto a ser construído e
preparar o material. Na fase de sessão é realizado um
ou mais encontros estruturados, envolvendo
desenvolvedores e usuários onde os requisitos são
desenvolvidos e documentados. A fase de finalização
tem por objetivo converter a informação da fase de
sessão em sua forma final (um documento de
especificação de requisitos).
Há seis tipos de participantes, embora nem todos
participem de todas as fases:
a) Líder da sessão: é responsável pelo sucesso do
esforço, sendo o facilitador dos encontros.
Deve ser competente, com bom relacionamento
pessoal e qualidades gerenciais de liderança;
b) Engenheiro de requisitos: é o participante
diretamente responsável pela produção dos
documentos de saída das sessões JAD. Deve ser
um desenvolvedor experiente para entender as
questões técnicas e detalhes que são discutidos
durante as sessões e ter habilidade de organizar
ideias e expressá-las com clareza;

5. c) Executor: é o responsável pelo produto sendo
construído. Tem que fornecer aos participantes
uma visão geral dos pontos estratégicos do
produto de software a ser construído e tomar as
decisões executivas, tais como alocação de
recursos, que podem afetar os requisitos e o
projeto do novo produto;
d) Representantes dos usuários: são as pessoas na
empresa que irão utilizar o produto de software.
Durante a extração de requisitos, os
representantes são frequentemente gerentes ou
pessoas chave dentro da empresa que tem uma
visão melhor do todo e de como ele será usado;
e) Representantes de produtos de software: são
pessoas que estão bastante familiarizadas com
as capacidades dos produtos de software. Seu
papel é ajudar os usuários a entender o que é
razoável ou possível que o novo produto faça;
f) Especialista: é a pessoa que pode fornecer
informações detalhadas sobre um tópico
específico.
O conceito do JAD de abordagem e dinâmica de
grupo poderá ser utilizado para diversas finalidades,
como: planejamento de atividades técnicas para um
grande projeto, discussão do escopo e objetivos de um
projeto e estimativa da quantidade de horas necessárias
para desenvolver sistemas grandes e complexos.
Para um sistema grande e complexo podem ser
usadas múltiplas sessões JAD para acelerar a definição
dos requisitos do sistema.
Os RNF’s desempenham um papel crítico durante o
desenvolvimento de sistemas, e erros devido a não
elicitação ou a elicitação incorreta destes estão entre os
mais caros e difíceis de corrigir, uma vez que um
sistema tenha sido implementado [13].
O Framework proposto por Chung [14] é
abordagem mais completa até o momento e procura
tratar de todos os tipos de requisitos não funcionais
desde as primeiras etapas do processo de
desenvolvimento de software. Apesar de ser um
framework bastante completo e eficaz para lidar com
requisitos não funcionais durante a elicitação de
requisitos, este framework não favorece a integração
destes requisitos nas etapas seguintes do
desenvolvimento de software, ficando, assim, uma
lacuna aberta para que conflitos entre requisitos
funcionais e não funcionais passem desapercebidos
durante o projeto do software.
Trabalhos apresentados por Cysneiros [15]
enfatizam premissas apresentadas por Chung [14] de
que a falta de integração dos RNFs aos requisitos
funcionais, e por consequência sua integração aos
modelos conceituais, pode resultar em tempos maiores
para se finalizar um software, assim como maiores
custos com manutenção.
6. Metodologias Ágeis (Iterativo e
Incremental)
Com o aumento do interesse por metodologias ágeis
no ano de 2000, principalmente após a publicação do
Manifesto Ágil em 2001, muitas equipes de
desenvolvimento aderiram as metodologias ágeis na
esperança de reduzir o tempo de entrega de
funcionalidades e minimizar a quantidade de erros.
Para muitos projetos onde o crescimento do sistema
aumenta a dificuldade em se adicionar novas
funcionalidades, equipes creem em uma proposta de
desenvolvimento ágil com menos burocracia, tornando
o processo mais rápido e com maior eficiência,
entregando funcionalidades prontas e testadas em
curtos ciclos de tempo.
Para muitas pessoas o apelo dessas metodologias
ágeis é a sua reação à burocracia das metodologias de
engenharia. Alguns pesquisadores creem que métodos
tradicionais conferem ao desenvolvimento de software
uma lentidão desnecessária, uma vez que se prendem a
processos e práticas excessivamente formais. Os
métodos ágeis, por sua vez, procuram aumentar a
interação entre as pessoas para reduzir a documentação
e a rigidez de processos, buscando o equilíbrio entre
aplicar nenhum ou muitos processos [16].
Os métodos ágeis apresentam mudanças
significativas nos métodos de engenharia, uma delas é
ser menos orientado a documento, pressupondo-se que
a parte fundamental da documentação é o código-fonte.
Frequentemente pessoas associam métodos ágeis
com a ausência de documentação, quando na realidade
valoriza-se a criação de documentos somente quanto
necessário ou quando estes servirem de apoio para o
ciclo de desenvolvimento. Métodos tradicionais
utilizam-se de muita documentação pois tendem a
tentar planejar uma grande parte do processo de
software com grande detalhe por um longo período de
tempo, o que funciona bem até que as coisas mudam.
Assim, sua natureza é a resistir à mudança. Os métodos
ágeis, no entanto, por trabalharem com pouca

6. documentação, costumam responder melhor as
mudanças [16].
As organizações ágeis se concentram na construção
de habilidades individuais e na promoção de um alto
grau de interação entre os membros da equipe e
clientes do projeto. Equipes ágeis acreditam que
projetos complexos de hoje, a compreensão vem mais
da interação face a face que de documentação e não
acreditam que a dependência de processos pesados faz-
se por falta de habilidade, talento e conhecimento [17].
Os métodos tradicionais pressupõem a derivação
precoce de um conjunto completo de requisitos
estáveis de software, focando a redução de custos,
mudanças através da sua eliminação, e tornar o
processo de desenvolvimento de software mais
previsível e eficiente. Essa meta é buscada por meio da
inclusão de processos disciplinados e artefatos bem
definidos que precisam ser seguidos e são dificilmente
adaptáveis.
Assumem ainda que desvios no planejamento são
consequência de falhas no processo: alguma etapa da
engenharia de requisitos que não envolveu as pessoas
corretas, ou o projeto de arquitetura que não
contemplou determinada restrição. Porém, há fatores
externos à equipe de desenvolvimento de software e
até mesmo às organizações que implicam a
necessidade de alteração de requisitos de software. Os
métodos ágeis surgem como uma alternativa para
melhor acomodar essas mudanças, mantendo a
qualidade do projeto e minimizando seus custos de
implementação, para tanto utilizando práticas como
entregas rápidas e sistemáticas, retroalimentação
constante, priorização dinâmica de requisitos, entre
outras [17].
Os métodos tradicionais pressupõem a derivação
precoce de um conjunto completo de requisitos
estáveis de software, focando a redução de custos,
mudanças através da sua eliminação, e tornar o
processo de desenvolvimento de software mais
previsível e eficiente. Essa meta é buscada por meio da
inclusão de processos disciplinados e artefatos bem
definidos que precisam ser seguidos e são dificilmente
adaptáveis. Assumem ainda que desvios no
planejamento são consequência de falhas no processo:
alguma etapa da engenharia de requisitos que não
envolveu as pessoas corretas, ou o projeto de
arquitetura que não contemplou determinada restrição.
Porém, há fatores externos à equipe de
desenvolvimento de software e até mesmo às
organizações que implicam a necessidade de alteração
de requisitos de software. Os métodos ágeis surgem
como uma alternativa para melhor acomodar essas
mudanças, mantendo a qualidade do projeto e
minimizando seus custos de implementação, para tanto
utilizando práticas como entregas rápidas e
sistemáticas, retroalimentação constante, priorização
dinâmica de requisitos, entre outras [17].
7. Metodologia Scrum
Definido por Ken Shwaber e Mike Beedle [18] no
início dos anos 90, o Scrum é um método ágil que pode
ser empregado no desenvolvimento de projetos
pequenos, médios e grandes. Apoiado em uma
abordagem iterativa e incremental, caracterizada pela
elaboração progressiva, para aumento da
previsibilidade e controle sobre os processos, o método
valoriza a colaboração entre as pessoas e trabalho em
equipe, melhorando a comunicação e maximizando a
colaboração, combinados com iterações curtas para
atingir seus resultados.
Figura 3: Visão Macro do Método Scrum
Conforme Schwaber e Sutherland [19] o Scrum é
sustentado por três pilares:
a) Transparência: todos os aspectos que afetam os
resultados do processo devem ser visíveis
àqueles que o gerenciam. Além disso, a
compreensão dos resultados é compartilhada
por todos os envolvidos no processo.
b) Inspeção: os aspectos do processo devem ser
inspecionados com uma frequência tal que
quaisquer variações indesejáveis sejam
passíveis de detecção.

7. c) Adaptação: quando os desvios detectados
forem inaceitáveis, o processo ou material
processado deve ser ajustado o mais rápido
possível para minimizar o impacto de desvios
posteriores.
Os principais papéis em um projeto Scrum são o
Product Owner, Time Scrum e Scrum Master.
Onde:
a) Product Owner é o representante do produto ou
patrocinador do projeto, é a pessoa responsável
por inserir itens no product backlog. Scrum
Master, é responsável por remover
impedimentos da equipe, convocar cerimoniais
como Daily Meeting e Sprint Planning, e
facilitar comunicação entre o Product Owner e
o Time Scrum;
b) Time Scrum, é composto por membros técnicos
(desenvolvedores, designers de interface,
administradores de banco de dados e outros) e
caracterizado por ser multidisciplinar e auto-
organizável;
c) Scrum Master não representa um papel de
gerente de projeto ou líder, mas sim um
facilitador, é comum membros da equipe
exercerem liderança situacional em suas
especialidades.
Como qualquer desenvolvimento iterativo e
incremental, a metodologia Scrum nomeia cada
iteração de sprint, sugerindo uma “timebox” de duas à
quatro semanas, período em que o time Scrum deve se
comprometer a entregar funcionalidades prontas e
testadas. Durante a sprint o time deve estar focado no
desenvolvimento dos itens de backlog que foram
selecionados durante a Sprint Planning, cerimonial de
planejamento que antecede o início de cada sprint.
No Sprint Planning, Product Owner, Scrum Master
e Time Scrum participam no planejamento do sprint
elicitando e estimando requisitos que deverão ser
implementados para o próximo sprint. Somente uma
parte do Product Backlog é analisada e levada ao
planejamento, que após ser particionada, priorizada e
estimada, passa a compor o BackLog do sprint a ser
iniciada, o que é chamada de Sprint BackLog.
Pela metodologia Scrum ser um framework aberto,
é possível engajar quaisquer técnicas de elicitação para
o planejamento de requisitos , assim como cerimoniais
a parte podem ser criados de acordo com a
necessidade, como é o caso do planejamento do
documento visão, que deve ser elaborado em conjunto
com o time Scrum antes de qualquer elicitação de
requisitos ou planejamento de sprints.
8. Combinando Técnicas de Elicitação
para o sistema SMAAPE
Visão geral sobre o SMAAPE
Na tentativa em reduzir acidentes rodoviários e
tornar as estradas mais seguras, o SMAAPE (Sistema
de Monitoramento de Acúmulo de Águas Pluviais em
Estradas) é um sistema a ser aplicado sob concessão do
estado para monitorar trechos de estradas propícios a
alagamento durante pancadas de chuvas. O sistema
deve contar com sensores distribuídos e instalados em
trechos de estradas, que ligados a uma central deve em
tempo real, coletar e enviar informações do nível
pluviométrico e metereológico do local. A central do
SMAAPE deve receber os dados coletados pelos
sensores, classificá-los e notificar somente trechos
potencialmente perigosos as unidades de conservação
mais próximas, que por vez, deverão encaminhar frotas
de apoio ao local.
Selecionando técnicas de elicitação
Muitos artigos e livros descrevem diferentes formas
de realizar elicitação de requisitos. Para os analistas de
requisitos, os esforços em se ter uma técnica eficiente,
pode-se conduzir a uma busca insaciável pela bala de
prata [13] no objetivo de resolver todos os problemas
de elicitação de um projeto. Entretanto, estudos [6]
comprovam que projetos exigem tipicamente mais de
uma técnica para ser utilizada em levantamento de
requisitos. Além disso, um grande problema na
elicitação de requisitos, hoje, é a diferença significativa
entre especialistas e analistas inexperientes. A falta de
consciência por analistas do estado da arte das técnicas
e ferramentas para levantamento de requisitos,
combinados com uma indisposição geral para adotá-los
é o grande responsável por esta situação. Esta situação
é ainda mais agravada pela atual escassez de diretrizes
sistemáticas e métodos flexíveis.
Para a elicitação de requisitos do SMAAPE, este
artigo propõe adotar e combinar três técnicas de
elicitação de requisitos mais populares entre os mais
experientes analistas de requisitos.
Workshops Colaborativos é considerado como uma
das mais bem sucedidas técnicas de elicitação na
produção de requisitos de qualidade e visto como

8. abordagem padrão pela maioria dos analistas de
requisitos. Considerando os stakeholders já definidos
no projeto, ao reuni-los em sessões de Brainstorming,
foi possível definir as principais sessões do documento
visão.
Entrevistas. Para compreender os diferentes pontos
de vistas dos stakeholders do projeto, as entrevistas
focam em levantar diretamente as necessidades das
visões individuais de cada entrevistado, descobrindo
assim, novas informações, possíveis conflitos e
políticas.
Modelos. A utilização de documentos facilitam o
entendimento entre os stakeholders e analistas e
requisitos. Para o SMAAPE, documentos gráficos
como IDEF0 e Modelo Semântico permitem um fácil
entendimento da visão funcional do projeto,
clarificando informações de entradas e de saída sem a
necessidade de conhecimento técnico.
Elicitando para a montagem do documento visão
Para modelagem do documento visão, a utilização
das técnicas Workshops Colaborativos e Entrevistas
utilizando-se JAD, foram aplicadas diretamente aos
seguintes stakeholders:
Stakeholders Identificados:
#1 Secretário de Transporte (Governo do Estado,
representado pela secretaria de transporte Patrocina o
projeto);
#2 Diretor DER (Depto Estradas e Rodagem,
responsável pelas estradas do estado);
#3 Diretoria Comercial CMSP (Centro de
Meteorologia de SP) (Centro Meteorológico de São
Paulo, responsável pelas previsões meteorológicas do
estado);
#4 Superintendente regional para conservação das
estradas (Secretaria responsável pela conservação das
estradas);
#5 Diretor Centro de Manutenção (Base Central –
Gestão e Coordenação);
#6 Coordenador Centro de Manutenção (Bases
Instaladas – Operacionais); e
#7 Polícia Federal Rodoviária (Participa do sistema
através de seu acionamento preventivo ou após
acidente).
Fases de Elicitação
1º Fase - Reunião com os principais stakeholders. O
objetivo desta reunião foca-se em responder
inicialmente cinco questões relacionadas a visão do
produto.
 Quem está comprando o produto? Quem é o
consumidor final?
 Para quais as necessidades do consumidor o
produto deve ser endereçado? Quais os atributos do
produto são críticos para satisfazer as necessidades
selecionadas, e, portanto, para o sucesso do
produto?
 Como o produto comparar com os produtos
existentes, tanto dos concorrentes como da mesma
companhia?
 Qual é o prazo e orçamento para desenvolver
e lançar o produto?
Na primeira fase os seguintes stakeholders
participaram: Secretário do Transporte como o líder da
sessão, representante DER, representante CMSP e
engenheiros de requisitos responsáveis pela
implementação do sistema SMAAPE.
2º Fase - Entrevistas individuais com os principais
stakeholders.
3º Fase - Brainstorm com todos os stakeholders.
Resultados obtidos para o Documento Visão
Os resultados obtidos estão divididos em três partes e
agregam ao documento visão: a) Questionário do
produto, b) Políticas e Restrições, c) Modelos gráficos
e, d) Product Backlog inicial
a) Questionário do produto
Quem está comprando o produto? Quem é o
consumidor final?
O estado é o comprador do sistema SMAAPE e o
consumidor final são os usuários de rodovias e
estradas.
Para quais as necessidades do consumidor o produto
deve ser endereçado?
Os usuários de estradas necessitam trafegar com maior
segurança em rodovias e estradas em épocas que
chuvas potencializam perigo em trechos com histórico
de acúmulo de água, derrapagens e acidentes.

9. Quais os atributos do produto são críticos para
satisfazer as necessidades selecionadas, e, portanto,
para o sucesso do produto?
Os atributos indispensáveis para que o sistema opere
são: coleta em tempo real das informações através da
alta disponibilidade e eficiência de coleta de dados dos
sensores. Recebimento em tempo real das informações
e eficiência na acurácia dos dados na Central de
Monitoramento. Agilidade na tomada de decisões,
acionamento e descolocamento das unidades de apoio
ao local aferido pelo monitoramento.
Como o produto se compara com os produtos
existentes, tanto dos concorrentes como da mesma
companhia?
Não existe concorrência ou comparações com o
SMAAPE por se tratar de um sistema único, inovador
e de iniciativa governamental.
Qual é o prazo e orçamento para desenvolver e lançar
o produto?
Orçamento inicial estimado em trinta milhões de reais
com um prazo para lançamento de uma versão piloto
em oito meses considerando alguns trechos de uma
única rodovia e doze meses para o lançamento oficial
considerando integramente uma única rodovia. Após o
lançamento o projeto será reavaliado e um novo
documento visão deverá ser montado visando atender a
implementação em todas rodovias do estado.
b) Políticas e restrições
 Restrições de negócio (em relação ao
Business da Empresa pelas informações de
usuários chaves e gestores;
 Políticas corporativas;
 Regras de negócio;
 Particularidades do negócio a ser otimização
por um sistema computacional.
c) Modelos gráficos
Durante as reuniões, os engenheiros de requisitos
produziram ao menos um documento que foi de
entendimento e consentimento de todos os
stakeholders.
Modelo Semântico. Com o modelo semântico, os
engenheiros de requisitos puderam esboçar a primeira
versão estrutural do sistema SMAAPE, explicitando
entidades, relacionamentos e dependências. A
produção deste documento também foi de fácil
entendimento por todos os stakeholders além de
fornecer grande valor à equipe de desenvolvimento.
Figura 5: Modelo Semântico SMAAPE
d) Product Backlog Inicial
O mínimo de planejamento necessário para se
iniciar um projeto em Scrum consiste em ter um
documento de Visão e um Product BackLog bem
definidos [6]. Com o documento visão especificado,
stakeholders bem definidos, políticas e restrições
estabelecidas, a equipe junto com stakeholders elencam
a primeira rodada de histórias do projeto SMAAPE
priorizadas pelos seguintes fatores: valor do
incremento do produto, o custo do desenvolvimento, a
quantidade de riscos removidos ao se desenvolver o
incremento do produto e o grau de incerteza no
desenvolvimento.
Histórias Prioridade
Monitorar trechos 1
Marcar trechos como perigosos 2
Desmarcar trechos como perigosos 3
Acionar unidades de apoio 4
Notificar trechos perigosos 5
Relatório de trechos perigosos 6
Alta disponibilidade dos sensores 1
Eficiência na apuração das
informações coletadas
6
Eficiência no acionamento das
unidades de conservação e apoio
4
Tabela 1: RF e RNF

10. Monitorar trechos
Como sistema SMAAPE devo coletar informações de trechos com
sensores localizados em determinados pontos da estrada e
encaminhá-los a central de monitoramento para análise.
Quem Sistema SMAAPE
Ação Devo coletar informações de trechos
Como Com sensores
Onde Localizados em determinados pontos da estrada
Motivo Encaminhá-los a central de monitoramento para
análise
Especificando Casos de Uso
Casos de uso descrevem uma sequência típica de
ações que um ator executa para completar uma
determinada tarefa [20]. A modelagem de casos de
usos procura clarificar o ponto de visão de como os
atores irão interagir com o sistema e como eles
atingirão os seus objetivos.
Escrever bons casos de uso é mais uma arte do que
uma ciência. E, como em qualquer arte, não há regras
absolutas para a criação de suas obras-primas. Porém,
mesmo não existindo regras absolutas, para se
especificar casos de uso, é necessário se atingir um
grau de abstração a ponto de torná-lo livre de
tecnologia e independente para implementações.
Em metodologias ágeis, como consequência da
forma de elicitação coletiva e colaborativa entre
desenvolvedores e analistas de negócio, casos de usos
são frequentemente substituídos por histórias de
usuários, que embora compartilhem da mesma meta de
interação com o usuário, não apresentam a riqueza em
detalhes como os casos de usos. Informações [23]
ressaltam um grande equívoco na substituição de casos
de uso com histórias de usuário.
Este artigo parte da seleção da história “Monitorar
trechos” como fonte para especificação de casos de
usos através de seu detalhamento, o que possibilita a
aplicação das técnicas: a) identificação de casos de uso,
b) identificação de atores e c) Diagrama de caso de
uso.
a) Identificando Casos de Uso:
O detalhamento da história de usuário [3]
“Monitorar trechos” possibilita a identificação de
casos de uso com base na seguinte informação:
uso: Coletar dados do trecho e Analisar dados do
trecho.
b) Identificando Atores
Encontrar atores é um dos primeiros passos na
definição de casos de uso do sistema SMAAPE. Cada
tipo de fenômeno externo com o qual o sistema deve
interagir é representado por um ator. Para identificar os
atores, foi utilizado o seguinte questionário [21].
a) Quem vai usar a funcionalidade principal do
sistema?
b) Quem terá o apoio do sistema para fazer suas
tarefas diárias?
c) Quem terá de manter e administrar o sistema,
e mantê-lo em funcionamento?
d) Com quais dispositivos de hardware o sistema
precisa lidar?
e) Com quais outros sistemas o sistema precisa
interagir?
f) Quem ou o que tem interesse nos resultados
(o valor) que o sistema produz?
A combinação do questionário com a aplicação da
técnica de especificação de história aos casos de uso, é
possível identificar os atores relacionados a “Quem”
executa as determinadas funções e “Como” executam.
Caso de uso: Coletar dados do trecho
Caso de Uso Quem (Ator) Como
Coletar dados do
trecho Sensor
Coletando
informações em
tempo real das
estradas
Tabela 3: Casos de Uso Coletar dados do trecho
Caso de uso: Analisar dados do trecho
Caso de Uso Quem (Ator) Como
Analisar dados do
trecho
Central de
monitoramento
Recebendo e analisando
as Informações dos
sensores
Tabela 2: Casos de Uso Sugeridos
A ação “devo coletar informações de trechos” e o
motivo “encaminhá-los a central de monitoramento
para análise” possibilitam a identificação dos casos de
Tabela 4: Casos de Uso Analisar dados do trecho
c) Diagrama de casos de uso
Com os casos de usos e atores identificados, a história
de usuário “Monitorar Trechos” pode ser representada
graficamente através de um diagrama de caso de uso.

11. Figura 4: Casos de Uso / Atores
Os diagramas de casos de uso fornecem apoio
visual a equipe de desenvolvimento e servem para
facilitar o entendimento e comunicação entre técnicos e
analistas de requisitos.
9. Conclusão
O artigo buscou atender o desafio proposto em se
combinar técnicas de elicitação de requisitos para a
produção do documento Visão e especificação de casos
de uso alinhado à metodologia ágil Scrum. A seleção e
combinação de técnicas de elicitação mostraram ser
eficazes para a amostragem SMAAPE, possibilitando a
rastreabilidade dos requisitos (RF e RNF) definidos
com o documento visão.
Durante o experimento notamos que cada vez mais
são exigidos conhecimentos em técnicas de elicitação
de requisitos quando utilizado metodologias ágeis para
desenvolvimento. Considerando que a metodologia
Scrum não oferece meio para elicitação, o analista de
requisitos não somente precisa dominar diferentes
técnicas (o que já é um grande desafio), mas também
precisa estar apto a trabalhar com equipes
colaborativas que participam efetivamente na
confecção do documento visão à construção e
validação das funcionalidades.
Não descaracterizar o comportamento iterativo e
incremental pode ser mantido na maioria das fases,
mas não ao longo de todo o ciclo como, por exemplo,
após a finalização do documento visão sugere-se que
não existam mais mudanças nos que se diz respeito aos
objetivos e características do produto, portanto, uma
vez estabelecido, o documento de visão passa a ser o
escopo fechado do projeto, cabendo ao Product
Backlog à responsabilidade de acomodar e aceitar
mudanças.
10. Referências Bibliográficas
[1] 1970. Royce, Winston (1970), "Managing the
Development of Large Software Systems",
Proceedings of IEEE WESCON 26 (August): 1–9.
Disponível em:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Pr
ocess/waterfall.pdf
Acesso realizado em 25 de abril de 2013.
[2] IBM RUP – Rational Unified Process - Disponível
em: http://www-01.ibm.com/software/rational/rup/
Acesso realizado em 30 de abril de 2013.
[3] Manifesto for Agile Software Development,
Disponível em: http://agilemanifesto.org
Acesso realizado em 25 de abril de 2013.
[4] IEEE Std 830-1998, IEEE Recommended Practice
for Software Requirements Specifications
[5] BABOK, A Guide to the Business Analysis Body
of Knowledge, Chapter 6. International Institute of
Business Analysis (IIBA).
[6] SCHWABER, Ken. Agile Project Management
with Scrum. Microsoft Press. 2004. Disponível em:
http://www.scrumalliance.org/articles/115-the-product-
vision
Acesso realizado em 27 de abril de 2013.
[7] WITHALL, S. Software requirement patterns. 1 ed.
Inglês, Redmon, EUA: Microsoft Press, 2007. Page:
384.
[8] SWEBOK: Guide to the Software Engineering
Body of Knowledge. Los Alamitos, EUA: IEEE
Computer Society, 2004. Page: 202.

12. [9] SOMMERVILLE, I. Engenharia de Software. 8 ed.
Português. São Paulo, Brasil: Addison Wesley, 2007.
Page: 552.
[10] LAUESEN, S. Software requirements: styles and
techniques. 1 ed. inglês. Londres, Inglaterra: Addison-
Wesley, 2002. Page: 591.
[11] A New Approach for Software Requirements
Elicitation, Prasad Rajagopal, Roger Lee, Thomas
Ahlswede, Chia-Chu Chiang, Dale Karolak
[12] Beichter, F. et al., “SLAN-4-A Software
Specification and Design Language.” IEEE
Transactions on Software Engineering, SE-10, 2, 1984,
pp. 155-162.
[13] Brooks Jr.,F.P."No Silver Bullet: Essences and
Accidents of SoftwareEngineering" IEEE Computer
Apr 1987, No 4 pp:10-19, 1987.
[14] Chung L., “Representing and Using Non-
Functional Requirements: AProcess Oriented
Approach” Ph.D. Thesis, Dept. of Comp..
Science.University of Toronto, June 1993.
[15] Cysneiros, L.M. and Leite, J.C.S.P. ‘Integrating
Non-FunctionalRequirements into data model” 4th
International Symposium on Requirements
Engineering – Ireland June 1999.
[16] FOWLER, M. The new methodology. 13 de
Dezembro de 2005. Disponível em:
http://martinfowler.com/articles/newMethodology.html
Acesso realizado em 25 de abril de 2013.
[17] HIGHSMITH, J.; COCKBURN, A.Agile
Software Development: the business of innovation.
IEEE Computer, num. 9 - 2001, september, pages: 120
to 127.
[18] SCHWABER, K. and M. Beedle (2002). Agile
Software Development with SCRUM,
Prentice-Hall.
[19] Ken Schwaber & Jeff Sutherland. Disponível em:
http://www.scrum.org/Scrum-Guides
Acesso realizado em 25 de abril de 2013.
[21] UML TOOK KIT 2.0 , 1991
Hans-Erik Eriksson, Magnus Penker, Brian Lyons,
David Fado, ERIKSSON. HANS , 1991
[22] POMPILHO, S. Análise Essencial Guia Prático de
Análise de Sistemas. Rio de Janeiro: Ed. Ciência
Moderna Ltda, 1995
[23] Nee, N., “Developing effective agile requirements
relies on both user stories and use cases”, ESI Point of
View, 2013