Cenários

Origem: Wikipédia, a enciclopédia livre.

Foi proposta a fusão deste artigo com: Cenário.

Cenários têm vindo a ser usados ao longo do tempo em diversas áreas, nomeadamente em interacção homem-computador, engenharia de requisitos, desenho orientado a objectos, planeamento estratégico, etc, uma vez que facilitam bastante a criação e utilização de casos de uso, de uma forma simples e flexível. A utilização desta aproximação em engenharia de requisitos é baseada na hipótese de que a integração desta técnica permite melhorar o processo de especificação de requisitos através de um maior envolvimento dos utilizadores no mesmo. Esta técnica descreve os requisitos numa linguagem fácil de entender e validar para todas as pessoas relacionadas com o projecto, motivando-as a discutir e participar, obtendo assim um maior feedback sobre o que se está a fazer.

Mais recentemente, a técnica tem sido utilizada no desenho e desenvolvimento de sistemas, contudo, poucos métodos emergiram para guiar a prática de análise e validação de requisitos baseada em cenários.

Índice

1 Definição do conceito
2 Principais vantagens do uso de cenários em Engenharia de Requisitos
3 Como a técnica de cenários pode afectar a qualidade dos requisitos
4 Métodos para representação de cenários
- 4.1 Uma aproximação: sistematicamente combinar texto estruturado com diagramas de estado
  - 4.1.1 Representação de um cenário
  - 4.1.2 Estruturação de um conjunto de cenários
- 4.2 O método SCRAM (Sutcliffe)
5 Problemas com a técnica de cenários
6 Conclusão
7 Referências

[editar] Definição do conceito

Esta secção apresenta duas das definições encontradas para o conceito de cenário:

Um cenário é um conjunto ordenado de interacção entre parceiros, normalmente entre um sistema e um conjunto de actores externos ao sistema. Pode consistir numa sequência concreta de passos de interacção (instância de cenário) ou num possível conjunto de passos de interacção (cenário tipo). (Jacobson, 1992)

Jacobson associou o termo use case (caso de uso) a cenários tipo e mais tarde introduziu essa noção no UML. Na sua terminologia, os cenários estão sempre ao nível da instância.

Um cenário é uma descrição que contém actores, a informação por trás deles, assumpções sobre o seu ambiente, os seus objectivos e sequências de acções e eventos. Pode incluir também os obstáculos, contingências e êxitos dos actores. Em alguns sistemas, os cenários podem omitir um dos elementos ou expressá-lo de forma simples ou implícita. (Rosson and Carroll, 2001)

É uma história partilhada entre vários colaboradores no desenho do sistema. Por exemplo, os clientes ou gestores de projecto descrevem as suas visões em episódios. Utilizadores conversam sobre os problemas que enfrentam à medida que acontecem. Os designers guardam a análise racional de um sistema na forma de um exemplo ou desenvolvem modelos para ilustrar o que os utilizadores deverão fazer. Escritores técnicos explicam a tarefa dos utilizadores num manual e escrevem-na como uma história. Estes são exemplos de cenários partilhados entre parceiros e distribuídos ao longo do ciclo de desenho de um sistema.

Os cenários podem ser expressos de várias formas e formatos. Por exemplo, podem ser simples narrativas textuais, storyboards, modelos em vídeo, ou ainda protótipos construídos de várias maneiras. Adicionalmente, podem estar numa notação formal, semi-formal ou informal. Um exemplo típico de um cenário informal é uma história, um tipo de cenário usado frequentemente para ter uma visão das tarefas do utilizador na interacção homem-computador.

[editar] Principais vantagens do uso de cenários em Engenharia de Requisitos

A utilização de cenários traz consigo algumas vantagens como:

Tem em conta o ponto de vista do utilizador

O cenário vê sempre o sistema do ponto de vista de, no mínimo, um dos seus utilizadores. Isto é uma vantagem fundamental quando se está a validar a adequação de requisitos. Cenários dão aos utilizadores a sensação do que irão ter, enquanto que as técnicas clássicas como a listagem de requisitos narrados, diagramas entidade-relação ou diagramas de classes orientados a objectos por vezes não o fazem.

