Um Método Semi-automatizado para Elicitação de Requisitos de Acessibilidade Web

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO MESTRADO EM SISTEMAS E COMPUTAÇÃO Um Método Semi-automatizado para Elicitação de Requisitos de Acessibilidade Web Romeu Ferreira de Oliveira Natal-RN Fevereiro de 2014

2 Romeu Ferreira de Oliveira Um Método Semi-Automatizado para Elicitação de Requisitos de Acessibilidade Web Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação. Linha de pesquisa: Engenharia de Software Orientadora Prof.ª Dr.ª Lyrene Fernandes da Silva PPgSC Programa de Pós-Graduação em Sistemas e Computação DIMAp Departamento de Informática e Matemática Aplicada CCET Centro de Ciências Exatas e da Terra UFRN Universidade Federal do Rio Grande do Norte Natal-RN Fevereiro de 2014

3 UFRN / Biblioteca Central Zila Mamede Catalogação da Publicação na Fonte Oliveira, Romeu Ferreira de. Um método semi-automatizado para elicitação de requisitos de acessibilidade web. / Romeu Ferreira de Oliveira. Natal, RN, f.: il. Orientadora: Profa. Dra. Lyrene Fernandes da Silva. Dissertação (Mestrado) Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação. 1. Acessibilidade web Dissertação. 2. Requisitos não-funcionais - Dissertação. 3. Elicitação - Dissertação. 4. Catálogo de RNFs Dissertação. 5. Framework NFR Dissertação. I. Silva, Lyrene Fernandes da. II. Universidade Federal do Rio Grande do Norte. III. Título. RN/UF/BCZM CDU

4 ROMEU FERREIRA DE OLIVEIRA Um Método Semi-automatizado para Elicitação de Requisitos de Acessibilidade Web Esta Dissertação foi julgada adequada para a obtenção do título de mestre em Sistemas e Computação e aprovado em sua forma final pelo Programa de Pós- Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte. Prof.ª Dra. Lyrene Fernandes da Silva UFRN (Presidente) Prof. Dr. Martin Alejandro Musicante UFRN (Coordenador do Programa) Banca Examinadora Prof.ª Dra. Lyrene Fernandes da Silva UFRN (Orientador) Prof. Dr. Leonardo Cunha de Miranda UFRN (Examinador Interno) Prof.ª Dra. Carla Taciana Lima Lourenço Silva Schuenemann UFPE (Examinador Externo) Fevereiro, 2014

5 Dedico este trabalho aos meus familiares, pelo eterno e incondicional incentivo, amor e dedicação.

6 Agradecimentos Em primeiro lugar agradeço a Deus por sempre me conceder, em todos os momentos da minha vida, as bênçãos e ensinamentos que moldaram o meu caráter. Eternamente louvarei e agradecerei ao senhor, por nunca me deixar desamparado, provando que o amor e a bondade vencem quaisquer obstáculos. Em segundo lugar, agradeço aos meus pais por, simplesmente, serem a minha fortaleza e o meu exemplo de vida. Agradeço imensamente, por me ensinarem a viver com honra e dignidade. Obrigado, vocês iluminaram os meus caminhos obscuros com afeto e dedicação, me deram a esperança por dias melhores. Agradeço carinhosamente a minha orientadora, Professora Lyrene Fernandes, por ter me indicado sempre o melhor caminho nas pesquisas, pela competência, atenção e enorme paciência que dispôs a cada etapa deste trabalho. Agradeço aos meus irmãos Renyer Ferreira e Aparecida Ferreira, pois de um jeito particular, me ajudaram, dando bons conselhos, se preocupando com minha saúde física e mental. Obrigado pelo carinho e respeito. Agradeço também aos meus amigos Arnóbio Pereira, Waldson Patrício e Junior Melo por terem sido companheiros ao longo desta jornada. Agradeço aos professores Leonardo Miranda, Marcia Jacyntha e Carla Silva por suas importantes considerações, feitas na ocasião da qualificação e defesa deste trabalho e, principalmente, pelo incentivo e ajuda que me forneceram ao longo deste Mestrado. Por fim, agradeço aos colegas e amigos que fiz durante o Mestrado. Preciso agradecer também a CAPES pelo apoio financeiro despendido a esta pesquisa. E agradeço a todos que de forma direta ou indireta cooperaram com a elaboração desta pesquisa, meus sinceros agradecimentos!

7 Há uma força motriz mais poderosa que o vapor, a eletricidade e a energia atômica: a vontade. Albert Einstein

8 Um Método Semi-automatizado para Elicitação de Requisitos de Acessibilidade Web Autor: Romeu Ferreira de Oliveira. Orientadora: Prof.ª Dr.ª Lyrene Fernandes da Silva RESUMO No contexto de Engenharia de Software, a Acessibilidade Web vem ganhando cada vez mais espaço, se firmando como um importante atributo de qualidade. Esse fato se deve a iniciativas de instituições como a W3C (World Wide Web Consortium) e ao surgimento de normas e leis como a Section 508 que fundamentam a importância de elaborar sites e aplicações Web acessíveis. Apesar dessas melhorias, a falta de acessibilidade na web ainda é um problema persistente, e pode está relacionada ao momento ou a fase em que este requisito é tratado dentro do processo de desenvolvimento. Tendo em vista que a Acessibilidade Web geralmente é considerada como um problema de programação ou tratada quando o aplicativo já está totalmente desenvolvido. Dessa forma, considerar a acessibilidade já durante as atividades de análise e especificação de requisitos se mostra uma estratégia para facilitar o andamento do projeto, evitando retrabalho em fases avançadas do desenvolvimento de software por causa de possíveis erros, falhas ou omissões na elicitação. O objetivo desta pesquisa é desenvolver um método e uma ferramenta para apoiar a elicitação dos requisitos de acessibilidade web. A estratégia de elicitação presente neste método é fundamentada através da abordagem orientada a metas do NFR Framework e na utilização de catálogos de RNFs, criados com base nas diretrizes contidas no WCAG 2.0 (Web Content Accessibility Guideline) proposto pela W3C. Palavras-chave: Acessibilidade Web, Requisitos não-funcionais, Elicitação, Catálogo de RNFs, Framework NFR.

9 A Semi-automated Method for Elicitation of Web Accessibility Requirements Author: Romeu Ferreira de Oliveira. Supervisor: Lyrene Fernandes da Silva, D.Sc. ABSTRACT In the context of Software Engineering, web accessibility is gaining more room, establishing itself as an important quality attribute. This fact is due to initiatives of institutions such as the W3C (World Wide Web Consortium) and the introduction of norms and laws such as Section 508 that underlie the importance of developing accessible Web sites and applications. Despite these improvements, the lack of web accessibility is still a persistent problem, and could be related to the moment or phase in which this requirement is solved within the development process. From the moment when Web accessibility is generally regarded as a programming problem or treated when the application is already developed entirely. Thus, consider accessibility already during activities of analysis and requirements specification shows itself a strategy to facilitate project progress, avoiding rework in advanced phases of software development because of possible errors, or omissions in the elicitation. The objective of this research is to develop a method and a tool to support requirements elicitation of web accessibility. The strategy for the requirements elicitation of this method is grounded by the Goal-Oriented approach NFR Framework and the use of catalogs NFRs, created based on the guidelines contained in WCAG 2.0 (Web Content Accessibility Guideline) proposed by W3C. Keywords: Web Accessibility, Non-functional requirements, Elicitation, Catalog of NFRs, Framework NFR.

10 10 Lista de Figuras Figura 1 - Princípio de operabilidade da usabilidade. Fonte: (Alonso et al., 2009) Figura 2 - Exemplo de um SIG baseado na abordagem NFR Framework Figura 3 - Exemplo de um modelo SD do framework i* Figura 4 - Parte do catálogo de usabilidade. Fonte: (Cysneiros, 2007) Figura 5 - Exemplo de um catálogo de métodos do NFR Framework Figura 6 Caixa do SADT Figura 7 - Elementos do catálogo relacionados ao princípio Perceptível do WCAG Figura 8 - Elementos do catálogo relacionados ao princípio Operável Figura 9 - Elementos do catálogo relacionados ao princípio Compreensível Figura 10 - Elementos do catálogo relacionados ao princípio Robustez Figura 11 - (A) Estrutura do catálogo de RNFs; e (B) exemplos de conteúdo contido no catálogo Figura 12 - Exemplo de elementos do catálogo de RNFs vinculados aos tipos de limitações e conteúdo Figura 13 - Visão geral do método de elicitação Figura 14 - Atividades do método de elicitação Figura 15 - Exemplo de filtragem dos requisitos de Acessibilidade Web Figura 16 - Exemplos de requisitos de acessibilidade com suas respectivas tarefas de operacionalização Figura 17 - Trecho do catálogo de requisitos de acessibilidade contendo conflitos Figura 18 - Parte dos requisitos elicitados relacionados ao princípio de "Conteúdos disponibilizados de maneira perceptível" Figura 19 Exemplo de operacionalizações selecionadas para o tipo de conteúdo Imagem... 68

11 11 Figura 20 - Parte dos requisitos elicitados relacionados ao princípio de "Conteúdos disponibilizados de maneira operável" Figura 21 Parte dos requisitos elicitados relacionados ao princípio de Conteúdos disponibilizados de maneira compreensível Figura 22 Parte dos requisitos elicitados relacionados ao princípio de Conteúdos disponibilizados de maneira robusta Figura 23 - Conflito entre as tarefas de operacionalização e outros RNFs do exemplo Figura 24 - Trecho da versão final do catálogo de RNFs para acessibilidade Web Figura 25 - Checklist do sistema Agendador de reuniões Figura 26 - Exemplo do XML gerado pela ferramenta StarUML Figura 27 - Arquitetura da ferramenta Omnes Web Figura 28 - Página inicial da ferramenta Omnes Web Figura 29 - Módulo de elicitação: Entrada das informações do projeto Figura 30 - Módulo de elicitação: definição das limitações do público alvo e os tipos de conteúdos para os RFs Figura 31 - Árvore contendo os requisitos e operacionalizações elicitadas Figura 32 - Módulo de elicitação: Análise de conflitos entre os RNFs Figura 33 - Módulo de elicitação: Geração de artefatos Figura 34 - Trecho do catálogo de requisitos de Acessibilidade Web gerado.. 89 Figura 35 - Trecho do checklist contendo a lista dos RFs RNFs Figura 36 - Módulo de Artefatos: Visões do catálogo de Acessibilidade Web. 91 Figura 37 - Módulo de Artefatos: Trecho do catálogo de Acessibilidade Web no formato de Tabela Figura 38 - Módulo de Artefatos: Exportação de XML do catálogos de RNFs. 93 Figura 39 - Módulo de Glossário da Omnes Web Figura 40 - Etapas do estudo de caso... 98

12 Figura 41 - Exemplo de um checklist gerado pela Omnes Web

13 13 Lista de Tabelas Tabela 1 - Princípios do WCAG 2.0. Fonte: (W3C-WCAG 2.0, 2013) Tabela 2 - Princípios da MWBP 1.0. Fonte: (W3C-MWBP 1.0, 2013) Tabela 3 - Tipos de limitações Tabela 4 - Refinamento das limitações Visual, Auditiva e Cognitiva Tabela 5 - Tipos de conteúdo Tabela 6 - Entradas, controles, mecanismos e saídas da atividade 1 do processo Tabela 7 - Entradas, controles, mecanismos e saídas da atividade 2 do processo Tabela 8 - Entradas, controles, mecanismos e saídas da atividade 3 do processo Tabela 9 - Entradas, controles, mecanismos e saídas da atividade 4 do processo Tabela 10 - Descrição e RFs do sistema Agendador de reuniões Tabela 11 - Tipos de conteúdo definidos para os RFs do exemplo Tabela 12 - Catálogo de correlação gerado para o exemplo Tabela 13 - Questões de pesquisa elaboradas para o estudo de caso Tabela 14 Situações versus Recursos disponíveis na etapa I do estudo de caso Tabela 15 - Configuração dos participantes para a etapa de elicitação do estudo de caso Tabela 16 - Configurações definidas para formação de duplas da etapa I Tabela 17 - Distribuição da documentação gerada na etapa I entre os participantes da etapa II Tabela 18 - Níveis de experiência dos participantes da segunda etapa Tabela 19 - Respostas das perguntas 1,2,3 e 4 do questionário para a categorização de perfil dos participantes da 3º etapa

