De Histórias a Casos de Uso

Grupo: Antonio, Batista, Fábio, Odalberto

e Anderson
Introdução
 Durante a fase inicial do desenvolvimento de software, indiferente do
processo adotado, os requisitos identificados não devem ser
representados através de um modelo formal, por não serem
compreendidos pelos usuários. Neste primeiro momento é necessário
gerar uma metáfora simples e intuitiva que facilite a comunicação e
a disseminação do conhecimento dentro da equipe envolvida. Para
usuários e clientes, o uso da linguagem natural oferece maior poder
de expressão, facilitando a comunicação. De outro lado, existe a
necessidade dos analistas em registrar e formalizar os requisitos
elicitados através da construção de modelos UML.

 Devido a necessidade das organizações de reter o conhecimento

gerado em seus projetos e atividades, a elicitação de requisitos vem
ganhando uma conotação cooperativa procurando integrar as diversas
visões :

 Estratégica, por meio de entrevistas com o gerente, um proprietário

ou administrador.

 Operacional, tratando diretamente com os usuários finais.

 É uma nova abordagem que envolve todos os participantes do

processo que executam as atividades ou os que dela se beneficiam.
Principais problemas para elicitação
 Falta de entendimento entre analistas, clientes e usuários, pois cada um destes
atores possui um modelo mental diferente referente ao processo e uma forma de
comunicação que dificulta a socialização do conhecimento sobre as atividades
envolvidas.

 Requisitos inconsistentes e modelagem falha são causados por desconhecimento

sobre o fluxo das informações, dependência entre fluxos incorretos e visão distorcida
da forma de execução das atividades.

 Muitas das inconsistências incorporadas aos requisitos do software e posteriormente

á aplicação desenvolvida ocorrem durante o processo de elicitação de requisitos e
elas decorrem de fatores como a comunicação entre os usuários e os analistas e a
falta de registros sobre o projeto. Os clientes não possuem uma idéia clara e
detalhada de suas reais necessidades, dificultando a identificação dos requisitos
funcionais e a distinção entre estes requisitos e as funções desejáveis para o
software. Durante o processo de explicitação do conhecimento, nem sempre os
usuários identificam todas as atividades que executam. Cada atividade pode ser
descrita de várias formas por diferentes usuários e, cada usuário pode apontar
diferentes requisitos que podem levar a requisitos incompletos e ambíguos.
Principais problemas para elicitação
 Questões em aberto mesmo com a existência de diversas soluções:

 Necessidade de expressão dos Stakeholder (ou, em Português,

parte interessada ou interveniente, refere-se a todos os
envolvidos no processo, por exemplo, usuários, clientes,
colaboradores, investidores, fornecedores, etc) através de uma
linguagem natural.

 Consolidação dos requisitos através de uma descrição única para cada

atividade.

 Formalização dos requisitos através da conversão dos cenários

descritos em modelos UML e facilitar a disseminação do conhecimento
produzido.
Fundamentação teórica
 Há diversos enfoques nas propostas apresentadas em trabalhos
publicados, mas há uma convergência quando apontam a necessidade
das organizações em armazenar, gerenciar e disseminar o
conhecimento gerado durante o desenvolvimento de seus projetos.

 Uma das abordagens estudadas é a Prática de Storytelling (Narração

de histórias) devido ao emprego da Gestão do Conhecimento e sua
aplicação em diversas áreas que possibilita um compartilhamento de
experiências de trabalho, do conhecimento altamente contextual
necessário para a solução de problemas do mundo real. Já no Group
Storytelling, mais de uma pessoa contribui para a construção de uma
história de forma síncrona ou assíncrona, localizada ou distribuída em
diversos pontos de decisão e utilizando diversos meios. Esta é a
técnica utilizada como ponto de partida para a elicitação de requisitos.

 A gestão do conhecimento na organização de software fornece os

recursos básicos necessários para o desenvolvimento de uma cultura
de trabalho na qual ocorrem constantes trocas de conhecimento e
aprendizado.
Enfoque da Solução em 3 camadas

 É consenso que o uso de um método cooperativo facilita e incentiva a

