A proposal to combine elicitation techniques to write vision document and use case specifications...

12
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 <[email protected]>, Herez Moise Kattan <[email protected]> e Nery Signorini Neto <[email protected]> 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, 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.

Transcript of A proposal to combine elicitation techniques to write vision document and use case specifications...

Page 1: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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 <[email protected]>, Herez Moise Kattan

<[email protected]> e Nery Signorini Neto <[email protected]>

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.

Page 2: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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.

Page 3: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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.

Page 4: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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;

Page 5: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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

Page 6: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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.

Page 7: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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

Page 8: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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.

Page 9: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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

Page 10: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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 h istó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.

Page 11: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

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.

Page 12: A proposal to combine elicitation techniques to write vision document and use case specifications align to scrum

[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