14 14 Tabela 20 - Requisitos de Acessibilidade extraídos Projeto Tabela 21 - Requisitos de Acessibilidade extraídos Projeto Tabela 22 - Requisitos de Acessibilidade selecionados Projeto Tabela 23 - Requisitos de Acessibilidade selecionados Projeto Tabela 24 - Tempo gasto por cada grupo na execução da etapa de elicitação 119 Tabela 25 - Artefatos gerados pelos grupos da etapa de elicitação Tabela 26 - Respostas dos participantes da etapa de elicitação para o questionamento 1 do questionário de pós - execução do estudo de caso Tabela 27 - Respostas dos participantes da etapa de elicitação para o questionamento 2 do questionário de pós - execução do estudo de caso Tabela 28 - Respostas dos participantes da etapa de elicitação para o questionamento 3 do questionário de pós - execução do estudo de caso Tabela 29 - Respostas dos participantes da etapa de elicitação para o questionamento 4 do questionário de pós - execução do estudo de caso Tabela 30 - Respostas dos participantes da etapa de elicitação para o questionamento 5 do questionário de pós - execução do estudo de caso Tabela 31 - Respostas dos participantes da etapa de elicitação para o questionamento 6 do questionário de pós - execução do estudo de caso Tabela 32 - Informações extraídas da etapa de prototipação Tabela 33 - Respostas dos participantes da etapa de prototipação para o questionamento 5 do questionário de pós - execução do estudo de caso Tabela 34 - Análise manual da Acessibilidade Web do Projeto 1 prototipação do participante Tabela 35 - Respostas dos questionamentos de 1 a 5 do questionário de avaliação da Acessibilidade Web prototipação do participante I da segunda etapa Tabela 36 - Análise manual da Acessibilidade Web do Projeto 2 prototipação do participante

15 15 Tabela 37 - Respostas dos questionamentos de 1 a 5 do questionário de avaliação da Acessibilidade Web prototipação do participante Tabela 38 Resultados das análises manuais de Acessibilidade Web efetuadas nos 4 aplicativos Tabela 39 - Médias das tentativas para executar as tarefas solicitadas nos roteiros dos aplicativos Tabela 40 - Resultados da análise automatizada nos aplicativos gerados na etapa de prototipação Tabela 41 - Respostas dos participantes da etapa de elicitação para o questionamento 7 do questionário de pós- execução da etapa de elicitação Tabela 42 - Respostas dos participantes da situação 1 da etapa de elicitação para o questionamento 8 do questionário de pós execução do estudo de caso Tabela 43 - Respostas dos participantes da situação 2 da etapa de elicitação para o questionamento 9 do questionário de pós execução do estudo de caso Tabela 44 - Respostas dos participantes da situação 3 da etapa de elicitação para o questionamento 10 do questionário de pós - execução do estudo de caso Tabela 45 - Respostas dos participantes da etapa de elicitação para o questionamento 11 do questionário de pós - execução do estudo de caso Tabela 46 - Respostas dos participantes da etapa de elicitação para o questionamento 12 do questionário de pós - execução do estudo de caso Tabela 47 - Respostas dos participantes da etapa de elicitação para o questionamento 13 do questionário de pós - execução do estudo de caso

16 16 Lista de abreviaturas e siglas CSCW - Computer Supported Cooperative Work CSS - Cascading Style Sheets HTML - Hypertext Markup Language IEC - International Electrotechnical Commission IEEE - Institute of Electrical and Electronics Engineers ISO - International Organization for Standardization MWBP - Mobile Web Best Pratices NFR - Non-functional requirement QP Questão de pesquisa RF Requisito Funcional RNF Requisito Não Funcional SADT - Structured Analysis and Design Technique SD - Strategic Dependency SIG - Softgoal Interdependency Graphs SR - Strategic Rationale W3C - World Wide Web Consortium WAI - Web Accessibility Initiative WCAG - Web Content Accessibility Guidelines XML - Extensible Markup Language

17 17 Sumário 1 Introdução Contexto Identificação dos problemas Objetivos e contribuições Organização do trabalho Fundamentação teórica A acessibilidade Web Valores agregados com a acessibilidade Relação entre acessibilidade e usabilidade Diretrizes e normas para alcançar acessibilidade na web Guias da W3C Normas da Seção 508 e do emag Estratégias da Engenharia de Software para promover a Acessibilidade Web Engenharia de requisitos O uso de abordagens orientadas a metas Catálogos de RNFs Notação SADT Considerações finais sobre o Capítulo Catálogo dos requisitos de Acessibilidade Web Bases e definições para a criação do catálogo Parâmetros para a extração das informações do catálogo Vantagens na utilização do catálogo Considerações finais sobre o Capítulo Método para a elicitação dos requisitos de acessibilidade web Estrutura do método Atividade 1 - Análise sobre os requisitos funcionais Atividade 2 - Seleção dos requisitos para a acessibilidade Atividade 3 - Análise de conflito entre os RNFs Atividade 4 Geração de artefatos Exemplo demonstrativo do processo Considerações finais sobre o Capítulo Ferramenta Omnes Web Plataforma tecnológica Arquitetura da Ferramenta Omnes Web Módulo de Elicitação Módulo de Artefatos... 91

18 Módulo de Glossário Considerações finais sobre o Capítulo Estudo de caso Objetivo Planejamento do estudo de caso Etapa I: Elicitação Etapa II: Prototipação Etapa III: Análise da acessibilidade Execução do estudo de caso Execução da etapa de elicitação Execução da etapa de prototipação Execução da etapa de Análise da Acessibilidade Análises dos dados extraídos durante a execução das etapas do estudo de caso Dados extraídos na etapa de elicitação Dados extraídos da etapa de prototipação Dados extraídos da etapa de análise da acessibilidade Ameaças a validade Validade interna Validade externa Considerações finais sobre o Capítulo Trabalhos relacionados Conclusão Contribuições Limitações e trabalhos futuros Referências Apêndice A Questionário para categorização de perfil dos participantes da etapa de elicitação Apêndice B Questionário de pós-execução da etapa de elicitação Apêndice C Resumo do documento de requisitos do aplicativo para criação de galeria de fotos interativa Apêndice D Resumo do documento de requisitos do aplicativo para gestão de metas Apêndice E Checklist para controle de implementação dos requisitos Acessibilidade Web Apêndice F Análise sobre as respostas dos questionamentos de 7 a 10 da 3º parte do questionário de pós-execução da etapa de elicitação

19 19 Apêndice G Análise sobre as respostas dos questionamentos da 4º parte do questionário de pós-execução da etapa de elicitação Apêndice H Questionário para categorização do perfil dos participantes da etapa de prototipação Apêndice I Questionário para categorização do perfil dos participantes da etapa de Análise da Acessibilidade Apêndice J Questionário de pós-execução dos participantes da etapa de Prototipação Apêndice L Roteiro de tarefas do projeto Apêndice M Roteiro de tarefas do projeto Apêndice N Questionário de avaliação da Acessibilidade Web dos aplicativos 204

20 20 1 Introdução Presenciamos nos últimos anos um crescimento exponencial do acesso a rede mundial de computadores, a integração da Internet em nossa sociedade está consolidando um fenômeno conhecido como computação onipresente. Estamos vinculando cada vez mais nossas tarefas cotidianas e de lazer ao uso de tecnologias disponibilizadas através de dispositivos conectados a Internet. Esse crescente interesse pela Internet está vinculado à diversificação de produtos e serviços que vêm sendo disponibilizados. Atualmente, entre diversas opções, podemos efetuar desde pesquisas escolares até compras online. Outro fator intimamente relacionado com o aumento do acesso à web é o surgimento das redes sociais. Este fato revolucionou a forma de interação entre as pessoas, criando novas possibilidades de comunicação. Por fim, a rápida capacidade de adaptação e evolução destes variados serviços viabiliza o domínio que a web vem exercendo em nossa sociedade. Infelizmente, essa evolução não veio acompanhada por uma conscientização em relação ao nível adequado do acesso sobre o conteúdo disponibilizado. Com o passar do tempo, a apresentação do conteúdo em páginas da web mudou radicalmente, saindo de um contexto onde as informações eram basicamente textuais, para o uso de novas formas de comunicação, tais como: o uso de efeitos gráficos, sons e vídeos (Power, C.; Petrie, H., 2007). Na medida em que os sites ou aplicações web foram preenchidos com páginas mais sofisticadas, envolvendo layouts mais ricos e atraentes, os usuários que possuem algum tipo de limitação (visual, auditiva, entre outras) foram prejudicados em relação ao acesso às informações disponibilizadas (Hanson, V. L.; Richards, J. T., 2003). Isso ocorre porque muitos sites e aplicações web não possuem estruturas adequadas ou alternativas que possam tratar a inclusão digital dessas pessoas. Visando resolver esse problema, surgiram trabalhos voltados para a definição dos requisitos de Acessibilidade Web. As ações mais importantes partem da W3C (World Wide Web Consortium). Essa instituição, através de sua iniciativa para acessibilidade na web (Web Accessibility Initiative), desenvolveu guias para conduzir o

21 21 desenvolvimento de sites e aplicações web (W3C-WAI, 2013). A acessibilidade, em um contexto mais amplo, significa possibilitar que pessoas com algum tipo de limitação participem de atividades que incluem o uso de serviços ou produtos (Brasil, 2013). De acordo com o banco mundial (World Bank, 2013), estima-se que cerca de um bilhão de pessoas, ou 15% da população mundial, têm algum tipo de limitação. Já o conceito de Acessibilidade Web, se refere ao direito de acesso às informações e a possibilidade de eliminação de barreiras arquitetônicas, facilitando o acesso físico a equipamentos e programas adequados, através da disponibilidade de conteúdos em formatos alternativos (Acesso Brasil, 2013). A acessibilidade web se relaciona com o design de sites e aplicações web, onde a elaboração de produtos e serviços para a Internet deve seguir padrões que possibilitem o acesso por todos (W3C-WCAG, 2013; Section 508, 2013). Dessa forma, a acessibilidade é um atributo essencial para a qualidade de uma aplicação Web. E considerar os atributos de qualidade já durante os estágios iniciais do desenvolvimento pode garantir que mudanças ou evoluções necessárias ao produto ocorram de forma sistemática (ISO-IEC/42010, 2007). Esta dissertação, através da Engenharia de Software, visa o desenvolvimento de uma estratégia que dê suporte a elaboração de produtos e serviços web mais acessíveis. Para isso, a ideia é a criação de um processo e uma ferramenta para o apoio à elicitação de requisitos de acessibilidade Web. As subseções a seguir abordam o contexto, motivação, problemas e objetivos para esta pesquisa. 1.1 Contexto A atenção para a acessibilidade Web vem aumentando nos últimos anos e podemos atribuir esse acontecimento a vários fatores, tais como: a responsabilidade legal, que se concretiza com leis e normas que determinam a prática da acessibilidade para produtos e serviços (Jaeger, 2006; Jaeger, 2008); a conscientização dos profissionais envolvidos com o desenvolvimento web, que contribui com a qualidade dos conteúdos disponibilizados; o desenvolvimento de princípios envolvendo ética e inclusão digital; e a atenção do mercado para o potencial desse público. Esses fatores fundamentam a necessidade de se trabalhar a acessibilidade

22 22 nos projetos de software. Para o tratamento da acessibilidade web surgiram pesquisas relacionadas ao desenvolvimento de tecnologias assistivas como, por exemplo, a adaptação de conteúdo de forma dinâmica (Hanson, V. L.; Richards, J. T., 2003), sem que haja a necessidade de reescrever a aplicação original. Existem também estudos sobre as adaptações efetuadas diretamente em browsers (Hanson et al., 2005) e ferramentas para testes e manutenção (Brajnik, 2004). Esta dissertação trata a acessibilidade como um atributo essencial para o sucesso de um site ou aplicação Web. Assim sendo, este trabalho visa à elaboração de uma estratégia através da engenharia de requisitos para prover a acessibilidade, tendo em vista que o sucesso de um produto está intimamente relacionado com a especificação de seus requisitos (Nuseibeh, B.; Easterbrook, S., 2000). Com foco na Engenharia de Software, alguns trabalhos relacionados a esta pesquisa como Cysneiros (2007) e Baguma et al. (2009), envolvendo o uso de catálogos de RNFs e a integração da acessibilidade com requisitos funcionais, contribuem para a elaboração do método de elicitação proposto. A primeira pesquisa chamou a atenção para a eficácia de se abordar RNFs com o uso de abordagens orientadas a metas. Na segunda pesquisa a ideia de considerar os requisitos de acessibilidade já durante a fase de elicitação, se tornou uma das estratégias presentes nesta dissertação. 1.2 Identificação dos problemas Nos últimos anos, estudos apontam que os problemas de acessibilidade em sites e aplicações Web persistem ao longo do tempo. Análises em sites governamentais, relatadas por Potter (2002) e Fagan (2004), e estudos de avaliação em larga escala, realizados por Lopes et al. (2010) e Costa et al. (2013) indicam um baixo nível de acessibilidade na maioria dos sites considerados. Essa persistente falta de acessibilidade na web pode está relacionada ao momento ou a fase em que este requisito é tratado dentro do processo de desenvolvimento (Dias et al., 2010). Para Martín et al. (2011) na maioria dos casos, a acessibilidade é considerada um problema de programação ou tratada quando o aplicativo já está totalmente desenvolvido. E em consequência desse fato, o processo