Especificações parciais

Cenários são um meio natural para escrever especificações parciais. Todos os cenários capturam uma sequência de interacções utilizador-sistema que representam uma transição no sistema, ou uma função no sistema, sempre na perspectiva do utilizador. Uma particularidade forte nos cenários recai precisamente no facto de que estes permitem a decomposição do sistema em funções, numa perspectiva do utilizador, em que cada uma das funções pode ser tratada de forma separada - uma aplicação clássica do princípio de separação de interesses / objectivos / preocupações.

Fácil de compreender

Cenários simplificam a elicitação e validação de requisitos, uma vez que a noção de interacção utilizador-sistema mostra-se como uma forma natural de compreender e discutir os requisitos, quer para os utilizadores, quer para os engenheiros. Os cenários herdam o conforto e a facilidade do uso da linguagem natural em especificações, ao mesmo tempo que evitam muitos dos problemas com especificações puramente narradas.

Ciclos de feedback curtos

A combinação da habilidade de tratar cada função do utilizador separadamente num cenário e a maneira orientada ao utilizador de representar os requisitos no cenário permite um ciclo de feedback entre o utilizador e o engenheiro de requisitos bastante pequeno.

Servir de base para os testes do sistema

As sequências de interacção capturadas nos cenários servem também como uma base ideal para definir testes ao sistema. Casos de teste podem ser derivados directamente a partir de cenários, melhorando assim a habilidade de verificação dos requisitos.

[editar] Como a técnica de cenários pode afectar a qualidade dos requisitos

A noção clássica de qualidade dos requisitos foca-se essencialmente nos seguintes aspectos: adequação, desambiguidade, completude, consistência, habilidade de verificação, habilidade de modificação e habilidade de rastreio (IEEE 1993). Na prática, no entanto, muitas especificações de requisitos não cumprem estas qualidades. Poder-se-ia dizer que isto seria uma questão de aplicar os métodos e processos certos, e de melhorar os processos de recolha de requisitos, até estes obterem a qualidade desejada. Contudo, a experiência revela que não é assim tão simples resolver o problema. A qualidade em si faz parte do próprio problema.

É necessário avançar no paradigma da qualidade de requisitos e arranjar técnicas de engenharia de requisitos adequadas, de forma a ir de encontro ao conjunto de qualidades em cima mencionadas. Usar cenários na especificação de requisitos tem um forte impacto positivo na qualidade de requisitos, nomeadamente ao nível da adequação, completude parcial, habilidade de modificação e habilidade de verificação - desde que os cenários sejam usados de forma adequada.

Os cenários situam os requisitos no ambiente onde o sistema irá ser usado e descrevem-nos de uma forma orientada aos utilizadores. Com a decomposição em funções do utilizador e a facilidade de compreensão, temos os ingredientes que nos permitem uma validação contínua de requisitos das intenções do cliente, levando assim a especificações mais adequadas.

Cada cenário (ou grupo de cenários relacionados) representam uma especificação parcial que é coerente, numa perspectiva do utilizador. Assim, completude parcial está naturalmente inerente com o suporte das especificações parciais.

O uso de cenários leva-nos a uma decomposição de funcionalidades, orientadas ao utilizador, sendo assim mais fácil de lidar com a evolução dos requisitos, melhorando a habilidade de modificação.

Uma vez que a partir de cenários podem-se derivar casos de teste, de uma forma natural e directa, os cenários são também verificáveis.

A utilização de cenários permite ter ciclos de tempo entre a escrita e a validação de requisitos mais pequenos. Permite ainda obter casos de teste derivados dos cenários mais cedo. Estas características, juntamente com a orientação ao utilizador dos cenários, proporcionam fortes capacidades para detectar e resolver ambiguidades. Contudo, os cenários não produzem especificações que à partida sejam não ambíguas (uma vez que usam linguagem natural), mas suportam processos com ciclos curtos de feedback. Este intervalo de tempo reduzido é um meio natural para detectar e resolver ambiguidades na comunicação entre humanos.

