Nesta seção é apresentado um exemplo para demonstração do processo, considerando alguns requisitos do sistema Agendador de reuniões (Lamsweerde et al., 1993). A seguir apresentamos os requisitos usados, e a execução da sequencia de atividade definidas no processo proposto.
Atividade 1: - Análise sobre os requisitos funcionais
Para esta atividade, inicialmente é necessário definir as seguintes informações de entrada, a descrição do sistema e os requisitos funcionais. A Tabela 10 apresenta tais informações para o sistema Agendador de reuniões. Além disso, o controle desta primeira atividade envolve a definição das limitações físicas apresentadas pelo público alvo da aplicação. Para esse exemplo foi definido que o público alvo do agendador de reuniões apresenta limitações visuais e auditivas.
Tabela 10 - Descrição e RFs do sistema Agendador de reuniões Artefatos de entrada da atividade 1
Descrição do sistema
O objetivo do agendador de reuniões é fornecer suporte para organização de reuniões, isto é, determinar, para cada requisição de reunião, uma data e um local, de modo que a maior parte dos participantes possa efetivamente participar da reunião.
Requisitos funcionais
RF001: O sistema deve permitir o cadastro, alteração e exclusão de usuários.
RF002: O sistema deve permitir o cadastro, alteração e exclusão de participantes das reuniões;
RF003: O sistema deve permitir o cadastro, alteração e cancelamento das reuniões; RF004: O sistema deve permitir a substituição de reuniões.
RF005: O sistema deve permitir que os participantes informem as datas que estarão disponíveis para as reuniões.
RF006: O sistema deve permitir o cadastro, alteração e exclusão de locais e requisitos especiais (datashow, computadores e entre outras coisas) para as reuniões.
RF007: O sistema deve permitir que os participantes informem os locais de preferência para as reuniões.
RF008: O sistema deve mostrar os locais disponíveis para as reuniões. RF009: O sistema deve bloquear a reserva de um local já reservado.
RF010: O sistema deve manter os participantes informados sobre os acontecimentos durante o processo de organização das reuniões.
RF011: O sistema deve permitir que um participante indique outra pessoa para representá-lo em uma reunião.
RF012: O sistema deve permitir informar o nível de prioridade para a presença de cada participante.
Como explicado na Seção 4.1.1, para ocorrer a definição do tipo de conteúdo dois passos devem ser seguidos, sendo estes: I - Levantamento de possíveis tipos de
conteúdo, e II - A análise dos tipos de conteúdo levantados em relação às limitações do público alvo. Para demonstrar a execução desses passos, foi selecionado o requisito funcional “O sistema deve permitir que os participantes informem as datas que estarão disponíveis para as reuniões (RF005)”, como segue:
1º passo - Levantamento de possíveis tipos de conteúdo: no caso do RF005 é preciso informar dados que devem obedecer ao formato de “datas”. Para isso o usuário deve acessar o componente de interface, que é responsável pelo envio de datas, presente no formulário da reunião em questão. Esse componente é um controle de formulário classificado como “entrada” e deve ser do tipo “Data” (<input type= “date" name= “datadisp>). Em relação ao que usuário precisa informar, por padrão para definir datas usamos caracteres alfanuméricos, não precisamos ou não é conveniente usar imagens ou qualquer outro tipo de conteúdo para definir essas informações. Em resumo, no RF005 o usuário acessa controles de formulários para o envio das datas, e para informar essas datas deve utilizar caracteres alfanuméricos, tornando assim, o tipo de conteúdo texto o único possível para este requisito.
2º passo - Análise dos tipos de conteúdo levantados em relação às limitações do público alvo: o tipo de conteúdo texto levantado no passo anterior favorece tanto a limitações visuais como auditivas, pois informações textuais contidas na página podem ser processadas através de tecnologias assistivas como leitores de tela ajudando pessoas com limitações de visão. Como o RF005 se refere a entrada de informações, nesse caso as datas de disponibilidade, essa entrada pode ser feita através de teclados adaptados com Braille, ou através de tecnologias assistivas como aplicativos processadores de voz. Em relação a pessoas com problemas auditivos, o fato do site ou aplicação web conter textos não causa nenhum impacto para compreensão das informações.
A Tabela 11 apresenta o resumo dessa análise aplicada a todos os RFs elicitados. Após avaliar os tipos de conteúdos levantados em relação as limitações do público alvo, foi possível concluir que o conteúdo do tipo texto atende bem a todos os RFs, sem provocar prejuízo no acesso as informações e as funcionalidades.
Vejamos por exemplo o caso do RF008 “O sistema deve mostrar os locais disponíveis para as reuniões”, onde o tipo de conteúdo imagem poderia ser disponibilizado, pois se desejado o sistema poderia incluir fotos no cadastro desses locais, para passar informações visuais como tamanho e estrutura. Porém após analisar o impacto sobre as limitações, especificamente sobre pessoas com limitações visuais mais graves, o uso de imagens traria possíveis prejuízos no acesso a informação contida. Então se concluiu que o uso de texto contendo essas mesmas informações era mais adequado e não comprometia a funcionalidade.
Tabela 11 - Tipos de conteúdo definidos para os RFs do exemplo
Requisitos Tipo (s) de conteúdos possíveis Tipo (s) de conteúdo definidos
RF001 Texto e Imagem Texto
RF002 Texto e Imagem Texto
RF003 Texto e Imagem Texto
RF004 Texto Texto
RF005 Texto Texto
RF006 Texto e Imagem Texto
RF007 Texto Texto
RF008 Texto e Imagem Texto
RF009 Texto e Imagem Texto
RF010 Texto Texto
RF011 Texto e Imagem Texto
RF012 Texto e Imagem Texto
As informações contidas nas tabelas 10 e 11 compõe o artefato de saída gerado para a próxima atividade.
Atividade 2 - Seleção dos requisitos para a acessibilidade
De acordo com as informações definidas na atividade anterior, sobre o tipo de conteúdo e as limitações apresentadas pelo público alvo, a seleção dos requisitos de acessibilidade no catálogo de RNFs criado pode ser efetuada.
No caso deste exemplo, os requisitos selecionados para alcançar a acessibilidade, foram aqueles que atendiam pessoas com limitações visuais e auditivas. Já a seleção das tarefas para operacionalização escolheu aquelas que possuem vínculos ao tipo de conteúdo Texto.
Para facilitar a visualização e compreensão dos requisitos de acessibilidade elicitados, foi efetuada uma separação, onde serão mostrados parcialmente os
requisitos selecionados de acordo com os 4 princípios do WCAG 2.0. A Figura 18 apresenta os requisitos elicitados relacionados ao primeiro principio “Conteúdos disponibilizados de maneira perceptível”.
Figura 18 - Parte dos requisitos elicitados relacionados ao princípio de "Conteúdos disponibilizados de maneira perceptível"
Destacado na Figura 18 por uma seta o principio “Conteúdos disponibilizados de maneira perceptível”, assim como os outros três princípios, são refinamentos da meta de Acessibilidade. Esse princípio foi refinado em outras quatro metas suaves, sendo estas: “Alternativas para conteúdos não textuais”, “Conteúdo apresentado de diferentes maneiras”, “Facilidade na audição e visualização das informações disponibilizadas” e “Alternativas para mídias baseadas no tempo de execução”.
Outros refinamentos devem acontecer até chegar às operacionalizações, ou seja, quando as alternativas para alcançar os requisitos de acessibilidade podem ser claramente definidas. Vejamos por exemplo, como apresentado na Figura 18, o caso da meta suave “Alternativas para conteúdos não textuais” que foi refinada para a meta suave “Conteúdos não textuais disponibilizados através de alternativas textuais”, que entre as alternativas possui a operacionalização “Fornecer descrições para controles de formulário”.
Se houver alguma alteração no tipo de conteúdo vinculado a algum RFs elicitado para o projeto do Agendador de Reuniões como, por exemplo, se efetuarmos uma alteração no tipo de conteúdo definido para o RF008, adicionando o tipo de conteúdo imagem, outras operacionalizações seriam selecionadas além de “Fornecer descrições para controles de formulário”. A Figura 19 mostra como ficaria a configuração da meta suave “Fornecer alternativas textuais para todo conteúdo não textual” em relação as suas de operacionalizações selecionadas, se caso essa alteração fosse confirmada.
Figura 19 – Exemplo de operacionalizações selecionadas para o tipo de conteúdo Imagem
O fato do RF008 passar a conter imagens fez com que fosse possível selecionar novas alternativas para alcançar a meta suave “Conteúdos não textuais disponibilizados através de alternativas textuais” como, por exemplo, “Substituir conteúdos não textuais por textos” e “Fornecer alternativas textuais curtas”, entre outras, como mostrado na Figura 19.
A Figura 20 aborda os requisitos elicitados para o segundo princípio relacionado com a operabilidade do conteúdo, indicado pela seta. Os requisitos relacionados com esse princípio visam possibilitar a interação dos usuários com as funcionalidades do sistema, principalmente a partir do teclado, como determina a meta suave “Adaptação das funcionalidades para utilização via teclado”. .
Figura 20 - Parte dos requisitos elicitados relacionados ao princípio de "Conteúdos disponibilizados de maneira operável"
Como apresentado na Figura 20 a meta “Adaptação das funcionalidades para utilização via teclado” é um refinamento da meta suave “Funcionalidades disponibilizadas a partir do teclado”. Outro foco em questão é a navegabilidade do sistema, destacada no catálogo através da meta suave “Suporte para a navegação no conteúdo”.
O princípio relacionado a "Conteúdos disponibilizados de maneira compreensível" promove a criação de conteúdos que possam ser facilmente entendidos pelos usuários, além de fornecer auxilio para utilização das funcionalidades do sistema. A Figura 21 mostra o principio e os requisitos elicitados.
Figura 21 – Parte dos requisitos elicitados relacionados ao princípio de “Conteúdos disponibilizados de maneira compreensível”
Como mostrado na Figura 21, o principio “Conteúdos disponibilizados de maneira compreensível” foi refinado em três metas suaves, sendo estas: “Conteúdos textuais disponibilizados de maneira legível e compreensível”, “Páginas com funcionamento previsível” e “Correção e prevenção de erros”. O requisito “Alterações de contexto mediante a solicitação” é um exemplo de meta que auxilia pessoas com limitações visuais. Esse requisito estabelece que as alterações de contexto nas páginas web ocorram somente quando o usuário solicitar, pois em muitos casos existem redirecionamentos automáticos de páginas sem aviso prévio, dificultando que pessoas com problemas de visão perceba a alteração do contexto na navegação. Para operacionalizar essa meta foram selecionadas três alternativas, sendo estas: “Permitir que o usuário solicite atualizações de conteúdo ao invés de atualizar automaticamente”, “Fornecer tratamento para redirecionamento automático” e “Tratar pop-up”.
Os requisitos de acessibilidade elicitados pelo principio de “Conteúdos disponibilizados de maneira robusta” abordados na Figura 22, são relacionados com a correta utilização das tags de HTML e identificação concisa dos controles de
formulários. A ideia é a aplicação de boas práticas de programação, fazendo com que o produto elaborado seja compatível com variados agentes de usuários.
Figura 22 – Parte dos requisitos elicitados relacionados ao princípio de “Conteúdos disponibilizados de maneira robusta”
Como podemos ver na Figura 22, o principio “Conteúdos disponibilizados de maneira robusta”, destacado pela seta foi refinado para a meta suave “Conteúdos disponibilizados com o máximo de compatibilidade”, que por sua vez foi refinada em outras duas metas, sendo estas: “Páginas analisadas quanto a formatação” e “Tratamento para os valores dos componentes de interface do usuário”. A primeira meta se preocupa em fornecer páginas validadas de acordo com as normas estabelecidas para o uso de linguagens de marcação. Já segunda meta tenta evitar que os controles de formulários recebam nomes ambíguos ou duplicados.
Os requisitos de acessibilidade Web destacados nas Figuras 18, 20,21 e 22, compõe o catálogo de RNFs elicitados para a acessibilidade do sistema Agendador de reuniões, que é o artefato de entrada da próxima atividade.
Atividade 3 – Análise de conflitos entre os RNFs
Nessa etapa devemos encontrar e resolver os conflitos entre as tarefas para operacionalização dos requisitos de acessibilidade e outros RNFs. Como entrada esta atividade recebe a nova versão de catálogo de requisitos de acessibilidade Web
gerada na atividade anterior e os RNFs elicitados. Para este exemplo os RNF selecionado foi segurança.
A Figura 23 destaca o único conflito encontrado nesse exemplo, onde a tarefa “Fornecer mecanismo captcha” relacionada ao RNF de segurança apresenta impactos negativos sobre a meta suave “Conteúdos disponibilizados de maneira perceptível” de acessibilidade. O uso de captcha para validar acessos envolve imagens, podendo assim, não ser percebido corretamente por usuários com limitações visuais.
Figura 23 - Conflito entre as tarefas de operacionalização e outros RNFs do exemplo
Após a identificação do conflito, a tarefa “Fornecer mecanismo captcha” passa a ser classificada como fracamente negada, situação essa indicada por um “W-” com um ponto embaixo, como mostra a Figura 23. A solução adotada para este conflito foi o refinamento desta tarefa, disponibilizando alternativas para viabilizar o uso do mecanismo captcha, uma vez que o aspecto de segurança tinha que ser atendido.
Como abordado anteriormente na Seção 4.1.3, o usuário pode resolver conflitos adicionando, excluindo ou alterando as tarefas de operacionalização dos requisitos de acessibilidade. Assim sendo, 3 tarefas foram adicionadas, e após a análise levando em consideração as limitações do público alvo deste sistema (visual e auditiva), apenas uma das alternativas foi selecionada, sendo esta a tarefa “Fornecer alternativas textuais que identifiquem o captcha”, destacada na Figura 23 por uma
seta. Esta seleção pode ser indicada no catálogo com o “V” e a exclusão definitiva das outras tarefas com um “X”.
Após concluir a análise, a tarefa “Fornecer mecanismo captcha” é aceita, juntamente com sua tarefa criada no refinamento, passando a fazer parte da nova versão do catálogo de requisitos de acessibilidade Web gerado. Essa nova versão do catálogo servirá de artefato para a próxima atividade.
Atividade 4 – Gerar artefatos contendo os requisitos de acessibilidades selecionados
Por fim, a última atividade se refere à geração de artefatos tais como a versão final do catálogo de requisitos de acessibilidade Web, checklist e catálogo de correlações. O engenheiro de requisitos pode optar por gerar um ou todos os artefatos de saídas citados.
Em relação a geração do catálogo, a Figura 24 mostra a única alteração ocorrida, que se relaciona com a resolução do conflito provocado pelo uso do captcha, destacado pela seta. O restante do catálogo continua exatamente como mostrado nas Figuras 20,21 e 22.
Figura 24 - Trecho da versão final do catálogo de RNFs para acessibilidade Web
A Tabela 12 mostra o catálogo de correlação gerado, contendo as tarefas para operacionalização dos requisitos de acessibilidade Web que influenciam de forma positiva ou negativa sobre os RNFs do sistema ou metas suaves.
Tabela 12 - Catálogo de correlação gerado para o exemplo
Catálogo de correlações Operacionalizações dos requisitos do catálogo
RNFs ou metas suaves impactadas
Conteúdos disponibilizados de maneira perceptível
Usabilidade Portabilidade
Fornecer mecanismo captcha - -
Fornecer alternativas textuais que identifiquem o captcha
+ Ajustar conteúdo para a navegação
vertical em dispositivos móveis
Help + +
Utilizar componentes de interface que possam ter focos destacados por agentes de usuários
Help + +
Separar a apresentação do conteúdo utilizando CSS
Help + +
Na Tabela 12, além dos impactos negativos já citados para a Tarefa “Fornecer mecanismo captcha”, temos casos de impactos positivos como, por exemplo, entre a tarefa “Ajustar conteúdo para a navegação vertical em dispositivos móveis” e os RNFs Usabilidade e Portabilidade. Neste artefato somente são destacados os impactos que podem ser claramente definidos, ou seja, alguns impactos são desconhecidos ou não foram detectados ainda, como no caso entre as tarefas relacionadas ao uso do captcha e o RNF de Portabilidade.
Por fim, outro possível artefato de saída dessa atividade é o checklist para controle de implementação dos requisitos de Acessibilidade Web. Como informado anteriormente, o checklist deve servir como uma visão alternativa dos requisitos contida no catálogo de RNFs (Seção 4.1.4). O sucesso na implementação de um sistema tem grande dependência da qualidade dos artefatos gerados na etapa de elicitação. Dessa forma, o checklist foi elaborado para aumentar o controle na implementação dos requisitos e operacionalizações elicitadas. Além disso, com esse artefato, os desenvolvedores poderão controlar também o motivo pelo qual algum requisito não foi implementado, verificando assim possíveis falha de produtividade.
A Figura 25 apresenta um trecho do checklist gerado para o sistema Agendador de reuniões.
Figura 25 - Checklist do sistema Agendador de reuniões
A primeira parte do checklist, apresentada na Figura 25, fornece a listagem dos RFs do sistema, onde o desenvolvedor pode definir o status da implementação de cada requisito. Na segunda parte, o checklist permite aos desenvolvedores a definição sobre o que foi implementando ou não em relação aos requisitos e respectivas operacionalizações de Acessibilidade Web. O artefato possui ainda uma terceira parte que se refere ao controle do que foi implementado pelo desenvolvedor, além dos itens presentes nesse checklist, visando registrar possíveis omissões de
elicitação em relação aos requisitos de acessibilidade. Dessa forma, esse artefato através de continuas verificações permite aos desenvolvedores um controle maior sobre a implementação.
Tendo gerado os três artefatos de saídas, o engenheiro de requisitos finaliza o processo de elicitação.
4.4 Considerações finais sobre o Capítulo
Neste capítulo, a estrutura geral e analítica do método de elicitação foi explicada apresentando as 4 atividades necessárias para a elicitação dos requisitos, sendo estas: I - Análise sobre os requisitos funcionais; II - Seleção dos requisitos para a acessibilidade; III - Análise para operacionalização dos requisitos de acessibilidade e IV - Geração de artefatos. Através de um exemplo simples, utilizando a descrição informal de um sistema agendador de reuniões (Lamsweerde, et al 1993), foi possível demonstrar como o processo funciona.
Com a execução do exemplo ficou evidente que muito tempo é gasto durante a elicitação e, principalmente durante a documentação dos requisitos de acessibilidade. A utilização de abordagens orientadas a metas, utilizando os catálogos de RNFs, ajuda na melhor compreensão e elicitação dos RNFs necessários para o projeto. Porém, trabalhar com estas soluções, apesar de eficaz demanda tempo, pois na medida em que os catálogos armazenam mais informações, sua análise se torna mais lenta. Dessa forma, a crescente escalabilidade de informação dos catálogos de RNFs pode se tornar um problema, diminuindo as vantagens de utilizar esse tipo de estratégia para elicitação de requisitos. Por este motivo automatizar o processo aqui proposto, pode otimizar o tempo gasto, e levar a um melhor aproveitamento de abordagens orientadas a meta como o NFR Framework*. Assim, o capítulo a seguir apresenta a ferramenta Omnes Web que implementa este método.
5 Ferramenta Omnes Web
O termo “Omnes” tem origem no idioma latim e significa “Todos” na língua portuguesa, já o termo Web (da sigla em inglês World Wide Web) é relacionado à rede mundial de computadores. Esses dois termos foram unidos para formar a expressão “Omnes Web” ou “Web de todos”, sendo esse o nome definido para a ferramenta de apoio ao processo de elicitação proposto por esta dissertação.
A ferramenta Omnes Web foi desenvolvida com o objetivo de fornecer suporte às atividades que fazem parte do método de elicitação dos requisitos de Acessibilidade Web. A idéia é facilitar a extração de informações contidas nos catálogos de RNFs, amenizando o problema de escalabilidade citado no Capítulo anterior. O público alvo da Omnes Web pode englobar engenheiros de requisitos e produtores de conteúdo pra Web em geral.
A ferramenta Omnes Web pode ser acessada no seguinte endereço: http://omnesweb.ucore.com.br/. As seções a seguir apresentam as ferramentas utilizadas para auxiliar o funcionamento da Omnes Web, sua arquitetura e funcionalidades.