Neste módulo apresentamos alguns conceitos relacionados as abordagens presentes na Omnes Web. São apresentados também os passos para executar o processo de elicitação dos requisitos de Acessibilidade Web através da ferramenta. Para acessar as informações, clique nos links abaixo.
Os requisitos de software são classificados em requisitos funcionais e não funcionais. Os requisitos funcionais se referem as funções que o sistema deve fornecer, definindo também o comportamento do sistema, ou seja, a maneira como os componentes de software processam as entradas para produzir saídas (PRESSMAN, 2001). Os requisitos não funcionais representam as restrições e aspectos de qualidade que o produto deve atender (PRESSMAN, 2001). Como estes requisitos estão relacionados com as propriedades do sistema, é importante garantir a melhor forma possível de tratá-los dentro do processo de desenvolvimento, uma vez que, se houver falhas ao cumprir um RNF todo o sistema pode se tornar inútil, mesmo atendendo seus requisitos funcionais. RNFs em geral são considerados difíceis de testar, muitas vezes sua análise precisa ser subjetiva com apoio de um julgamento humano.
Para tratar os requisitos entra em cena a engenharia de requisitos, envolvendo processos para identificação, documentação e gerenciamento de requisitos (CHENG, B. H. C.; ATLEE, J. M., 2007). A engenharia de requisitos envolve também a compreensão sobre variados fatores, tais como: o contexto em que o software será utilizado, modelagem, análise, negociação, priorização, validação e verificação dos requisitos documentados e rastreabilidade SOMMERVILLE (2003). De acordo com NUSEIBEH e EASTERBROOK (2000) e SOMMERVILLE (2003) a engenharia de requisitos é dividida nas seguintes atividades: elicitação de requisitos, modelagem e análise dos requisitos, comunicação dos requisitos através da documentação, verificação e validação de requisitos e gerenciamento de requisitos.
O NFR framework é uma abordagem onde os requisitos não funcionais também são trabalhados como metas suaves (Softgoals) a serem atingidas (CHUNG et al., 2000). Uma meta suave pode ser interdependente e, ao mesmo tempo, pode impactar em outras metas, representando um objetivo, que não tem definição e/ou critério bem definido, no que diz respeito à sua satisfação, ou não. O NFR framework utiliza relações de contribuição entre as metas para auxiliar o desenvolvedor no processo de avaliação de impactos (CHUNG, L.; LEITE, J. C., 2009). Existem três tipos de representações para as relações entre metas, sendo elas:
- Refinamentos de metas suaves utilizando AND e OR, onde o elemento de contribuição AND obriga a implementação da operacionalização, no caso do elemento OR, esta implementação é opcional.
- Contribuição entre metas suaves, podendo ser negativas e positivas, apresentando possíveis soluções para a satisfação do objetivo.
- Operacionalização através da alegação para considerar a meta suave.
O NFR Framework contribui para que os desenvolvedores tratem os requisitos não funcionais, auxiliando a expressá-los sistematicamente e usá-los para guiar o processo de desenvolvimento de software de forma racional. O uso de uma representação chamada “Softgoal Interdependency Graphs (SIGs)” oferece uma estrutura para armazenamento de possibilidades de desenvolvimento, adicionando um raciocínio lógico sobre o processo de engenharia para os requisitos não funcionais.
Instituições como a W3C (World Wide Web Consortium) auxiliam os engenheiros do software na elaboração de aplicações e sites acessíveis. A missão da W3C é conduzir a produção do conteúdo para a web, por meio do desenvolvimento de protocolos e diretrizes que garantam o crescimento a evolução da web à longo prazo.
A partir da iniciativa de acessibilidade para web (WAI) a W3C criou o guia para acessibilidade do conteúdo web, conhecido pela sigla em inglês WCAG (W3C-WCAG, 2013), atualmente existem duas versões deste guia, sendo estas: WCAG 1.0 e WCAG 2.0. Em relação ao desenvolvimento voltado para dispositivos móveis a W3C disponibiliza o MWBP (Mobile Web Best Pratices) na versão 1.0 (W3C-MWBP 1.0, 2013). A seguir será abordado cada um dos guias citados
WCAG
O WCAG é considerado o padrão oficial para produção de conteúdo web na união europeia. As diretrizes contidas nesse guia aparecem na maior parte das legislações para web em todo o mundo. Esta influência que o WCAG tem sobre organizações públicas e privadas (incluindo órgãos reguladores) aumenta a importância de analisá-lo para compreender sua estrutura (testabilidade das diretrizes). Como já citado existem duas versões disponíveis para o WCAG, como segue:
-
WCAG 1.0: foi publicado em 1999, é composto de 14 diretrizes ou recomendações. Cada diretriz contém um conjunto de pontos verificações, o objetivo destes pontos é explicar como alcançar a conformidade com cada diretriz. Os níveis de conformidade são classificados em: A (sendo o nível mais baixo indica que os pontos de verificação de prioridade 1 foram alcançados), AA (indicando que todos os pontos de prioridade 1 e 2 foram alcançados), AAA (nivel mais alto indicando que todos os níveis de prioridades foram alcançados, ou seja, 1,2 e 3). As 14 diretrizes são englobadas por dois temas genéricos (W3C-WCAG 1.0, 2013), como segue:
- Assegurar uma transformação harmoniosa - Tratada especialmente nas diretrizes de 1 a 11, esse princípio se relaciona com a capacidade das páginas web se manterem acessíveis independente de quaisquer limitações;
- Tornar o conteúdo compreensível e navegável - abordada nas diretrizes de 12 a 14, se relaciona com a importância de tornar os produtos compreensíveis e navegáveis, utilizando linguagens simples e claras.
-
WCAG 2.0: foi publicado em 2008, sendo amplamente aconselhado pela W3C, pois abrange diversas tecnologias e é considerado por seus criadores mais compreensível (W3C-WCAG 2.0, 2013). Assim como WCAG 1.0, este guia é composto por diretrizes ou recomendações. Uma das inovações do WCAG 2.0 é o agrupamento dessas diretrizes por 4 princípios, sendo estes: Perceptível, Operável, Compreensível e Robusto. Onde cada diretriz é composta por critérios de sucesso, estes critérios garantem a testabilidade sobre a conformidade para alcançar acessibilidade. Relacionados com os critérios de sucessos estão variadas técnicas, visando indicar estratégias em níveis de programação para se alcançar conformidade com os critérios de sucesso e respectivas diretrizes (W3C-WAI, 2013; W3C-WCAG 2.0, 2013). A configuração dos níveis de prioridade atende ao seguinte padrão: A (o mais básico), AA (intermediário) e AAA (o mais elevado). A tabela abaixo mostra os 4 princípios que englobam as 12 diretrizes do WCAG 2.0:
Tabela - Princípios do WCAG 2.0. Fonte: (W3C-WCAG 2.0, 2013) Princípios Diretrizes contidas Perceptível - Fornecer Alternativas textuais para qualquer conteúdo não textual;
- Fornecer Alternativas para mídias baseadas no tempo;
- Criar conteúdo que pode ser apresentado de modos diferentes sem perder informação ou estrutura;
- Tornar mais fácil aos usuários a visualização e audição de conteúdos incluindo as separações das camadas da frente e de fundo.
Operável - Fazer com que todas as funcionalidades estejam disponíveis no teclado;
- Prover tempo suficiente para os usuários lerem e usarem o conteúdo;
- Não projetar conteúdo de uma forma conhecida por causar ataques epiléticos;
- Prover formas de ajudar os usuários a navegar, localizar conteúdos e determinar onde se encontram.
Compreensível - Tornar o conteúdo de texto legível e compreensível;
- Fazer com que as páginas da Web apareçam e funcionem de modo previsível;
- Ajudar os usuários a evitar e corrigir erros.
Robusto - Maximizar a compatibilidade entre os atuais e futuros agentes do usuário, incluindo as tecnologias assistivas.
O WCAG 2.0 propõe uma estrutura focada na experiência do usuário, visando determinar com mais exatidão os níveis de acessibilidade, onde a avaliação dos critérios de sucesso das diretrizes necessita muitas vezes de um julgamento humano para determinar se um componente de um site está ou não acessível. Esta é uma das diferenças fundamentais para a versão anterior, uma vez que os pontos de verificações (checkpoints) presentes no WCAG 1.0 davam erroneamente a sensação de que os testes para conformidade com a acessibilidade poderiam ser julgados basicamente por computador. Os checkpoints do WCAG 1.0 foram substituídos pelos critérios de sucessos no WCAG 2.0.
A ferramenta Omnes web fornece apoio ao processo de elicitação dos requisitos de acessibilidade Web. Como fonte dos requisitos a ferramenta utiliza o catálogo de RNFs, em formato de XML, contendo os requisitos de Acessibilidade Web.
O processo de elicitação da ferramenta contém 4 atividades, sendo estas: I Análise sobre os requisitos funcionais; II Seleção dos requisitos de Acessibilidade; III Análise dos conflitos entre RNFs; IV Geração de Artefatos. A seguir são abordados as 4 atividades do processo de elicitação e os procedimentos necessários para execução de cada uma.
Atividade 1 - Análise sobre os requisitos funcionais
Para iniciar o processo de elicitação o usuário deve clicar no botão “Iniciar Elicitação” na tela inicial da ferramenta, destacado pela seta verde na figura abaixo.
Inicialmente o usuário deve fornecer as informações básicas do projeto como nome, os autores, e logo depois a descrição da aplicação.
Após fornecer as informações do projeto, o usuário deve definir as limitações presentes no público alvo da aplicação. Essas limitações serão utilizadas como parâmetros para seleção automática dos requisitos de Acessibilidade Web, presentes no catálogo de RNFs.
Obs.: No caso em que a limitação é refinada em outras limitações, o usuário pode especificar quais dessas limitações o sistema deve considerar. Por exemplo, no caso da limitação visual, houve um refinamento em três limitações, sendo estas: Daltonismo, Baixa Visão e Sem Visão. Assim o usuário pode selecionar todas ou somente a limitação visual que o público alvo da aplicação possui, na figura x por exemplo, foram selecionadas as limitações de Baixa Visão e Sem Visão.
Em seguida o usuário deve efetuar a entrada dos requisitos funcionais da aplicação e definir quais os tipos de conteúdo presentes em cada um. Os tipos conteúdos definidos para os RFs serão utilizados como parâmetros para seleção automática das operacionalizações dos requisitos de Acessibilidade Web, presentes no catálogo.
A entrada dos requisitos pode ser feita de duas maneiras, como segue:
-
Marcando a opção "Individual":
essa opção permite o usuário inserir a descrição dos requisitos individualmente.
Após inserção da descrição do requisito o usuário deve informar a classificação do requisito,
informando se é requisito funcional (RF) ou não funcional (RNF).
Se o requisito inserido for um RF, o usuário deve informar o tipo de conteúdo relacionado.
O tipo de conteúdo será utilizado como parâmetro para seleção das operacionalizações dos
requisitos de acessibilidade. Após informar a descrição, classificação e tipo de conteúdo do RF,
o usuário deve clicar no botão “Adicionar”.
A figura abaixo mostra um exemplo de inserção individual de um RF.
Na inserção de RNF o usuário deve apenas informar a descrição e classificação.
A opção de inserção individual aceita a entrada de requisitos através do editor da descrição. Essa opção deve ser utilizada no caso em que o usuário possua algum documento contendo os requisitos. O conteúdo desse documento deve ser copiado e colado no editor, assim o usuário pode selecionar a descrição de um determinado requisito e adicioná-lo clicando no botão circulado na figura x. O requisito selecionado é levado até o campo “Requisito” destacado pela seta, e logo em seguida, após serem informados a classificação do requisito e o tipo de conteúdo o usuário pode clicar no botão “Adicionar”.
Obs.: Os RNFs só podem ser inseridos selecionando a opção de inserção Individual.
-
Marcando a opção "Grupo" essa opção permite ao usuário informar os RFs por grupo, e a descrição desse grupo pode ser personalizada, a figura abaixo mostra um exemplo de inserção de RFs por grupo.
Como podemos ver na figura x, destacado por um circulo, dois grupos de RFs foram informados, o primeiro grupo compreende 12 RFs e o segundo grupo compreende 10 RFs, ambos vinculados ao tipo de conteúdo Texto.
Os requisitos adicionados serão mostrados em duas tabelas abaixo do campo de inserção, sendo uma tabela para os requisitos inseridos individualmente, e outra para os inseridos por grupos, como mostra a figura x.
Após informar todos os RFs e seus respectivos tipos de conteúdos, assim como todos os RNFs, o usuário deve clicar no botão prosseguir para que o sistema execute automaticamente a segunda atividade do processo de elicitação, que é a seleção dos requisitos de Acessibilidade Web, presentes no catálogo de RNFs.
Essa atividade é executada automaticamente pela Omnes Web, e se trata da seleção dos requisitos de acessibilidade juntamente com as formas de operacionalizações destes requisitos, contidos no catálogo de RNFs. A seleção dos requisitos de acessibilidade se baseia nas limitações do público alvo informadas, enquanto as operacionalizações são selecionadas com base nos tipos de conteúdos vinculados aos RFs.
Assim sendo, após concluir o procedimento de seleção, o sistema direciona o usuário para a terceira atividade, que é a Análise de conflitos entre os RNFs.
Essa atividade consiste na detecção de possíveis conflitos entre os RNFs, informados na primeira atividade, e os requisitos de Acessibilidade Web elicitados.
O usuário deve selecionar cada RNF informado e produzir refinamentos, adicionando novos requisitos, clicando no botão “Adicionar requisito”, para detalhar melhor o que pretende implementar no RNF em questão, como mostra a figura x.
Quando o usuário clicar no botão “Adicionar requisitos”, destacado pela seta na figura x, o sistema abre uma tela para inserção dos dados do requisito a ser adicionado. Inicialmente o usuário deve informar o nome do requisito, logo em seguida selecionar o seu estereótipo. O estereótipo é importante para a correta identificação de cada elemento do catálogo de RNFs, quando o XML for importado pela ferramenta STARUML. Para a escolha do estereótipo existem três possibilidades, sendo estas: I NFRSoftgoal que são os requisitos vinculados as metas suaves do catálogo, II OperationalizingSoftgoal que são as operacionalizações dos requisitos, e por fim, III ClaimSoftgoal que são as alegações para definir como prioritário o requisito a ser adicionado. A figura x mostra um exemplo de inserção do nome para o requisito e a escolha do estereótipo.
Nesse exemplo o RNF selecionado era Segurança, como mostra a figura x, e o requisito adicionado para refinar este RNF foi Testes de requisições, e o estereótipo escolhido para este requisito é NFRSoftgoal.
As próximas informações a serem definidas para esse requisito se referem as correlações com o elemento pai, no caso desse exemplo Segurança, e a correlações com outros RNFs. A figura x destaca as possibilidades de correlações deste requisito adicionado com o elemento pai, ao todo são 9 possibilidades, sendo estas: I AND decomposition que determina como obrigatória a implementação do requisito, II OR decomposition que significa dizer que a implementação do requisito é opcional, III Equal decomposition determinando que a descrição do requisito deve ser igual a descrição do elemento pai, IV Someplus que determina um impacto positivo com entre o requisito e o elemento pai, V Make que significa dizer que o requisito adicionado implementa o elemento pai, VI Help que determina que o requisito adicionado auxilia na implementação do elemento pai, VII Someminus que determina um impacto negativo entre requisito e o elemento pai, VIII Break que se relaciona com o fato de que este requisito inviabiliza a implementação do elemento pai, e por fim IX Hurt que determina que o requisito em questão prejudica a implementação do elemento pai.
Após informar a correlação com o elemento pai, o usuário deve informar a correlação ou impactos do requisito com outros RNFs. Primeiro o usuário deve informar o requisito impactado e em seguida o tipo de impacto, logo em seguida clicar no botão Adicionar, destacado pela seta na figura X.
Essa análise para identificar impacto do RNF com outros requisitos deve auxiliar ao usuário em decisões como alterar e excluir ou não o RNF adicionado. Essa análise deve ser efetuada para todo RNF adicionado, o usuário também pode optar por fazer a análise de conflitos com os requisitos de acessibilidade Web selecionados.
O ultimo procedimento a ser feito em relação ao requisito adicionado é a criação de suas operacionalizações. Para criar uma operacionalização o usuário deve informar o nome da mesma e clicar no botão “Adicionar”. Após adicionar a operacionalização para o requisito o usuário deve clicar em editar para repetir o mesmo processo de detectar impactos, só que nesse caso serão identificados os conflitos entre a operacionalização com outros RNFs. Para editar a operacionalização criada o usuário deve clicar no botão destacado pela seta na figura x.
Se caso a operacionalização apresentar impacto negativo com algum elemento do catálogo de acessibilidade, o usuário pode resolver excluindo ou adicionando uma operacionalização alternativa, como mostra a figura x.
No caso exemplo mostrado na figura x, foi identificado que o Fornecer Mecanismo capctha tem impacto negativo sobre o principio “Conteúdos disponibilizados de maneira perceptível”. Assim sendo, para corrigir sem alterar ou excluir a operacionalização, o usuário pode adicionar uma alternativa, no caso da figura x, foi adicionada a operacionalização “Fornecer alternativas textuais que identifiquem o capctha”. Após adicionar a alternativa o usuário deve clicar no botão editar para informar o tipo de impacto que a nova operacionalização causa no principio impactado pela operacionalização pai. Nesse exemplo a nova operacionalização apresenta impacto positivo no principio “Conteúdos disponibilizados de maneira perceptível”, corrigindo assim a situação de impacto negativo causado pela operacionalização pai “Fornecer mecanismo capctha”.
Após efetuar a análise de impactos entre os RNFs o usuário deve clicar no botão prosseguir para ser direcionado a 4º e ultima atividade, que é a geração de artefatos.
Essa atividade é totalmente automatizada e consiste basicamente na geração dos artefatos referentes ao projeto, ao todo são 3 artefatos, sendo estes: I o checklist para controle da implementação dos requisitos de acessibilidade junto aos requisitos funcionais, II O catálogo dos requisitos de acessibilidade elicitados, e por fim III a tabela de correlações, contendo os impactos detectados entre os RNFs e os requisitos de acessibilidade.
Nessa tela é possível também exportar o arquivo do projeto criado, para ser importado futuramente caso o usuário deseje efetuar alterações, ou visualizar as informações.
Lorem ipsum
A ferramenta Omnes Web foi elaborada para fornecer suporte ao processo de elicitação dos requisitos de Acessibilidade Web. Esse processo faz parte do projeto apresentado ao Departamento De Informática E Matemática Aplicada (DIMAP) da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.