Consistência não é contemplada nos cenários. Pelo contrário, ter uma visão de cada cenário como uma entidade separada pode conduzir a problemas sérios de inconsistência. Mas nem todos os requisitos devem ser descritos usando cenários. Por exemplo, a persistência de dados ou comportamentos dependentes de estados são mais fáceis de especificar usando modelos de objectos ou autómatos de estado. Assim, em aproximações baseadas em cenários, é necessário um esforço explícito para garantir a consistência. Uma aproximação sistemática na estruturação do conjunto dos cenários é um passo bastante importante nestes casos.

[editar] Métodos para representação de cenários

Como foi dito anteriormente, a qualidade dos requisitos pode beneficiar consideravelmente através do uso de cenários. No entanto, essa melhoria não é obtida automaticamente, depende fortemente da forma como os cenários são usados e representados. A especificação pode cair num conjunto de cenários extremamente extenso, ou mal escrito, ou ainda mal estruturado, acabando por piorar este processo, em vez de o melhorar.

Apesar da atenção crescente que os cenários têm atraído em engenharia de requisitos, poucos métodos emergiram para guiar a prática de análise e validação de requisitos baseados em cenários.

De seguida, são apresentados dois métodos de forma resumida.

[editar] Uma aproximação: sistematicamente combinar texto estruturado com diagramas de estado

Nesta aproximação, um conjunto de cenários com uma estrutura baseada em diagramas de estado é combinado com uma representação textual estruturada de cada cenário.

[editar] Representação de um cenário

As características desta representação são:

uma separação clara dos eventos (estímulos) produzidos pelo actor e as respostas do sistema;
utilização de alguns termos simples de controle de fluxo (como if, go to, terminate), para tornar o fluxo o menos ambíguo possível;
a possibilidade de transformar esta representação num diagrama de estados de uma forma simples -- cada estímulo transforma-se num evento e cada resposta do sistema numa acção activada por esse evento. As alternativas são modeladas por estados, com uma transição de estado para cada alternativa.

Desta forma, é combinada a facilidade de leitura de texto em linguagem natural com o rigor da estruturação dos diagramas de estado. De notar que o fluxo normal pode conter alternativas e iterações.

[editar] Estruturação de um conjunto de cenários

Os diagramas de estado são mecanismos poderosos de estruturação e abstracção, que é o necessário para sistematicamente organizar um conjunto de cenários. Estruturação é um requisito na expressão de relações como "cenário A deve ser seguido pelo cenário B", ou "neste ponto, podem ser executados o cenário A ou o cenário B". Abstracção permite o uso de cenários quer a um nível mais detalhado, quer a um nível mais alto, e sistematicamente relacionar cenários detalhados com cenários de alto nível.

[editar] O método SCRAM (Sutcliffe)

O SCenario Requirements Analysis Method (SCRAM) é um método que segue um estilo de prototipagem na aproximação à Engenharia de Requisitos, motivado pela necessidade de ter os utilizadores activamente empenhados na descoberta de uma solução que melhor poderá ajudá-los a alcançar os seus objectivos.

Esta aproximação recomenda uma combinação entre demonstradores de conceitos, protótipos, cenários e modelos de análise racional. O método mostrou-se bastante prometedor, mas chegou-se à conclusão de que é preciso algum treino para que o seu uso seja produtivo/efectivo. O método é baseado em três técnicas:

protótipos, storyboards ou demonstradores de conceito;
cenários;
modelos de análise racional (design rationale);

As técnicas são combinadas na análise de requisitos. O método consiste nas quatro fases seguintes:

Captura inicial de requisitos e familiarização do domínio em questão: Isto é levado a cabo com entrevistas e procura de factos para ganhar informação suficiente para desenvolver o 1º demonstrador de conceito;
Especificação e desenvolvimento do demonstrador de conceito: Este tem funcionalidades e interacção limitadas, de forma a poder correr como um script para ilustrar apenas as acções de uma tarefa típica (e básica) de um utilizador; os efeitos são descritos pelo designer. O objectivo é criar visões do sistema requisitado, numa fase inicial, explicadas aos utilizadores através do demonstradores de conceito ou storyboards.
Sessão de análise / Exploração e validação de requisitos: Os utilizadores são convidados a participar na sessão, para criticar ou comentar o demonstrador de conceito e a fazer perguntas aos designers. A sessão é gravada para posterior análise;
Análise da sessão (sumário): Os dados recolhidos nas sessões anteriores são analisados e as conclusões são reportadas também aos utilizadores.