explicação do conhecimento dos stackeholders (envolvidos) sobre as
atividades, levando a requisitos consistentes, menos ambíguos e que
atendam aos usuários.

 Na metodologia proposta neste trabalho, a observação, entrevistas e

análise de documentos empregados na Engenharia de Requisitos dão
lugar a narrativa, com o objetivo de explorar as inúmeras visões do
negócio, do processo e da própria atividade.

 O uso da técnica de Group Storyteling possibilita a comunicação de

uma forma simples e pouco formal entre os participantes, promove o
compartilhamento do conhecimento individual sobre as atividades que
devem ser apoiadas pelo software a ser desenvolvido.
Enfoque da Solução em 3 camadas
 Primeira camada, Construção da História:

 Propõe a construção cooperativa de histórias para explicar o processo

a ser apoiado pelo software em desenvolvimento e todo o contexto
que o cerca.

 Para facilitar a narrativa, a história é divida em cenários. Cada cenário

deve retratar o domínio do trabalho, as atividades, suas condições de
execução e implicações. Este modelo explora conhecimentos e
habilidades necessários para a execução das atividades, assim como
os constrangimentos impostos pelo processo ou pela organização.

 Os usuários poderão trazer para a história figuras, representações de

uma determinada situação ou mesmo de registros do cenário descrito.
A criação de um glossário facilitará a construção de um vocabulário
comum á equipe e através de votações, suprir a necessidade de um
mecanismo de tomada de decisões e a solução de impasses.

 Nesta camada coexistem três papeis a serem assumidos pelos

usuários: o redator, o moderador e o comentador.
Enfoque da Solução em 3 camadas
 Terceira camada, Conversão para casos de uso:

 Responsável pela conversão dos cenários descritos e trabalhados

anteriormente para casos de uso, resultando em um modelo formal de
especificação de requisitos de software e que atenda à Engenharia de
Software.

 Este método baseia-se em preceitos da teoria da atividade, no método

de group task analisys e na construção de casos de uso e estabelece
ainda um paralelo entre as informações relacionadas à teoria da
atividade.

 Esta camada irá apoiar a interação da equipe de analistas alocados ao

processo de engenharia de requisitos. O objetivo é apoiar a atividade
do analista e, mantendo seu poder de decisão.

 Além dos papéis vistos anteriormente, existe ainda o papel do

converso, responsável por converter os cenários para casos de uso. Os
redatores desta camada poderão alterar as decisões dos casos de uso,
depurando o que foi produzido.
Enfoque da Solução em 3 camadas
 Segunda camada, Descrição dos Cenários:

 Consiste no refinamento do que foi descrito através das

histórias construídas na primeira camada. Estes cenários
serão utilizados para reduzir as ambigüidades, identificar os
papéis que emergem a partir das histórias .
 Trata-se de uma descrição semi-estruturada que facilita a
identificação dos requisitos e a posterior formalização.
Possibilita a junção dos cenários relacionados, assim como o
desmembramento de uma descrição que propõe duas ou mais
situações independentes .

 O método aqui utilizado apóia a geração destes cenários

incentivando a cooperação entre os participantes. Os papéis a
serem assumidos pelos usuários serão análogos à camada
anterior.
Metodologia e estado atual do trabalho

 Como primeiro passo no desenvolvimento deste trabalho está

o levantamento bibliográfico sobre a gestão do conhecimento,
elicitação de requisitos, storytelling e teoria da atividade na
elicitação de requisitos além de fazer um levantamento e
comparação das soluções existentes.

 Em seguida, levantamos as técnicas e ferramentas utilizadas

no decorrer do trabalho. Iniciamos o detalhamento do modelo,
método e a modelagem da ferramenta a ser implementada
como parte da solução proposta a serem concluídas. Ao
concluir a modelagem, passa-se à implementação e em
seguida, à fase de testes do artefato.
Validação dos Resultados
 Será realizado estudo de caso envolvendo uma equipe de
desenvolvimento de software, clientes e usuários do sistema
que será projetado. A partir daí será realizado um estudo
preliminar para detalhar as condições em que será realizado o
experimento.

 De posse destas informações serão estabelecidos critérios