23 23 tardio de tornar um site ou uma aplicação Web acessível, geralmente ocasiona um retrabalho significativo, aumentando custos com novas análises para recodificação, o que pode estar totalmente fora do escopo e do orçamento do projeto. Dado que o problema de acessibilidade na web persiste ao longo dos anos, e uma das causas identificadas para esta limitação é o tratamento tardio deste atributo dentro do projeto de desenvolvimento. Esta dissertação procura considerar a acessibilidade em atividades iniciais do processo de desenvolvimento, mais especificamente durante a atividade de elicitação dos requisitos, visando garantir desde o inicio a qualidade para o nível de acesso ao produto. 1.3 Objetivos e contribuições Tendo em vista a necessidade de promover a inserção do requisito de acessibilidade em atividades iniciais do desenvolvimento de sites e aplicações web, o objetivo desta pesquisa é desenvolver um método e uma ferramenta de apoio para a elicitação de requisitos de Acessibilidade Web. Esse método é baseado na definição e utilização de um catálogo de RNFs para o domínio da Acessibilidade Web, elaborado com o NFR Framework (Chung et al., 2000). E a ferramenta de apoio visa automatizar o reuso dos requisitos contidos nesse catálogo, dessa forma visamos apoiar engenheiros de requisitos na geração dos seguintes artefatos: novas versões do catálogo sobre a acessibilidade baseadas na análise dos RFs específicos de uma aplicação; catálogos de correlações; e checklists para controle de implementação dos requisitos de Acessibilidade Web. Como objetivos específicos, destacam-se os seguintes: Definir um catálogo de requisitos de acessibilidade web baseado nas diretrizes da W3C. Isso significa modelar o requisito de acessibilidade, estabelecendo qual a relação existente entre metas e metas flexíveis para alcançar tal requisito, bem como qual o contexto em que cada requisito é definido e empregado. Este catálogo é um importante artefato de entrada para o método proposto, pois servirá como repositório de alternativas a serem consideradas para alcançar a Acessibilidade Web, além de conter uma base de conhecimento sobre os impactos identificados entre os RNFs presentes no catálogo;

24 24 Tornar o processo de reuso de requisitos do catálogo de acessibilidade mais ágil, uma vez que na medida em que estes artefatos vão representando mais informações, o procedimento de selecionar alternativas se torna mais difícil, lento e suscetível a omissões. Automatizar a extração das informações contidas neste catálogo, visando otimizar o tempo gasto para o método de elicitação; Definir artefatos que apoiem a equipe de desenvolvimento na implementação dos requisitos elicitados. Nesse sentido, o método e a ferramenta geram como saída os seguintes artefatos: Checklist para controle de implementação dos requisitos de Acessibilidade Web, catálogo de requisitos de Acessibilidade Web, e catálogo de correlações entre os RNFs, que contém os impactos detectados entre os requisitos. Planejar e realizar estudos de casos para avaliar o uso do catálogo de RNFs definido, assim como o método e a ferramenta propostos. Dessa forma, as principais contribuições desta dissertação são as seguintes: Definição de um catálogo de requisitos para alcançar a acessibilidade na web com base nas normas da W3C. Esse catálogo representa o ponto de partida para analisar-se como o requisito não-funcional de acessibilidade afeta e é afetado por outros requisitos não-funcionais;criação de um método para elicitação dos requisitos que considerem a acessibilidade na web. Com isso, almeja-se que o requisito de acessibilidade seja pensado desde o início do processo de desenvolvimento ao invés de ser postergado para quando a aplicação já está pronta, ou em fases tardias; Criação de uma ferramenta para automação do método de elicitação, agilizando e facilitando as tarefas de levantamento e análise dos requisitos para acessibilidade. Definição de um estudo de caso, afim de promover a discussão de dados qualitativos e quantitativos resultantes do uso do método e da ferramenta comparado a não usá-los. Promover também a discussão sobre como programadores usam as especificações de acessibilidade e como as aplicações implementadas espelham, ou não, tais especificações. Com essas contribuições, busca-se que o tratamento da acessibilidade ocorra cedo no processo de desenvolvimento e que seja de forma sistematizada e apoiada

25 25 por ferramenta. 1.4 Organização do trabalho Além deste capítulo introdutório, este documento está organizado da seguinte forma: No Capítulo 2 é mostrada a fundamentação teórica que serviu de base para elaboração desta dissertação, envolvendo conceitos sobre Acessibilidade Web, o tratamento deste requisito através da Engenharia de Requisitos, e conceitos sobre abordagens orientadas a metas. O Capítulo 3 apresenta detalhes sobre a criação do catálogo de requisitos de Acessibilidade Web. O Capítulo 4 apresenta o método de elicitação proposto, explicando o funcionamento de cada uma das atividades contidas para o levantamento de requisitos de Acessibilidade Web. O Capítulo 5 apresenta a ferramenta Omnes Web, desenvolvida para dar suporte ao método de elicitação desenvolvido. No Capítulo 6 é mostrado um estudo de caso, elaborado para avaliar os impactos causados pela utilização do método e sua ferramenta de apoio, a Omnes Web, nas atividades de análise e especificação de requisitos. No capítulo 7 são abordados os trabalhos relacionados com esta pesquisa. Finalmente o Capítulo 8 apresenta a conclusão e os trabalhos futuros.

26 26 2 Fundamentação teórica Este Capítulo apresenta alguns conceitos que serviram de base para o desenvolvimento desta pesquisa, a saber: acessibilidade; engenharia de requisitos; estratégias orientadas a metas para elicitar requisitos, e a notação SADT (Structured Analysis and Design Technique) que foi utilizada para explicar o método de elicitação elaborado. Refletimos também sobre a importância da acessibilidade e as relações entre acessibilidade e usabilidade, e acessibilidade e engenharia de software. 2.1 A acessibilidade Web De acordo com o guia da ISO (ISO/IEC, 2001) o design voltado para a acessibilidade é o design centrado no princípio de estender qualquer projeto para as pessoas com algum tipo de limitação. Como princípio base visa possibilitar que pessoas com algum tipo de problema físico participem de atividades que incluem o uso de serviços ou produtos (Brasil, 2013). No contexto da web esse requisito se relaciona ao design de sites ou aplicações web, e representa a necessidade de criar produtos e serviços para todos os tipos de limitações que os usuários possam vir a apresentar (W3C-WCAG, 2013). A idéia é maximizar o número de clientes potenciais que possam usufruir de um produto ou um serviço web (Wegge, K. P.; Zimmermann, D., 2007). De acordo com Paddison e Englefield (2002) a acessibilidade pode ser dividida em duas áreas: acessibilidade técnica e acessibilidade utilizável. Acessibilidade técnica corresponde às boas práticas dentro da engenharia de software, por exemplo, o correto uso do atributo "alt" na tag img de HTML. Ferramentas automatizadas, como TAW (TAW, 2013), geralmente são utilizadas para o teste de acessibilidade técnica. Acessibilidade utilizável está relacionada com princípios de usabilidade como, por exemplo, o suporte existente para as tarefas do usuário, navegação consistente, entre outros.

27 Valores agregados com a acessibilidade Sierkowski (2002) e Paddison e Englefield (2002) defendem que o valor da acessibilidade vai além da aplicação de diretrizes e recomendações, e assim definem as seguintes perspectivas: Perspectiva ética: refere-se à conscientização da sociedade para a inclusão digital de pessoas com alguma limitação física, mostrando a importância de tornar estes indivíduos independentes no uso de tecnologias. Portanto, tornar as informações e serviços acessíveis na web é uma maneira de ajudar essas pessoas a alcançarem sua independência. Perspectiva legislativa: as questões envolvendo a acessibilidade começaram a ganhar importância graças a introdução de novas leis, ou adaptação de legislações existentes, incentivando as organizações a produzirem produtos e serviços mais acessíveis. Nos EUA, por exemplo, o governo exige que todos os sites ou aplicações web que foram desenvolvidos, adquiridos, mantidos ou utilizados pelo governo federal devem ser acessíveis de acordo com as normas estabelecidas pela seção 508 (Section 508, 2013). Perspectiva de negócios: a quantidade considerável de pessoas com alguma limitação chamou a atenção do mercado, fazendo com que a indústria de software lançasse olhares diferenciados para esta parcela da sociedade. Custo beneficio à longo prazo: trabalhar a acessibilidade no projeto requer tempo, planejamento e pesquisa. Porém, a acessibilidade envolve o uso de tecnologias e design que tornam mais barato e ágil o gerenciamento do conteúdo (facilitando futuras migrações) em relação a modelos mais antigos que misturam seus conteúdos com a apresentação. Acessibilidade incentiva tarefas como separar a apresentação do conteúdo, através da utilização de folhas de estilo, permitindo maior flexibilidade na implementação.

28 Relação entre acessibilidade e usabilidade De acordo com a taxonomia proposta por Alonso et al. (2009), o atributo de acessibilidade é um refinamento de usabilidade partindo do princípio da operabilidade, como mostra a Figura 1. Figura 1 - Princípio de operabilidade da usabilidade. Fonte: (Alonso et al., 2009) Para Moreno et al. (2008), além de tornar um site acessível é preciso também analisar fatores de utilização do mesmo. Para isso é preciso garantir que os bons princípios de usabilidade sejam aplicados como, por exemplo, a facilidade no uso, o apoio para as tarefas do usuário, entre outros (Paddison, C.; Englefield, P., 2002). Dessa forma, não é suficiente seguir somente as normas ou recomendações sobre acessibilidade, é necessário alinhá-las com análises sobre a usabilidade do produto. É preciso também considerar os diferentes perfis de usuários, entendendo suas necessidades específicas, dentro de um processo de design centrado no usuário. 2.2 Diretrizes e normas para alcançar acessibilidade na web A maioria das pesquisas relacionadas a acessibilidade Web seguem padrões de desenvolvimento fornecidos pela W3C ou normas técnicas contidas na seção 508 (Hanson, V. L.; Richards, J. T., 2003). As subseções a seguir mostra um resumo do

29 29 WCAG (Web Content Accessibility Guidelines) propostos pela W3C, e também apresenta as normas da seção Guias da W3C 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 (Web Accessibility Initiative) 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

30 30 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: o 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; o 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 1 mostra os 4 princípios que englobam as 12 diretrizes do WCAG 2.0. 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.

31 31 Tabela 1 - Princípios do WCAG 2.0. Fonte: (W3C-WCAG 2.0, 2013) Princípios Perceptível Operável Compreensível Robusto Diretrizes contidas 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. 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. 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. Maximizar a compatibilidade entre os atuais e futuros agentes do usuário, incluindo as tecnologias assistivas MWBP 1.0 O MWBP 1.0 especifica as melhores práticas para o desenvolvimento de aplicações para dispositivos móveis. O principal objetivo é aprimorar a experiência do usuário no acesso ao conteúdo web, quando este for acessado por dispositivos móveis (MWBP 1.0, 2013). O MWBP 1.0 aborda 5 temas contendo declarações de boas práticas para o desenvolvimento, a Tabela 2 mostra esses temas e de forma resumida cita as melhores práticas envolvidas.