No fim, o analista entrega uma especificação de requisitos com:

o demonstrador de conceito;
um conjunto de diagramas de análise racional analisados que expressam as preferências dos utilizadores para várias opções;
uma especificação em forma de texto, gráficos ou outras notações mais formais;

[editar] Captura inicial de requisitos e familiarização do domínio em questão

Esta fase recolhe factos sobre o domínio a captura as intenções dos utilizadores para o novo sistema. Entrevistas e outras técnicas poderão ser usadas para ter uma ideia do âmbito do domínio e ter uma visão dos cenários para o sistema.

Angariar um conjunto de cenários considerado suficiente é uma questão bastante discutida. Existem vários problemas inerentes nesta tarefa:

Os utilizadores tendem a esquecer passos nos cenários que assumem que o analista já sabe: o problema do conhecimento implícito;
Cada pessoa pode dar o seu próprio ponto de vista sobre o problema. Pode ser difícil conseguir um conjunto de problemas a partir de utilizadores com visões distintas;
Conseguir um número suficiente de cenários para cobrir não só o uso normal do sistema, como também as situações onde as coisas podem correr mal pode requerer um esforço considerável. A quantidade de cenários pode ser enorme e torna-se uma problema conseguir seleccionar um sub-conjunto adequado para análise;
As pessoas tendem a esquecer os casos menos comuns ou anormais e a exagerar os problemas que encontram. Os problemas encontrados mais frequentemente ou recentemente serão primeiramente relembrados, mas as pessoas irão lembrar-se de episódios diferentes e qualificá-los com um grau de gravidade diferente, conforme a personalidade do utilizador. Separar e clarificar estas potenciais ambiguidades pode ser difícil.

A melhor forma de proceder é recolher cenários da utilização normal do sistema; olhar para as semelhanças entre as diferentes visões individuais e criar um "caso de uso normal". As variações dessa "normalidade" podem ser mais tarde usadas para fazer questões sobre as estratégias individuais da utilização do sistema.

Conseguido o caso de uso normal, deve-se reunir um conjunto de excepções ou caminhos alternativos. O analista deverá anotar todos os problemas que motivam esses caminhos alternativos, uma vez que estes poderão indicar requisitos do sistema. O número de alternativas necessárias depende da complexidade do sistema, em proporção directa. Todos os cenários de excepção que não sejam seleccionados para a análise de requisitos poderão mais tarde vir a ser necessários na refinação dos requisitos, mesmo que não possam ser todos usados na análise interactiva.

Esta fase deverá ainda capturar as intenções (de alto nível) dos utilizadores. Técnicas de brainstorming e de análise de objectivos são as mais apropriadas nestes casos.

[editar] Especificação e desenvolvimento do demonstrador de conceito (ter uma visão do desenho do sistema)

Esta fase cria visões preliminares do sistema o mais rápido e "barato" possível.

Storyboards é a técnica que produz os resultados mais esperados, mas pode ser melhorada com a utilização de protótipos. Os storyboards são criados depois do desenvolvimento de um estudo preliminar a partir do sub-conjunto de cenários reunidos na primeira fase. No fundo, são modelos da estrutura ou desenhos sem detalhes que mostram os passos chave na interacção do utilizador com o sistema. O analista segue o storyboard, explicando o que acontece em cada fase, em termos da funcionalidade do sistema e pede opiniões aos utilizadores. Uma variação poderá ser mostrar ao utilizador um cenário motivador e depois pedir para ser ele a seguir o storyboard. Esta variação mostra-se bastante útil, uma vez que foca os requisitos do interface com utilizador na medida em que prevê os problemas que um utilizador poderá encontrar (por exemplo, quando não sabe por onde seguir, ou não encontra o que quer).

A limitação dos storyboards é a sua fraca interactactividade. Pode-se pedir aos utilizadores para simular as acções, mas simular as respostas do sistema é bem mais difícil.