para análise dos resultados e elaboração de cenários, os quais
envolvem elicitação de requisitos em três situações :
utilizando os métodos convencionais com o uso do método
proposto mas sem a utilização da ferramenta computacional e
utilizando o método proposto e o artefato computacional que
faça parte da solução.

 Realizado o experimento, será feita a análise dos resultados

coletados nas três situações descritas a partir dos critérios
previamente estabelecidos.
Conclusão

 Este é um trabalho de pesquisa que visa a criação de um modelo e

artefato computacional para apoiar o processo de elicitação de
requisitos de software, realizado de forma cooperativa, através de
linguagem natural.

 Esta solução possibilita ainda a captura e formalização dos requisitos a

partir das histórias obtidas através da explicação do conhecimento
dos envolvidos acerca das atividades, contexto e cenários. Sua
utilização irá favorecer, aliviando a carga cognitiva tanto dos analistas
quanto dos usuários finais, uma vez que este se comunica através de
metáforas simples.

 Os próximos passos incluem a identificação e detalhamento da

abordagem adotada e os itens que irão compor os cenários, descrição
mais criteriosa do método utilizado para a formalização dos requisitos,
projeto e realização de um estudo de caso e posterior análise dos
resultados encontrados.
Método base de apoio
 CSCW é a abreviatura de "Computer Supported Cooperative Work", traduzido em
Português como Trabalho Cooperativo Suportado por Computador.
 De uma forma genérica, o CSCW é uma área científica interdisciplinar que estuda a forma
como o trabalho em grupo pode ser suportado por tecnologias de informação e
comunicação, de forma a melhorar o desempenho do grupo na execução das suas tarefas.
 As pesquisas em CSCW são normalmente caracterizadas em um quadro de duas
dimensões: a distância das pessoas cooperando (remota ou localmente), e a forma de
comunicação (síncrona ou assíncrona).
 O CSCW enquadra-se num domínio científico interdisciplinar, envolvendo diversas áreas
científicas, tanto técnicas, como sistemas distribuídos, comunicação multimédia,
telecomunicações, ciências da informação, quanto humanas e sociais, como psicologia,
percepção e teoria sócio-organizacional.

O CSCW surgiu na década de 80, emergindo a partir da Automação de Escritório ("Office
Automation"). Esta, por sua vez, apareceu cerca de dez anos antes, como uma forma de
suportar o trabalho administrativo de grupos e organizações, evoluindo a partir de sistemas
organizacionais como os sistemas de emissão de bilhetes de avião, que tinham surgido na
década de 60.

Os programas informáticos cujo objectivo é serem usados por grupos cooperativos
designam-se habitualmente por groupware. Genericamente, pode-se considerar o
groupware como sendo software que suporta CSCW. As aplicações groupware mais
antigas são o correio electrónico (E-mail), os grupos de discussão (newsgroup) e os
sistemas de mensagens curtas, como o ICQ e o MSN Messenger.
Método base de apoio
 Um aspecto bastante importante para o groupware é a
existência de um ambiente partilhado pelos vários elementos
do grupo. Este ambiente partilhado coexiste normalmente
com ambientes privados de cada elemento do grupo, o que
implica possuir diferentes mecanismos de gestão de acesso à
informação, consoante esta seja privada ou partilhada. Neste
último caso, há que ter particular cuidado com os aspectos de
controlo de concorrência, de forma a assegurar a consistência
da informação partilhada.

 Potenciais domínios aplicacionais da utilização de groupware:

 Projecto e desenvolvimento de software, a coordenação de

processos de trabalho (Workflow), o Ensino, a telecooperação,
a Arquitectura, o projecto de Engenharia, a Telemedicina e a
edição cooperativa.
Método base de apoio
 As aplicações groupware podem ser agrupadas de acordo com a sua
funcionalidade genérica, constituindo as seguintes classes de
aplicação:

 sistemas de comunicação;

 espaços de informação partilhada (Mediaspaces);

 coordenação de processos de trabalho (Workflow);

 suporte a reuniões (Workgroup computing);

 editores de grupo;

 agentes cooperantes;

 ensino assistido por computador (no qual se inclui o E-learning);

 Realidade Virtual.