32 32 Tabela 2 - Princípios da MWBP 1.0. Fonte: (W3C-MWBP 1.0, 2013) Temas Comportamento geral Navegação e links Layout de página e conteúdo Definição de página Entradas do usuário Melhores práticas envolvidas Consistência temática, onde o conteúdo deve ser acessível por uma variedade de dispositivos; Exploração da capacidade dos dispositivos; Resolução de implementações problemáticas; Efetuar testes e simulações em diferentes plataformas, etc. Permissão de entradas curtas de URL; Facilidade para se alcançar os objetivos durante a navegação; Prover mecanismos de navegação consistentes; Fornecimento de teclas chaves; Evitar a utilização do mapa de imagens; Evitar refresh e abertura de páginas em novas abas, etc. Adaptação do conteúdo para o contexto mobile; Usar linguagens claras; Gerenciamento do tamanho das páginas; Limitar direções para navegação; Evitar o uso de imagens pesadas; Gerenciar o uso de cores. Fornecimento de títulos curtos para as páginas; Evitar o uso de frames; Evitar o uso de Tabelas (a menos que se garanta que o dispositivo tenha suporte); Prover alternativas textuais para conteúdos não textuais; Uso de folhas de estilos para layout e apresentação; Evitar uso de tipos de documentos não suportados pelos dispositivos; Fornecer mensagens de erros informativos, etc. Gerenciar o numero de entradas por teclas; Gerenciar a entrada de textos livres; Fornecer valores padrões para seleção; Utilizar máscaras ou textos padronizados para entradas do usuário; Fornecimento de controles de formulários, etc Normas da Seção 508 e do emag Em 1986 a Seção 508 foi adicionada como uma emenda à lei americana para reabilitação de 1973 (Section 508, 2013). As normas desta seção atuam no tratamento do acesso a tecnologias eletrônicas e informações. A Seção 508 não obriga que sites privados estejam de acordo com as normas estabelecidas, a menos que eles estejam recebendo verbas federais ou têm contrato de serviços vinculados a uma agência federal. Com o passar do tempo, essa lei sofreu alterações, passando a englobar também outras recomendações de boas práticas como, por exemplo, as recomendações contidas no WCAG da W3C. O diferencial da Seção 508 em relação

33 33 ao WCAG é que as normas de acessibilidade presentes em seus documentos devem ser verificadas tanto para o desenvolvimento de hardware como também de softwares ou web sites, enquanto que o WCAG estabelece padrões e diretrizes voltados apenas para o contexto da web. Em 2005 surge no Brasil o emag (Modelo de Acessibilidade de Governo Eletrônico), esse documento reúne as contribuições de profissionais especialistas e as novas pesquisas na área de Acessibilidade Web (Governo Eletrônico, 2014). O emag foi criado através da parceria entre o Departamento de Governo Eletrônico, da Secretaria de Logística e Tecnologia da Informação (SLTI) do Ministério do Planejamento e o Instituto Federal do Rio Grande do Sul (IFRS). Assim como a Section 508, o emag também é baseado nas recomendações do WCAG 2.0, da W3C. Em 2007, o governo federal torna obrigatória a implementação das recomendações contidas no documento em sites e portais do governo. 2.3 Estratégias da Engenharia de Software para promover a Acessibilidade Web A acessibilidade nos últimos anos vem ganhando importância e sendo cada vez mais avaliada dentro do contexto de engenharia de software. Estratégias para elicitação de RNFs tais como as abordagens orientadas metas, visam aprimorar o tratamento desse tipo de atributo dentro do processo de desenvolvimento. As subseções a seguir abordam as estratégias de Engenharia de Requisitos que foram adotadas por esta pesquisa, e como elas podem auxiliar no processo de elicitação de RNFs, tal como a Acessibilidade Web Engenharia de requisitos Antes de analisar os processos de engenharia de requisitos, é necessário compreender alguns conceitos básicos sobre os requisitos. Os requisitos de software podem ser compreendidos como um conjunto de condições ou capacidades necessárias que o sistema deve possuir, obedecendo as suas limitações e restrições, além de características não ligadas diretamente às funções desempenhadas pelo software (Sommerville, 2003).

34 34 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. A engenharia de requisitos envolve a compreensão sobre variados fatores, tais como Sommerville (2003): 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. 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. Esta pesquisa de dissertação trabalha diretamente com a atividade de elicitação dos requisitos. Essa atividade é composta por tarefas que possibilitam a compreensão dos objetivos, assim como as motivações para a construção de um sistema de software O uso de abordagens orientadas a metas A estratégia da Engenharia de Requisitos adotada por esta pesquisa engloba o uso de Abordagens orientadas a metas, que são caracterizadas pela construção de modelos intencionais, onde podemos definir e refinar as metas que os usuários possuem em relação ao sistema a ser desenvolvido (Mylopoulos et al., 1999). No

35 35 contexto desta dissertação as metas compreendem os RNFs, onde a meta mais abstrata a ser alcançada será a acessibilidade. A abordagem orientada a metas utilizada por esta pesquisa é o NFR framework, que é uma abordagem onde os requisitos não funcionais 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: o Refinamentos de metas suaves utilizando AND e OR, onde o elemento de contribuição AND obriga a implementação do refinamento, enquanto no caso do elemento OR, esta implementação é opcional. o Contribuição entre metas suaves, podendo ser negativas e positivas, apresentando possíveis soluções para a satisfação do objetivo. o Alegação (Claim) para considerar uma meta suave e respectivas operacionalizações. O NFR Framework contribui para que os desenvolvedores tratem os requisitos não funcionais, auxiliando a expressá-los sistematicamente, servindo como base para guiar o processo de elicitação de forma racional. Para isso, o NFR Framework utiliza uma representação gráfica chamada Softgoal Interdependency Graphs (SIGs). Essa estrutura permite armazenar e tratar as alternativas levantadas para alcançar a implementação dos RNFs, levando em consideração o contexto da aplicação. A Figura 2 mostra um exemplo básico de um SIG do NFR Framework, nessa estrutura é mostrado o requisito não funcional de usabilidade e as possibilidades para sua operacionalização.

36 36 Figura 2 - Exemplo de um SIG baseado na abordagem NFR Framework No exemplo da Figura 2, a meta suave usabilidade foi refinada ou decomposta em outras duas metas suaves, Cognoscibilidade e Operabilidade. Por sua vez, para estas novas metas suaves foram criadas operacionalizações a serem implementadas como, por exemplo, no caso da Cognoscibilidade foi criada a operacionalização Fornecer interface amigável com feedback para cada ação do usuário. A premissa do NFR framework diz que as decisões devem ser baseadas em argumentos bem justificados (Chung et al., 2000), nesse contexto o elemento de alegação é o responsável direto para indicar a razão (rationale) por trás de algumas decisões tomadas. Outra abordagem que faz parte do contexto orientado a metas é o framework i* (i-estrela), proposto por Yu em (Yu, 1995) e trata a modelagem intencional de software, especificamente na fase de requisitos, considerando contextos organizacionais. Essa abordagem permite a análise dos relacionamentos de dependência entre os atores, facilitando a compreensão sobre os relacionamentos organizacionais, analisando os vários agentes que fazem parte do ambiente em questão. No i*, há a ideia de componentes conhecidos como atores, de acordo com Yu (1995), atores são entidades ativas que efetuam ações para alcançar metas através

37 37 do exercício de suas habilidades e conhecimentos, podendo ter dependências intencionais entre si. Além dos atores, os elementos básicos que compõe o i* são: Metas: representados pelos objetivos que os atores possuem em relação as funcionalidades do sistema; Tarefas: são as ações que os atores podem realizar dentro da organização para atingir suas metas; Metas suaves ou flexíveis: são qualidades ou situações desejáveis, geralmente são referenciados como requisitos não funcionais do sistema. Estas metas não possuem critérios claros para sua satisfação, ou seja, são subjetivas e dependentes dos pontos de vista dos stakeholders. Assim como o NFR Framework, o framework i* também é composto por variados elos de associações entre os atores i*, tais como: é parte de, é um, desempenha e ocupa. Há também as dependências estratégicas entre atores e elos que relacionam com o cumprimento das metas, chamados de elos meio-fim. O framewok i*, como originalmente proposto por Yu (1995), usa dois modelos, sendo estes: Modelo SD (Strategic Dependency) e Modelo SR (Strategic Rationale). A Figura 3 ilustra um exemplo do modelo SD do framework i*. Figura 3 - Exemplo de um modelo SD do framework i* No exemplo da Figura 3 é mostrada uma situação sobre pagamento de contas, envolvendo os atores Cliente e Banco. Nesse modelo o cliente deseja efetuar pagamentos de contas diversas e para atingir essa meta, duas tarefas são definidas para possibilitar esses pagamentos, sendo estas: Usar débito automático e Usar

38 38 cartão de crédito. A tarefa Usar débito automático ajuda na meta flexível Prevenção contra atrasos, já a segunda tarefa Usar cartão de créditos auxilia Gerenciar dívidas, ambas ainda auxiliam uma terceira meta flexível chamada Conveniência. No contexto do ator Banco existe uma meta que é Obter novos clientes e para alcançá-la existem duas tarefas, sendo estas: Oferecer serviço de débito automático e Oferecer cartão de crédito. A primeira tarefa auxilia na meta Aumentar comodidade do cliente, a segunda ajuda a Aumentar lucros. Na interação entre esses dois atores, suas tarefas dependem de dois recursos, o primeiro é o Cartão de crédito e o segundo é Serviço de débito automático. Além de utilizar elementos gráficos em forma de nuvens para indicar os componentes, a representação SIG do NFR Framework possui outras diferenças em relação aos modelos existentes no i* (Chung et al., 2000; Lamsweerde, 2001), tais como: a ausência do elemento ator; as operacionalizações no i* são abordadas pelas tarefas (elemento gráfico hexágono), já no NFR framework é utiliza-se a notação de nuvens com bordas em negrito indicando formas de refinamentos para as metas suaves; e a existência de elementos de argumentação que representam as alegações, oferecendo noções sobre o rationale da estrutura. Em resumo tanto a abordagem i* como o NFR Framewok permitem ao engenheiro de requisitos a elaboração e manutenção de catálogos de requisitos não funcionais, permitindo assim trabalhar as decisões através de análises sobre os impactos apresentados entre os requisitos do sistema. Essas abordagens permitem também que os aspectos de subjetividade e interatividade, relacionados aos atributos de qualidades de um software, sejam mais compreensíveis Catálogos de RNFs A estratégia proposta nesta pesquisa faz uso das abordagens orientadas à meta através da utilização de catálogos para elicitação de requisitos não funcionais. A criação do catálogo de requisitos de acessibilidade Web, a ser usado nesse trabalho obedeceu às regras gerais dos modelos presentes no NFR Framework mostrado anteriormente.

39 39 De acordo com Cysneiros (2007), a utilização destes catálogos aliados a um processo bem definido pode auxiliar o engenheiro de requisitos a tratar quaisquer atributos de qualidade do sistema, uma vez que estes catálogos tratam questões como formas de operacionalizações e análise de conflitos entre os RNFs. A Figura 4 mostra parte de um catálogo criado para a usabilidade baseado no framework i* (Cysneiros, 2007). Figura 4 - Parte do catálogo de usabilidade. Fonte: (Cysneiros, 2007) Em relação ao NFR Framework, além da possibilidade de criar catálogos de RNFs, essa abordagem também oferece a possibilidade de elaborar catálogos de métodos e correlações. A Figura 5 mostra o exemplo de um catálogo de métodos extraído a partir do catálogo de acessibilidade Web criada para esta dissertação.

40 40 Figura 5 - Exemplo de um catálogo de métodos do NFR Framework Na Figura 5 temos a meta suave de Acesso a conteúdo não textuais, que foi refinada em Fornecimento de alternativas textuais para todo conteúdo não textual, para este ultimo refinamento foram relacionadas 4 métodos (técnicas) para operacionalização, sendo essas: Substituir conteúdo não textual por textos, Utilizar alternativas textuais curtas ou longas, Utilizar atributo alt para descrição de imagens e Utilizar labels para associar a controle de formulários. Os catálogos de RNFs devem ser encarados como guias para os engenheiros de requisitos, uma vez que trabalhar com a noção de metas para alcançar determinado atributo de qualidade pode facilitar o trabalho de elicitação, fornecendo maior controle e entendimento sobre o que precisa ser implementado. A análise de conflitos e refinamentos presentes no i* e NFR Framework consolidam o apoio durante a fase de elicitação da engenharia de requisitos. 2.4 Notação SADT Para representar o método de elicitação, foi utilizada a notação SADT (Structured Analysis and Design Technique), devido a sua estrutura possuir elementos que permitem compreender como as atividades de um processo se comportam para produzir um determinado resultado, além de controles que determinam este

41 41 resultado (Ross, D. T.; Schoman, K. E., 1977). O elemento básico do SADT é a caixa, que pode ser usada para a representação de uma atividade ou de um dado. A Figura 6 mostra o elemento caixa do SADT. Figura 6 Caixa do SADT Como mostra a Figura 6, existem quatro setas que se ligam a caixa SADT, sendo elas: Setas de entrada: representam para a atividade os dados que serão processados ou consumidos. Setas de controle: indicam as variáveis que governam a maneira pela qual as transformações ocorrem dentro da atividade. Setas de mecanismo: representam qualquer agente que participa da execução da atividade como, por exemplo, pessoas, recursos, hardwares. Setas de saída: compreendem os resultados que são produzidos pela atividade, estas saídas servem de entradas para outras atividades. 2.5 Considerações finais sobre o Capítulo Neste capítulo, foi apresentada uma visão geral dos principais conceitos usados como base para a criação do método de elicitação proposto nesta dissertação. A abordagem inicial envolveu a compreensão sobre o domínio da Acessibilidade Web, descrevendo os conceitos e valores que são agregados a este atributo de qualidade, assim como sua relação com a usabilidade de um site ou aplicação Web. Ainda sobre o domínio da Acessibilidade Web, a análise sobre o WCAG permitiu compreender como esse requisito pode ser alcançado, e como seu conteúdo seria melhor adaptado junto as estratégias de Engenharia de Software adotadas por esta pesquisa. Vale ressaltar que o problema da falta de acessibilidade em sistemas Web, como discutido na Seção 1.2, está diretamente relacionado ao momento em que