Os pontos chaves a notar no desenho de um storyboard são:

A sequência deverá ilustrar os passos chave do cenário, e cada imagem/ecrã está ligada a outra para mostrar a sequência global.
Os passos são anotados com descrições da funcionalidade do sistema e possíveis implicações no desenho do mesmo. Estas anotações servem como "lembranças" ao analista para explicar as sequências. Outras anotações poderão ser anotadas com os comentários dos utilizadores.
Num storyboard interactivo, um conjunto de diferentes imagens/ecrãs são apresentados manualmente para imitar os caminhos alternativos.

[editar] Estrutura da sessão

A sessão de análise é feita com o objectivo de encorajar a captura de requisitos de forma cooperativa entre dois, talvez três utilizadores e dois engenheiros. Um dos engenheiros faz o papel de facilitador e o outro o de operador dos demonstradores de conceito. A presença de pelo menos dois utilizadores ajuda a que a sessão seja mais partilhada e esteja menos na posse dos engenheiros; acaba também por torná-la mais produtiva, no sentido de colocar as pessoas a falar sobre o sistema, sobre o domínio e requisitos. As sessões seguem o seguinte esquema:

Introdução e apresentação, para colocar os utilizadores mais à vontade, explicar os papéis do designer e realçar que o que está em estudo é o sistema e não os utilizadores;
Demonstração dos cenários. O demonstrador de conceito é ilustrado usando uma sequência de scripts, ligados aos cenários. Nos pontos chave, são feitas perguntas de teste do demonstrador aos utilizadores, enquanto são usados diagramas de análise racional para explicar as opções de desenho.
Sumário. O facilitador sumariza os factos chave apreendidos na sessão e interactivamente constrói um mapa de conceitos de requisitos (funcionais e não funcionais) num quadro e pede opiniões. Os utilizadores são também encorajados a levarem consigo o demonstrador de conceito.

Após uma sessão, é feita a sua análise usando o vídeo ou áudio gravados e aproveitando as notas tiradas durante a sessão. A profundidade da análise depende dos recursos disponíveis.

Os diagramas de análise racional são usados para promover a discussão e é usada linguagem gestual sempre que possível, para ilustrar a diferença entre as várias opções. A motivação para o uso de análise racional é a de permitir explorar soluções possíveis junto ao utilizador e amplificar os requisitos através da exploração do desenho do sistema.

Um problema óbvio é a influência da opção implementada no demonstrador. Para minimizar este problema, deve-se usar cenários demonstradores de outras opções e fazer críticas mais vigorosas à versão implementada, por parte de quem desenvolveu.

Para além dos pontos chave do demonstrador, o engenheiro deve dar espaço aos utilizadores para serem abordados outros assuntos (isto é, a sessão não se deve limitar à explicação do demonstrador e elaboração de perguntas por parte do engenheiro).

De notar aqui que o sucesso de uma sessão está também dependente da experiência e treino do engenheiro / facilitador. A quantidade e qualidade de requisitos capturados por um novato ou um engenheiro experiente pode variar imenso (segundo Sutcliffe e Ryan, 1998).

[editar] Análise da sessão

Os requisitos capturados nas sessões efectuadas são sumarizados em listas, elaboradas num formato à escolha. Estas listas de requisitos são então estruturadas em grupos de funcionalidades relacionadas, ou como uma rede de objectivos a mostrar as relações, tal como os objectivos de segundo nível, as dependências e conflitos.

O resumo da sessão tem três objectivos principais:

Discutir e concordar em alternativas para requisitos em particular;
Clarificar problemas e ambiguidades que sejam levantados durante a sessão de demonstração;
Concordar nas prioridades dadas aos requisitos;

De seguida, o analista procede para o próximo requisito que tenha alternativas ainda por resolver. A discussão de alternativas é um processo que pode acabar por levar a uma decomposição das funcionalidades maior, na medida que são discutidos outros pontos não contemplados e angariar assim mais requisitos. É sempre um dilema gerir o nível de detalhe que se quer nestas sessões. Geralmente, dever-se-á marcar os pontos onde a decomposição estava iminente, ou onde estava aparente o desacordo entre utilizadores, ou ainda onde ficou a sensação de ambiguidade, e continuar para o próximo requisito, para manter o nível de detalhe ao longo da documentação de requisitos.