42 42 este atributo é tratado dentro do processo de desenvolvimento. Assim sendo, este capítulo também descreveu brevemente o domínio das abordagens orientadas a metas, que são estratégias de Engenharia de Requisitos que podem ser utilizadas já nas atividades de análise e especificação de requisitos de software. O NFR Framework, que foi a estratégia selecionada por esta pesquisa, permite-nos modelar, analisar e reusar requisitos através da estrutura de catálogos de RNFs. Por meio desses catálogos de RNFs, se torna possível a criação de um domínio de conhecimento comum sobre as alternativas para se alcançar um determinado requisito. Nesse contexto, o requisito a ser tratado nesta pesquisa é a Acessibilidade Web, onde tratamos este atributo como uma meta a ser atingida. Por fim, este capítulo apresentou a notação SADT, utilizada para descrever sistematicamente as atividades contidas no método de elicitação e no estudo de caso elaborado por esta pesquisa.

43 43 3 Catálogo dos requisitos de Acessibilidade Web apresentadas nas figuras 7, 8, 9 e 10, correspondendo aos 4 princípios de A criação do catálogo tem como objetivo a definição de uma base de conhecimento para o domínio dos requisitos de Acessibilidade Web. A ideia é a criação de uma estrutura que possa servir de guia para análise e reuso durante a elicitação dos requisitos de Acessibilidade Web. Para a criação do catálogo, utilizado pelo método e a ferramenta Omnes Web, utilizamos a ferramenta STARUML (STARUML, 2013), com o auxilio do plugin RE- Tools (Supakkul, S.; Chung, L, 2012). Além da criação de catálogos de RNFs, essa ferramenta permite também desenhar modelos de UML (Unified Modeling Language), e possui características que foram importantes para sua escolha, tais como: fácil utilização, interface amigável, flexibilidade para importação e exportação de projetos, através de arquivos XML, rápido desempenho. Neste capítulo abordamos como identificamos e modelamos as informações do catálogo de requisitos de acessibilidade web. A versão atual do catálogo contém 260 elementos, sendo 186 operacionalizações e 74 metas suaves (Softgoals). Os elementos do catálogo estão organizados em 5 níveis, que serão explicados a seguir, na seção 3.1. Devido ao tamanho do catálogo, dividimos sua exibição em 4 partes, acessibilidade de acordo com o WCAG 2.0 (Veja seção ). Mesmo com essa divisão a compreensão desse artefato talvez não seja totalmente possível, devido à resolução das imagens. Assim para a melhor visualização e compreensão, o catálogo está disponível no seguinte endereço:

44 Figura 7 - Elementos do catálogo relacionados ao princípio Perceptível do WCAG

45 Figura 8 - Elementos do catálogo relacionados ao princípio Operável 45

46 Figura 9 - Elementos do catálogo relacionados ao princípio Compreensível 46

47 47 Figura 10 - Elementos do catálogo relacionados ao princípio Robustez Os elementos do catálogo estão organizados em 5 níveis, que serão explicados a seguir na seção 3.1. Além disso, abordamos como identificamos e modelamos as informações do catálogo de requisitos de acessibilidade web. 3.1 Bases e definições para a criação do catálogo O catálogo de RNFs utilizado pelo método proposto por esta dissertação foi criado com base nas diretrizes do WCAG 2.0. A documentação contida nesse guia foi estudada e usada como fonte para a modelagem da estrutura orientada a metas do catálogo, obedecendo as regras do NFR Framework. O primeiro passo na criação do catálogo foi a definição da Acessibilidade Web como uma meta a ser atingida. Logo em seguida, através do estudo sobre os padrões de acessibilidade fornecidos pela W3C e leis, como a Section 508, foi possível identificar uma estrutura a ser seguida. É nesse contexto que entra o WCAG proposto pela W3C. O WCAG é considerado o padrão oficial para produção de conteúdo web em vários países (Seção ). Sua documentação é de fácil compreensão e contém uma série de boas práticas para a implementação dos requisitos de Acessibilidade Web. Por esse motivo, escolhemos o WCAG em sua versão 2.0, que é a mais atual, para a modelagem do catálogo de RNFs aqui proposto.

48 48 Dessa forma, a estrutura fornecida pelo WCAG 2.0, contendo uma hierarquia dos elementos de Acessibilidade, auxiliou na elaboração da estrutura e dos níveis a serem considerados no catálogo. A idéia de agrupar as diretrizes de Acessibilidade por princípios, contida no WCAG 2.0, foi adaptada para o contexto do NFR Framework. Assim, o catálogo inicialmente possuía requisitos divididos em 3 níveis, onde Acessibilidade foi estabelecida como o primeiro nível, os 4 princípios do WCAG 2.0 (veja tabela 1 da Seção ) foram definidos para o segundo nível, e as diretrizes foram alocadas no terceiro nível, sendo consideradas como refinamento dos princípios. Após mais análises, verificou-se que os critérios de sucesso da WCAG 2.0 (Seção ) poderiam ser adaptados para serem utilizados e classificados como refinamentos das diretrizes. Dessa forma, o quarto nível do catálogo passou a compreender os refinamentos das diretrizes. Por fim, faltava definir as informações de baixo nível do catálogo, ou seja, as operacionalizações dos requisitos de Acessibilidade, que representam as informações sobre técnicas ou idéias para a implementação de um determinado requisito. Essa definição ocorreu com base na análise de exemplos para a implementação de técnicas fornecidas pelo WCAG 2.0 (WCAG20-TECHS, 2014). As informações sobre as técnicas e respectivos exemplos de implementação foram catalogados e utilizados como operacionalização dos requisitos de Acessibilidade Web, contidos no catálogo. Assim, as operacionalizações passaram a compreender o quinto nível do catálogo de RNFs aqui proposto. A Figura 8, lado esquerdo, apresenta uma visão geral de como os elementos da WCAG 2.0 foram modelados no NFR framework. Na Figura 11, lado direito, exemplificamos o conteúdo associado a cada um dos níveis desse catálogo.

49 49 Figura 11 - (A) Estrutura do catálogo de RNFs; e (B) exemplos de conteúdo contido no catálogo. Como apresentado na Figura 11, a partir da meta suave de Acessibilidade até os princípios foram utilizadas as correlações de decomposição AND, indicando que cada desses requisitos são obrigatórios. A partir dos princípios até os requisitos contidos no quarto nível, foram utilizadas as decomposições AND e OR, indicando a possibilidade de escolha desses requisitos. No quinto nível do catálogo, foi possível definir suas operacionalizações, utilizando as correlações de contribuição. Além dos refinamentos de requisitos, utilizando as decomposições, algumas análises de impactos entre os RNFs foram estabelecidas no catálogo, como por exemplo, entre requisitos de segurança e os princípios de Acessibilidade (Seção 4.1.3), com base nas análises do autor desta dissertação. 3.2 Parâmetros para a extração das informações do catálogo Além das metas e respectivas operacionalizações contidas no catálogo, outras informações devem ser levadas em consideração. Essas informações são as limitações físicas apresentadas pelo público alvo da aplicação e a definição dos tipos de conteúdo que serão necessários aos requisitos funcionais da aplicação.

50 50 O objetivo de incluir essas informações é utilizá-las como parâmetros para a seleção dos elementos do catálogo. As limitações foram vinculadas aos requisitos do catálogo e os tipos de conteúdos foram vinculados às suas respectivas operacionalizações. A ideia é que essa estratégia possa facilitar a extração das informações, guiando os elicitadores na seleção dos requisitos e operacionalizações que realmente são relacionados ao contexto da aplicação para a qual o método de elicitação esteja sendo aplicado. Por exemplo, para uma aplicação onde o público alvo apresenta limitações visuais, então a idéia é que o elicitador consiga selecionar somente os requisitos relacionados à limitação apresentada. Esta dissertação leva em consideração 5 tipos de limitações físicas, sendo estas (Brasil Media, 2014): Visual, Auditiva, Cognitiva, Convulsões e Motora. No catálogo cada meta suave (Softgoal) equivale a um requisito de acessibilidade, e cada um desses requisitos foi vinculado ao tipo de limitação correspondente. Para isso, logo após a descrição dos requisitos foram colocados caracteres entre colchetes, correspondendo as primeiras letras do nome relacionado ao tipo de limitação física atendida pelo requisito de acessibilidade. A Tabela 3 mostra os tipos de limitações físicas e as letras utilizadas no catálogo. Tabela 3 - Tipos de limitações Limitações Visual Auditiva Cognitiva Convulsões Motora Letras [V] [A] [C] [CO] [M] As limitações Visual, Auditiva e Cognitiva foram refinadas para especificar qual o tipo específico de limitação apresentada pelo público alvo da aplicação. Já em relação as outras duas limitações, após análise verificou-se que não houve necessidade de refiná-las. Segue o refinamento das limitações (BrasilMedia, 2014): A limitação visual foi refinada em: Daltonismo, Baixa visão e Sem visão. A limitação auditiva foi refinada em: Perda Parcial e Perda total da audição. Já a limitação cognitiva foi refinada em: Déficit de memória, Déficit de atenção, Déficit de aprendizado e Déficit na resolução de problemas.

51 51 A Tabela 4 apresenta os tipos de limitações refinadas e suas respectivas letras utilizadas no catálogo. Tabela 4 - Refinamento das limitações Visual, Auditiva e Cognitiva Limitações Refinamento Letras Visual Daltonismo [D] Baixa Visão [BV] Sem Visão [SV] Auditiva Perda parcial [APP] Perda total [APT] Cognitiva Déficit de memória [CDM] Déficit de atenção [CDAT] Déficit de aprendizado [CDAP] Déficit na resolução de problemas [CDRP] Para os tipos de conteúdo, também foram 5 classificações, sendo estas: Texto, Imagem, Vídeo, Áudio e Animação. Essas classificações foram levantadas com base na análise do tipo de conteúdo abordado pelas técnicas do WCAG 2.0 (WCAG20- TECHS, 2014). Como já explicado esses tipos de conteúdos foram vinculados às tarefas que operacionalizam os requisitos de acessibilidade. E da mesma forma que foi feita para as limitações físicas, cada tipo de conteúdo foi representado no catálogo através de caracteres correspondentes as letras iniciais de seus respectivos nomes, como mostra a Tabela 5. Tabela 5 - Tipos de conteúdo Tipo do conteúdo Texto Imagem Vídeo Áudio Animação Letras [T] [I] [VI] [AU] [AN] A Figura 12 mostra um exemplo de como os elementos do catálogo encontram-se vinculados aos tipos de limitações e conteúdo.

52 52 Figura 12 - Exemplo de elementos do catálogo de RNFs vinculados aos tipos de limitações e conteúdo Como apresentado na Figura 12, o requisito Disponibilidade de linguagens de sinais está vinculado a limitação Auditiva de perda total, indicada pelas letras APT entre colchetes, e suas operacionalizações estão vinculadas ao tipo de conteúdo Vídeo, indicado pelas letras VI. Há operacionalizações no catálogo que não foram vinculadas a tipos de conteúdos, e sim à Componentes de Interface (CI), e após a descrição destes elementos vêm as letras CI entre colchetes. Esse tipo de vínculo foi criado por que alguns elementos do catálogo não se relacionam com tipos de conteúdo, e sim com estruturas comuns nas páginas, como botões ou links. Dessa forma, esses elementos informam o que deve ser feito, em relação a acessibilidade, quando um componente de interface for inserido na página. 3.3 Vantagens na utilização do catálogo A utilização do catálogo baseado no NFR Framework permitiu tratar a acessibilidade Web como uma meta a ser alcançada. Esse fato permitiu analisar e detalhar as alternativas para alcançar esse atributo, aumentando assim o conhecimento sobre o domínio desse atributo de qualidade. Outro ponto importante no uso de catálogos é a possibilidade de realizar análises dos relacionamentos entre os requisitos de acessibilidade Web com outros RNFs. Esse fato permite compreender e determinar quais situações podem impactar positivamente ou negativamente na implementação da acessibilidade. Além disso, outras vantagens foram percebidas na utilização do catálogo de RNFs de Acessibilidade, tais como:

53 53 fácil utilização, permite a documentação consistente dos requisitos de acessibilidade, promove a flexibilidade para resolução de conflitos, permite justificar cada decisão de elicitação tomada. Dessa forma, um catálogo contendo informações sobre o domínio da Acessibilidade Web, verificando os relacionamentos entre as alternativas consideradas, se torna um fator diferencial para tratar esse atributo já nas fases de elicitação e análise de requisitos do processo de desenvolvimento. 3.4 Considerações finais sobre o Capítulo Este capítulo apresentou detalhes sobre a criação do catálogo de requisitos de Acessibilidade Web, utilizado pelo método de elicitação aqui proposto. O objetivo da criação desse catálogo é disponibilizar uma base de conhecimento comum para o domínio dos requisitos de Acessibilidade Web. O guia para produção de conteúdo Web acessível da W3C, o WCAG 2.0, serviu de fonte para a modelagem da estrutura do nosso catálogo de RNFs. As análises efetuadas sobre o WCAG 2.0 facilitaram a compreensão sobre os requisitos de Acessibilidade, facilitando o processo de levantamento, assim como o procedimento de refinamentos sobre esses requisitos. Para viabilizar a extração das informações contidas no catálogo, adotamos a estratégia de vincular parâmetros aos requisitos e suas respectivas operacionalizações. Através desses parâmetros, os elicitadores poderão selecionar quais alternativas satisfazem as necessidades do projeto em questão. Esses parâmetros compreendem as limitações do público alvo, que foram vinculados aos requisitos do catálogo, e os tipos de conteúdos, que foram vinculados às operacionalizações. Entre outros fatores, destacamos a possibilidade do catálogo servir como um guia para os engenheiros de requisitos durante as atividades de análises e especificação de requisitos de Acessibilidade Web. Pois a utilização desse tipo de artefato permite tratar a acessibilidade como uma meta a ser alcançada. Dessa forma, podemos analisar e armazenar as alternativas consideradas para alcançar esse atributo de qualidade, aumentando assim o conhecimento sobre o domínio desse RNF.

54 54 Entretanto, apesar das vantagens detectadas, percebemos duas limitações na utilização do catálogo. A primeira limitação se relaciona com a utilização de siglas para vincular os parâmetros de seleção aos elementos do catálogo. Embora a estratégia de utilizar parâmetros facilite a extração de informações, entendemos que futuramente podem e devem surgir maneiras mais amigáveis de relacionar esses parâmetros aos requisitos e respectivas operacionalizações. Porém, no momento acreditamos ser esta a melhor opção. A segunda limitação, se refere a escalabilidade do catálogo de RNFs, pois percebemos que na medida em que esse artefato foi representando mais informações, a localização e seleção dos requisitos e operacionalizações se tornou mais lenta e difícil. As limitações citadas fundamentam a necessidade de utilizar estratégias que tornem mais viável a utilização desse tipo de artefato. Nesse contexto a definição de procedimentos sistematizados pode garantir um melhor aproveitamento do catálogo de RNFs. O capítulo a seguir aborda justamente a estratégia de elicitação elaborada por esta pesquisa, que agrupa um conjunto de atividades para viabilizar a elicitação de RNFs, tal como a Acessibilidade Web.

55 55 4 Método para a elicitação dos requisitos de acessibilidade web Tendo em vista a importância da Acessibilidade Web e a preocupação tardia em atender esse atributo dentro do processo de desenvolvimento, esta dissertação definiu um método para considerar este RNF já nas atividades de análise e especificação de requisitos. Esse método é semi-automatizado e baseia sua estratégia de elicitação na utilização de catálogos de RNFs. Envolvendo também uma análise sobre os requisitos funcionais levantados, visando a definição do tipo de conteúdo a ser acessado na aplicação. Essa definição leva em consideração as limitações apresentadas pelo público alvo do sistema. As seções a seguir descrevem o método de elicitação elaborado, sendo exemplificado através do sistema Agendador de reuniões (Lamsweerde et al., 1993). 4.1 Estrutura do método Uma visão geral do método de elicitação de requisitos para acessibilidade web é apresentada na Figura 13. Figura 13 - Visão geral do método de elicitação

56 56 Como apresentado na Figura 13, as informações de entrada para o processo compreendem a descrição do projeto, assim como os seus requisitos funcionais e requisitos não funcionais, e o catálogo de requistos de acessibilidade Web baseado na W3C. Essas informações são processadas para gerar como saída os seguintes artefatos: Checklist para controle de implementação dos requisitos de Acessibilidade Web, Versão final do SIG do produto, contendo os requisitos de Acessibilidade Web, e o catálogo de correlações entre os RNFs que contém os impactos detectados entre os requisitos. Para ocorrer a elicitação, há algumas variáveis envolvidas e precisam ser definidas. Estas variáveis serão os controles que guiam a seleção dos requisitos de acessibilidade. Como mostra a Figura 13, os controles compreendem as seguintes informações: a definição das limitações do público alvo, e a análise e resolução de possíveis conflitos entre as operacionalizações e outros RNFs. O primeiro controle refere-se a descrição das limitações apresentadas pelo público alvo da aplicação, tais como limitações visuais, auditivas, convulsões, cognitivas e motoras. O segundo controle refere-se à análise de impacto que as operacionalizações dos requisitos de acessibilidade possam ter sobre outros RNFs do sistema, tais como usabilidade, segurança, desempenho. Esta análise é importante para auxiliar na tomada de decisões, em situações de conflitos entre elementos do catálogo. Para executar a elicitação, o processo necessita dos seguintes agentes e recursos: engenheiro de requisitos; a abordagem NFR Framework; e a ferramenta de modelagem StarUML (StarUML, 2013). A atividade de Elicitação, mostrada na Figura 13, foi refinada em 4 atividades, sendo estas: (I) Análise sobre os requisitos funcionais; (II) Seleção dos requisitos para a acessibilidade; (III) Análise de conflito entre os RNFs; e por fim (IV) a Geração de artefatos contendo os requisitos de acessibilidade selecionados. A Figura 14 ilustra como estas 4 atividades estão encadeadas.

57 57 Figura 14 - Atividades do método de elicitação Cada uma das atividades mostradas na Figura 14 é responsável pela produção de um artefato que serve de entrada para a atividade seguinte. As subseções a seguir abordam com detalhes como estas atividades devem ser executadas dentro do processo Atividade 1 - Análise sobre os requisitos funcionais Como mostra a Figura 14, esta atividade se inicia com a entrada de informações contendo a descrição e os requisitos funcionais do sistema. A Tabela 6 mostra um resumo das entradas, controles, mecanismos e saídas desta primeira atividade. Tabela 6 - Entradas, controles, mecanismos e saídas da atividade 1 do processo Atividade 1 - Análise sobre os requisitos funcionais Entrada(s) Descrição do sistema e requisitos funcionais do sistema Controle(s) Definição do público alvo e limitações físicas Mecanismo(s) Engenheiro de requisitos Saída(s) Requisitos funcionais com tipos de conteúdo definidos Após preparar as informações de entrada, o engenheiro de requisitos deve analisar como os requisitos funcionais podem ser ajustados em relação à acessibilidade. O objetivo dessa análise é definir o tipo de conteúdo necessário para

58 58 cada RF (Seção 3.1). Para isso dois passos devem ser seguidos: 1 - O levantamento de possíveis tipos de conteúdo para cada RF; 2 - A análise dos tipos de conteúdos levantados em relação às limitações do público alvo. Para levantar os tipos de conteúdo no primeiro passo, é preciso analisar quais os tipos de dados que o usuário precisa acessar ou informar. Já no segundo passo é preciso confrontar os tipos de conteúdos levantados no primeiro passo, para averiguar impactos sobre as limitações apresentadas pelo público alvo. O primeiro passo, além de permitir o levantamento dos tipos de conteúdo, permite refinar a compreensão sobre os requisitos funcionais elicitados. O segundo passo se refere à necessidade de ajustar os RFs de acordo com a perfil apresentado pelo público alvo. Como exemplo para a definição do tipo de conteúdo, podemos imaginar um contexto onde o público alvo apresente limitações visuais. Nessa situação, disponibilizar funcionalidades com conteúdos do tipo Texto, que são acessados através de tecnologias assistivas como leitores de tela, pode facilitar o acesso deste público às informações. Essa estratégia de vincular os requisitos de acessibilidade à tipos de limitações e suas respectivas operacionalizações à tipos de conteúdos (Seção 3.2), adotada por essa dissertação, serve como agente facilitador para a extração das informações contidas no catálogo de RNFs. Porém, além de verificar se as informações extraídas estão de acordo com esses parâmetros, os elicitadores devem também levar em consideração se todos os requisitos de acessibilidade extraídos do catálogo realmente se aplicam aos requisitos funcionais da aplicação. Por exemplo, vamos considerar o desenvolvimento de um aplicativo voltado para pessoas com limitações auditivas, incluindo indivíduos com perda parcial e perda total de audição, e que possui o seguinte requisito funcional: O sistema deve permitir associar arquivos de áudio pré-gravados a fotos. Conforme a análise da descrição do RF, podemos perceber que um dos tipos de conteúdo presentes na funcionalidade é do tipo áudio. E durante a seleção dos requisitos de acessibilidade contidos no catálogo, de acordo com as limitações do público alvo, entre outras possibilidades, a meta suave Alternativas para conteúdos de áudio (ao vivo) poderia ser selecionada, isso por que no catálogo esse requisito encontra-se

59 59 vinculado ao tipo de limitação auditiva, tanto para perda parcial como para perda total de audição. Na Figura 15 podemos ver a ilustração desse exemplo. Figura 15 - Exemplo de filtragem dos requisitos de Acessibilidade Web Como apresenta a Figura 15, nesse exemplo três requisitos poderiam vir: Alternativas para mídias pré-gravadas do tipo áudio e vídeo, Disponibilidade de legenda para mídias pré-gravadas e ao vivo e Alternativa para conteúdo de áudio (ao vivo). Como o requisito funcional em questão não se relaciona com o processamento de áudio transmitido ao vivo, e sim com associação entre arquivos de áudio pré-gravados e fotos, o requisito de acessibilidade Alternativas para conteúdos de áudio (ao vivo) deve ser descartado dessa elicitação pelo engenheiro de requisitos, como mostrado na Figura 15. A saída dessa atividade deverá ser um artefato contendo os RFs vinculados a tipos de conteúdo, este artefato servirá de entrada para a próxima atividade Atividade 2 - Seleção dos requisitos para a acessibilidade O objetivo desta atividade é a elicitação dos requisitos de acessibilidade juntamente com suas operacionalizações, de acordo com os parâmetros passados para os tipos de limitações do público alvo e tipos de conteúdos. A Tabela 7 mostra o resumo dos componentes desta atividade. Tabela 7 - Entradas, controles, mecanismos e saídas da atividade 2 do processo Entrada(s) Controle(s) Mecanismo(s) Saída(s) Atividade 2 - Análise sobre os requisitos funcionais elicitados Requisitos funcionais com tipos de conteúdo definidos / Catálogo de requisitos de acessibilidade baseado na W3C Definição das limitações físicas do público alvo / Levantamento dos requisitos para alcançar a acessibilidade NFR Framework / Ferramentas de modelagem StarUML SIG do produto