É necessário ter sempre presente que a opção de um desenho do sistema escolhida para fazer a demonstração acaba sempre por influenciar os utilizadores e toda a informação resultante das sessões. Para minimizar esta influência, é aconselhado a serem também abordadas outras opções durante a sessão.

Na atribuição de prioridades aos requisitos é frequente surgir um problema: os utilizadores acham que tudo é essencial, e então tudo é sempre prioritário. Para resolver este problema pode-se convidar os utilizadores a imaginarem a seguinte situação: supondo que cada um tem um crédito de pontos/dinheiro/unidades, eles terão que "pagar" usando esse crédito pelas opções que escolherem como prioritárias.

[editar] Problemas com a técnica de cenários

Existem ainda problemas em aberto na utilização de cenários em engenharia de requisitos:

Como já foi mencionado, um problema é a influência que uma opção escolhida para implementar um cenário poderá ter. Os utilizadores tendem a favorecer a opção escolhida no cenário, por ser a que têm uma ideia mais completa;

Outro potencial problema é a duração e quantidade de reuniões. Fazer demonstrações de conceitos com cenários pode demorar um tempo considerável. Daí que cada cenário deva ser limitado a quatro, cinco pontos chave, onde é necessário explorar alternativas. Na prática, isto significa que as sessões têm que se dividir em subsessões separadas, aumentando assim o número de sessões.

Não existem ainda medidas ou processos adequados para determinar qual o grau de formalidade necessário para garantir consistência e reduzir a ambiguidade a um nível tolerável;

Conceitos para uma integração sistemática com outras aproximações de engenharia de requisitos são ainda raras e preliminares;

Não existe ainda conceitos claros de como integrar requisitos não funcionais, nem se sabe como trabalhar sistematicamente diferentes níveis de requisitos (por exemplo, requisitos do negócio vs. requisitos detalhados de software)

Existe ainda a dúvida: estas aproximações, que de certa forma são de alto nível, conseguirão produzir requisitos de baixo nível, ou seja, tão detalhados quanto desejável?

[editar] Conclusão

Engenharia de requisitos baseada em cenários é definitavamente um passo na direcção certa. Em particular, cenários são uma chave que permite um novo estilo de engenharia de requisitos evolucionário e incremental.

Os cenários focam-se nos utilizadores, em descrições concretas e instâncias específicas. O desenho de sistemas baseado em cenários atribui um grande ênfase aos utilizadores; articula qual o seu papel, o que fazem, como fazem, e sobre que circunstâncias o fazem. Um cenário é uma descrição concreta do trabalho e actividades, descrevendo assim uma instância específica e um caso de uso.

Dois métodos foram aqui apresentados. O primeiro surgiu de um esforço para analisar a potencialidade dos cenários para melhorar a qualidade dos requisitos capturados. É um método simples e directo, que consiste em combinar sistematicamente texto estruturado com diagramas de estado. Um estudo feito com este método demonstrou que os cenários -- quando utilizados de forma correcta -- melhoram a qualidade de uma especificação de requisitos.

O segundo método começa com uma captura inicial de factos para ter uma ideia do âmbito do projecto. Segue-se uma fase de utilização de storyboarding, modelos e esquemas para obter um feedback prévio dos utilizadores nas visões do sistema preliminares. A próxima fase desenvolve o desenho do sistema como um demonstrador de conceito que é avaliado pelos utilizadores, através da execução de scripts, explicando alternativas ao desenho e pedindo aos utilizadores algum feedback. Os demonstradores de conceito refinam o desenho do sistema e produzem uma lista detalhada de requisitos. Na fase final desenvolvem-se protótipos funcionais para os utilizadores poderem testar. O método consegue fazer uma análise dos requisitos em falta ou inadequados tão bem como diagnosticar os defeitos de usabilidade. Aqueles protótipos são depois melhorados e testados num ciclo, até que os requisitos estabilizem, após o qual o produto final poderá então ser desenvolvido.