60 60 Como abordado na atividade anterior, cada requisito de acessibilidade contido no catálogo de acessibilidade encontra-se vinculado a um tipo ou mais de limitações, enquanto as operacionalizações estão vinculadas à tipos de conteúdos. Durante a execução dessa segunda etapa, o engenheiro de requisitos pode fazer alterações no SIG do produto gerado como, por exemplo, adicionar, alterar ou excluir algum requisito de acessibilidade existente, assim como suas respectivas tarefas de operacionalização. Para exemplificar a relação entre os requisitos de acessibilidade e suas respectivas operacionalizações no catálogo, a Figura 16 apresenta uma parte do catálogo, contendo três requisitos, sendo estes: Conteúdo preservado independente do formato da apresentação, Conteúdos disponibilizados com instruções alternativas às características sensoriais dos itens da página e Informações disponibilizadas através de sequências bem definidas. Figura 16 - Exemplos de requisitos de acessibilidade com suas respectivas tarefas de operacionalização Após a descrição de cada um destes requisitos citados, há caracteres entre colchetes, indicando as limitações do público que estes requisitos atendem (Seção

61 ). Entre as operacionalizações, destacamos Separar a apresentação do conteúdo, que abrange todos os tipos de conteúdo, como indicado na Figura 16. A seleção dos requisitos de Acessibilidade Web, através do catálogo de RNFs, deve ocorrer seguindo uma ordem de verificação. Inicialmente deve ser levado em consideração se o requisito de acessibilidade relacionado atende as limitações definidas para o público alvo da aplicação. Logo em seguida é analisado se as operacionalizações desse requisito estão de acordo com os tipos de conteúdo definidos para os RFs, se sim, o requisito de acessibilidade relacionado é selecionado, caso contrário deve ser descartado. A saída desta atividade compreende O SIG do produto, que contém os requisitos de Acessibilidade Web elicitados do catálogo de RNFs original, contendo apenas os requisitos específicos para o projeto em questão. O SIG do produto obedece a estrutura do catálogo original, ou seja, os refinamentos e os relacionamentos entre os componentes são conservados, indicando de onde os requisitos elicitados vieram e como se relacionam dentro do catálogo Atividade 3 - Análise de conflito entre os RNFs Nesta etapa as operacionalizações dos requisitos de acessibilidade são analisadas, levando em consideração o controle para identificar e resolver possíveis conflitos com outros RNFs elicitados para o sistema. O SIG do produto gerado na atividade anterior e o RNFs elicitados compõe as informações de entrada para essa atividade. A Tabela 8 mostra um resumo dos componentes dessa atividade. Tabela 8 - Entradas, controles, mecanismos e saídas da atividade 3 do processo Atividade 3 - Análise de conflito entre os RNFs Entrada(s) SIG do produto / Requisitos não funcionais Controle(s) Resolução de possíveis conflitos entre as operacionalizações e outros RNFs Mecanismo(s) Engenheiro de requisitos Saída(s) Versão do SIG do produto com análise de conflitos entre os RNFs efetuada Essa atividade necessita de um julgamento humano, sendo assim deve ser manual, porém na ferramenta, a ser apresentada no capítulo 5, o usuário poderá optar por ignorar os conflitos e partir para a próxima atividade. Os autores desta pesquisa consideram que esta análise deva ser efetuada, pois possíveis conflitos com

62 62 os RNFs podem ocasionar impactos negativos na qualidade do produto, exigindo um retrabalho considerável para a equipe de desenvolvimento, durante a correção das falhas. Após identificar algum conflito, o engenheiro de requisitos pode resolver buscando alternativas no próprio catálogo. Caso ainda não existam alternativas satisfatórias, os conflitos podem ser resolvidos adicionando, excluindo ou alterando as tarefas para operacionalização dos requisitos de acessibilidade. A Figura 17 mostra um trecho do catálogo, onde a meta suave Melhorar acesso a conteúdos não textuais referente a acessibilidade, e o RNF de usabilidade sofrem impactos da operacionalização Fornecer mecanismo captcha, pertecente ao requisito não funcional de segurança. Para resolver este conflito, uma alternativa seria excluir ou substituir esta operacionalização por outro mecanismo de validação. Porém se a utilização do Capctha for prioridade, o engenheiro de requisitos pode solucionar este conflito através do refinamento desta operacionalização em operacionalizações alternativas. Na seção 4.2 a seguir é mostrado um exemplo de solução para este conflito quando o requisito conflitante em questão tem prioridade e não pode ser excluído. Figura 17 - Trecho do catálogo de requisitos de acessibilidade contendo conflitos Como resultado, esta atividade gera uma nova versão do SIG do Produto contendo as análises de impactos efetuadas, informando quais alternativas foram consideradas para resolver os conflitos detectados.

63 Atividade 4 Geração de artefatos Esta é a quarta e última atividade do método, basicamente se refere a geração de artefatos relacionados com os requisitos de acessibilidade elicitados. Como informação de entrada, esta atividade recebe o SIG do produto analisado da atividade anterior, após excluir as alternativas inadequadas é gerada uma versão final do SIG do produto, contendo os requisitos de Acessibilidade Web elicitados para o projeto. O engenheiro de requisitos pode gerar também o checklist para controle de implementação dos requisitos de Acessibilidade Web elicitados, além de catálogos de correlações. O artefato checklist foi elaborado para ser uma visão alternativa dos requisitos contida no catálogo de RNFs, fornecendo apoio aos desenvolvedores para a verificação do que precisa ser implementado de Acessibilidade Web. Enquanto que o artefato catálogo de correlações fornece um relatório dos conflitos identificados entre os requisitos de acessibilidade e suas respectivas operacionalizações com outros RNFs, como disponibilidade, segurança, etc. Ao término do processo, se for detectado algum erro ou omissão na elicitação, o engenheiro de requisitos precisa rever todos os procedimentos, iniciando novamente desde a primeira atividade. A Tabela 9 mostra um resumo dos componentes para esta quarta atividade. Tabela 9 - Entradas, controles, mecanismos e saídas da atividade 4 do processo Atividade 4 Geração de artefatos Entrada(s) Versão final do SIG do produto com análise de conflitos entre os RNFs efetuada Controle(s) Documentação dos requisitos de acessibilidade Mecanismo(s) Engenheiro de requisitos Saída(s) Versão final do catálogo de RNFs para acessibilidade / Catálogo de correlações / Documento de requisitos Na seção a seguir apresentamos o template definido para estes artefatos, bem como um exemplo para ilustrar a importância e o comportamento do método de elicitação.

64 Exemplo demonstrativo do processo 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. Descrição do sistema Requisitos funcionais Tabela 10 - Descrição e RFs do sistema Agendador de reuniões Artefatos de entrada da atividade 1 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. 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

65 65 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.

66 66 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

67 67 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.

68 68 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..

69 69 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.

70 70 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

71 71 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

72 72 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

73 73 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.

74 74 Catálogo de correlações Tabela 12 - Catálogo de correlação gerado para o exemplo Operacionalizações dos requisitos do RNFs ou metas suaves impactadas catálogo Conteúdos disponibilizados Usabilidade Portabilidade de maneira perceptível Fornecer mecanismo captcha - - Fornecer alternativas textuais que + identifiquem o captcha Ajustar conteúdo para a navegação Help + + vertical em dispositivos móveis Utilizar componentes de interface que Help + + possam ter focos destacados por agentes de usuários 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.

75 75 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

76 76 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.

77 77 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: As seções a seguir apresentam as ferramentas utilizadas para auxiliar o funcionamento da Omnes Web, sua arquitetura e funcionalidades. 5.1 Plataforma tecnológica Para a implementação da Omnes Web, a linguagem de programação utilizada foi PHP (PHP, 2013). O PHP é uma linguagem de script Open Source, e além de oferecer suporte à programação orientada à objetos, possui compatibilidade com diversos servidores web. Para testes e execução da Omnes Web, durante o processo de desenvolvimento, a ferramenta utilizada foi o WAMP (WAMP, 2013). Essa ferramenta fornece um ambiente servidor de suporte ao desenvolvimento de sites e aplicações Web. Esse suporte ocorre através da disponibilidade de importantes recursos, tais como: Gerenciamento dos serviços do APACHE e MYSQL, bom desempenho, fácil utilização e configuração, entre outros. A interação entre a Omnes Web e o catálogo de RNFs, elaborado por esta pesquisa, ocorre através de um arquivo XML exportado pela ferramenta StarUML

78 78 (Capítulo 3). O conteúdo desse XML é utilizado como base para a elicitação dos requisitos de contidos no catálogo. A Figura 26 apresenta uma parte de um arquivo XML gerado através da ferramenta StarUML. Figura 26 - Exemplo do XML gerado pela ferramenta StarUML O conteúdo do arquivo XML, apresentado na figura 26, é composto pelas seguintes partes: Model, Diagram e TaggedValue. As informações que são processadas pela Omnes Web encontram-se na tag Model, destacados pelas setas na figura 26, estão os 3 elementos que são utilizados pela ferramenta, sendo eles: Class, Dependency e Stereotype. O elemento Class guarda as informações dos requisitos e operacionalizações do catálogo modelado. O elemento Dependency guarda os relacionamentos entre os elementos do tipo Class, ou seja, as relações entre os requisitos e operacionalizações. Por fim, o elemento Stereotype define a classificação dos elementos Class e Dependency, informando, por exemplo, se o elemento Class é uma meta suave (NFRSoftgoal) ou uma operacionalização (OperationalizingSoftgoal). 5.2 Arquitetura da Ferramenta Omnes Web A Omnes Web foi desenvolvida para o ambiente Web, permitindo assim que uma quantidade maior de usuários possa usufruir de seus benefícios. A ferramenta

79 79 foi estruturada em 3 módulos principais: módulo de Elicitação que implementa as 4 atividades do processo; módulo Artefatos, contendo o catálogo, baseados no Framework NFR, que são utilizados pela ferramenta; e módulo Glossário que contém a documentação para guiar os usuários na utilização da ferramenta. O padrão de projeto escolhido para a implementação da ferramenta foi o Model View Control (GARLAN, D. & SHAW, M., 1993), utilizando o framework Kohana (Kohana, 2014). Esse framework possui código aberto e permite programar no paradigma de orientação à objetos. A seguir serão apresentadas as informações sobre a arquitetura da Omnes Web e como as funcionalidades estão organizadas através de sua estrutura. A Figura 27 apresenta a arquitetura da ferramenta Omnes Web. Figura 27 - Arquitetura da ferramenta Omnes Web O módulo de Elicitação, mostrado na Figura 27, compreende em sua view 5 formulários, sendo estes: 1 - elicitacao.php que abrange as atividades de Análises dos requisitos funcionais, 2- crud.php que abrange a atividade de Análise de conflito entre os RNFs, 3 - projeto.php que abrange a atividade de Geração de artefatos do

80 80 processo de elicitação, 4 checklist.php que se relaciona com o checklist gerado para controle de implementação dos requisitos de Acessibilidade Web, e 5 correlacoesprojeto.php que mostra as informações de impactos detectados entre os RNFs. O módulo de Artefatos também possui 5 formulários em sua view, sendo estes: 1 acessibilidade.php que mostra os requisitos de Acessibilidade do catálogo em formato de árvore, 2 acessibilidade-grafico.php que exibe o gráfico de interdependência (SIG) dos requisitos de Acessibilidade, 3 acessibilidadetabela.php que exibe os requisitos de Acessibilidade em formato de Tabela, 4 correlações.php que apresenta a Tabela de impactos entre os RNFs do catálogo de Acessibilidade, e 5 exportação-xml.php que apresenta o formulário para exportação do XML do catálogo de requisitos de Acessibilidade Web. Por fim, o módulo de Glossário apresenta em sua view o formulário glossario.php, que contém a documentação para guiar a utilização da Omnes Web, além disso, também apresenta informações sobre os temas de Engenharia de requisitos, NFR Framework e W3C. Ainda de acordo com a figura 27, a arquitetura da ferramenta Omnes Web possui um controlador chamado Controller-Requisitos, que é responsável por 7 ações, sendo estas: 1 Importação e exportação do XML e do projeto que contém a implementação para a importação e exportação do XML e do arquivo do projeto (Projeto.owp) gerados pela Omnes Web; 2 - Seleção dos requisitos que contém a implementação para selecionar os requisitos e operacionalizações do catálogo, de acordo com os parâmetros passados das limitações físicas e tipos de conteúdo; 3 Montagem da árvore de requisitos do projeto que contém a implementação de relacionamento entre os requisitos de Acessibilidade elicitados, e que será exibido em formato de árvore na view de crud.php; 4 CRUD de requisitos do catálogo de RNFs que contém a implementação para os procedimento de leitura, cadastro, alteração e exclusão dos requisitos e operacionalizações elicitados; 5 Definições do checklist que contém a implementação para geração e exportação do checklist para controle de implementação dos requisitos de Acessibilidade elicitados; 6 Definições do catálogo de correlações do projeto que contém a implementação para geração do catálogo de impactos detectados entre os RNFs durante a elicitação; 7

81 81 Definições dos dados mostrados na árvore e na Tabela de Acessibilidade, e no catálogo de correlações do Módulo de artefatos, contendo as implementações de relacionamento dos requisitos que serão exibidos nos documentos contidos no módulo de Artefatos. Por fim, a Figura 27 apresenta o componente SIG que possui as informações referentes ao processamento e geração da estrutura do XML do catálogo de requisitos de Acessibilidade Web. Essa classe contém as informações para cada instancia dos elementos do XML, gerado pela ferramenta StarUML, ao todo existem 4 elementos: 1 UMLClass que compreende os requisitos e operacionalizações do catálogo, 2 UMLDependency que se relaciona com os impactos e refinamentos entre os requisitos e operacionalizações, 3 UMLStereotype que classifica o tipo do elemento contido no catálogo, 4 UMLTaggedValue que atribui os rótulos dos impactos e decomposições entre os requisitos e operacionalizações. Como informado anteriormente, a Omnes Web utiliza o XML do catálogo exportado pela StarUML como base para a elicitação dos requisitos de Acessibilidade (seção 5.1). A Omnes Web não possibilita a visualização do SIG resultante do projeto de elicitação. Dessa forma, para a visualização do SIG, a ferramenta StarUML pode ser novamente utilizada, importando o XML resultante do processo de elicitação executado na Omnes Web, como mostrado na Figura 27, pelo ator StarUML. Outra importante funcionalidade da Omnes Web é a importação e exportação do projeto de elicitação criado. Através de um arquivo de extensão owp, o usuário pode salvar o projeto e caso necessite pode reutilizá-lo, importando o arquivo na ferramenta. As seções a seguir apresentam detalhes de cada módulo da Omnes Web e as interfaces gráficas com que se relacionam. Inicialmente são mostrados os procedimentos executados no módulo de elicitação (Seção 5.1.1), posteriormente é apresentado o módulo de Artefatos (Seção 5.1.2), e por fim será apresentado o módulo de Glossário (Seção 5.1.3).

82 Módulo de Elicitação O módulo de elicitação da ferramenta compreende as 4 atividades contidas no processo de elicitação dos requisitos de Acessibilidade Web (Seção 4.1), proposto por esta pesquisa. Para explicar a execução e sequência das tarefas dentro da ferramenta, o exemplo do sistema Agendador de reuniões (como definido na seção 4.2) será utilizado. A Figura 28 destaca os três módulos da Omnes Web, para iniciar o módulo de elicitação, o usuário deve clicar no botão Iniciar elicitação na página inicial da ferramenta. Ao invés de iniciar a atividade de elicitação para um projeto novo, o usuário pode importar um arquivo produzido anteriormente, através do botão Importar. Figura 28 - Página inicial da ferramenta Omnes Web Ao clicar no botão Iniciar elicitação, a ferramenta direciona o usuário para a tela da primeira atividade da elicitação, que é a Análise dos requisitos funcionais. O primeiro procedimento a ser realizado é a entrada de informações do projeto, tais como: Nome do projeto, Autor (es) do projeto e Descrição do projeto. A Figura 29 apresenta a entrada dessas informações.

83 83 Figura 29 - Módulo de elicitação: Entrada das informações do projeto Como comentado e destacado na Figura 29, ao iniciar o módulo de elicitação o sistema apresenta através de abas as 4 atividades do processo de elicitação. Logo após essas abas, há um texto explicativo sobre os procedimentos a serem realizados. Em seguida são apresentados os campos para que o usuário insira as informações do projeto. Após a entrada dessas informações, o usuário deve fornecer duas informações essenciais para o processo de elicitação, sendo estas: I - As limitações presentes no público alvo da aplicação, II- Os tipos de conteúdo vinculados a cada Requisito funcional. Como já explicado na Seção 4.1.1, cada requisito contigo no catálogo de Acessibilidade Web encontra-se vinculado a uma ou mais limitações, dessa forma, a Omnes Web seleciona esses requisitos de acordo com as limitações físicas informadas pelo usuário. Enquanto que as operacionalizações dos requisitos encontram-se vinculadas aos tipos de conteúdos, assim sendo, a seleção das operacionalizações é feita de acordo com os tipos de conteúdos definidos pelo

84 84 usuário. A Figura 30 mostra as limitações do público alvo e os tipos de conteúdo definidos para o sistema agendador de reuniões. Figura 30 - Módulo de elicitação: definição das limitações do público alvo e os tipos de conteúdos para os RFs Conforme apresentado na Figura 30, as limitações definidas para o público alvo foram as limitações Visuais (abrangendo pessoas com Daltonismo, baixa visão e sem visão) e Auditivas (Abrangendo pessoas com perda auditiva parcial ou total). Após a definição das limitações, o usuário deve informar os requisitos funcionais e não funcionais da aplicação. Como apresentado na Figura 30, para cada Requisito funcional registrado, foram informados os tipos de conteúdos de acordo com a

85 85 análise efetuada pelo usuário. Como já explicado na Seção 4.1.1, para ocorrer a definição dos tipos 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. No exemplo mostrado na Seção 4.2, todos os requisitos funcionais cadastrados foram vinculados ao tipo de conteúdo Texto, porém para variar os resultados neste exemplo os requisitos RF8 e RF12 foram vinculados também ao tipo de conteúdo Imagem, como destacados por círculos na Figura 30. Após fornecer todas as informações necessárias para a primeira atividade do módulo de elicitação, o usuário deve clicar no botão Prosseguir, no canto inferior direito da interface, dando início a atividade 2 do processo de elicitação A segunda atividade do processo de elicitação, que se relaciona com a seleção dos requisitos de Acessibilidade Web, é executada de maneira automatizada pela Omnes Web. Como já explicado anteriormente, os requisitos são selecionados de acordo com os parâmetros passados referentes às limitações do público alvo, e as operacionalizações são levantadas de acordo com os tipos de conteúdo informados. A Figura 31 apresenta os requisitos resultantes da segunda etapa do processo. Figura 31 - Árvore contendo os requisitos e operacionalizações elicitadas

86 86 Como mostrado na Figura 31, os RNFs estão organizados em formato de árvore, onde primeiro são apresentados os requisitos não funcionais informados na atividade anterior, seguidos dos requisitos de Acessibilidade Web. Os requisitos de Acessibilidade foram organizados seguindo uma hierarquia, onde há princípios detalhados por diretrizes, que por sua vez são detalhadas por requisitos, que são detalhados por operacionalizações. Na Figura 31, destacada entre chaves, é possível ver essa hierarquia, o princípio Conteúdos disponibilizados de maneira operável foi detalhado por três diretrizes, entre elas está a diretriz Suporte para a navegação do conteúdo, que por sua vez foi detalhada em outros requisitos, sendo um deles Identificação da finalidade de cada link. Para operacionalizar o requisito Identificação da finalidade de cada link duas operacionalizações foram selecionadas, a primeira é Fornecer alternativas textuais para elementos de área contidos em mapas de imagens, enquanto a segunda é Fornecer textos descrevendo a finalidade do link, ambas destacadas por um círculo na Figura 31. Essas duas operacionalizações citadas, fazem parte de um grupo de elementos do catálogo que estão vinculados a componentes de interface (botões, links, inputs, etc.), e esse tipo de operacionalização vem de maneira automática na elicitação, tendo em vista que geralmente as páginas web possuem um ou mais tipos de componentes de interface. Porém, se o usuário definir que não precisa de algumas dessas operacionalizações, a exclusão desses elementos pode ser efetuada. Tendo o usuário revisado os requisitos de Acessibilidade Web selecionados pela ferramenta, o próximo passo é a execução da terceira atividade que é a Análise de conflito entre os RNFs. A Figura 32 apresenta um exemplo de análise efetuada para o projeto Agendador de Reuniões.

87 87 Figura 32 - Módulo de elicitação: Análise de conflitos entre os RNFs Como identificado na seção 4.2, o requisito de segurança chamado Testes de requisições possuí uma operacionalização chamada Fornecer mecanismo Captcha. Essa operacionalização causa impacto negativo na meta de Conteúdos disponibilizados de maneira perceptível, devido ao uso desse tipo de tecnologia envolver imagens, fato este que causa problemas na percepção do conteúdo para a parcela de usuários que não possuem visão. Dessa forma, como destaca e comenta a Figura 32, a operacionalização Fornecer alternativas que identifiquem o Captcha foi criada como alternativa para viabilizar o uso de capcthas, causando um impacto positivo na meta Conteúdos disponibilizados de maneira perceptível, como destaca o círculo na Figura 32. Após finalizar a análise de conflito para todos os requisitos, o usuário deve clicar no botão prosseguir para executar a Geração de artefatos que é a última atividade do processo. A Figura 33 mostra a tela referente a Geração dos artefatos.

88 88 Figura 33 - Módulo de elicitação: Geração de artefatos Conforme destaca a Figura 33, na página referente a quarta atividade do processo, o sistema apresenta as informações do projeto, assim como as limitações definidas para o público alvo, e a lista dos RFs e RNFs inseridos na primeira atividade. A Omnes web disponibiliza funcionalidades que permitem ao usuário gerar três artefatos, sendo estes: I O XML contendo a versão final do catálogo de requisitos de Acessibilidade Web, II O Checklist para controle de implementação dos requisitos de Acessibilidade; III Tabela de correlações entre os RNFs. Ainda em relação a página da atividade de Geração de Artefatos, o sistema disponibiliza a funcionalidade de exportação do projeto, através do botão Exportar Projeto, no canto inferior direito da Figura 33. O arquivo gerado pela exportação possui extensão owp, que significa Omnes Web Project, e poderá ser novamente importado pela Omnes Web para eventuais alterações ou visualizações do projeto. Para a visualização e /ou ajustes do SIG (Gráfico de interdependência) contido no XML gerado pela Omnes Web, é necessário efetuar a importação deste

89 89 arquivo na ferramenta StarUML. A Figura 34 apresenta um trecho do SIG gerado para o projeto do Agendador de reuniões. Figura 34 - Trecho do catálogo de requisitos de Acessibilidade Web gerado As setas pretas na Figura 34 destacam a análise de conflito entre os RNFs, realizada durante a terceira atividade do processo, onde a criação da operacionalização Fornecer alternativas textuais que identifiquem o Captcha, amenizou o impacto negativo causado na meta Conteúdos disponibilizados de maneira perceptível pela operacionalização Fornecer mecanismo Captcha. A Figura 35 apresenta parte do checklist para controle de implementação dos requisitos de Acessibilidade Web gerado para o projeto Agendador de Reuniões.

90 90 Figura 35 - Trecho do checklist contendo a lista dos RFs RNFs Na Figura 35 é apresentada a tabela dos RFs e RNFs informados durante a atividade de Análise dos requisitos funcionais. A primeira e segunda coluna dessa Tabela informam respectivamente o ID e a descrição de cada requisito, enquanto que a terceira coluna está relacionada ao controle que o desenvolvedor deve efetuar sobre o status da implementação de cada requisito. Como mostra a Figura 35, o checklist gerado relacionou os requisitos funcionais com as operacionalizações dos requisitos de acessibilidade. Isso permite ao desenvolvedor identificar o que exatamente de acessibilidade precisa ser implementado no RF relacionado. Ainda de acordo com a Figura 35, a operacionalização Fornecer alternativas textuais curtas e seus refinamentos foram relacionadas aos RFs com id RF8 e RF12.

91 Módulo de Artefatos O módulo de artefatos da ferramenta contém visões do catálogo de Acessibilidade Web, utilizado como base para o processo de elicitação proposto por esta pesquisa. A Figura 36 apresenta as opções de visualização do catálogo de Acessibilidade Web. Figura 36 - Módulo de Artefatos: Visões do catálogo de Acessibilidade Web Conforme apresenta a Figura 36, além da estrutura de árvore, o catálogo de Acessibilidade Web pode ser visualizado através do gráfico de interdependência (SIG) e no formato de Tabela. A Figura 37 apresenta um trecho do catálogo no formato de Tabela.

92 92 Figura 37 - Módulo de Artefatos: Trecho do catálogo de Acessibilidade Web no formato de Tabela Conforme mostrado na Figura 37, a estrutura da Tabela gerada está diretamente relacionada com a estrutura do WCAG 2.0, obedecendo a seguinte configuração hierárquica: Princípios Requisitos (Diretrizes e Refinamentos) Operacionalizações (Técnicas de implementação). Além de visualização do catálogo de Acessibilidade Web, o módulo de Artefatos também permite ao usuário efetuar a exportação de XMLs dos catálogos de RNFs. A Figura 38 apresenta a tela de exportação de XMLs.

93 93 Figura 38 - Módulo de Artefatos: Exportação de XML do catálogos de RNFs Módulo de Glossário O módulo de Glossário da Omnes Web serve de guia para o usuário a respeito da utilização da ferramenta, além disso, traz informações sobre os temas que envolvem o processo de elicitação proposto. A Figura 39 apresenta a tela referente ao módulo de Glossário. Figura 39 - Módulo de Glossário da Omnes Web 5.3 Considerações finais sobre o Capítulo Este capítulo apresentou detalhes sobre a plataforma tecnológica da ferramenta Omnes Web, assim como também informações sobre sua arquitetura. Além disso, foram abordadas as interfaces gráficas da ferramenta, utilizando como base o exemplo do projeto referente Agendador de reuniões (utilizado também na Seçaõ 4.2). Através desse exemplo foi possível apresentar alguns trechos dos artefatos produzidos pela Omnes Web.