Post on 09-Nov-2018
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
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
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, 2014.
205 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 004.738.5
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
Dedico este trabalho aos meus
familiares, pelo eterno e incondicional
incentivo, amor e dedicação.
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!
Há uma força motriz mais poderosa que o vapor, a
eletricidade e a energia atômica: a vontade.”
Albert Einstein
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.
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
Lista de Figuras
Figura 1 - Princípio de operabilidade da usabilidade. Fonte: (Alonso et al.,
2009) ................................................................................................................................... 28
Figura 2 - Exemplo de um SIG baseado na abordagem NFR Framework ........ 36
Figura 3 - Exemplo de um modelo SD do framework i* .................................... 37
Figura 4 - Parte do catálogo de usabilidade. Fonte: (Cysneiros, 2007) .............. 39
Figura 5 - Exemplo de um catálogo de métodos do NFR Framework .............. 40
Figura 6 – Caixa do SADT ..................................................................................... 41
Figura 7 - Elementos do catálogo relacionados ao princípio Perceptível do
WCAG 2.0 .......................................................................................................................... 44
Figura 8 - Elementos do catálogo relacionados ao princípio Operável ............. 45
Figura 9 - Elementos do catálogo relacionados ao princípio Compreensível ... 46
Figura 10 - Elementos do catálogo relacionados ao princípio Robustez ........... 47
Figura 11 - (A) Estrutura do catálogo de RNFs; e (B) exemplos de conteúdo
contido no catálogo. .......................................................................................................... 49
Figura 12 - Exemplo de elementos do catálogo de RNFs vinculados aos tipos
de limitações e conteúdo .................................................................................................. 52
Figura 13 - Visão geral do método de elicitação .................................................. 55
Figura 14 - Atividades do método de elicitação .................................................. 57
Figura 15 - Exemplo de filtragem dos requisitos de Acessibilidade Web ......... 59
Figura 16 - Exemplos de requisitos de acessibilidade com suas respectivas
tarefas de operacionalização ............................................................................................ 60
Figura 17 - Trecho do catálogo de requisitos de acessibilidade contendo
conflitos .............................................................................................................................. 62
Figura 18 - Parte dos requisitos elicitados relacionados ao princípio de
"Conteúdos disponibilizados de maneira perceptível" .................................................. 67
Figura 19 – Exemplo de operacionalizações selecionadas para o tipo de
conteúdo Imagem ............................................................................................................. 68
11
Figura 20 - Parte dos requisitos elicitados relacionados ao princípio de
"Conteúdos disponibilizados de maneira operável" ...................................................... 69
Figura 21 – Parte dos requisitos elicitados relacionados ao princípio de
“Conteúdos disponibilizados de maneira compreensível” ........................................... 70
Figura 22 – Parte dos requisitos elicitados relacionados ao princípio de
“Conteúdos disponibilizados de maneira robusta” ....................................................... 71
Figura 23 - Conflito entre as tarefas de operacionalização e outros RNFs do
exemplo .............................................................................................................................. 72
Figura 24 - Trecho da versão final do catálogo de RNFs para acessibilidade
Web .................................................................................................................................... 73
Figura 25 - Checklist do sistema Agendador de reuniões .................................. 75
Figura 26 - Exemplo do XML gerado pela ferramenta StarUML ....................... 78
Figura 27 - Arquitetura da ferramenta Omnes Web ........................................... 79
Figura 28 - Página inicial da ferramenta Omnes Web ........................................ 82
Figura 29 - Módulo de elicitação: Entrada das informações do projeto ............ 83
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 ........................................................................................ 84
Figura 31 - Árvore contendo os requisitos e operacionalizações elicitadas ...... 85
Figura 32 - Módulo de elicitação: Análise de conflitos entre os RNFs .............. 87
Figura 33 - Módulo de elicitação: Geração de artefatos ...................................... 88
Figura 34 - Trecho do catálogo de requisitos de Acessibilidade Web gerado .. 89
Figura 35 - Trecho do checklist contendo a lista dos RFs RNFs......................... 90
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 ........................................................................................................ 92
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 ............................................... 93
Figura 40 - Etapas do estudo de caso ................................................................... 98
12
Figura 41 - Exemplo de um checklist gerado pela Omnes Web ...................... 186
13
Lista de Tabelas
Tabela 1 - Princípios do WCAG 2.0. Fonte: (W3C-WCAG 2.0, 2013) ................ 31
Tabela 2 - Princípios da MWBP 1.0. Fonte: (W3C-MWBP 1.0, 2013) ................. 32
Tabela 3 - Tipos de limitações ............................................................................... 50
Tabela 4 - Refinamento das limitações Visual, Auditiva e Cognitiva ............... 51
Tabela 5 - Tipos de conteúdo ................................................................................ 51
Tabela 6 - Entradas, controles, mecanismos e saídas da atividade 1 do processo
............................................................................................................................................ 57
Tabela 7 - Entradas, controles, mecanismos e saídas da atividade 2 do processo
............................................................................................................................................ 59
Tabela 8 - Entradas, controles, mecanismos e saídas da atividade 3 do processo
............................................................................................................................................ 61
Tabela 9 - Entradas, controles, mecanismos e saídas da atividade 4 do processo
............................................................................................................................................ 63
Tabela 10 - Descrição e RFs do sistema Agendador de reuniões ....................... 64
Tabela 11 - Tipos de conteúdo definidos para os RFs do exemplo .................... 66
Tabela 12 - Catálogo de correlação gerado para o exemplo ............................... 74
Tabela 13 - Questões de pesquisa elaboradas para o estudo de caso ................ 97
Tabela 14 – Situações versus Recursos disponíveis na etapa I do estudo de caso
............................................................................................................................................ 99
Tabela 15 - Configuração dos participantes para a etapa de elicitação do
estudo de caso ................................................................................................................. 102
Tabela 16 - Configurações definidas para formação de duplas da etapa I ..... 103
Tabela 17 - Distribuição da documentação gerada na etapa I entre os
participantes da etapa II ................................................................................................. 105
Tabela 18 - Níveis de experiência dos participantes da segunda etapa .......... 107
Tabela 19 - Respostas das perguntas 1,2,3 e 4 do questionário para a
categorização de perfil dos participantes da 3º etapa .................................................. 109
14
Tabela 20 - Requisitos de Acessibilidade extraídos – Projeto 1 ........................ 117
Tabela 21 - Requisitos de Acessibilidade extraídos – Projeto 2 ........................ 118
Tabela 22 - Requisitos de Acessibilidade selecionados – Projeto 1 .................. 118
Tabela 23 - Requisitos de Acessibilidade selecionados – Projeto 2 .................. 119
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 ................. 120
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 .................. 122
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 .................. 123
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 .................. 124
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 .................. 125
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 .................. 126
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 .................. 127
Tabela 32 - Informações extraídas da etapa de prototipação ........................... 131
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 .................. 134
Tabela 34 - Análise manual da Acessibilidade Web do Projeto 1 – prototipação
do participante 1 ............................................................................................................. 139
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
.......................................................................................................................................... 140
Tabela 36 - Análise manual da Acessibilidade Web do Projeto 2 – prototipação
do participante 2 ............................................................................................................. 142
15
Tabela 37 - Respostas dos questionamentos de 1 a 5 do questionário de
avaliação da Acessibilidade Web – prototipação do participante 2 ........................... 143
Tabela 38 – Resultados das análises manuais de Acessibilidade Web efetuadas
nos 4 aplicativos .............................................................................................................. 144
Tabela 39 - Médias das tentativas para executar as tarefas solicitadas nos
roteiros dos aplicativos ................................................................................................... 145
Tabela 40 - Resultados da análise automatizada nos aplicativos gerados na
etapa de prototipação ..................................................................................................... 146
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 ............. 187
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 ...... 188
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 ...... 189
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 ..... 189
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 ................ 190
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 ................ 191
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 ................ 192
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
Sumário
1 Introdução ...................................................................................................................... 20
1.1 Contexto .................................................................................................................... 21
1.2 Identificação dos problemas.................................................................................... 22
1.3 Objetivos e contribuições ......................................................................................... 23
1.4 Organização do trabalho ......................................................................................... 25
2 Fundamentação teórica ................................................................................................. 26
2.1 A acessibilidade Web ............................................................................................... 26
2.1.1 Valores agregados com a acessibilidade ....................................................... 27
2.1.2 Relação entre acessibilidade e usabilidade ................................................... 28
2.2 Diretrizes e normas para alcançar acessibilidade na web .................................... 28
2.2.1 Guias da W3C .................................................................................................. 29
2.2.2 Normas da Seção 508 e do eMAG .................................................................. 32
2.3 Estratégias da Engenharia de Software para promover a Acessibilidade Web .. 33
2.3.1 Engenharia de requisitos ................................................................................ 33
2.3.2 O uso de abordagens orientadas a metas ...................................................... 34
2.3.3 Catálogos de RNFs .......................................................................................... 38
2.4 Notação SADT .......................................................................................................... 40
2.5 Considerações finais sobre o Capítulo ................................................................... 41
3 Catálogo dos requisitos de Acessibilidade Web ....................................................... 43
3.1 Bases e definições para a criação do catálogo ........................................................ 47
3.2 Parâmetros para a extração das informações do catálogo .................................... 49
3.3 Vantagens na utilização do catálogo ...................................................................... 52
3.4 Considerações finais sobre o Capítulo ................................................................... 53
4 Método para a elicitação dos requisitos de acessibilidade web .............................. 55
4.1 Estrutura do método ................................................................................................ 55
4.1.1 Atividade 1 - Análise sobre os requisitos funcionais ................................... 57
4.1.2 Atividade 2 - Seleção dos requisitos para a acessibilidade .......................... 59
4.1.3 Atividade 3 - Análise de conflito entre os RNFs ........................................... 61
4.1.4 Atividade 4 – Geração de artefatos ................................................................ 63
4.2 Exemplo demonstrativo do processo ..................................................................... 64
4.4 Considerações finais sobre o Capítulo ................................................................... 76
5 Ferramenta Omnes Web ............................................................................................... 77
5.1 Plataforma tecnológica ............................................................................................ 77
5.2 Arquitetura da Ferramenta Omnes Web................................................................ 78
5.2.1 Módulo de Elicitação....................................................................................... 82
5.2.2 Módulo de Artefatos ....................................................................................... 91
18
5.2.3 Módulo de Glossário ....................................................................................... 93
5.3 Considerações finais sobre o Capítulo ................................................................... 93
6 Estudo de caso ................................................................................................................ 96
6.1 Objetivo ..................................................................................................................... 96
6.2 Planejamento do estudo de caso ............................................................................. 98
6.2.1 Etapa I: Elicitação ............................................................................................ 99
6.2.2 Etapa II: Prototipação .................................................................................... 104
6.2.3 Etapa III: Análise da acessibilidade ............................................................. 107
6.3 Execução do estudo de caso .................................................................................. 111
6.3.1 Execução da etapa de elicitação ................................................................... 111
6.3.2 Execução da etapa de prototipação ............................................................. 113
6.3.3 Execução da etapa de Análise da Acessibilidade ....................................... 114
6.4 Análises dos dados extraídos durante a execução das etapas do estudo de caso
.......................................................................................................................................... 115
6.4.1 Dados extraídos na etapa de elicitação ........................................................ 115
6.4.2 Dados extraídos da etapa de prototipação .................................................. 130
6.4.3 Dados extraídos da etapa de análise da acessibilidade .............................. 137
6.5 Ameaças a validade ............................................................................................... 148
6.5.1 Validade interna ............................................................................................ 148
6.5.2 Validade externa ............................................................................................ 152
6.6 Considerações finais sobre o Capítulo ................................................................. 153
7 Trabalhos relacionados............................................................................................... 157
8 Conclusão ..................................................................................................................... 164
8.1 Contribuições .......................................................................................................... 165
8.2 Limitações e trabalhos futuros .............................................................................. 166
Referências ...................................................................................................................... 169
Apêndice A – Questionário para categorização de perfil dos participantes da etapa
de elicitação .................................................................................................................. 176
Apêndice B – Questionário de pós-execução da etapa de elicitação........................ 177
Apêndice C – Resumo do documento de requisitos do aplicativo para criação de
galeria de fotos interativa ........................................................................................... 181
Apêndice D – Resumo do documento de requisitos do aplicativo para gestão de
metas ............................................................................................................................. 183
Apêndice E – Checklist para controle de implementação dos requisitos
Acessibilidade Web .................................................................................................... 185
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 ........................................ 187
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 .............................................. 192
Apêndice H – Questionário para categorização do perfil dos participantes da etapa
de prototipação ............................................................................................................ 193
Apêndice I – Questionário para categorização do perfil dos participantes da etapa
de Análise da Acessibilidade ..................................................................................... 195
Apêndice J – Questionário de pós-execução dos participantes da etapa de
Prototipação .................................................................................................................. 196
Apêndice L – Roteiro de tarefas do projeto 1 ............................................................. 199
Apêndice M – Roteiro de tarefas do projeto 2 ............................................................ 201
Apêndice N – Questionário de avaliação da Acessibilidade Web dos aplicativos 204
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
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
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
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
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
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
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
2.1.1 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
2.1.2 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
WCAG (Web Content Accessibility Guidelines) propostos pela W3C, e também
apresenta as normas da seção 508.
2.2.1 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.
2.2.1.1 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
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
Tabela 1 - Princípios do WCAG 2.0. Fonte: (W3C-WCAG 2.0, 2013)
2.2.1.2 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.
Princípios Diretrizes contidas
Perceptível
Fornecer Alternativas textuais para qualquer conteúdo não textual;
Fornecer Alternativas para mídias baseadas no tempo;
Criar conteúdo que pode ser apresentado de modos diferentes sem perder informação ou estrutura;
Tornar mais fácil aos usuários a visualização e audição de conteúdos incluindo as separações das camadas da frente e de fundo.
Operável
Fazer com que todas as funcionalidades estejam disponíveis no teclado;
Prover tempo suficiente para os usuários lerem e usarem o conteúdo;
Não projetar conteúdo de uma forma conhecida por causar ataques epiléticos;
Prover formas de ajudar os usuários a navegar, localizar conteúdos e determinar onde se encontram.
Compreensível
Tornar o conteúdo de texto legível e compreensível;
Fazer com que as páginas da Web apareçam e funcionem de modo previsível;
Ajudar os usuários a evitar e corrigir erros.
Robusto Maximizar a compatibilidade entre os atuais e futuros agentes do
usuário, incluindo as tecnologias assistivas.
32
Tabela 2 - Princípios da MWBP 1.0. Fonte: (W3C-MWBP 1.0, 2013)
2.2.2 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
Temas Melhores práticas envolvidas
Comportamento geral
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.
Navegação e links
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.
Layout de página e conteúdo
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.
Definição de página
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.
Entradas do usuário
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.
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.
2.3.1 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
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.
2.3.2 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
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
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
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
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.
2.3.3 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
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
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
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
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
3 Catálogo dos requisitos de Acessibilidade
Web
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,
apresentadas nas figuras 7, 8, 9 e 10, correspondendo aos 4 princípios de
acessibilidade de acordo com o WCAG 2.0 (Veja seção 2.2.1.1). 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:
http://omnesweb.ucore.com.br/artefatos/acessibilidade/grafico-de-
interdependencia.
44
Figura 7 - Elementos do catálogo relacionados ao princípio Perceptível do WCAG 2.0
45
Figura 8 - Elementos do catálogo relacionados ao princípio Operável
46
Figura 9 - Elementos do catálogo relacionados ao princípio Compreensível
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 2.2.11). 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
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 2.2.11) 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 2.2.1.1) 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
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
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 Letras
Visual [V]
Auditiva [A]
Cognitiva [C]
Convulsões [CO]
Motora [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
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 Letras
Texto [T]
Imagem [I]
Vídeo [VI]
Áudio [AU]
Animação [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
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
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
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
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
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
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.
4.1.1 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
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
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.
4.1.2 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
Atividade 2 - Análise sobre os requisitos funcionais elicitados
Entrada(s) Requisitos funcionais com tipos de conteúdo definidos / Catálogo de requisitos de acessibilidade baseado na W3C
Controle(s) Definição das limitações físicas do público alvo / Levantamento dos requisitos para alcançar a acessibilidade
Mecanismo(s) NFR Framework / Ferramentas de modelagem StarUML
Saída(s) SIG do produto
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
4.1.1). 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.
4.1.3 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
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
4.1.4 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
4.2 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.
Tabela 10 - Descrição e RFs do sistema Agendador de reuniões
Artefatos de entrada da atividade 1
Descrição do sistema
O objetivo do agendador de reuniões é fornecer suporte para organização de reuniões, isto é, determinar, para cada requisição de reunião, uma data e um local, de modo que a maior parte dos participantes possa efetivamente participar da reunião.
Requisitos funcionais
RF001: O sistema deve permitir o cadastro, alteração e exclusão de usuários.
RF002: O sistema deve permitir o cadastro, alteração e exclusão de participantes das reuniões;
RF003: O sistema deve permitir o cadastro, alteração e cancelamento das reuniões;
RF004: O sistema deve permitir a substituição de reuniões.
RF005: O sistema deve permitir que os participantes informem as datas que estarão disponíveis para as reuniões.
RF006: O sistema deve permitir o cadastro, alteração e exclusão de locais e requisitos especiais (datashow, computadores e entre outras coisas) para as reuniões.
RF007: O sistema deve permitir que os participantes informem os locais de preferência para as reuniões.
RF008: O sistema deve mostrar os locais disponíveis para as reuniões.
RF009: O sistema deve bloquear a reserva de um local já reservado.
RF010: O sistema deve manter os participantes informados sobre os acontecimentos durante o processo de organização das reuniões.
RF011: O sistema deve permitir que um participante indique outra pessoa para representá-lo em uma reunião.
RF012: O sistema deve permitir informar o nível de prioridade para a presença de cada participante.
Como explicado na Seção 4.1.1, para ocorrer a definição do tipo de conteúdo
dois passos devem ser seguidos, sendo estes: I - Levantamento de possíveis tipos de
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
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
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
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
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
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
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
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
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
Tabela 12 - Catálogo de correlação gerado para o exemplo
Catálogo de correlações
Operacionalizações dos requisitos do catálogo
RNFs ou metas suaves impactadas
Conteúdos disponibilizados de maneira perceptível
Usabilidade Portabilidade
Fornecer mecanismo captcha - -
Fornecer alternativas textuais que identifiquem o captcha
+
Ajustar conteúdo para a navegação vertical em dispositivos móveis
Help + +
Utilizar componentes de interface que possam ter focos destacados por agentes de usuários
Help + +
Separar a apresentação do conteúdo utilizando CSS
Help + +
Na Tabela 12, além dos impactos negativos já citados para a Tarefa “Fornecer
mecanismo captcha”, temos casos de impactos positivos como, por exemplo, entre a
tarefa “Ajustar conteúdo para a navegação vertical em dispositivos móveis” e os
RNFs Usabilidade e Portabilidade. Neste artefato somente são destacados os
impactos que podem ser claramente definidos, ou seja, alguns impactos são
desconhecidos ou não foram detectados ainda, como no caso entre as tarefas
relacionadas ao uso do captcha e o RNF de Portabilidade.
Por fim, outro possível artefato de saída dessa atividade é o checklist para
controle de implementação dos requisitos de Acessibilidade Web. Como informado
anteriormente, o checklist deve servir como uma visão alternativa dos requisitos
contida no catálogo de RNFs (Seção 4.1.4). O sucesso na implementação de um
sistema tem grande dependência da qualidade dos artefatos gerados na etapa de
elicitação. Dessa forma, o checklist foi elaborado para aumentar o controle na
implementação dos requisitos e operacionalizações elicitadas. Além disso, com esse
artefato, os desenvolvedores poderão controlar também o motivo pelo qual algum
requisito não foi implementado, verificando assim possíveis falha de produtividade.
A Figura 25 apresenta um trecho do checklist gerado para o sistema
Agendador de reuniões.
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
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
5 Ferramenta Omnes Web
O termo “Omnes” tem origem no idioma latim e significa “Todos” na língua
portuguesa, já o termo Web (da sigla em inglês World Wide Web) é relacionado à
rede mundial de computadores. Esses dois termos foram unidos para formar a
expressão “Omnes Web” ou “Web de todos”, sendo esse o nome definido para a
ferramenta de apoio ao processo de elicitação proposto por esta dissertação.
A ferramenta Omnes Web foi desenvolvida com o objetivo de fornecer suporte
às atividades que fazem parte do método de elicitação dos requisitos de
Acessibilidade Web. A idéia é facilitar a extração de informações contidas nos
catálogos de RNFs, amenizando o problema de escalabilidade citado no Capítulo
anterior. O público alvo da Omnes Web pode englobar engenheiros de requisitos e
produtores de conteúdo pra Web em geral.
A ferramenta Omnes Web pode ser acessada no seguinte endereço:
http://omnesweb.ucore.com.br/. As seções a seguir apresentam as ferramentas
utilizadas para auxiliar o funcionamento da Omnes Web, sua arquitetura e
funcionalidades.
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
(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
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
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 – correlacoes-
projeto.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 – acessibilidade-
tabela.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
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
5.2.1 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
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
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
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
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
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
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
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
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
5.2.2 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
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
Figura 38 - Módulo de Artefatos: Exportação de XML do catálogos de RNFs
5.2.3 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.
94
Os principais benefícios observados na utilização da Omnes web estão
relacionados com custo de tempo gasto na elicitação e suporte para produzir
artefatos como o SIG do produto e o checklist. A diminuição do tempo gasto foi
promovida pela seleção automatizada dos elementos com base nas limitações físicas
e tipos de conteúdo relacionados aos RFs. Além da diminuição do tempo, essa
automatização diminuiu também o trabalho de elicitação, tendo em vista que não foi
necessário efetuar uma varredura completa no catálogo para extrair os elementos
desejados. Dessa forma, o problema da escalabilidade desses artefatos pôde ser
amenizado. Em relação a produção dos artefatos, o tempo e esforços gastos para
criação do SIG do produto e o checklist também foi perceptível. Tendo em vista que
para a verificação do SIG do produto, basta que o XML gerado pela Omnes Web seja
importado pela StarUML, permitindo assim os ajustes necessários. E em relação ao
checklist, a Omnes Web disponibiliza esse artefato de maneira totalmente
automatizada, sem que seja necessário algum procedimento por parte do usuário.
Apesar do suporte na modelagem do catálogo de RNFs, fornecido pelo plugin
Re-tools, algumas dificuldades surgiram na relação entre a ferramenta Omnes Web e
a StarUML. Entre essas dificuldades duas se destacaram e causaram problemas
consideráveis na implementação da Omnes Web. A primeira limitação está
relacionada ao fato da ferramenta StarUML limitar o espaço em 480mm na horizontal
para a montagem de catálogos baseados no NFR Framework. O segundo problema,
se deve ao fato da ferramenta StarUML possuir a limitação de não aceitar as
definições necessárias para organizar os elementos dentro do catálogo de RNFs
através do XML gerado pela Omnes Web.
Até mesmo o XML exportado pela própria StarUML não contém as
informações para a organização e localização dos elementos graficamente, fato este
que provoca a desorganização da disposição dos elementos gráficos do catálogo,
mesmo quando o XML importado foi gerado pela própria StarUML. A solução
adotada para esses dois problemas foi a criação de um arquivo para controle do XML
gerado, chamado “xmltemplate.php”. Através desse arquivo foram disponibilizadas
as configurações relacionadas ao limite horizontal de montagem do catálogo, assim
como a distância entre os elementos do catálogo.
95
Entre as limitações da Omnes Web, podemos citar que a mesma não
possibilita a visualização do SIG do projeto, necessitando assim de uma ferramenta
que pudesse montar o SIG através do XML exportado. Por isso, apesar dos
problemas citados, a StarUML foi a solução que melhor forneceu suporte tanto para
a criação do catálogo como na importação do XML gerado. Dessa forma, tornou-se
possível a visualização e /ou ajustes do SIG do projeto criado na Omnes Web,
justificando assim a escolha pela StarUML. Isso nos revela que o problema de
escalabilidade de abordagens orientadas a metas, ocorre já na atividade de desenho,
e se estende até a análise, que ainda carece de soluções adequadas. Outra limitação
presente na Omnes Web se refere ao fato desta ferramenta se limitar ao trabalho com
requisitos do domínio de Acessibilidade Web. Porém futuramente, alterações
podem ser realizadas para que essa estratégia considere outros RNFs e seus
respectivos catálogos, tornando-se assim uma ferramenta mais genérica.
96
6 Estudo de caso
Para avaliar o método de elicitação e sua ferramenta de apoio, propostos nesta
dissertação, foi elaborado um estudo de caso, com as seguintes etapas: I Elicitação
dos requisitos de Acessibilidade Web, II Prototipação de 2 projetos baseados na
elicitação dos requisitos da etapa anterior, e III Análise da acessibilidade nos
projetos implementados.
A Seção 6.1 apresenta o objetivo da execução desse estudo de caso, a Seção 6.2
contém o plano para a realização de cada etapa, a seção 6.3 apresenta detalhes da
execução do estudo de caso, a Seção 6.4 aborda a análise dos resultados produzidos
em cada etapa do estudo de caso, na Seção 6.5 há discussões sobre as ameaças para a
validade dos resultados, e por fim na seção 6.6 são abordadas as discussões finais
sobre o capítulo.
6.1 Objetivo
A realização desse estudo de caso tem como objetivo avaliar o suporte que a
estratégia apresentada nesta pesquisa oferece à atividade de elicitação dos requisitos
de Acessibilidade Web.
A utilização de artefatos como catálogos de RNFs, fornecidos pela abordagem
NFR Framework, proporciona a criação de extensas bases de conhecimento,
dificultando a análise e seleção de requisitos representados no framework. Como
apresentado no Capítulo 3, o catálogo de requisitos de Acessibilidade Web é um
exemplo de como essas bases podem ser extensas e complexas. Assim sendo, nosso
intuito é verificar se a utilização do processo aqui proposto e da Omnes Web
conseguem melhorar e viabilizar a elicitação de requisitos referentes a Acessibilidade
Web.
Dessa forma, foram elaboradas 3 questões de pesquisas a serem respondidas
com a execução do estudo de caso. A Tabela 13 apresenta as 3 questões de pesquisas
elaboradas.
97
Tabela 13 - Questões de pesquisa elaboradas para o estudo de caso
ID Questões de pesquisas
QP1 O método de elicitação e sua ferramenta de apoio causam algum impacto à atividade de elicitação de requisitos de Acessibilidade Web?
QP2 A documentação gerada pela estratégia de elicitação proposta causa algum impacto no processo de prototipação?
QP3 A documentação gerada pela estratégia de elicitação proposta causa algum impacto no produto?
Com as questões de pesquisas elaboradas, mostradas na tabela 13, visamos
investigar se a estratégia de elicitação desta pesquisa promove impactos na atividade
de elicitação, prototipação e no produto gerado. Além disso, visamos investigar
também se os impactos detectados são negativos ou positivos. Assim sendo, durante
a discussão dos resultados de cada questão de pesquisa, serão apresentadas
argumentações de acordo com os resultados apresentados com a execução do estudo
de caso.
Dessa forma, a primeira questão de pesquisa (QP1) foi elaborada com o
objetivo de identificar a contribuição que a estratégia proposta oferece ao processo de
elicitação de requisitos de Acessibilidade Web. Durante a análise dessa contribuição,
também verificamos o suporte fornecido por cada recurso disponibilizado por esta
pesquisa. Vale ressaltar que os recursos disponibilizados por esta pesquisa são três: I
- Catálogo de requisitos de Acessibilidade Web, II - Processo de elicitação, e III-
Ferramenta de apoio Omnes Web. Além de avaliar a estratégia de elicitação ,
registramos a experiência de cada participante na utilização do processo e de sua
ferramenta de apoio.
Já a segunda questão de pesquisa (QP2) visa extrair a avaliação dos grupos de
prototipadores em relação a documentação gerada pelos grupos de elicitadores, e
sobre a prototipação dos requisitos de Acessibilidade Web.
A terceira questão de pesquisa (QP3) visa investigar se a documentação
gerada pelo método e a ferramenta Omnes Web, propostos como estratégia de
elicitação, causa algum impacto no nivel de acessibilidade dos protótipos gerados.
Essa avaliação tanto a automatizada, através da ferramenta Wave (Wave, 2014),
como a manual, é realizada por participantes que desempenham o papel de usuários
finais.
98
6.2 Planejamento do estudo de caso
Como citado anteriormente, este estudo de caso consiste de três etapas,
Elicitação, Prototipação e Análise de Acessibilidade, como mostra a Figura 40. Na
primeira etapa, Elicitação, ocorre a utilização do método e da ferramenta definidos
nesta dissertação. Os requisitos elaborados nessa etapa são as entradas para a
segunda etapa do estudo de caso, Prototipação, na qual são geradas as aplicações
Web. Essas aplicações são avaliadas na terceira etapa, Análise de Acessibilidade.
Cada uma dessas etapas foi planejada para responder às questões de pesquisa QP1,
QP2 e QP3, respectivamente.
Este estudo de caso também foi organizado de modo a possibilitar duas
formas de comparação: I – para um mesmo estudo de caso, comparar os artefatos
produzidos por estratégias de elicitação diferentes; e II – para diferentes estudos de
caso, comparar os artefatos produzidos pela mesma estratégia de elicitação. Para
isso, foi necessário a utilização de dois cenários e o envolvimento de 14 participantes,
sendo 8 pessoas para a primeira etapa, 4 pessoas para a segunda etapa, e 2 pessoas
para a etapa final.
Figura 40 - Etapas do estudo de caso
99
Nas seções a seguir, detalhamos cada etapa do planejamento do estudo de
caso, indicando a seleção dos participantes, os artefatos a serem processados e
produzidos, e a preparação do ambiente e treinamento.
6.2.1 Etapa I: Elicitação
Nessa primeira etapa ocorre o levantamento dos requisitos de Acessibilidade
Web, basicamente é o momento onde a estratégia proposta por esta pesquisa é
utilizada, ou seja, o processo proposto é o controle para execução desta etapa, e a
ferramenta Omnes Web é um dos mecanismos de suporte, como mostrado na Figura
38. Vale ressaltar que o método de elicitação, apresentado nesta dissertação,
compreende definições como o tipo de conteúdo e limitações do público alvo para
efetuar a elicitação. No que se refere a limitação do público alvo, este parâmetro foi
definido de acordo com a limitação apresentada pelos participantes da etapa III, a
saber, limitação visual.
Com a execução desta primeira etapa do estudo de caso visamos responder a
primeira questão de pesquisa (QP1), que trata da avaliação do impacto causado pela
utilização da estratégia de elicitação aqui apresentada, e a diferença na utilização de
cada recurso disponibilizado (Seção 6.1). Dessa forma, para possibilitar a
comparação dos artefatos produzidos pelos elicitadores, citada na seção anterior, e
assim responder a QP1, foram definidas três situações para execução desta primeira
parte do estudo de caso. E Para cada uma dessas situações foram definidos quais os
recursos de elicitação seriam utilizados. A Tabela 14 apresenta as três situações
definidas e quais são os recursos permitidos para apoiar a elicitação em cada uma
delas.
Tabela 14 – Situações versus Recursos disponíveis na etapa I do estudo de caso
Situação Recursos utilizados
Catálogo de RNF Processo Ferramenta Omnes Web
Situação 1 X X X
Situação 2 X X
Situação 3 X
Como mostra a Tabela 14, na primeira situação, será permitida a utilização do
Catálogo de RNFs de Acessibilidade Web, juntamente com o processo de elicitação e
100
a sua ferramenta de apoio Omnes Web. Na segunda situação, a elicitação deve
ocorrer de forma manual, ou seja, sem o uso da ferramenta. Na terceira situação será
permitida apenas a utilização do catálogo de RNFs, além de manual, a elicitação
deverá ser feita de maneira Ad-hoc.
A configuração das situações, apresentada na Tabela 14, tem o objetivo de
avaliar variáveis como o tempo gasto e a qualidade da elicitação resultante nas 3
situações elaboradas. Essa avaliação torna possível identificar a diferença e vantagem
de utilizar ou não a ferramenta Omnes Web, comparando os resultados entre as
situações 1 e 2. Já a comparação dos resultados entre as situações 2 e 3 torna possível
mostrar o impacto da utilização do processo proposto, visando verificar o suporte
que a estratégia oferece à elicitação de RNFs, mesmo que não haja ferramenta. Dessa
forma, além de avaliar o impacto promovido pelos recursos de elicitação utilizados
em cada situação elaborada, podemos também verificar a diferença entre as
situações. Ou seja, tentar verificar se a ferramenta Omnes Web realmente oferece
algum suporte ao método de elicitação, e por fim verificar se esse método promove
algum suporte a atividade de elicitação, ou se somente a utilização do catálogo de
definições do NFR Framework já seria suficiente. Vale salientar que para cada
situação foram designados diferentes grupos de participantes.
Espera-se que com a comparação dos resultados alcançados nas três situações
possamos demonstrar o impacto que o uso da estratégia proposta causa na atividade
de elicitação dos requisitos de Acessibilidade Web, respondendo assim a QP1.
6.2.1.1 Artefatos e ferramentas da elicitação
Essa primeira etapa recebe como artefatos de entrada o catálogo de requisitos
de Acessibilidade Web, e os documentos de requisitos referentes aos projetos para os
quais serão elicitados os requisitos de Acessibilidade Web. Foram usados dois
projetos, sendo estes: I - Um aplicativo para criação de galerias de fotos interativa, e
II - Um aplicativo para gestão de Metas. O primeiro projeto é um aplicativo que visa
facilitar a criação de galerias de fotos Web. O aplicativo deve permitir aos usuários
criar, organizar e configurar galerias e gerando automaticamente as páginas Web
referentes à galeria criada. O segundo projeto tem o propósito de auxiliar na
definição e controle de ações importantes para alcançar determinadas metas. Os
101
documentos de requisitos referentes aos projetos I e II são mostrados nos apêndices
C e D respectivamente (escopo e lista dos requisitos de cada projeto).
Para essa primeira etapa, além da ferramenta Omnes Web, a StarUML fornece
suporte para as três situações mostradas Tabela 14. Na situação 1, a StarUML é
utilizada apenas para importar o XML do catálogo gerado pela ferramenta Omnes
Web, permitindo assim que o SIG do produto possa ser visualizado. Na situação II, a
StarUML fornece suporte para a visualização, exploração e extração dos requisitos
contidos no catálogo de Acessibilidade Web. Na terceira situação, o uso da StarUML
tem o mesmo sentido da situação anterior, porém sem a utilização do processo de
elicitação proposto por esta pesquisa.
Como saída, essa etapa gera as elicitações relacionadas a cada situação
mostrada na Tabela 14. A documentação resultante dessas elicitações compreendem
três artefatos, sendo estes: I Nova versão do catálogo de requisitos de Acessibilidade
Web, II Checklist para controle de prototipação, III Catálogo de correlações. Como
apresentado no Capítulo 4, o primeiro artefato compreendendo o catálogo de RNFs
contém os requisitos de acessibilidade Web elicitados. O segundo artefato checklist
fornece uma estrutura de relação entre os requisitos contidos no catálogo e os
requisitos funcionais, visando proporcionar um controle maior sobre o que deve ser
prototipado e implementado de Acessibilidade Web em cada RF. O terceiro artefato
contém uma Tabela com as informações dos impactos detectados entre os requisitos
de acessibilidade e os outros RNFs elicitados.
6.2.1.2 Seleção dos participantes para a elicitação
Foram selecionadas 8 pessoas para participar dessa etapa. Os participantes
foram divididos em 4 grupos, sendo dois grupos para a primeira situação e dois
grupos para as duas outras situações. Os grupos 1 e 2 ficaram responsáveis pela
elicitação dos dois projetos usados para esse estudo de caso, enquanto que os grupos
3 e 4 ficaram responsáveis por um dos projetos, como mostra a Tabela 15.
102
Tabela 15 - Configuração dos participantes para a etapa de elicitação do estudo de caso
Situação Grupos Projetos designados
Projeto 1 Projeto 2
Situação 1 Grupo 1 e Grupo 2 X X
Situação 2 Grupo 3 X
Situação 3 Grupo 4 X
A definição de duas duplas trabalhando na situação 1, tem o objetivo de
verificar se a utilização da ferramenta Omnes Web, em dois projetos diferentes,
proporciona resultados com padrões semelhantes. Levando em consideração o
tempo gasto na elicitação, a comparação dos artefatos gerados e avaliação de uso da
ferramenta por parte dos elicitadores.
A composição dos grupos foi feita de acordo com o nível de experiência e
conhecimento apresentado por cada participante em Acessibilidade Web e Elicitação
de Requisitos através da abordagem NFR Framework. Assim sendo, visando
estabelecer um equilíbrio do conhecimento em cada dupla, a distribuição dos
participantes foi baseada em informações, previamente declaradas, em relação aos
seus níveis de conhecimento.
A definição de cada grupo ocorreu antes da execução do estudo de caso, cada
um dos participantes preencheu um questionário, mostrado no apêndice A, contendo
duas seções. A primeira seção relaciona questões sobre experiência e o conhecimento
dos participantes em Acessibilidade Web, contendo sete conjecturas acerca desta área
de conhecimento. A segunda seção relaciona questões sobre a experiência e
conhecimento do participante em relação a Elicitação de Requisitos através da
abordagem NFR Framework, contendo 9 conjecturas sobre esta área de
conhecimento.
Com base na estrutura para a avaliação de questionários fornecida pela escala
Likert (Breffle et al. 2011), critérios de avaliação foram relacionados com as
conjecturas do questionário, esses critérios foram associados a valores de 0 a 4, onde
0 indica o menor nível possível de conhecimento e 4 o maior nível. Assim, de acordo
com a soma das respostas, tornou-se possível identificar o nível de experiência para
cada participante. Foram considerados inexperientes aqueles participantes cuja soma
das respostas foi menor que 14, no caso da primeira seção, e menor que 18 na
103
segunda seção. Foram considerados experientes aqueles participantes cuja soma das
respostas foi igual ou maior que 14, para a primeira seção, e igual ou maior que 18 na
segunda seção.
Após a identificação do nível de experiência dos participantes, cada grupo foi
organizado visando promover o equilíbrio de conhecimento entre os participantes,
como mostra a Tabela 16.
Tabela 16 - Configurações definidas para formação de duplas da etapa I
Grupo Experiência - Participante 1 Experiência - Participante 2 Elicitação de
requisitos Acessibilidade
Web Elicitação de
requisitos Acessibilidade
Web
G1 X
G2 X X
G3 X
G4 X X
Conforme a Tabela 16, dos 8 participantes 5 apresentaram experiência em uma
das áreas de conhecimento para a realização do estudo de caso, logo um dos grupos
teria que ter obrigatoriamente dois participantes com algum nível de experiência.
Devido a situação de estudo definida para o grupo 4, onde os participantes
utilizaram somente o catálogo de RNFs, concluímos que seria conveniente definir
esse grupo com os dois participantes experientes em pelo menos uma das áreas.
Assim sendo, com excessão do grupo 4, os outros 3 grupos foram estruturados
sempre contendo um participante com experiência em pelo menos uma das áreas de
conhecimento, e um participante sem experiência alguma.
6.2.1.3 Preparação do ambiente e treinamento para a elicitação
A ferramenta StarUML foi a única instalação necessária nos computadores
utilizados para a execução desta primeira etapa. Além de importar o XML do
catálogo de RNFs, gerado pela ferramenta Omnes Web, A StarUML também serve
como instrumento para as duplas que não utilizaram a ferramenta Omnes Web.
A fim de amenizar possíveis problemas relacionados ao nível de
conhecimento dos elicitadores, detectado com o preenchimento do questionário para
categorização do nível de experiência dos participantes, um treinamento foi
104
ministrado antes da execução do estudo de caso, abordando a Acessibilidade Web e
Elicitação de Requisitos através da abordagem NFR Framework.
6.2.2 Etapa II: Prototipação
Nessa segunda etapa ocorre a prototipação dos 2 projetos definidos para esse
estudo de caso (Seção 6.2.1.1). Essa prototipação foi baseada nas elicitações
resultantes da etapa I, onde os requisitos funcionais foram relacionados aos
requisitos de Acessibilidade Web elicitados.
O objetivo de executar essa etapa é investigar o suporte que a documentação
gerada na etapa de elicitação oferece à implementação da Acessibilidade Web nos
projetos, respondendo assim a QP2.
6.2.2.1 Artefatos e ferramentas da Prototipação
Essa etapa recebe como artefatos de entrada as elicitações produzidas na etapa
I. Os elicitadores disponibilizaram 6 documentações de requisitos, cada
documentação dessa disponibilizou os seguintes artefatos: O SIG do produto, O
catálogo de correlações e o checklist para controle da prototipação. As atividades de
prototipação, realizadas pelos participantes dessa segunda etapa, ocorreu com base
nessa documentação fornecida pelos participantes da etapa I. Além de fornecer a
especificação dos requisitos, o SIG do produto foi utilizado pelos prototipadores para
a compreensão do relacionamento entre as alternativas para atingir a Acessibilidade
Web. O catálogo de correlações foi utilizado para verificação do resumo de impactos
detectado entre os RNFs. Por fim, o checklist foi utilizado para fornecer uma visão
alternativa ao SIG do produto, permitindo também o controle sobre as
funcionalidades prototipadas.
Devido a etapa de prototipação possuir apenas 4 participantes, das 6
documentações geradas na etapa de elicitação, duas não foram aproveitadas. Como
os grupos 1 e 2 da etapa de elicitação trabalharam nos dois projetos (ver seção
6.2.1.2), então uma documentação de cada um desses dois grupos foi descartada. Em
relação ao grupo 1, a documentação descartada pertencia ao projeto 2, relacionada ao
Aplicativo para gestão de metas. Enquanto que a documentação descartada do grupo
2 pertencia ao projeto 1, relacionado ao Aplicativo para criação de galeria de fotos
105
interativa. Dessa forma, garantimos que cada participante da etapa II recebesse um
projeto diferente para a prototipação. A tabela 17 apresenta a distribuição da
documentação, gerada pelos elicitadores, entre os participantes dessa segunda etapa.
Tabela 17 - Distribuição da documentação gerada na etapa I entre os participantes da etapa II
Elicitadores – Etapa I
Situação Grupo Prototipadores – Etapa II
Participante 1 Participante 2 Participante 3 Participante4
Situação 1 Grupo 1 X
Grupo 2 X
Situação 2 Grupo 3 X
Situação 3 Grupo 4 X
Como mostrado na tabela 17, o participante 1 da etapa de prototipação
recebeu a documentação gerada pelo grupo 1 da etapa de elicitação. Enquanto que o
participante 2, dessa segunda etapa, recebeu a documentação produzida pelo grupo
2 da etapa de elicitação. Lembrando que os grupos 1 e 2 produziram os artefatos de
acordo com a configuração da situação I da etapa de elicitação. Já o participante 3
recebeu a documentação produzida pelo grupo 3, relacionado com a situação 2 da
etapa de elicitação. Por fim, o participante 4 recebeu a documentação gerada pelo
grupo 4, relacionado com a situação 3 da etapa de elicitação. Através dessa
documentação, os 4 participantes dessa segunda etapa prototiparam os 2 projetos
definidos para esse estudo de caso (seção 6.2.1.1). Essas prototipações são os artefatos
de saída dessa segunda etapa.
Devido a disponibilidade de tempo dos participantes dessa segunda etapa,
não foi possível prototipar todos os requisitos funcionais levantados para os dois
projetos relacionados. Assim sendo, ficou definido que para cada projeto seriam
prototipados grupos de funcionalidades que possibilitassem a criação de casos de
testes a serem executados na terceira etapa do estudo de caso.
A definição sobre as ferramentas para modelagem e implementação, assim
como a escolha da linguagem de desenvolvimento dos aplicativos ficaram a cargo
dos desenvolvedores. Essa flexibilidade se tornou necessária devido a cada
participante dessa etapa apresentar preferência ou domínio maior sobre linguagens e
ferramentas distintas, não possibilitando assim adotar uma IDE ou linguagem de
programação padrão para a implementação das aplicações Web. Apesar dessa
106
flexibilidade, os participantes foram orientados a verificarem se as tecnologias
adotadas ofereciam suporte a prototipação ou implementação dos requisitos de
Acessibilidade Web, com base no WCAG 2.0.
6.2.2.2 Seleção dos participantes da Prototipação
Foram selecionadas 4 pessoas para execução dessa segunda etapa, cada um
dos participantes ficou responsável pela prototipação de um dos projetos, com base
na documentação dos requisitos gerada na etapa de elicitação, ou seja, cada
participante deve prototipar sozinho o projeto pelo qual ficou responsável. Como
apresentado na tabela 17, os participantes 1, 3 e 4 ficaram responsáveis pela
prototipação do projeto 1, enquanto que o participante 2 ficou responsável pela
prototipação do projeto 2. Possuir alguma experiência no desenvolvimento de
projetos para a Web, e disponibilidade para a participação foram os critérios
utilizados para selecionar os participantes dessa etapa. Salientando que estes
participantes não são os mesmos da etapa de elicitação.
Antes do inicio dessa segunda etapa, cada participante respondeu um
questionário para a categorização de perfil. Esse questionário, apresentado no
apêndice H, foi elaborado com o objetivo de registrar a experiência dos participantes
no desenvolvimento de softwares e Acessibilidade Web. O questionário possui 4
perguntas, onde as três primeiras questões visam coletar a experiência do
participante no desenvolvimento de software, enquanto a 4º questão visa registrar a
experiência do participante em relação a Acessibilidade Web.
A 4º pergunta do questionário possui 9 conjecturas sobre o conhecimento dos
participantes em Acessibilidade Web, que foram relacionados a critérios de
avaliação, contendo valores de 0 a 4. Assim sendo, para a definição da experiência
em acessibilidade, selecionamos a mesma estratégia utilizada no primeiro
questionário fornecido aos participantes da etapa de elicitação (Seção 6.2.1.2). Foram
considerados experientes aqueles participantes cuja soma das respostas foi igual ou
maior que 18.
Conforme as respostas para as questões 1, 2 e 3, fornecidas pelos participantes,
concluímos que todos os participantes possuíam domínio e níveis de experiência
107
suficientes para participarem dessa segunda etapa do estudo de caso. Todos os
participantes responderam que já utilizaram no mínimo 3 linguagens de
programação, desenvolvem para a Web há mais de um ano, e usam no mínimo 3
padrões de projeto.
A Tabela 18 apresenta a classificação da experiência dos usuários em relação
ao desenvolvimento e Acessibilidade Web. Em relação a Acessibilidade Web,
conforme apresentado na Tabela 18, dos quatro participantes dois apresentaram
experiência em Acessibilidade Web.
Tabela 18 - Níveis de experiência dos participantes da segunda etapa
Participante Experiência Desenvolvimento Web Acessibilidade Web
Participante 1 X
Participante 2 X X
Participante 3 X
Participante 4 X X
6.2.2.3 Preparação do ambiente e treinamento para a Prototipação
Cada participante instalou e utilizou em seus computadores a IDE (Integrated
Development Environment) que geralmente utilizam para o desenvolvimento de suas
aplicações Web. Como já citado na Seção 6.2.2.1, essa flexibilidade ocorreu devido
aos participantes possuírem preferências e domínios sobre ferramentas e linguagens
de programação distintas.
Antes de iniciar a execução da segunda etapa, um treinamento envolvendo
Acessibilidade Web e NFR Framework foi ministrado para os desenvolvedores.
Além de familiarizar os participantes com conhecimento sobre a Acessibilidade Web,
a idéia foi mostrar os conceitos básicos da abordagem NFR Framework para que os
desenvolvedores consigam entender as informações passadas através do catálogo de
RNFs de Acessibilidade Web, que é um dos artefatos a serem fornecidos pelos
participantes da etapa de elicitação.
6.2.3 Etapa III: Análise da acessibilidade
A terceira e última etapa desse estudo de caso compreende a análise da
acessibilidade nos projetos implementados. Essa análise ocorre através de testes
108
manuais, com julgamento e avaliação humana, e testes automatizados com o suporte
da ferramenta Wave (Wave, 2013) para avaliação da acessibilidade Web.
Para conduzir a análise manual da Acessibilidade Web, foram definidos
roteiros de testes, contendo as tarefas a serem executadas pelos participantes dessa
etapa nos projetos resultantes da etapa de prototipação (Seção 6.2.1.1). Cada roteiro
foi elaborado com uma quantidade distinta de tarefas, de acordo com a quantidade
de requisitos funcionais prototipados em cada produto.
Dessa forma, foi possível definir 8 tarefas para o roteiro relacionado às 3
implementações geradas para o projeto 1, realizadas pelos participantes 1, 3 e 4
(Seção 6.2.2.2). Em relação ao roteiro do projeto 2, implementado pelo participante 2,
foram definidas 11 tarefas. Os apêndices L e M trazem os roteiros de tarefas dos
projetos 1 e 2 respectivamente.
Para controlar e avaliar a execução de cada tarefa dos roteiros, os seguintes
três fatores foram levados em consideração: I – Número de tentativas para executar a
tarefa, II – Necessidade de auxilio para executar a tarefa, III – Status da tarefa.
A execução dessa etapa visa responder a QP3, verificando se a documentação
gerada na etapa de elicitação e utilizada na etapa de prototipação, consegue
influenciar o nível de acessibilidade em cada aplicação implementada.
6.2.3.1 Artefatos e ferramentas da análise da acessibilidade
Essa etapa recebe como artefatos de entrada os 4 projetos prototipados na
etapa II. Os artefatos de saída são os resultados dos testes de Acessibilidade Web
realizados, a saber: o resultado dos testes manuais, o questionário respondido pelos
participantes desta etapa a respeito da avaliação manual nas aplicações
implementadas, e o resultado dos testes efetuados na ferramenta Wave.
A ferramenta Wave (Wave, 2013) foi selecionada para a execução dos testes
automatizados devido a sua análise ser baseada nas diretrizes do WCAG 2.0. Além
disso, foram considerados os seguintes fatores: fácil utilização, interface amigável,
relatórios simples e completos, consistência na identificação dos problemas
encontrados, entre outros.
109
6.2.3.2 Seleção dos participantes para a análise da acessibilidade
Para essa etapa foram selecionados dois participantes, ambos com a limitação
visual em seu grau mais acentuado, ou seja, sem visão. Esses participantes
realizaram os testes manuais, utilizando as aplicações resultantes da etapa de
prototipação, a fim de verificar o grau de acessibilidade gerado em cada projeto. Já os
testes automatizados, através da ferramenta Wave, foram realizados pelo supervisor
desse estudo de caso (autor da pesquisa).
Antes de iniciar a execução dessa terceira etapa, os participantes responderam
ao questionário para a categorização do perfil, contendo 8 perguntas. Esse
questionário, apresentado no apêndice I, foi criado com o objetivo de registrar as
características, assim como a experiência dos participantes no uso de tecnologias
relacionadas a Web. A Tabela 19 apresenta as respostas, fornecidas pelos
participantes, para as perguntas 1,2,3 e 4 do questionário de categorização do perfil.
Tabela 19 - Respostas das perguntas 1,2,3 e 4 do questionário para a categorização de perfil dos
participantes da 3º etapa
Pergunta Respostas Participante 1 Participante 2
1 - Qual a sua limitação física? Sem Visão Sem Visão
2 - Sua limitação física teve origem no seu nascimento? Caso não, informe há quanto tempo você possui essa limitação.
Não. O participante possui a limitação há 6 anos.
Sim
3- Há quanto tempo você navega na Web? Acima de dois anos Acima de dois anos
4- Quais as ferramentas de suporte você costuma utilizar durante a navegação na Web?
Leitores de tela Leitores de tela
Como apresenta a Tabela 19, as respostas para a primeira pergunta do
questionário mostra que os dois participantes não possuem visão. Já as respostas
para a segunda pergunta, que se relaciona com o tempo que cada participante possui
a limitação, mostram que o participante 1 possui a limitação há 6 anos, enquanto o
participante 2 possui a limitação desde o nascimento. Essa segunda pergunta é
importante, pois o fato do participante já ter possuído visão pode fornecer uma
compreensão diferenciada e facilitada sobre a execução das tarefas solicitadas
durante o estudo de caso. Essa hipótese foi discutida durante a aplicação do
110
questionário, onde o participante 1 afirmou que o fato de já ter possuído uma visão
normal tem facilitado a utilização da web, tendo em vista que ele já utilizava essa
tecnologia antes de possuir a limitação visual.
Ainda em relação Tabela 19, as respostas da terceira pergunta, fornecidas
pelos participantes, mostra que ambos utilizam a Web há mais de 2 anos. E em
relação a 4º pergunta, os softwares para leitura de tela foram as únicas ferramentas
citadas para fornecer suporte a navegação Web.
A 5º pergunta do questionário registrou quais dispositivos já utilizados pelos
participantes para a navegação Web. Os dois participantes informaram que já
utilizaram smartphones, notebooks e desktops. Apenas o participante 2 afirmou já
ter utilizado tablet. A 6º pergunta verificou quais as atividades que os participantes
costumam realizar na Web, os dois participantes responderam que costumam fazer
compras, estudar e ouvir músicas. Apenas o participante 1 afirmou utilizar redes
sociais.
A questão 7 registrou qual a avaliação dos participantes em relação ao nível
da Acessibilidade Web disponibilizado atualmente, os dois participantes se
mostraram parcialmente satisfeitos, entre as justificativas afirmaram que apesar da
melhoria percebida nos últimos anos, ainda encontram dificuldades para usufruir de
determinados conteúdos disponibilizados. A questão 8 solicitou que os participantes
citassem quais os principais problemas enfrentados durante a navegação web, sendo
informados os seguintes problemas: Links inacessíveis, falta de descrição textual
para as imagens e componentes de interface sem etiquetas. Desses problemas citados
na questão 8, o mais recorrente é a falta de descrição textual das imagens
disponibilizadas nos sites e aplicativos Web.
6.2.3.3 Preparação do ambiente e treinamento para a análise da acessibilidade
Para a realização dos testes manuais foi utilizado um notebook com teclado
convencional, possuindo marcações táteis nas teclas “F” e “J”, atendendo os padrões
da Associação Brasileira de Normas Técnicas (ABNT, 2014). Essas marcações nas
duas teclas citadas são basicamente linhas definidas em um leve relevo, que servem
111
para guiar a localização das teclas, facilitando a digitação para pessoas com
limitações visuais.
Para a leitura de tela foi utilizado o software NVDA (NonVisual Desktop
Access) na versão 2013.1rc1 (NVDA, 2014). Esse software foi indicado pelos próprios
participantes dessa etapa, sua utilização é grátis, sendo baseada na licença pública
GNU (General Public License).
Antes de iniciar os testes, os participantes receberam um treinamento
contendo detalhes sobre os objetivos do estudo de caso, assim como informações
necessárias para avaliação das aplicações fornecidas.
6.3 Execução do estudo de caso
Para a execução de cada etapa do estudo de caso, algumas atividades foram
realizadas a fim de garantir a melhor execução dos procedimentos necessários. Os
Capítulos a seguir descrevem como se deu a execução de cada uma das 3 etapas.
6.3.1 Execução da etapa de elicitação
A execução da etapa de elicitação do estudo de caso iniciou-se após a
preparação do ambiente, o preenchimento do questionário para a categorização de
perfil dos participantes, a divisão dos grupos e o treinamento dos participantes.
A execução dessa etapa ocorreu nas dependências da Universidade Federal do
Rio Grande do Norte, em uma sala reservada para esta execução. Os grupo 1 e 3
executaram as atividades no dia 22 de Janeiro de 2014 , e os Grupo 2 e 4 no dia 27 de
Janeiro de 2014. Essa configuração ocorreu de forma a atender a disponibilidade de
agenda dos participantes.
Os elicitadores utilizaram suas próprias máquinas, contendo a instalação da
ferramenta StarUML e os artefatos de entrada compreendendo os documentos de
requisitos dos projetos e o catálogo de requisitos de Acessibilidade Web. Para
facilitar a geração dos artefatos produzidos na primeira etapa, cada participante
recebeu os arquivos contendo o template dos artefatos checklist e catálogo de
correlações entre os RNFs.
112
Visando garantir o melhor andamento da etapa de elicitação, alguns
procedimentos foram realizados, como segue:
1) Solicitação aos participantes para que deixassem abertos somente as ferramentas e sites
relacionados a execução do estudo de caso: Esse procedimento foi importante para
garantir o foco dos elicitadores na execução das tarefas do estudo de caso;
2) Acessar a Ferramenta StarUML e os artefatos de apoio a execução da elicitação: Os
participantes acessaram a ferramenta STARUML e efetuaram a importação do
XML do catálogo de requisitos de Acessibilidade Web fornecido. Além desse
catálogo, cada grupo recebeu os documentos de requisitos dos projetos. Os
grupos 1 e 2 ficaram responsáveis pela elicitação dos requisitos de
Acessibilidade Web para os dois projetos elaborados, assim sendo, receberam
os documentos de requisitos correspondentes. Enquanto que os grupos 3 e 4
receberam a documentação referente apenas ao projeto do Aplicativo para
criação de galeria de fotos interativa. Além dos artefatos, para facilitar a
memorização e garantir a ordem de execução de cada procedimento, os
grupos receberam um documento contendo o roteiro para execução de cada
atividade.
3) Aplicação do processo semi-automatizado para elicitação dos requisitos de
Acessibilidade Web: Os grupos 1, 2 e 3 realizaram as 4 atividades do método
proposto por esta pesquisa de dissertação, sendo estas: I - Análise dos
requisitos funcionais para definir os tipos de conteúdo necessários, II - A
Seleção dos requisitos de Acessibilidade Web, III - Análise de conflito entre os
RNFs, e por fim IV – Geração dos artefatos. No caso dos grupos 1 e 2 a
execução se deu com a utilização da ferramenta Omnes Web, enquanto o
grupo 3 executou o processo de maneira manual.
Após a execução dos procedimentos apresentados acima, os dados resultantes
foram coletados e armazenados. A coleta desses dados ocorreu a partir de duas
formas distintas, sendo estas: I - Através dos artefatos produzidos com a execução da
elicitação, e II – Através do questionário de pós-execução do estudo de caso,
apresentado no apêndice B desta dissertação.
113
6.3.2 Execução da etapa de prototipação
Os participantes dessa segunda etapa informaram indisponibilidade para a
execução das atividades relacionadas ao estudo de caso em um local e horário pré-
definidos. Entre as justificativas, os participantes informaram o envolvimento com
outros projetos, e que para viabilizar a participação no estudo de caso, o ideal seria
deixá-los produzir em locais e horários definidos por eles. Alguns participantes
também justificaram afirmando que a prototipação das funcionalidades solicitadas,
levando em consideração os requisitos de Acessibilidade, consumiria um tempo
relevante, fundamentando assim, a necessidade de flexibilizar a execução de suas
tarefas. Dessa forma, a fim de viabilizar a execução das atividades relacionadas ao
estudo de caso, concedeu-se a flexibilidade solicitada pelos participantes.
Antes de iniciar a execução dessa segunda etapa, após o treinamento os
participantes receberam os artefatos produzidos na etapa de elicitação. Os
participantes 1 e 3 receberam os artefatos, produzidos pelos grupos 1 e 3, no dia 24
de janeiro de 2014. Enquanto que os participantes 2 e 4 receberam os artefatos,
produzidos pelos grupos 2 e 4, no dia 28 de janeiro de 2014. Salientando que os
grupos 1 e 2 da etapa de elicitação trabalharam nos dois projetos definidos para esse
estudo de caso, gerando 4 documentações de requisitos. Porém duas dessas 4
documentações foram descartadas (ver seção 6.2.2.1), dessa forma, a documentação
que foi de fato disponibilizada pelo grupo 1 pertencia ao projeto 1, relacionado ao
Aplicativo para criação de galeria de fotos interativa. Enquanto que o grupo 2
disponibilizou a documentação do projeto 2, relacionado ao Aplicativo para a gestão
de Metas. Os grupos 3 e 4 disponibilizaram a documentação de requisitos do projeto
1. Em relação ao período de execução das atividades, o participante 1 realizou a
prototipação no período de 26/01/04 à 03/02/14. O participante 2 utilizou o período
de 07/02/14 à 12/02/14. O participante 3 utilizou o período de 07/02/14 à
08/02/14. E por fim, o participante 4 realizou a prototipação no período de 05/02/14
à 08/02/14.
Visando garantir o melhor andamento da etapa de prototipação, alguns
procedimentos foram realizados, como segue:
114
1) Solicitação aos participantes para que registrassem os dias e horários em que a
prototipação ocorreu: Tendo em vista que os participantes executaram a
implementação de acordo com suas disponibilidades, o controle em relação as
datas de execução e horários serviu para indicar o tempo despendido para a
prototipação dos projetos;
2) Acessar o material de apoio do WCAG 2.0: Para sanar eventuais dúvidas sobre
“como” implementar os requisitos de Acessibilidade Web, contidos nos
artefatos fornecidos, os participantes foram orientados a acessar os links
relacionados a exemplos de prototipação disponibilizados na documentação
do WCAG 2.0.
Após a execução dos procedimentos apresentados acima, os dados resultantes
foram coletados e armazenados, assim como ocorreu na primeira etapa. A coleta
desses dados ocorreu a partir de duas formas, sendo estas: I - Através dos protótipos
criados com a execução da prototipação, e II – Através do questionário de pós-
execução do estudo de caso, apresentado no apêndice J desta dissertação.
6.3.3 Execução da etapa de Análise da Acessibilidade
A execução da etapa de análise da acessibilidade do estudo de caso iniciou-se
após a preparação do ambiente e o preenchimento do questionário para a
categorização de perfil dos participantes.
A execução dessa etapa ocorreu nas dependências da Universidade Federal do
Rio Grande do Norte, no laboratório de acessibilidade da Biblioteca Central Zila
Mamede. Os dois participantes relacionados executaram o as atividades no dia 12 de
Fevereiro de 2014.
Visando garantir o melhor andamento desta etapa, alguns procedimentos
foram realizados, como segue:
1) Solicitação aos participantes para que deixassem abertos somente os aplicativos a
serem analisados: Devido a ferramenta para a leitura de tela ler toda e qualquer
informação de softwares abertos, foi solicitado aos participantes que
fechassem os aplicativos não relacionados às atividades do estudo de caso,
115
para evitar conflitos de informações recebidas durante a análise da
acessibilidade;
2) Configuração do NVDA: foi solicitado que cada participante configurasse, de
acordo com suas preferências, a velocidade de leitura de tela do NVDA, assim
como o volume do áudio no sistema operacional.
Após a execução dos procedimentos apresentados acima, os dados resultantes
foram coletados e armazenados. A coleta desses dados também ocorreu a partir de
duas formas, sendo estas: I - Através dos roteiros de tarefas, apresentados nos
apêndices L e M, e II – Através do questionário de pós-execução do estudo de caso.
6.4 Análises dos dados extraídos durante a execução das etapas
do estudo de caso
Após a execução de cada uma das etapas do estudo de caso os dados foram
extraídos e analisados, tornando possível assim responder as questões de pesquisas
levantadas.
A seguir são apresentadas as análises sobre os dados extraídos em cada etapa
do estudo de caso. A Seção 6.4.1 apresenta a análise sobre os dados extraídos durante
a execução da etapa de elicitação, utilizados para responder a QP1. A Seção 6.4.2
apresenta a análise dos dados extraídos durante a execução da etapa de prototipação,
utilizados para responder a QP2. E por fim, na Seção 6.4.3 é apresentada a análise
sobre os dados extraídos durante a execução da etapa de análise da acessibilidade,
utilizados para responder a QP3.
6.4.1 Dados extraídos na etapa de elicitação
Esta Seção apresenta a análise sobre os dados extraídos durante a execução da
etapa de elicitação do estudo de caso, visando responder a primeira questão de
pesquisa contendo a seguinte pergunta: “O processo de elicitação e sua ferramenta de
apoio causam algum impacto à atividade de elicitação de requisitos de Acessibilidade Web?”.
Para responder a QP1, foram considerados três fatores, sendo estes: I a
corretude dos dados obtidos na elicitação dos requisitos de Acessibilidade Web, II O
116
tempo total despendido para execução da elicitação, e III A análise sobre a
documentação gerada. Além disso, a avaliação dos participantes em relação a
utilização dos recursos disponibilizados por esta dissertação (Seção 6.2.1), também
foi considerada. A seguir são apresentadas as análises dos dados extraídos para
responder a QP1.
6.4.1.1 Corretude dos dados, tempo despendido e análise da documentação gerada
Para verificar a corretude dos dados obtidos na elicitação dos requisitos de
Acessibilidade Web, foi efetuado um balanço para comparar o número de requisitos
e respectivas operacionalizações extraídas do catálogo de RNFs pelos participantes
em relação a quantidade existente no catálogo, levando em consideração as
limitações do público alvo e tipos de conteúdo dos requisitos funcionais, passados
como parâmetros da elicitação. Assim sendo, a análise da corretude se baseia na
verificação da eficiência dos elicitadores na extração da quantidade esperada de
requisitos.
As limitações definidas para o público alvo dos projetos foram as limitações
visuais e auditivas. Já os tipos de conteúdo definidos para os requisitos funcionais
foram Texto, Imagem e Áudio. O catálogo de requisitos de Acessibilidade Web,
fornecido aos participantes, contém 63 requisitos vinculados ao tipo de limitação
Visual, incluindo as limitações específicas de Daltonismo, Baixa Visão e Sem Visão. E
Vinculado ao tipo de limitação auditiva existem 31 requisitos.
Dessa forma, ao todo o catálogo possui 94 requisitos vinculados às duas
limitações em questão. Porém nem todos esses requisitos possuem
operacionalizações vinculadas aos tipos de conteúdos definidos para os RFs dos dois
projetos. Assim sendo, de acordo com a configuração da elicitação, definida na
segunda atividade do processo (Seção 4.1.2), era esperado que os participantes
extraíssem do catálogo 44 requisitos de acessibilidade com suas respectivas
operacionalizações.
A tabela 20 mostra os dados obtidos da elicitação para o projeto do aplicativo
para criação de galeria de fotos interativa.
117
Tabela 20 - Requisitos de Acessibilidade extraídos – Projeto 1
Configuração Grupo Requisitos encontrados (%)
Operacionalizações encontradas (%)
Situação 1: Ferramenta + processo + catálogo
Grupo 1 100% 100%
Grupo 2 100% 100%
Situação 2: Processo + Catálogo Grupo 3 90,90% 86,75 %
Situação 3: Catálogo Grupo 4 81,81% 70,19%
Verificando a quantidade de requisitos que cada um dos grupos extraiu,
apresentada na tabela 20, ficou constatado que os grupos 1 e 2, que utilizaram o
método junto a ferramenta Omnes Web, conseguiram abranger todos os requisitos e
suas respectivas operacionalizações disponíveis no catálogo de RNFs. Enquanto que
o grupo 3 conseguiu abranger 90,90% do total de requisitos de acessibilidade
disponíveis no catálogo, e em relação as operacionalizações, o grupo 3 conseguiu
Abranger 86,75 % do total.
Ainda em relação aos dados da tabela 20, o grupo 4 que realizou a elicitação
utilizando apenas o catálogo de RNFs e de maneira ad-hoc conseguiu abranger
81,81% dos requisitos de acessibilidade Web, em relação as operacionalizações a
abrangência foi de 70,19%. Esses dados mostram que apenas os grupos 1 e 2
obtiveram sucesso para relacionar corretamente a quantidade de requisitos e
respectivas operacionalizações disponíveis no catálogo. Ou seja, esses dois grupos
conseguiram extrair todos os requisitos disponíveis para pessoas com limitações
auditivas e visuais, e todas as operacionalizações associadas aos tipos de conteúdo
de Texto, Imagem e Áudio. Esses resultados podem indicar que as elicitações dos
grupos 1 e 2 são menos suscetíveis a omissão de requisitos, em relação as elicitações
dos outros grupos, uma vez que suas extrações conseguiram abranger corretamente
a quantidade existente de elementos no catálogo, de acordo com os parâmetros de
elicitação utilizados.
A elicitação dos requisitos de Acessibilidade Web também foi realizada para o
projeto do aplicativo para a gestão de Metas. Os participantes responsáveis por essa
elicitação pertenceram aos grupos 1 e 2. A tabela 21 mostra o resultado da elicitação
para o segundo projeto.
118
Tabela 21 - Requisitos de Acessibilidade extraídos – Projeto 2
Configuração Grupo Requisitos encontrados (%)
Operacionalizações encontradas (%)
Situação 1: Ferramenta + processo + catálogo
Grupo 1 100% 100%
Grupo 2 100% 100%
Os grupos 1 e 2 repetiram no segundo projeto os mesmos resultados
alcançados no primeiro projeto, abrangendo todos os requisitos e respectivas
operacionalizações disponíveis no catálogo de Acessibilidade Web.
Após a extração das informações contidas no catálogo de RNFs, os
participantes efetuaram a análise para filtrar os requisitos de acessibilidade que
realmente se aplicavam aos requisitos funcionais da aplicação ( veja seção 4.1.1). A
tabela 22 mostra o numero de requisitos de acessibilidade selecionados, após a
análise, para o projeto 1.
Tabela 22 - Requisitos de Acessibilidade selecionados – Projeto 1
Configuração Grupo Total de requisitos de acessibilidade extraídos
Total de requisitos de acessibilidade selecionados
Situação 1: Ferramenta + processo + catálogo
Grupo 1 44 26
Grupo 2 44 23
Situação 2: Processo + Catálogo
Grupo 3 40 25
Situação 3: Catálogo Grupo 4 36 36
Conforme os dados apresentados na tabela 22, é possível ver que o grupo 1
selecionou 26 requisitos dos 44 extraídos do catálogo. Já o grupo 2 selecionou 26, e o
grupo 3 selecionou 25. Ainda em relação aos dados da tabela 22, é possível perceber
que o número de requisitos selecionados pelos participantes do grupo 4 foi bem
superior em relação aos outros grupos. Esse fato está relacionado com a imprecisão
na análise efetuada, hipótese essa confirmada durante a análise dos artefatos
gerados, onde foi constatado que o grupo 4 selecionou requisitos de acessibilidade
que não se relaciona com as limitações do público alvo do projeto I.
A tabela 23 apresenta os requisitos selecionados para o projeto do aplicativo
para gestão de metas.
119
Tabela 23 - Requisitos de Acessibilidade selecionados – Projeto 2
Configuração Grupo Total de requisitos de acessibilidade selecionados
Total de requisitos de acessibilidade selecionados
Situação 1: Ferramenta + processo + catálogo
Grupo 1 44 27
Grupo 2 44 25
Como apresentado na tabela 23, os participantes do grupo 1 definiu que dos
44 requisitos extraídos, apenas 27 deveriam ser selecionados. Já os participantes do
grupo 2 selecionaram 25 requisitos. Essa análise para filtrar os requisitos que
realmente fazem parte do contexto das funcionalidades, presentes nos projetos, se
torna um importante procedimento, a fim de evitar que requisitos desnecessários
sejam especificados e repassados aos prototipadores.
A tabela 24 apresenta o tempo que cada grupo levou para a execução da etapa
de elicitação.
Tabela 24 - Tempo gasto por cada grupo na execução da etapa de elicitação
Grupo Data Duração Tempo despendido
Projeto 1 Projeto 2 Total
Grupo 1 22/01/14 10:22-12:40 1 h e 15 min 1 h e 03 min 2 h e 18 min
Grupo 2 27/01/14 13:55-15:42 1 h e 01 min 0 h e 46 min 1 h e 47 min
Grupo 3 22/01/14 10:22-14:24 4 h e 2 min Não executou 4 h e 2 min
Grupo 4 27/01/14 13:55-17:56 4 H e 1 min Não executou 4 h e 1 min
Os dados mostrados na tabela 24 indicam que a utilização da ferramenta
Omnes Web, por parte dos grupos 1 e 2, reduziu o tempo gasto em média pela
metade em relação ao tempo gasto pelos grupos 3 e 4. Deve ser levado em
consideração que os grupos 1 e 2 efetuaram a elicitação dos requisitos de
Acessibilidade Web para dois projetos, enquanto que os grupos 3 e 4 realizaram o
mesmo procedimento para apenas um projeto. Ainda em relação aos grupos 1 e 2, de
acordo com os dados da tabela 24, é possível perceber que o tempo gasto para a
execução da elicitação do segundo projeto foi em media inferior a 13,5 minutos, em
relação ao tempo gasto para a elicitação do primeiro projeto. Ao serem questionados
sobre essa diferença do tempo gasto, os grupos justificaram que o aumento da
familiaridade com a ferramenta Omnes Web contribuiu para tornar mais rápido a
elicitação para o segundo projeto.
120
Em relação a documentação gerada pelos participantes, analisamos se os
quatro grupos conseguiram gerar com sucesso os três artefatos de saída requeridos
(Seção 6.2.1.1). A tabela 25 mostra a quantidade de artefatos gerados com sucesso por
cada um dos 4 grupos da etapa de elicitação.
Tabela 25 - Artefatos gerados pelos grupos da etapa de elicitação
Grupo Artefatos gerados
Catálogo de RNFs Catálogo de Correlações Checklist
Grupo 1 X X X
Grupo 2 X X X
Grupo 3 X X X
Grupo 4 X
Conforme os dados apresentados na tabela 25, é possível ver que o grupo 4 foi
o único que não conseguiu gerar todos os artefatos esperados, conseguindo
disponibilizar apenas a versão final do catálogo de requisitos de Acessibilidade Web.
Além de informarem motivos de indisponibilidade em relação ao tempo que ainda
seria necessário para gerar os artefatos faltantes, os participantes do grupo 4
alegaram cansaço, e julgaram que o artefato gerado já seria suficiente para o
desenvolvedor implementar os requisitos de Acessibilidade. Apesar da
argumentação, por parte do supervisor desse estudo de caso (autor desta pesquisa de
dissertação), de que uma visão alternativa dos requisitos elicitados era importante, e
que ajudaria na implementação, os participantes assumiram que de fato
disponibilizar somente um artefato prejudicaria a tarefa de implementação, porém
devido a indisponibilidade de tempo, o grupo decidiu que somente o artefato já
produzido seria fornecido.
Como apresentado na tabela 24, o tempo gasto pelos grupos 3 (4 horas e 2
minutos) e 4 (4 horas e 1 minuto) foi praticamente o mesmo, com diferença de apenas
um minuto. Ambos efetuaram a elicitação de maneira totalmente manual, porém
somente o grupo 3 apresentou sucesso na geração de todos os artefatos. Esse fato é
uma indicação de que o processo de elicitação, proposto por esta dissertação,
auxiliou aos elicitadores do grupo 3, servindo como guia para garantir uma execução
organizada de cada procedimento da elicitação. Comparando os resultados do grupo
3 e 4 é possível perceber que o processo induziu a uma melhor execução das
121
atividades, ao ponto de promover a otimização do tempo gasto, permitindo assim
que no período de 4 horas os resultados esperados fossem gerados. Fato este que não
se repetiu com o grupo 4 que executou a elicitação no mesmo período de tempo.
Em relação a qualidade dos artefatos gerados, foi constatado que a
documentação fornecida pelos grupos 1, 2 e 3 apresentaram consistências entre si,
em relação as informações disponibilizadas em cada artefato, ou seja, os requisitos
contidos no checklist representaram fielmente os requisitos contidos na versão final
do SIG do produto.
Apesar do grupo 3 ter efetuado o processo de elicitação de maneira manual,
os artefatos produzidos, além de consistentes entre si, também apresentaram
estrutura suficientemente organizada para a compreensão dos dados contidos. Os
impactos detectados também foram corretamente refletidos no catálogo de
correlações desse grupo.
A análise sobre o SIG gerado pelo grupo 4 revelou que alguns requisitos
elicitados não estão relacionados com as limitações presentes no público alvo (visuais
e auditivas). Um exemplo desse fato foi a elicitação de dois requisitos para pessoas
com problemas de convulsões, sendo estes: “Tratamento de conteúdo para que não
cause convulsão” e “Quantidade limitada de Flashes no conteúdo”. Essa situação
pode complicar ainda mais a implementação dos requisitos Acessibilidade Web, uma
vez que o desenvolvedor que receber este artefato terá dificuldades para decidir
quais requisitos de fato precisam ser prototipados ou implementados.
6.4.1.2 Avaliação dos participantes sobre as estratégias de elicitação utilizadas
Para determinar como os participantes avaliaram cada estratégia de elicitação,
as respostas fornecidas através do questionário de pós-execução do estudo de caso
foram analisadas, levando em consideração que foram elaboradas 3 situações
diferentes (Seção 6.2.1.2), uma para cada grupo.
O questionário de pós- execução do estudo de caso, apresentado no apêndice
B, foi dividido em 5 partes, sendo estas: Parte 1 - Dados Pessoais, Parte 2 –
Configuração do estudo de caso, Parte 3 - Desempenho, Parte 4 – Aprendizado, Parte
5 – Sugestões, críticas e comentários. A primeira parte do questionário se refere ao
fornecimento de informações básicas do participante, como nome e idade. A segunda
122
parte se relaciona com a situação pela qual cada participante efetuou a elicitação dos
requisitos de Acessibilidade Web. Na terceira parte do questionário foi registrada a
opinião de cada participante em relação ao seu desempenho durante a execução da
elicitação dos requisitos de Acessibilidade Web.
A terceira parte do questionário contém perguntas que foram respondidas
pelos participantes através de critérios que indicam os níveis de desempenho. A
seguir serão apresentadas as análises sobre os questionamentos de 1 a 6. Esses
questionamentos foram respondidos considerando os seguintes critérios: péssimo,
ruim, razoável, bom e excelente. Caso desejasse, o participante poderia justificar a
escolha de cada métrica informada. As análises referentes aos questionamentos de 7
a 12 ainda relacionados a 3º parte do questionário são apresentadas no apêndice F, e
os questionamentos de 13 a 15 da quarta parte são apresentadas no apêndice G.
O primeiro questionamento do questionário de pós- execução do estudo de
caso está relacionado com o desempenho geral dos participantes em relação a
estratégia utilizada para a etapa de elicitação. A tabela 26 mostra as respostas dos
participantes da etapa de elicitação para a primeira pergunta do questionário.
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
Pergunta Configuração Péssimo Ruim Razoável Bom Excelente
1- Como você classifica o desempenho geral da estratégia para a elicitação dos requisitos de Acessibilidade Web apresentada?
Situação 1: Ferramenta +
processo + catálogo
- - - 4 -
Situação 2: Processo + Catálogo
- - 2 - -
Situação 3: Catálogo
- - 2 - -
Como apresentado na tabela 26, os 4 participantes vinculados a situação 1 da
etapa de elicitação classificaram como “Bom“ o desempenho geral da estratégia de
elicitação dos requisitos de Acessibilidade Web, utilizando o processo proposto
juntamente com a ferramenta de apoio Omnes Web e o catálogo de RNFs. Ainda em
relação aos participantes da situação 1, de acordo com suas justificativas, a
ferramenta Omnes Web tornou o processo de elicitação mais rápido, e a
123
automatização proporcionada em parte da seleção dos requisitos realça a
potencialidade da estratégia de elicitação apresentada.
Os 2 participantes vinculados a situação 2, envolvendo o uso do processo e do
catálogo sem a ferramenta, classificaram como “Razoável” o desempenho geral da
estratégia de elicitação utilizada, como mostra a tabela 26. Os participantes da
situação II não justificaram suas respostas. Os participantes que utilizaram somente o
catálogo de requisitos de Acessibilidade, relacionados a situação 3, também
classificaram a estratégia utilizada como Razoável. Os participantes da situação 3
alegaram que o procedimento exigia muito tempo, e que uma abordagem sistemática
poderia facilitar o andamento da elicitação.
A segunda pergunta do questionário se relaciona com o grau de
confiabilidade que os participantes detectaram em relação a estratégia de elicitação
utilizada. A tabela 27 apresenta as respostas dos participantes para o questionamento
2 do questionário.
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
Pergunta Configuração Péssimo Ruim Razoável Bom Excelente
2- Como você classifica o aumento do grau de confiabilidade na elicitação dos requisitos de Acessibilidade Web com o uso da estratégia apresentada?
Situação 1: Ferramenta +
processo + catálogo
- - - 3 1
Situação 2: Processo + Catálogo
- 1 - 1
Situação 3: Catálogo
1 1
Analisando as respostas fornecidas para a segunda pergunta, apresentadas na
tabela 27, é possível constatar que dos 4 participantes da situação 1, 3 classificaram
como “Bom” o aumento do grau de confiabilidade na elicitação dos requisitos de
Acessibilidade Web, com o uso da estratégia de elicitação apresentada. Enquanto que
um participante classificou esse grau de confiabilidade como “Excelente”. Entre as
justificativas declaradas, dois participantes alegaram que a abordagem sistemática
do processo de elicitação fornecido reduz o surgimento de falhas.
124
Ainda de acordo com os dados apresentados na tabela 27, um dos
participantes da situação 2 classificou como “Ruim” o grau no aumento da
confiabilidade na elicitação dos requisitos de Acessibilidade Web, com o uso da
estratégia de elicitação apresentada, justificando que não possuía conhecimento e
experiência suficiente para classificar a confiabilidade dos dados corretamente. Já
outro participante da situação 2 classificou essa confiabilidade como “BOM”,
justificando que os resultados foram satisfatórios. Em relação aos participantes da
situação 3, as classificações ficaram entre “Ruim” e “Razoável”. Apenas o
participante que classificou como “Ruim” a confiabilidade justificou sua resposta,
afirmando que sem um método sistemático, a possibilidade de gerar dados
confiáveis diminui.
O questionamento 3 aborda como os participante classificaram o suporte
oferecido pela estratégia utilizada na etapa de elicitação. A tabela 28 apresenta as
respostas dos participantes para o questionamento 3 do questionário.
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
Pergunta Configuração Péssimo Ruim Razoável Bom Excelente
3- Como você classifica o suporte à atividade de
elicitação de requisitos de Acessibilidade Web oferecido pela estratégia apresentada?
Situação 1: Ferramenta +
processo + catálogo
- - - 2 2
Situação 2: Processo + Catálogo
1 1
Situação 3: Catálogo
2
Conforme os dados apresentados na tabela 28, dos 4 participantes da situação
1, 2 classificaram como “Bom” o suporte oferecido à atividade de elicitação de
requisitos de Acessibilidade Web oferecido pela estratégia apresentada, enquanto
que os outros 2 classificaram esse suporte como excelente. Nas justificativas
fornecidas, havia argumentos de que as informações disponibilizadas pela
ferramenta Omnes Web facilitou bastante o trabalho de elicitação.
Em relação as respostas dos participantes da situação de elicitação 2,
apresentadas na tabela 28, um dos participantes classificou como Razoável o suporte
125
fornecido, enquanto que o outro classificou como Bom, não foram fornecidas
justificativas. Os dois participantes da situação 3, classificaram o suporte da
estratégia de elicitação como Razoável, lembrando que esses participantes utilizaram
somente o catálogo de RNFs de Acessibilidade. As justificativas fornecidas pelos
participantes da situação III se relacionaram com o fato de que o catálogo de
requisitos de Acessibilidade Web contém muitas informações, e que executar a
elicitação através dele de maneira manual se tornava uma tarefa complexa e
demorada. Os dois participantes da situação 3, também argumentaram que apesar
dos procedimentos disponibilizados pela abordagem NFR Framework, passados
através do treinamento, ainda sentiram falta de um método sistemático que
auxiliasse na varredura do catálogo de RNF.
A quarta pergunta do questionário de pós- execução do estudo de caso se
relaciona ao nível de qualidade detectado pelos participantes em relação a
documentação gerada durante a etapa de elicitação. A tabela 29 apresenta as
respostas dos participantes para o questionamento 4 do questionário.
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
Pergunta Configuração Péssimo Ruim Razoável Bom Excelente
4- Como você classifica o nível de qualidade da documentação gerada
através do uso da estratégia de elicitação apresentada?
Situação 1: Ferramenta +
processo + catálogo
- - - 2 2
Situação 2: Processo + Catálogo
2
Situação 3: Catálogo
2
De acordo com as respostas fornecidas pelos participantes, apresentadas na
tabela 29, dos 4 participantes da situação 1 da etapa de elicitação, 2 classificaram
como “Bom” o nível de qualidade da documentação gerada pela estratégia adotada,
enquanto que os outros dois participantes classificaram como excelente essa
documentação. Entre as justificativas, há argumentos informando que o fator
diferencial se relaciona com a possibilidade da geração automatizada de artefatos,
através da ferramenta Omnes Web.
126
Os dois participantes da situação 2 da elicitação classificaram como “Bom” o
nivel da documentação gerada, como mostra a tabela 29, justificando que apesar do
tempo necessário para gerá-los, os resultados foram satisfatórios. Em relação aos
participantes da situação 3, a nível de qualidade da documentação gerada foi
classificada como Ruim, as justificativas foram relacionadas com o fato de que
devido a grande quantidade de dados existentes no catálogo de RNFs, gerar outros
artefatos além dele tomaria muito tempo.
O questionamento 5 do questionário de pós- execução do estudo de caso
verifica a opinião dos participantes em relação ao tempo despendido para execução
das tarefas da etapa de elicitação, de acordo com a estratégia utilizada. A tabela 30
apresenta as respostas dos participantes em relação ao questionamento 5.
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
Pergunta Configuração Péssimo Ruim Razoável Bom Excelente 5 - como você
classifica o tempo despendido com o
uso da solução apresentada?
Situação 1: Ferramenta + processo + catálogo
- - 1 3
Situação 2: Processo + Catálogo
- 1 1 - -
Situação 3: Catálogo 1 1 - - -
Como apresentado pela tabela 30, dos 4 participantes da situação 1, 3
classificaram como “Excelente” o tempo despendido para execução das tarefas
utilizando o processo juntamente com a ferramenta Omnes Web. Enquanto apenas 1
considerou o tempos despendido como “Razoável”, justificando que a tarefa de
análise de impacto entre os RNFs tomou muito tempo. Em relação aos participantes
da situação 2, o tempo despendido foi classificado como “Ruim” e “Razoável”. A
justificativa desses participantes se relacionou com problemas de conhecimento
sobre a área de Engenharia de Requisitos, e não com a estratégia de elicitação
utilizada.
Ainda em relação aos dados da tabela 30, os participantes da situação 3
classificaram como Péssimo e Ruim o tempo despendido para execução das
atividades de elicitação da estratégia utilizada. A justificativa desses participantes
127
informava que devido a grande quantidade de itens no catálogo de requisitos de
Acessibilidade Web, a elicitação se tornou muito demorada.
A pergunta 6 do questionário de pós- execução do estudo de caso visou
extrair as opiniões dos participantes em relação ao suporte oferecido pela ferramenta
de apoio STARUML, durante a modelagem do catálogo de RNFs, baseando-se na
abordagem NFR Framework. A tabela 31 apresenta as respostas dos participantes
para o questionamento 6.
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
Pergunta Configuração Péssimo Ruim Razoável Bom Excelente
6 - como você classifica o suporte oferecido pela ferramenta STARUML junto à aplicação da solução apresentada?
Situação 1: Ferramenta + processo + catálogo
- 1 1 - 2
Situação 2: Processo + Catálogo
- 1 - 1 -
Situação 3: Catálogo
2 - - -
De acordo com os dados apresentados na tabela 31, dos 4 participantes que
efetuaram a elicitação de acordo com a situação 1, apenas 2 se mostraram
plenamente satisfeitos com a integração de artefatos entre a Ferramenta Omnes Web
e a StarUML, classificando o suporte oferecido pela StarUML como “Excelente”.
Esses participantes justificaram que o trabalho de importar o XML do catálogo de
RNFs, gerado pela ferramenta Omnes Web, na ferramenta StarUML foi simples e o
resultado foi satisfatório. Os outros dois participantes da situação 1, classificaram
como Ruim e Razoável o suporte da ferramenta de modelagem StarUML, alegando
que a ferramenta deveria ser mais automatizada. Porém, deve ser ressaltado que a
única ação que os participantes da situação 1 realizaram na StarUML foi a
importação do XML gerado pela ferramenta Omnes Web.
Ainda relacionado aos dados da tabela 31, um participante da situação 2
classificou como Ruim o suporte oferecido pela ferramenta StarUML, informando
que a ferramenta apresentou variadas limitações, sem citar quais. Já o outro
participante da situação 2 classificou como Bom o suporte oferecido pela StarUML.
128
Em relação aos dois participantes da situação 3, o suporte oferecido pela StarUML às
atividades de elicitação foi considerado Ruim, as justificativas foram em relação a
problemas apresentados pela ferramenta, como a dificuldade de controle sobre o
tamanho da área de modelagem do catálogo e a configuração do tamanho de cada nó
(nuvem) do gráfico que necessitava de ajustes individuais, tomando muito tempo
para ajustar.
6.4.1.3 Conclusão para a QP1
Analisando os dados obtidos durante a execução da etapa de elicitação do
estudo de caso, foi possível constatar que o desempenho geral dos grupos 1 e 2, que
utilizaram o processo proposto junto a sua ferramenta de apoio Omnes Web, foi
melhor em relação ao desempenho geral dos grupos 3 e 4. Apenas os grupos 1 e 2
conseguiram abranger todos os requisitos existentes no catálogo e em menos tempo.
Apesar de efetuarem a elicitação para dois projetos diferentes, os grupos 1 e 2
gastaram em média metade do tempo utilizados pelos grupos 3 e 4, que efetuaram a
elicitação dos requisitos de Acessibilidade Web para apenas um projeto. E por fim, os
3 artefatos esperados foram gerados com sucesso.
O desempenho do grupo 3 na geração de artefatos foi melhor em relação ao
desempenho do grupo 4. Esse fato pode indicar que o processo de elicitação
proposto forneceu suporte para a execução das tarefas de elicitação. Porém, a
quantidade de requisitos de Acessibilidade Web considerados e o tempo despendido
apontam que a execução de forma manual carece de estratégias que automatize
alguns procedimentos, visando melhorar a seleção dos requisitos e o tempo gasto
para a elicitação.
A avaliação da estratégia de elicitação, fornecida através do questionário de
pós- execução do estudo de caso, mostrou que os participantes dos grupos 1 e 2
ficaram satisfeitos com a utilização da estratégia de elicitação proposta. Lembrando
que esses participantes utilizaram o processo de elicitação e sua ferramenta de apoio.
Entre os fatos que fundamentam essa satisfação, podemos destacar a classificação
fornecida para o desempenho geral da estratégia de elicitação, onde os todos os
participantes classificaram como “Bom” a execução da elicitação através do processo
de elicitação e sua ferramenta de apoio. Destacamos também, as classificações
129
atribuídas ao suporte oferecido pelo processo e sua ferramenta de apoio à atividade
de elicitação, onde dos 4 participantes 2 classificaram esse suporte como “BOM”, e os
outros dois como “Excelente”. E por fim, outro fato a ser destacado é que todos os
participantes afirmaram que se caso necessário tornariam a utilizar a estratégia de
elicitação fornecida por esta dissertação.
Os participantes do grupo 3, que utilizaram o processo manualmente,
apontaram como pontos fortes o suporte oferecido pelo processo à atividade de
elicitação e a qualidade da documentação gerada, classificando como “Bom” esses
dois fatores. O tempo despendido foi apontado pelo grupo 3 como uma limitação da
utilização do processo de forma manual, onde um dos participantes classificou como
“Ruim” o tempo gasto, e o outro como “Razoável”. Os dois participantes do grupo 3
também afirmaram que se caso necessário tornariam a utilizar a estratégia de
elicitação proposta.
Os participantes do grupo 4, que realizaram a elicitação sem utilização do
método aqui proposto, não se mostraram satisfeito em executar as atividades usando
somente o modelo de metas do NFR Framework. Entre as justificativas informaram a
falta de uma estratégia sistematizada que os guiasse durante a extração das
informações do catálogo. Outro problema detectado pelos participantes foi em
relação a escalabilidade do processo, alegando que devido ao tamanho do catálogo
tiveram dificuldades para selecionar os requisitos. Esse fato confirma que na medida
em que o catálogo representa mais informações, a vantagem de utilizá-los diminui.
Ao serem questionados se tornariam a utilizar novamente estratégia de elicitação
utilizando somente o catálogo, ambos os participantes responderam que não.
Por fim, de acordo com a análise dos dados extraídos durante a execução da
etapa de elicitação, foi possível definir a resposta para a questão de pesquisa “O
processo de elicitação e sua ferramenta de apoio causam algum impacto à atividade de
elicitação de requisitos de Acessibilidade Web?”. Concluímos que sim, o processo e a
ferramenta Omnes Web causam um impacto positivo na atividade de elicitação. A
utilização da estratégia de elicitação, contendo esses recursos, possibilitou uma maior
abrangência dos requisitos de acessibilidade contidos no catálogo, e em menos
tempo, além de facilitar a geração de artefatos. A avaliação dos participantes auxiliou
130
a fundamentar esse impacto satisfatório, demonstrando que além de inferir
melhorias na atividade de elicitação, também foi bem aceita por seus utilizadores.
6.4.2 Dados extraídos da etapa de prototipação
Esta Seção apresenta a análise sobre os dados extraídos durante a execução da
etapa de prototipação do estudo de caso, visando responder a segunda questão de
pesquisa: “A documentação gerada pela estratégia de elicitação proposta causa algum
impacto no processo de prototipação?”.
Para responder a QP2, foram considerados dois fatores, sendo estes: I -
Controle sobre a prototipação dos requisitos, II – A avaliação dos desenvolvedores
em relação a documentação de requisitos recebida. No primeiro fator foi verificado o
tempo despendido para a execução do estudo de caso, e também se a prototipação
dos requisitos de acessibilidade está de acordo com o que foi solicitado. O segundo
fator visa analisar o grau de suporte identificado pelos desenvolvedores em relação a
documentação gerada na etapa de elicitação. A seguir são apresentadas as análises
dos dados extraídos para responder a QP2.
6.4.2.1 Controle sobre a prototipação dos requisitos
Sobre a distribuição dos projetos, os participantes 1, 3 e 4 ficaram responsável
pela prototipação do projeto 1, referente ao aplicativo para a criação de galeria de
fotos interativa. Enquanto que o participante 2 ficou responsável pela prototipação
do projeto 2, referente ao aplicativo para gestão de metas. Salientando que todos os
participantes receberam documentações distintas (veja a tabela 17 na seção 6.2.2.1).
Devido a baixa disponibilidade dos participantes, o número de RFs solicitados
em cada projeto foi revisado e diminuído. Para o projeto 1, dos 20 RFs definidos
inicialmente, apenas 13 foram repassados aos participantes. Para o projeto 2, a
quantidade de RFs solicitados caiu de 21 para 12. Essa revisão na quantidade de RFs,
realizada pelo autor desta dissertação, ocorreu de maneira que permitisse criar casos
de testes suficientes para a etapa III do estudo de caso.
Em relação a prototipação dos requisitos de Acessibilidade Web, as
informações contidas no checklist foram analisadas. O objetivo dessa análise é
131
averiguar a quantidade de requisitos de acessibilidade implementados em relação a
quantidade elicitada. A tabela 32 apresenta as informações sobre a prototipação dos
projetos
Tabela 32 - Informações extraídas da etapa de prototipação
Participante Requisitos de Acessibilidade implementados (%) Tempo despendido
Projeto 1 Projeto 2
Participante 1 46,15 % - 15h e 18m
Participante 2 - 80% 16h e 20m
Participante 3 80% - 11h e 30m
Participante 4 16,66% - 9h e 35m
Conforme os dados apresentados na tabela 32 é possível perceber que
nenhum dos participantes conseguiu disponibilizar por completo a prototipação dos
requisitos de Acessibilidade Web contidos no checklist. O participante 1 entregou o
aplicativo para criação de galerias de foto interativa com 46,15% dos requisitos de
Acessibilidade Web prototipados. Os participantes 2 e 3 foram os que entregaram os
projetos com maior número de requisitos prototipados, ambos prototiparam 80% dos
requisitos elicitados para os seus respectivos projetos. Já o participante 4, apresentou
o pior desempenho, tendo prototipado apenas 16% dos requisitos de Acessibilidade.
Entre as justificativas apresentadas, os participantes alegaram que a
produtividade não foi maior devido a pouca disponibilidade de tempo. Os
participantes 1 e 3 também citaram o pouco conhecimento em Acessibilidade Web
como fator problemático, e que isso atrapalhou o andamento da prototipação dos
projetos. Com exceção do participante 4, que recebeu unicamente o catálogo de RNFs
como artefato, todos os outros participantes informaram que não encontraram
dificuldade de seguir o checklist recebido, pelo contrário, todos elogiaram o controle
que esse artefato promove. Alguns participantes chegaram a afirmar inclusive, que
sem o checklist a produtividade teria sido menor ainda.
O participante 4, apesar de possuir alguma experiência em Acessibilidade,
informou que sua baixa produtividade se deu também pela dificuldade de seguir
somente o catálogo de RNFs como guia da prototipação. Esse participante afirmou
que o catálogo é interessante e simples de entender, porém devido a escalabilidade
desse artefato, uma visão alternativa seria interessante. Vale ressaltar que além do
132
catálogo o participante 4, assim como os outros participantes, recebeu material de
apoio e indicações de links do site da W3C contendo exemplos de técnicas para
implementar a Acesssibilidade web.
Com exceção da prototipação apresentada pelo participante 4, foi constatado
que os requisitos que faltaram ser implementados pelos participantes 1, 2 e 3 se
relacionam com nível de conformidade AAA dos critérios de sucesso e respectivas
diretrizes do WCAG 2.0 (W3C-WCAG 2.0, 2013). Esse fato é importante, pois indica
que os requisitos mais básicos, relacionados ao nível de conformidade A e AA foram
implementados. Dessa forma, a acessibilidade dos projetos encontra-se em um nível
aceitável, tendo em vista que vários requisitos relacionados ao nível de
conformidade AAA se relacionam a fatores que podem ser opcionais na
prototipação, e que sua falta não significa obrigatoriamente que o site ou aplicativo
esteja inacessível. A prototipação dos requisitos de Acessibilidade Web
implementados pelos participantes 1, 2 e 3 estava consistente com as especificações
contidas no catálogo de RNFs e checklist.
Alguns requisitos implementados pelo participante 4 estavam parcialmente
de acordo com as especificações dos artefatos, fato este que influenciou na decisão de
considerá-los como não implementados. Por exemplo, o requisito “Disponibilidade
de alternativas para evitar armadilhas ou bloqueio do teclado”, referente ao princípio
de Operabilidade, foi considerado parcialmente prototipado. Isso por que em várias
situações o uso do mouse foi obrigatório. Assim sendo, esse requisito não foi
classificado como prototipado.
Na Seção 6.4.3 são apresentados os dados que fundamentam essa
argumentação.
6.4.2.2 Avaliação dos implementadores em relação à documentação recebida
Para determinar como os participantes da etapa de prototipação avaliaram a
documentação recebida, as respostas fornecidas através do questionário de pós-
execução do estudo de caso foram analisadas.
O questionário de pós- execução do estudo de caso foi dividido em 4 partes,
sendo estas: Parte 1 - Dados Pessoais, Parte 2 – Utilização dos artefatos produzidos,
133
Parte 3 - prototipação, Parte 4 – Sugestões, críticas e comentários. A primeira parte
do questionário também se refere ao fornecimento de informações básicas do
participante, como nome e idade. A segunda parte se relaciona com avaliação dos
participantes em relação aos artefatos recebidos. Na terceira parte do questionário
foi registrada a opinião de cada participante em relação a prototipação dos requisitos
de Acessibilidade Web, no que se refere ao grau de dificuldade para implementá-los.
Por fim, na quarta parte do questionário foram registradas informações mais
subjetivas como sugestões, críticas e comentários diversos relacionados à
documentação de elicitação recebida.
A seguir são apresentadas as análises sobre as respostas, fornecidas pelos
participantes, para os questionamentos do questionário de pós- execução do estudo
de caso. Os questionamentos de 1 a 5 foram respondidos considerando os seguintes
critérios: péssimo, ruim, razoável, bom e excelente. Enquanto que os
questionamentos de 6 a 9 foram respondidos considerando os seguintes critérios:
Muito Difícil, Difícil, Razoável, Fácil e Muito Fácil. Caso desejasse, o participante
poderia justificar a escolha de cada métrica informada.
A primeira pergunta verificou a opinião dos participantes em relação a clareza
e consistência na especificação dos requisitos, com base na documentação recebida.
Os participante 1 e 2 classificaram o nível da clareza e da consistência como “Bom” e
“Excelente” respectivamente. Ressaltando que esses participantes receberam os
artefatos produzidos pelos grupos 1 e 2, que utilizaram o processo e a ferramenta
Omnes Web. Já os participantes 3 e 4 classificaram o nível da clareza e consistência
como “Razoável”. O participante 3 recebeu os artefatos produzidos pelo grupo 3, e o
participante 4 recebeu do grupo 4. Vale salientar que os participantes 1,2 e 3
receberam todos os artefatos, enquanto que o participante 4 recebeu somente o
catálogo de RNFs.
A segunda pergunta verificou a opinião dos participantes sobre a
objetividade das informações na especificação dos requisitos. Os participantes 1 e 2
classificaram o nível da objetividade como “Bom” e “Excelente” respectivamente.
Enquanto que os participantes 3 e 4 classificaram como “Razoável”.
134
A terceira pergunta verificou como os participantes classificaram o suporte à
prototipação dos requisitos de Acessibilidade Web oferecido pela documentação.
Esse suporte está relacionado a descrição das operacionalizações de Acessibilidade
Web, ou seja, se as operacionalizações fornecidas realmente fornecer suporte na
implementação de seus respectivos requisitos. Os participantes 1, 3 e 4 classificaram
esse suporte como “Bom”. Já o participante 2 classificou como “Excelente”.
A quarta pergunta extraiu a opinião dos participantes em relação ao tempo
despendido a compreensão da documentação. Os participantes 1, 3 e 4 classificaram
como “Bom” o tempo despendido para a compreender os artefatos fornecidos.
Enquanto que o participante 2 classificou como “Excelente”.
A tabela 33 destaca a opinião dos participantes em relação a viabilidade de
implementar os requisitos de Acessibilidade Web, com base na documentação
recebida.
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
Pergunta Participante Péssimo Ruim Razoável Bom Excelente
5 - Como você classifica a viabilidade de
implementação dos requisitos, com base na
documentação?
Participante 1 X
Participante 2 X
Participante 3 X
Participante 4 X
Conforme apresenta a tabela 33, os participantes 1 e 4 classificaram o nível da
viabilidade de prototipação dos requisitos, através da documentação fornecida, como
“Bom”. Enquanto que os participantes 2 e 3 classificaram esse nível como
“Excelente”.
A sexta pergunta verificou a opinião dos participantes sobre o grau de
dificuldade encontrado na utilização de cada um dos artefatos da documentação
recebida. Em relação ao catálogo de correlações, o participantes 1 classificou o nível
de dificuldade para utilizá-lo como “Razoável”. Já os participante 2 e 3 classificaram
o grau de dificuldade para a utilização do catálogo de correlações como “Muito Fácil
e “Fácil” respectivamente. Em relação ao catálogo de RNFs os participantes 1 e 4
classificaram o grau de dificuldade na utilização deste artefato como “Razoável”. Já
135
os participantes 2 e 3 classificaram como “Muito Fácil” e “Fácil” respectivamente. No
que se refere a utilização do checklists, os 3 participantes que o receberam
classificaram sua utilização como “Muito Fácil”.
Na sétima pergunta foi questionado se os participantes haviam encontrado
algum problema com a identificação dos requisitos, na documentação fornecida,
todos responderam que não.
A terceira parte do questionário contém dois questionamentos que verificaram
a opinião dos participantes em relação a dificuldade de prototipação e testes dos
requisitos de Acessibilidade Web. Os participantes 1 e 2 classificaram como
“Razoável” o grau de dificuldade para a implementação dos requisitos de
Acessibilidade web. Enquanto que os participantes 3 e 4 classificaram como “Difícil”.
Em relação ao grau de dificuldade para analisar e testar os requisitos de
Acessibilidade Web, os participantes 1 e 4 classificaram como Razoável a execução
dos testes. Enquanto que os participantes 2 e 3 classificaram como “Fácil”.
6.4.2.3 Conclusão para a QP2
Os resultados mais expressivos em relação à prototipação dos requisitos de
Acessibilidade Web, foram alcançados pelos participantes 2 e 3. O participante 2
recebeu os artefatos produzidos pelo grupo 2 da etapa de elicitação, que utilizou o
processo junto a ferramenta Omnes Web. Já o participante 3 recebeu os artefatos
produzidos pelo grupo 3, que utilizou o processo manualmente. Ambos
participantes receberam os seguintes 3 artefatos: I - Catálogo de RNFs, II – Catálogo
de correlações, III – Checklist para controle da prototipação dos requisitos de
acessibilidade.
Com exceção do participante 4, que recebeu somente o catálogo, todos os
outros participantes enfatizaram que a documentação fornecida, principalmente o
checklist, garantiu um maior controle de prototipação, e que sem ela tudo teria sido
mais complicado. O participante 1, apesar de ter recebido a documentação contendo
todos os artefatos, gerou uma prototipação abaixo do esperado, prototipando apenas
46% dos requisitos esperados. Além de justificar falta de tempo e conhecimento, esse
participante também informou problemas de saúde e que isso o atrapalhou na
produção.
136
Mesmo faltando alguns requisitos de acessibilidade, os projetos
implementados pelos participantes 1, 2 e 3 demonstraram bom desempenho durante
a etapa de análise da acessibilidade, os dados analisados são apresentados mais
adiante, na seção 6.4.3. Essa situação ocorreu por que a maioria dos requisitos
relacionados ao nível de conformidade A e AA do WCAG 2.0, contidos no checklist,
foram implementados. No caso da prototipação do participante 2 todos foram
prototipados.
Em relação à avaliação da documentação gerada na etapa de elicitação,
fornecida através do questionário de pós-execução do estudo de caso, os
participantes que receberam os artefatos produzidos pelos grupos 1, 2 e 3, avaliaram
de maneira bastante satisfatória a documentação recebida. Como um dos destaques
que comprovam essa satisfação, podemos citar a classificação recebida para o fator
viabilidade de utilização da documentação gerada. Com exceção do participante 4,
todos os outros participantes classificaram como “Excelente” a viabilidade de utilizar
a documentação fornecida. O participante 4 relacionou sua falta de produtividade a
ausência de mais artefatos que pudessem auxiliá-lo.
Por fim, de acordo com a análise dos dados, extraídos durante a etapa de
prototipação, foi possível definir a resposta para questão de pesquisa: A documentação
gerada pela estratégia de elicitação proposta causa algum impacto no processo de
prototipação?. Concluímos que sim, a documentação gerada causa impacto positivo
na implementação. Pois mesmo com todas as adversidades, a documentação gerada
forneceu suporte à prototipação dos requisitos de Acessibilidade Web, relacionados
aos níveis de conformidade A e AA e alguns de nível AAA, garantindo um nível
satisfatório de acessibilidade para alguns projetos (Seção 6.4.3.1). Isso de acordo com
os próprios participantes, que afirmaram que a documentação promoveu, através
dos catálogos baseados no NFR Framework e do checklist, um conhecimento maior
sobre as alternativas a serem consideradas na prototipação da Acessibilidade Web.
Outro fato que comprova essa situação, está relacionada a diferença da produção
disponibilizada pelos participantes 1, 2 e 3, que receberam todos os artefatos, em
relação a produção do participante 4, que recebeu somente o catálogo de RNFs.
137
6.4.3 Dados extraídos da etapa de análise da acessibilidade
Esta Seção apresenta os dados extraídos durante a execução da etapa de
análise da acessibilidade do estudo de caso, visando responder a terceira questão de
pesquisa, contendo a seguinte pergunta: “A documentação gerada pela estratégia de
elicitação proposta causa algum impacto no produto implementado?”.
Para responder a QP3, foram considerados os resultados da análise manual e
automatizada do grau de Acessibilidade Web nos aplicativos.
6.4.3.1 Análise manual da Acessibilidade Web
Para verificar o grau de Acessibilidade Web dos projetos, de acordo com
análise manual, foram analisados os dados registrados durante a aplicação dos
roteiros de tarefas em cada projeto (Seção 6.2.3), e o preenchimento do questionário
de pós- execução do estudo de caso pelos participantes. Ressaltando que os
participantes que efetuaram a análise manual possuem limitação visual em seu grau
mais acentuado, ou seja, não possuem visão.
Durante a aplicação do roteiro de tarefas para cada projeto, os participantes da
etapa III poderiam tentar executar cada tarefa solicitada quantas vezes achassem
necessário, pedindo ajuda a qualquer momento. Essa ajuda compreendia desde dicas
simples como a localização de um determinado menu, à execução da tarefa pelo
participante, que acontecia em casos em que o participante desistia ou era detectado
que o aplicativo não fornecia suporte para execução da tarefa. Dessa forma, a ajuda
era fornecida no intuito de efetuar a tarefa pelo usuário, para dar continuidade ao
roteiro, seguindo para a próxima tarefa. Em casos como esse, o status de execução
da tarefa era classificado como não concluído.
Após a execução de cada roteiro de tarefas, o questionário de avaliação da
aplicação, apresentado no apêndice N, foi respondido pelo participante. Esse
questionário foi dividido em 4 partes, sendo estas: Parte 1 - Dados Pessoais, Parte 2 –
Aplicativo avaliado, Parte 3 – Análise da Acessibilidade Web, Parte 4 – Sugestões,
críticas e comentários. A parte 3, contém 6 perguntas, onde os questionamentos de 1
a 5 foram respondidos considerando os seguintes critérios: péssimo, ruim, razoável,
138
bom e excelente. Enquanto que o questionamento 6 foi respondido considerando os
seguintes critérios: Muito Difícil, Difícil, Razoável, Fácil e Muito Fácil.
A fim de detalhar os resultados obtidos na execução dessa etapa, foram
selecionados os roteiros de tarefas relacionados aos dois protótipos gerados pelos
participantes 1 e 2 da etapa de prototipação.Vale salientar que os participantes dessa
terceira etapa analisaram os 4 projetos prototipados na segunda etapa do estudo de
caso. A razão pelo detalhamento dos resultados de dois projetos se deve ao objetivo
de evitar informações redundantes, e até mesmo pela constatação de que
conseguimos explicar a lógica da análise manual descrevendo apenas os resultados
de dois projetos.
Apesar do protótipo 1, gerado pelo participante 1 da etapa de prototipação,
não ter sido considerado um caso total de sucesso, em relação a utilização de nossa
estratégia de elicitação, decidimos detalhá-lo mesmo, a fim de efetuar comparações
de desempenho deste protótipo com o protótipo 2, gerado pelo participante 2, que
foi considerado um caso de sucesso, assim como o protótipo 3. Vale ressaltar que o
protótipo 1 não pode ser considerado um caso de sucesso devido à limitações
apresentadas pelo prototipador responsável (ver seção 6.4.2.3), e não por problemas
relacionados a estratégia de elicitação apresentada nesta dissertação.
A tabela 33 apresenta os resultados dos testes manuais de Acessibilidade no
projeto I, implementado pelo participante 1 da segunda etapa do estudo de caso. O
roteiro das implementações resultantes para o projeto 1, apresentado no apêndice L,
foi definido com 8 tarefas. Porém, o participante 1 implementou dois requisitos
funcionais, contidos na documentação apresentada no Apêndice C, que não foram
considerados pelos demais participantes, sendo estes: RF10 - O sistema deve
permitir associar sons a fotos, temas e galerias; RF11 - O sistema deve permitir o
controle sobre a execução de sons (Iniciar, pausar, voltar, adiantar e mudar de faixa).
Assim sendo, foram inseridas mais 2 tarefas no roteiro de testes da aplicação gerada
pelo participante 1. Para os campos de “Ajuda” e “Conclusão”, da tabela 34, a letra X
tem sentido Sim, o campo vazio significa Não. Por exemplo, se para o campo de
ajuda de uma tarefa há a letra X, então para essa tarefa o usuário necessitou de
algum tipo de ajuda.
139
Tabela 34 - Análise manual da Acessibilidade Web do Projeto 1 – prototipação do participante 1
Tarefa Participante 1 Participante 2
Tentativas Ajuda Conclusão Tentativas Ajuda Conclusão Tarefa 1 - Identificar todo o conteúdo da página inicial
4 X 5 X
Tarefa 2 – Criar uma galeria de fotos
3 X 4 X X
Tarefa 3 – Acessar a galeria criada
2 X 2 X
Tarefa 4 – Fazer uploads de fotos
2 X 3 X X
Tarefa 5 – Acessar a foto inserida
4 X X 4 X X
Tarefa 6 - Rotular fotos
2 X 3 X
Tarefa 7 - Editar o rótulo da foto inserida
2 X 2 X
Tarefa 8 – Excluir a foto inserida
1 X 1 X
Tarefa9 – Vincular som a foto inserida
5 X 6 X
Tarefa 10 – Ouvir o som vinculado a foto
1 X 1 X
Conforme apresentado na tabela 34, das 10 tarefas relacionadas, os dois
participantes conseguiram concluir 8. Porém, apenas as tarefas 8 e 10 foram
concluídas com apenas uma tentativa e sem necessidade ajuda. Já as tarefas 2 e 5
foram as que mais exigiram tentativas dos participantes, sendo que o participante 1
tentou 4 vezes e necessitou de ajuda na tarefa 5, enquanto que o participante 2
necessitou de ajuda para concluir as duas tarefas. A ajuda fornecida aos participantes
para a conclusão das tarefas 2 e 5, se relacionaram com a localização da
funcionalidade, sendo fornecido dicas sobre a proximidade com outros elementos da
página.
Ainda de acordo com a tabela 34, as tarefa 1 e 9 não foram concluídas por
nenhum dos dois participantes. Na tarefa 1, o participante deveria informar o
conteúdo presente na página inicial da aplicação, informando se tinha imagens,
identificando os links e botões, e a clareza das informações dos elementos presentes.
Mesmo após 4 tentativas do participante 1, e 5 tentativas do participante 2, algumas
informações não foram corretamente identificadas. Apesar de informar corretamente
os elementos presentes, as informações contidas em alguns deles não estavam claras,
140
de acordo com os participantes. Um exemplo desse fato foi constatado na
funcionalidade que permitia escolher a cor do plano de fundo da página, onde havia
somente os textos “Claro”, “Escuro” e “Azul”, sem utilizar etiquetas para explicar
exatamente para o usuário o que aconteceria se ele clicasse em algum dos botões
daquela funcionalidade. Assim, para finalizar essa tarefa e dar sequência ao roteiro,
entre outras explicações, para cada participante foi explicado o significado desses
três textos citados.
Por fim, em relação à tarefa 9, os participantes deveriam selecionar um
arquivo de som, armazenado em uma pasta na área de trabalho do computador, e
associá-lo a foto inserida. O desenvolvedor colocou essa funcionalidade na parte de
edição das fotos inseridas, porém, os participantes não conseguiram encontrar essa
funcionalidade utilizando o teclado, assim foi necessária a intervenção do supervisor
do estudo de caso (autor da desta pesquisa), executando a tarefa pelos participantes.
Dessa forma a tarefa 9 teve falha na sua execução.
A tabela 35 apresenta as respostas fornecidas pelos participantes, para os
questionamentos de 1 a 5 do questionário de avaliação sobre a aplicação do roteiro
de tarefas do projeto 1, implementado pelo participante 1 da segunda etapa do
estudo de caso.
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
Pergunta Participante 1 Participante 2
1 - Como você classifica o tempo despendido para a execução das tarefas solicitas para o aplicativo?
Bom Excelente
2- Como você classifica o suporte oferecido pela aplicação na execução das tarefas solicitas?
Razoável Péssimo
3 - Realizar as tarefas solicitadas na aplicação foi estressante? Não Sim
4 - Realizar as tarefas solicitadas na aplicação foi cansativo? Não Sim
5 - Como você classifica de maneira geral o grau de acessibilidade encontrado durante a análise do aplicativo?
Razoável Razoável
Conforme os dados apresentados na tabela 35, o participante 1 considerou o
tempo despendido para concluir as tarefas como “Bom”, a saber: o tempo gasto pelo
participante 1 na execução desse roteiro foi de 13 minutos e 35 segundos. O
participante 2, classificou esse tempo despendido como excelente, porém o mesmo
141
justificou que devido ao péssimo suporte e usabilidade que a aplicação oferece, o
tempo gasto para executar suas tarefas foi considerado pequeno, a saber: o tempo
gasto pelo participante nesse roteiro foi de 15 minutos.
Ainda de acordo com a tabela 35, em relação ao suporte oferecido pela
aplicação, o participante 1 classificou como “Razoável”, e o participante 2 como
citado classificou como “Péssimo”. Além de problemas de acessibilidade, o
participante 2 detectou falta de feedback sobre algumas ações do usuário. O
participante 1 não considerou a realização das tarefas estressantes e nem cansativas,
ao contrário do participante 2. Em relação a classificação geral do grau de
Acessibilidade Web da aplicação, ambos os participantes classificaram como
Razoável. Entre as justificativas, os participantes informaram que apesar da aplicação
possuir um determinado grau de acessibilidade, faltaram ser implementadas
alternativas textuais que fornecessem suporte para efetuar algumas ações, como por
exemplo, o upload de fotos e vínculo de sons.
O questionamento 6 solicita a classificação para o nível de dificuldade
encontrado pelos participantes na execução das tarefas solicitados para o aplicativo.
O participante 1 classificou esse nível como “Fácil”, enquanto o participante 2 como
“Difícil“. Mais uma vez a justificativa do participante 2 se relaciona com a falta de
feedback sobre algumas ações. Outro problema citado pelo participante 2 foi a falta
de controle sobre o som vinculado a foto.
A tabela 36 apresenta os resultados dos testes manuais de Acessibilidade no
projeto 2, implementado pelo participante 2 da segunda etapa do estudo de caso. O
roteiro da prototipação resultante para o projeto 2, apresentado no apêndice M, foi
definido com 11 tarefas.
142
Tabela 36 - Análise manual da Acessibilidade Web do Projeto 2 – prototipação do participante 2
Tarefa Participante 1 Participante 2
Tentativas Ajuda Conclusão Tentativas Ajuda Conclusão Tarefa 1 – Identificar conteúdo não textual
1 X 2 X
Tarefa 2 – Identificar os tipos de login presentes na aplicação e escolher um deles
1 X 2 X
Tarefa 3 – Efetuar cadastro no sistema
1 X 1 X
Tarefa 4 – Acessar o menu de ajuda da aplicação
1 X 1 X
Tarefa 5 – Retornar a tela inicial
2 X 1 X
Tarefa 6 - Cadastrar uma categoria de meta
1 X 1 X
Tarefa 7 – Cadastrar uma meta e vincular a uma categoria
2 X 1 X
Tarefa 8 – Cadastrar uma ação para a meta criada
1 X 1 X
Tarefa 9 - Agendamento da ação
1 X 1 X
Tarefa 10 – Retornar a tela inicial e aguardar o alerta surgir
1 X 1 X
Tarefa 11 – Confirmar a execução da ação
1 X 2 X
Conforme os dados apresentados na tabela 36, os dois participantes
conseguiram concluir todas as 11 tarefas contidas no roteiro do aplicativo resultante
do projeto 2. Outro fato relevante é que os participantes não precisaram de ajuda
para concluir as tarefas. Em relação à quantidade de tentativas, com exceção das
tarefas 5 e 7, o participante 1 concluiu todas as outras com apenas uma tentativa. Já
o participante 2, com exceção da tarefas 1, 2 e 11, concluiu todas as outras com
apenas uma tentativa.
Durante a aplicação do roteiro para o projeto 2, ficou explícita a
independência e facilidade com que os participantes executaram as tarefas. A tabela
37 apresenta as respostas fornecidas pelos participantes, para os questionamentos de
1 a 5 do questionário de avaliação sobre a aplicação do roteiro de tarefas do projeto 2,
implementado pelo participante 2 da segunda etapa do estudo de caso.
143
Tabela 37 - Respostas dos questionamentos de 1 a 5 do questionário de avaliação da Acessibilidade
Web – prototipação do participante 2
Pergunta Participante 1 Participante 2
1 - Como você classifica o tempo despendido para a execução das tarefas solicitas para o aplicativo?
Excelente Bom
2- Como você classifica o suporte oferecido pela aplicação na execução das tarefas solicitas?
Bom Bom
3 - Realizar as tarefas solicitadas na aplicação foi estressante? Não Não
4 - Realizar as tarefas solicitadas na aplicação foi cansativo? Não Não
5 - Como você classifica de maneira geral o grau de acessibilidade encontrado durante a análise do aplicativo?
Bom Bom
Como apresentado na tabela 37, o participante 1 classificou o tempo
despendido para a execução do roteiro do projeto 2 como “Excelente”, a saber: o
tempo gasto pelo participante 1 na execução desse roteiro foi de 10 minutos e 20
segundos. O participante 2, classificou o tempo despendido como “Bom”, a saber: o
tempo gasto pelo participante 2 na execução desse roteiro foi 13 minutos e 30
segundos. Em relação ao suporte que a aplicação ofereceu para a execução das
tarefas, ambos os participantes classificaram “Bom”. Entre as justificativas foi
informado que as funcionalidades estavam possuíam etiquetas e rótulos bem claros e
simples de entender.
Ainda em relação à tabela 37, nenhum dos participantes achou cansativo ou
estressante a execução das tarefas. Por fim, ambos os participantes classificaram o
grau de acessibilidade da aplicação como “Bom”.
A tabela 38 apresenta a comparação dos resultados dos testes manuais de
Acessibilidade entre os 4 aplicativos gerados na etapa de prototipação.
144
Tabela 38 – Resultados das análises manuais de Acessibilidade Web efetuadas nos 4 aplicativos
Projeto/ implementador da segunda etapa
Participante 1 Participante 2
Nº de ajuda
Tarefas concluídas
(%)
Tempo despendido
Nº de ajuda
Tarefas concluídas
(%)
Tempo despendido
Projeto 1 – prototipação do participante 1
3 80% 13min e 35seg 5 80% 15min
Projeto 2 - Prototipação do participante 2
0 100% 10min e 20seg 0 100% 13min e 30seg
Projeto 1- Prototipação do participante 3
1 90% 14min 2 100% 16min
Projeto 1 – Prototipação do participante 4
8 37,5% 12min 8 25% 14min
De acordo com os dados apresentados na tabela 38, podemos constatar que os
aplicativos implementados pelos participantes 2 e 3 da segunda etapa do estudo de
caso obtiveram os melhores desempenhos durante as análises manuais de
Acessibilidade Web. Como já havia sido apresentado na tabela 36, os participantes da
etapa de análise da acessibilidade conseguiram efetuar todas as tarefas solicitadas
para o aplicativo referente ao projeto 2, gerado na etapa de prototipação. Enquanto
que o aplicativo implementado pelo participante 3 apresentou uma única falha
durante o teste manual, efetuado pelo participante 1 da etapa de análise, onde a
tarefa 3 referente ao acesso da galeria de fotos criada, não foi concluída com sucesso.
O protótipo do projeto 1, gerado pelo participante 1 da etapa 2, devido a
ausência de requisitos de acessibilidade, exigiu um pouco mais de esforço dos dois
participantes da etapa de análise. Apesar das ajudas fornecidas, os participantes da
etapa 3 não conseguiram utilizar todas as funcionalidades disponíveis. Porém, o pior
desempenho foi do projeto prototipado pelo participante 4, devido ao baixo índice
de requisitos de acessibilidade web implementados no aplicativo, foram
implementados apenas 16.6% dos requisitos solicitados.
A tabela 39 apresenta a média de tentativas efetuadas pelos dois participantes
da etapa de análise do estudo de caso, para executar as tarefas solicitadas nos
roteiros dos aplicativos.
145
Tabela 39 - Médias das tentativas para executar as tarefas solicitadas nos roteiros dos aplicativos
Projeto/ implementador da segunda etapa Média das tentativas
Participante 1 Participante 2 Média total Projeto 1 – Prototipação do participante 1 2,6 3,1 2,85
Projeto 2 - Prototipação do participante 2 1,18 1,27 1,22
Projeto 1- Prototipação do participante 3 1,6 1,3 1,45
Projeto 1 – Prototipação do participante 4 3,37 3,85 3,61
Conforme os dados apresentados na tabeca 39, com a média de 1,22 tentativas,
o aplicativo que menos exigiu esforços para a execução de suas tarefas foi o
aplicativo referente ao projeto 2, sendo implementado pelo participante 2 da etapa de
prototipação. Enquanto que o aplicativo implementado pelo participante 4, com a
média de 3,61 foi o que mais exigiu esforço dos dois participantes da etapa de
análise da Acessibilidade Web.
Em relação às respostas fornecidas pelos dois participantes da etapa de
análise, no questionário de avaliação, destacamos as classificações fornecidas ao grau
de acessibilidade geral dos aplicativos implementados pelos participantes 3 e 4 da
segunda etapa do estudo de caso. O aplicativo implementado pelo participante 3
recebeu as classificações “Razoável” e “Bom” para o grau de acessibilidade geral.
Enquanto que o aplicativo implementado pelo participante 4 recebeu as
classificações “Ruim” e “Péssimo” para o grau de acessibilidade geral.
6.4.3.2 Análise automatizada da Acessibilidade Web
Para a verificação automatizada da acessibilidade Web foi utilizada a
ferramenta Wave (Wave, 2014). A vantagem de utilizar a ferramenta Wave, é que
além de apresentar os problemas detectados diretamente no conteúdo, também
apresenta os recursos de acessibilidade que a aplicação possui. A ferramenta possui
um relatório que disponibiliza os problemas relacionados aos critérios de sucesso
para alcançar as diretrizes do WCAG 2.0 (Seção 2.2.1.1), os erros específicos de
contrastes de cores e os alertas. A tabela 40 apresenta os resultados dos testes
efetuados na ferramenta Wave.
146
Tabela 40 - Resultados da análise automatizada nos aplicativos gerados na etapa de prototipação
Projeto/ implementador da segunda etapa Problemas relatados
Erros Alertas Contrastes
Projeto 1 – Prototipação do participante 1 0 3 0
Projeto 2 - Prototipação do participante 2 0 0 7
Projeto 1- Prototipação do participante 3 1 1 0
Projeto 1 – Prototipação do participante 4 4 2 0
Os resultados mostrados na tabela 40 indicam que a aplicação gerada pelo
participante 1 da etapa de prototipação, não possui erros referentes ao WCAG 2.0 e
nem sobre contrastes de cores. Conforme foi detectado durante as análises manuais,
efetuadas pelos participantes com limitações visuais, esse resultado não está
totalmente consistente. A aplicação possui alguns problemas relacionados ao
princípio de conteúdo compreensível do WCAG 2.0, ou seja, há controles de
formulários que não possuem clara descrição do que são e o que desempenham.
Além disso, foi detectado outro problema que se relaciona ao princípio de
operabilidade, onde existem controles de formulários que não são acessíveis pelo
teclado, somente pelo mouse. Os três alertas informados são relacionados à possíveis
mudanças de contextos, que podem ser iniciados por menus de salto implementados
em Java Script. Esse alerta não foi confirmado, os menus implementados não estão
efetuando mudança de contexto ou chamando novo conteúdo.
Ainda de acordo com os dados da tabela 40, em relação ao aplicativo
implementado pelo participante 2 da segunda etapa, foram detectados somente erros
de contrastes de cores. Esse implementador definiu para algumas “dicas” e “blocos
de conteúdo” cores muito próximas entre o texto e o segundo plano (background).
Sobre o aplicativo implementado pelo participante 3, foram detectados um erro e um
alerta. O erro se relaciona a falta de definição sobre o idioma da página, e o alerta
com um controle de formulário sem rótulo, porém o alerta não foi confirmado.
Por fim, o aplicativo implementado pelo participante 4 da etapa de
prototipação, de acordo com a tabela 40, apresenta 4 erros, onde dois se relacionam à
falta de rótulos em controles de formulário, um com a definição sobre o idioma da
página e o último com a falta de descrição textual de uma imagem. Os alertas são
sobre a falta de organização do conteúdo em cabeçalhos, para determinar a
147
hierarquia da informação, facilitando a compreensão. Porém, conforme os testes
manuais executados nesse aplicativo, muitos outros problemas existem, entre eles a
“quase” total falta de operabilidade com o teclado, além da falta de suporte e dicas
sobre as funcionalidades.
6.4.3.3 Conclusão para a QP3
Os resultados extraídos dos testes manuais apontaram problemas que não são
detectados por ferramentas de avaliação automática da Acessibilidade Web. Esses
problemas envolvem principalmente a compreensão do conteúdo e suporte à
utilização das funcionalidades da aplicação.
As análises manuais apontaram também que as aplicações implementadas
pelos participantes 2 e 3, durante a etapa de prototipação, apresentaram os melhores
desempenhos em relação a Acessibilidade Web. Vale lembrar que esses participantes
receberam as documentações de requisitos que foram produzidas pelos grupos 2 e 3
da etapa de elicitação, que utilizaram as estratégias de elicitação propostas por esta
pesquisa. O grupo 2 efetuou a elicitação através do processo de elicitação junto a
ferramenta de apoio Omnes web. Enquanto que o grupo 3 efetuou a elicitação
utilizando o processo proposto manualmente.
O participante 1 da etapa de prototipação também recebeu a documentação de
um grupo que utilizou a ferramenta junto ao processo, que foi o grupo 1. Porém,
devido a motivos de indisponibilidade de tempo informada por esse participante, a
quantidade de requisitos de acessibilidade implementada ficou abaixo do esperado,
sendo refletida assim nos testes manuais. Por fim, a prototipação do participante 4
apresentou o pior desempenho em relação a Acessibilidade Web. Esse participante
recebeu a documentação de requisitos de acessibilidade do grupo 4, que efetuou a
elicitação sem utilizar as estratégias de elicitação propostas por esta dissertação.
Por fim, de acordo com a análise dos dados, extraídos durante a etapa de
análise da acessibilidade, foi possível definir a resposta para questão de pesquisa: A
documentação gerada pela estratégia de elicitação proposta causa algum impacto no produto
implementado?. Concluímos que sim, a documentação gerada causa impacto positivo
no produto implementado. Destacamos as implementações efetuadas pelos
148
participantes 2 e 3 que utilizaram as documentações de requisitos, produzidas
através das estratégias de elicitação proposta por esta pesquisa, cujo o resultado
mostrado durante as análises manuais e automatizadas de acessibilidade foi bem
satisfatório. Os dois participantes que possuem limitações visuais elegeram o
aplicativo para gestão de metas, referente ao projeto 2, como o mais acessível de
todos os analisados. Entretanto, deve-se levar em consideração que há outros fatores
importantes que impactam o produto final, dentre eles, a experiência e
disponibilidade do desenvolvedor. Esses fatores devem ser controlados de maneira
mais rígida, a fim de alcançar resultados mais conclusivos. O projeto prototipado
pelo participante 1 não apresentou resultados satisfatórios, apesar desse participante
ter recebido todas as documentações necessárias. Porém, vale salientar que as falhas
detectadas nesse protótipo não se relacionaram diretamente com limitações da
estratégia de elicitação, apresentada nesta dissertação, e sim por problemas do
próprio prototipador, de acordo informações fornecidas pelo mesmo. A aplicação
gerada pelo participante 4, auxilia no entendimento de que a estratégia de elicitação
adotada e sua consequente documentação podem influenciar de maneira profunda o
produto final a ser disponibilizado pelos implementadores.
6.5 Ameaças a validade
De acordo com Travassos et al. (2002) as ameaças de validade englobam
fatores, internos e externos, que podem ocasionar variações conflitantes para os
resultados alcançados através de estudos empíricos. A seguir são apresentadas as
principais ameaças à validade dos resultados obtidos no estudo de caso apresentado
neste documento.
6.5.1 Validade interna
A validade interna de um estudo de caso leva em consideração os fatores que
não foram controlados ou medidos e que podem influenciar os resultados
encontrados. Para cada uma das etapas do estudo de caso foram levantadas as
ameaças à validade interna que podem influenciar diretamente no grau de
acessibilidade dos protótipos gerados.
149
Para a etapa de Elicitação do estudo de caso foram levantadas as seguintes ameaças
internas:
Nível de conhecimento dos elicitadores: os participantes apresentaram níveis
distintos de conhecimento em relação à atividade de elicitação de requisitos e
Acessibilidade Web. Porém, para minimizar os efeitos desta ameaça, foi
realizado, antes da execução dessa primeira etapa do estudo de caso, um
treinamento com todos os participantes, a fim de apresentar os principais
conceitos envolvidos na execução das atividades da etapa de elicitação. Dessa
forma, esse treinamento auxiliou na diminuição das discrepâncias existentes entre
os níveis de conhecimento apresentados por cada um dos participantes. Outra
estratégia adotada para amenizar essa ameaça envolveu a divisão dos grupos.
Essa divisão ocorreu de maneira uniforme, tanto em termos de quantidade de
participantes quanto em termos do nível de conhecimento apresentado pelos
mesmos.
Catálogo RNFs incompleto ou desatualizado: o catálogo de Requisitos de
Acessibilidade Web, elaborado por esta pesquisa, foi modelado com base no
WCAG 2.0 da W3C. Porém, o próprio WCAG admite que embora suas diretrizes
abranjam um grande número de problemas, o documento não têm capacidade
para abordar as necessidades de pessoas com todos os tipos, graus e combinações
de incapacidades (W3C-WCAG 2.0, 2013). Visando abranger o máximo de
requisitos, pesquisas foram efetuadas a cerca de outros documentos elaborados
para a Acessibilidade Web, como a Section 508 (Section 508, 2013) e o eMAG
(Governo Eletrônico, 2014). Porém, constatamos que estas documentações contêm
basicamente as diretrizes do WCAG 2.0, com algumas adaptações para
consideração da acessibilidade na elaboração de hardwares, como é o caso da
Section 508. Outra diferença envolve a questão da obrigatoriedade de
implementação da Acessibilidade, definida na Section 508 e no eMAG, para
elaboração de sites governamentais. A implementação das diretrizes do WCAG
não é obrigatória, pois se trata de um documento de boas práticas e não de regras.
Consideramos que os efeitos dessa ameaça foram minimizados, pois foi
constatado que as principais diretrizes de Acessibilidade Web foram levantadas
150
pelas iniciativas do WCAG, por este motivo este documento foi selecionado e
usado como base para a modelagem do catálogo RNFs aqui apresentado.
Para a etapa de Prototipação do estudo de caso foram consideradas as seguintes
ameaças:
Nível de conhecimento do prototipador: o nível de conhecimento de
prototipação, dos participantes dessa segunda etapa do estudo de caso, foi
considerado um fator de grande importância. Tendo em vista que esse fator
influencia diretamente na qualidade do protótipo gerado. Visando minimizar
essa ameaça foram selecionados participantes que possuíssem alguma
experiência em prototipação de aplicativos Web. Em relação ao conhecimento dos
prototipadores acerca da Acessibilidade Web, dos quatro participantes, dois
apresentaram alguma experiência nessa área. Para minimizar os efeitos desse
problema, assim como foi feito na etapa de elicitação, antes da execução da etapa
de prototipação, todos os participantes receberam um treinamento, a fim de
apresentar os principais conceitos envolvidos de Acessibilidade Web.
Complexidade dos projetos: apesar de todos os participantes da etapa 2
possuírem alguma experiência em prototipação, o grau de dificuldade para
executar as atividades necessárias, pode ser considerada uma ameaça. Visando
minimizar esse problema, efetuamos uma revisão nas funcionalidades dos
projetos relacionados, redefinindo e selecionando funcionalidades menos
complexas de serem prototipadas.
Controle no tempo de disponibilidade dos participantes: apesar de selecionar
apenas pessoas que possuíssem disponibilidade para a execução das atividades
da prototipação, não foi possível estabelecer um controle para garantir o máximo
aproveitamento do tempo de disponibilidade de cada participante. Tendo em
vista que todos os participantes informaram algum grau de limitação em suas
disponibilidades, exigindo uma flexibilidade tanto para os horários, como para o
local de execução das atividades. Dessa forma, a fim de minimizar os efeitos
dessa ameaça, foi acordado que os participantes realizariam as atividades em
locais e horários definidos por eles. Sendo controlado apenas o tempo total
despendido para a execução da prototipação. Além disso, visando atingir um
151
grau maior na qualidade das funcionalidades prototipadas, o autor desta
pesquisa realizou uma revisão na quantidade de requisitos funcionais definida
inicialmente para os projetos. Para o projeto do Aplicativo para criação de galeria
de fotos interativa, dos 20 RFs definidos inicialmente, apenas 13 foram repassados
aos participantes. Para o projeto do Aplicativo para gestão de Metas, a
quantidade de RFs caiu de 21 para 12. Essa revisão ocorreu de maneira a permitir
criar casos de testes suficientes para a etapa de Análise da Acessibilidade Web do
estudo de caso.
Para a etapa de Análise da acessibilidade do estudo de caso foram consideradas as
seguintes ameaças:
Experiência em navegação Web: a pouca experiência dos participantes em
navegação Web pode gerar resultados distorcidos em relação a classificação
do grau de acessibilidade disponibilizados nos protótipos. Apesar de registrar
a experiência dos participantes, através do questionário apresentado no
apêndice I, essa informação foi utilizada apenas para fins de registro e não
como critério de seleção. Porém, para minimizar os efeitos desta ameaça, foi
realizado, antes da execução dessa terceira etapa, um treinamento com os dois
participantes selecionados, a fim de apresentar detalhadamente todas as
funcionalidades contidas nos protótipos a serem analisados.
Grau da limitação física apresentada: os dois participantes definidos para
essa terceira etapa possuíam o mesmo grau de limitação visual, relacionada à
perda total da visão. Porém, entendemos a importância de relacionar usuários
com diferentes níveis de limitações, a fim de gerar e analisar os variados
resultados em relação ao grau de acessibilidade disponibilizado nos
protótipos gerados. Como os dois participantes disponíveis e selecionados
para esse estudo de caso apresentaram o mesmo o grau de limitação visual, os
roteiros de tarefas elaborados, apresentados nos apêndices L e M, seguiram o
mesmo padrão de execução. Porém, para futuros estudos de casos, cuja
seleção dos participantes inclua usuários com diferentes níveis de limitações,
se faz necessário realizar revisões nesses roteiros de tarefas, a fim de registrar
os novos resultados.
152
Configuração do ambiente: o ambiente utilizado pelos participantes durante
a análise da acessibilidade influencia diretamente na facilidade de uso dos
aplicativos Web. Como os participantes selecionados apresentaram o mesmo
grau de limitação visual, basicamente a estrutura do ambiente exigia um
computador, desktop ou notebook, com teclado de marcações táteis nas teclas
“F” e “J“, além da instalação de um software para leitura de tela. Porém,
devido quantidade de sistemas operacionais e navegadores Web (browsers)
disponíveis atualmente, se torna comum que os usuários apresentem
preferência por um determinado sistema operacional e navegador. Essa
preferência muitas vezes está relacionada com a facilidade de adaptação na
usabilidade desses softwares. Dessa forma, oferecer um ambiente totalmente
compatível com cada participante relacionado nem sempre é viável. Porém,
para minimizar os efeitos dessa ameaça, permitimos que os participantes
utilizassem seus próprios computadores. O mesmo procedimento foi adotado
na escolha do software para a leitura de tela, onde os dois participantes
indicaram o NVDA (NonVisual Desktop Access) na versão 2013.1rc1 (NVDA,
2014).
6.5.2 Validade externa
A validade externa de um estudo de caso se relaciona com fatores que limitam
a generalização dos resultados alcançados por este. Desta maneira, quatro ameaças à
validade externa foram detectadas. Essas ameaças abrangem as três etapas do estudo
de caso, apresentado por esta pesquisa.
A primeira das ameaças à validade externa desse estudo de caso se relaciona à
quantidade de projetos definidos para o mesmo. Definimos apenas dois projetos, a
fim de avaliar a estratégia de elicitação proposta. Para obtermos resultados mais
precisos e comparativos, seria ideal então, no futuro, a realização deste estudo de
caso com uma quantidade maior de projetos.
A segunda ameaça à validade externa está relacionada ao tamanho e a
complexidade dos projetos. Tendo em vista que os projetos definidos para esse
estudo de caso foram baseados em escopos simples, contendo uma quantidade
153
pequena de requisitos. Para futuros testes o ideal é utilizar a abordagem proposta
por esta pesquisa em projetos mais robustos, a fim de testar a eficácia da mesma.
A terceira ameaça à validade externa está relacionada à quantidade de
situações elaboradas na etapa de elicitação desse estudo de caso. Essas situações
foram criadas para definir a utilização dos recursos de elicitação disponibilizados por
esta pesquisa (veja seção 6.2.1.2). Para essa etapa foram definidas apenas 3 situações,
para cada situação havia uma definição específica sobre qual recurso de elicitação
seria disponibilizados aos elicitadores. Essas três situações permitiu comparar os
resultados alcançados, na execução das atividades de elicitação, através de três
cenários distintos. Visando gerar e analisar resultados que possibilite novas
comparações, se torna interessante definir novas situações, a fim de verificar a
eficácia na utilização de cada recurso de elicitação disponibilizado.
Por fim, citamos a ameaça à validade externa que está relacionada à
quantidade de participantes desse estudo de caso. A pequena quantidade de
participantes que conseguimos selecionar, nos limita na questão de generalização
dos resultados alcançados. Dessa forma, visando obter resultados mais expressivos,
que nos permita, por exemplo, estimular a utilização em larga escala da estratégia de
elicitação proposta, seria ideal no futuro, a realização deste estudo com um número
maior de participantes.
6.6 Considerações finais sobre o Capítulo
Este capítulo apresentou o estudo de caso elaborado para avaliar o suporte
que a estratégia apresentada nesta pesquisa oferece à atividade de elicitação dos
requisitos de Acessibilidade Web. Inicialmente foi abordada toda a parte de
planejamento desse estudo, a fim de mostrar os detalhes de sua estrutura que foi
dividida em três etapas: I – Elicitação, II – Prototipação e III – Análise da
acessibilidade.
Essas etapas foram elaboradas para responder três questões de pesquisas (veja
tabela 13 na seção 6.1). Para cada uma dessas etapas foram definidos os artefatos a
serem processados e produzidos, a seleção dos participantes e a preparação do
ambiente. Após a descrição do planejamento de cada uma das etapas, foram
154
abordados detalhes sobre a execução destas. Através da execução das etapas, as
questões de pesquisas foram respondidas.
Os dados extraídos na etapa de elicitação foram utilizados para responder a
QP1 (primeira questão de pesquisa). Para isso, foram considerados os seguintes
fatores: I - a corretude dos dados obtidos na elicitação dos requisitos de
Acessibilidade Web, II - O tempo total despendido para execução da elicitação e - III
A análise sobre a documentação gerada. Os dados extraídos na etapa de prototipação
foram utilizados para responder a QP2. Para isso, foram considerados os fatores: I -
Controle sobre a prototipação dos requisitos, II – A avaliação dos desenvolvedores
em relação a documentação de requisitos recebida. Os dados extraídos da etapa de
Análise da acessibilidade foram utilizados para responder a QP3. Para isso, foram
considerados os resultados da análise manual e automatizada do grau de
Acessibilidade Web nos protótipos.
Com a configuração do estudo de caso estabelecida em três etapas, foi
possível analisar o impacto que a estratégia de elicitação, proposta por esta
dissertação, causou em diferentes contextos. Na etapa de elicitação foi possível
concluir que o método de elicitação e sua ferramenta de apoio oferecem um nível de
suporte satisfatório aos elicitadores, promovendo a otimização do tempo gasto tanto
para a extração das informações do catálogo de RNFs como para a geração de
artefatos. Além disso, a estratégia de elicitação proposta fornece uma maior
abrangência sobre as informações a serem extraídas do catálogo, graças à definição
de parâmetros que auxiliam na identificação e seleção dos requisitos.
Na etapa de prototipação foi constatado que a documentação gerada, através
da estratégia de elicitação aqui proposta, promove um maior controle sobre a
prototipação dos requisitos de Acessibilidade Web. Mesmo diante de algumas
limitações, como falta de disponibilidade e conhecimento defasado, por parte dos
participantes, artefatos como o checklist ofereceram um suporte satisfatório,
mostrando a viabilidade de utilizá-los durante a prototipação. De acordo com
informações passadas pelos participantes, sem o checklist, que foi obtido a partir dos
requisitos elicitados, a quantidade de requisitos de acessibilidade a serem
considerados seria precária, pois a visão alternativa que ele oferece dos elementos
155
contidos no catálogo foi fundamental na compreensão dos requisitos, e sobre o que
deve ser feito em relação a eles, com base nas operacionalizações. A produção bem
abaixo do esperado, disponibilizada pelo participante 4 da etapa de prototipação,
auxilia na confirmação de que a falta de artefatos representando visões alternativas
dos RNFs pode ocasionar implementações problemáticas.
Na etapa de análise da acessibilidade, foi possível constatar que os projetos
prototipados pelos participantes que receberam todos os artefatos do método
proposto, apresentaram um desempenho melhor durante os testes manuais e
automatizados. Os desempenhos dos protótipos gerados pelos participantes 2 e 3, da
etapa 2 do estudo de caso, fundamentaram essa constatação. Inclusive, o protótipo
gerado pelo participante 2 foi eleito o mais acessível pelos participantes da etapa 3.
Em contra partida, o projeto prototipado pelo participante 1 não apresentou
resultados satisfatórios, apesar desse participante ter recebido todas as
documentações necessárias, assim como os participantes 2 e 3. O participante 1
apresentou justificativas que isentaram a estratégia de elicitação proposta, o mesmo
informou limitações na disponibilidade de tempo e outros problemas, inclusive de
saúde. O pior desempenho foi apresentado pelo protótipo do participante 4,
lembrando que esse participante recebeu apenas o SIG do produto como artefato.
Esse fato indica que a estratégia de elicitação adotada e sua consequente
documentação podem influenciar de maneira profunda o produto final.
Por fim, este capítulo apresentou as ameaças à validade dos resultados
obtidos no estudo de caso elaborado. Foram abordadas ameaças à validade interna
como o “Nível de conhecimento dos participantes da etapa de elicitação”, o
“Controle no tempo de disponibilidade dos participantes da etapa de prototipação” e
o “Grau de limitações físicas apresentadas pelos participantes da terceira etapa”.
Em relação às ameaças à validade externa, ao todo foram identificadas 4
ameaças, todas abrangendo as três etapas do estudo de caso. Entre as ameaças
externas destacamos o tamanho e a complexidade dos projetos, que se relaciona com
a necessidade realizar o estudo de caso, apresentado neste documento, em projetos
mais robustos. Essas ameaças levantadas, tanto as internas como as externas, devem
ser controladas de maneira mais rígida, a fim de garantir o melhor andamento de um
156
estudo de caso. Aumentando assim, a chance de alcançar resultados mais
expressivos e conclusivos.
157
7 Trabalhos relacionados
Na literatura foram encontrados trabalhos voltados tanto para alcançar a
acessibilidade durante o processo de desenvolvimento, quanto para sites ou
aplicações web já finalizados. Além de pesquisas envolvendo a acessibilidade,
destacamos também estudos contendo estratégias para a elicitação de RNFs. A
seguir, apresentamos os principais trabalhos relacionados à nossa pesquisa. Para
facilitar a compreensão, distribuímos esses trabalhos em tópicos que levamos em
consideração quando definimos nossa estratégia:
Interdependência entre componentes técnicos e humanos: Na pesquisa de
Chisholm e HENRY (2005) defende-se a idéia de que a acessibilidade na web
depende da relação entre componentes técnicos e humanos. No passado a
responsabilidade sobre acessibilidade era direcionada apenas para os produtores
de conteúdo web, mas esta visão mudou, e a relação entre componentes humanos
e técnicos tornou-se um aspecto importante para o desenvolvimento, eliminando
assim a responsabilidade sobre um único elemento. Assim, para Chisholm e
HENRY (2005) a inserção da acessibilidade no ciclo de desenvolvimento é
extremamente necessária. Entretanto, os autores não esclarecem em qual estágio
do desenvolvimento seria adequado considerar a acessibilidade, tornando-se uma
das limitações desta pesquisa. Outra limitação é a falta de uma análise sobre a
interação dos usuários com as funcionalidades do sistema, onde um
levantamento sobre o público alvo e suas respectivas limitações, poderiam gerar
funcionalidades mais adequadas ou agilizar o processo de elicitação dos
requisitos de acessibilidade. Não há também uma preocupação clara sobre os
possíveis conflitos existentes entre os requisitos de acessibilidade e outros RNFs.
Integração entre requisitos de Acessibilidade Web e RFs: Baguma et al (2009)
afirma que analisar acessibilidade na fase inicial do desenvolvimento é mais
viável, pois facilita o andamento do projeto, evitando o retrabalho na fase de
implementação, uma vez que a equipe de desenvolvimento não precisará perder
tempo fazendo adaptações, podendo assim se preocupar com outras tarefas. A
158
pesquisa deixa explícito que esses requisitos devem ser integrados já nas fases de
análise e especificação de requisito. O estudo mostra a integração dos requisitos
de acessibilidade com requisitos funcionais, indicando os benefícios que os
engenheiros de software podem extrair desta abordagem como, por exemplo, a
detecção precoce de eventuais conflitos entre o projeto de interface com os
princípios de acessibilidade. Essa ideia de existir um relacionamento entre os RFs
e os requisitos de Acessibilidade Web influenciou a definição da primeira
atividade do processo de elicitação proposto por esta dissertação. Porém, a
pesquisa de Baguma et al (2009) não fornece uma estratégia clara para
estabelecer esse relacionamento. Nossa pesquisa propõe uma análise em cada RF,
a fim de compreender quais os tipos de conteúdos que aquele RF irá trabalhar.
Dessa forma o relacionamento que passará a existir entre o RF e os requisitos de
acessibilidade se torna mais explícito, facilitando controlar o que de
acessibilidade aquele RF precisará. Outra limitação do trabalho é a não
sistematização da elicitação, os autores utilizam algumas definições, porém não
chegam a propor um processo sistematizado que possa guiar a elicitação dos
requisitos de Acessibilidade Web.
Transformação do conteúdo web: Uma ferramenta que garante uma
transformação menos exaustiva de conteúdo web é proposta por HANSON e
RICHARDS (2003), os autores fornecem exemplos sobre como a capacidade de
transformação conhecida como “on the fly” (transformação instantânea ou em
tempo real) pode ser dinâmica. Esse trabalho defende que a acessibilidade pode
ser alcançada com baixo custo para o desenvolvimento e abranger uma
quantidade maior de usuários. Essa estratégia para a transformação de conteúdo
visa a acessibilidade web, em produtos já implementados ou finalizados,
enquanto a pesquisa aqui proposta visa uma estratégia que considere o
tratamento para os requisitos de Acessibilidade Web já nas atividade de elicitação
e análise de requisitos.
Acessibilidade através de auxilio colaborativo: Um framework de avaliação em
camadas é definido no trabalho de Boldyreff (2002), onde uma melhor
compreensão sobre a acessibilidade é o fator chave para alcançá-la. Buscando
159
atender a esse propósito, o autor criou um modelo abstrato e específico para esse
domínio. Essa pesquisa abrange conceitos sobre o trabalho de auxílio
colaborativo através da computação, com o intuito de refinar e estender as
questões técnicas, além disso, destaca a necessidade de se considerar a
acessibilidade sob o ponto de vista dos desenvolvedores e mantenedores (bem
como, também, o usuário da web). O framework se apresenta como um diagrama
em camadas mostrando a interdependência de componentes, fazendo uma
analogia entre os sistemas web e sistemas CSCW (Computer Supported
Cooperative Work). Os critérios de avaliação das camadas são dependentes uns
dos outros em relação a sua eficácia. As camadas de avaliação contidas nesse
framework são: confiança, eficiência, funcionalidade, usabilidade, eficácia,
manutenibilidade e padrões. Os autores dessa pesquisa definem um framework
para compreensão da Acessibilidade Web, porém não define procedimentos ou
estratégias para elicitar e analisar as alternativas a serem consideradas de acordo
com esse domínio. Nossa pesquisa, além de definir um processo e uma
ferramenta de apoio, indica a utilização de um catálogo que possa servir como
base de conhecimento comum sobre o domínio da Acessibilidade Web.
Framework para elicitação dos requisitos de Acessibilidade Web: Na pesquisa
de Masuwa (2008) é apresentado um framework, chamado AccessOnto, visando
o apoio à especificação de requisitos de acessibilidade. O framework fornece um
repositório de diretrizes de acessibilidade e mais uma linguagem de especificação
para ajudar os desenvolvedores de software a incluírem os requisitos de
acessibilidade no documento de requisitos. O AccessOnto mescla as diretrizes de
acessibilidade com a engenharia de requisitos, fornecendo uma plataforma para a
localização dos requisitos através do repositório contido no framework. Entretanto,
uma limitação do Framework AccessOnto, se refere ao fato de não oferecer
suporte para análise dos requisitos funcionais do sistema, a fim de compreender
o que de acessibilidade está relacionada com cada funcionalidade elicitada.
Apesar de promover a facilidade na localização dos requisitos de Acessibilidade
Web, a pesquisa de Masuwa (2008) não oferece estratégias claras para conduzir o
processo de análise e especificação dos requisitos. E por fim, o framework
160
AccessOnto não oferece uma estrutura para que o engenheiro de requisitos possa
efetuar análises de conflitos entre os RNFs e refinamento dos requisitos de
Acessibilidade Web.Acessibilidade através da Engenharia Web: O trabalho
apresentado por Dias et al. (2012) ) aborda uma extensão do framework criado
para Engenharia Web de Pressman e Lowe (2008). O Foco dessa pesquisa é a
inserção dos requisitos de acessibilidade durante o processo de desenvolvimento
de software. O framework estendido aborda especificamente o processo de
elicitação dos requisitos presente na fase de comunicação da Engenharia Web. A
idéia dos autores é a elicitação dos requisitos considerando as características dos
usuários. Nesse contexto, os requisitos são elicitados levando em consideração
apenas o perfil dos utilizadores em relação a suas limitações. O trabalho de Dias
et al (2012) influenciou a definição do processo para elicitação dos requisitos de
acessibilidade proposto nesta dissertação, a idéia dos autores de considerar as
limitações do usuário para elicitação foi incorporada, pois influencia diretamente
na escolha do tipo de conteúdo a ser disponibilizado pelas funcionalidades do
sistema (vídeos, imagens, textos, etc.). Ao analisar esse trabalho, ficou evidente
que a forma de elicitar os requisitos de acessibilidade é limitada, uma vez que a
lista de requisitos criada contém descrições genéricas, englobando de forma
reduzida as diretrizes da W3C. Não há na pesquisa nenhuma indicativa de
análise ou refinamento dos requisitos de acessibilidade elicitados. Dessa forma,
não se define estratégias para operacionalizar a acessibilidade.
Uso de catálogo de RNFs para reutilização de modelos: A pesquisa de Serrano,
M. M. (2013) aborda a elicitação de requisitos para os domínios da computação
invisível, invasiva e móvel. Visando oferecer um corpo adequado para a
reutilizável de conhecimento, os autores disponibilizam um catálogo de RNFs
baseado na abordagem NFR Framework e para sua utilização foi elaborado um
método e uma ferramenta. O método proposto é composto por 5 atividades,
sendo estas: Exploração, Coleta, Modelo, Operacionalização e Validação. A
atividade de Exploração é composta pelas sub-atividades de Consulta e Extração,
e auxilia os desenvolvedores na exploração e extração de conhecimento do
catálogo. A atividade de Coleta é composta pelas sub-atividades Recolhimento e
161
Instanciação, nessa etapa ocorre a escolha dos requisitos, onde os elicitadores
podem pegar os requisitos tal como estão especificados no catálogo ou adaptá-los
para a aplicação em desenvolvimento. Na atividade Modelo os elicitadores
devem trabalhar na decomposição ou determinação das interdependências, essa
atividade só é necessária caso o elicitador tiver efetuado adaptações ou evoluções
em algum requisito na atividade de Coleta. A atividade de Operacionalização
auxilia o elicitador disponibilizando estratégias pré-definidas que podem ser
utilizadas durante a fase de implementação. A atividade de Validação é composta
pelas sub-atividades Avaliar e Resolver conflitos, de acordo com a avaliação do
elicitador os requisitos e seus descendentes podem ou não ser aceitos. Em caso de
algum conflito entre os requisitos, o elicitador deve buscar soluções ou negar a
aceitação do requisito conflitante. Em relação a ferramenta desenvolvida para
utilização do catálogo há poucas informações, baseando-se unicamente na
descrição dos autores foi possível identificar que ela ajuda na apresentação e
navegação do conteúdo do catálogo através de uma árvore de exploração. Pela
descrição das atividades foi possível identificar também que não existe
automatização para nenhum dos procedimentos existentes no método de uso do
catálogo, e que realmente a ferramenta desenvolvida trata basicamente questões
especificas, tais como: exploração, visualização, seleção manual dos RNFs e suas
interdependências. Em Serrano, M. M. (2013) apesar dos autores informarem que
o acesso ao catálogo e a ferramenta está aberto ao público para análises e
contribuições, não foi possível acessar nenhum dos dois para maiores
verificações. Mas analisando esse trabalho foi possível perceber alguns pontos em
comum com a nossa pesquisa, tais como: o uso de abordagens orientadas a meta,
a intenção de melhorar a utilização do catálogo de RNFs proposto através de
atividades agrupadas em um método, e por fim o desenvolvimento de uma
ferramenta. As limitações detectadas na pesquisa, que na verdade também
revelam algumas das principais diferenças para a nossa pesquisa, inicialmente
referem-se à composição do método proposto pelos autores, onde basicamente
existem procedimentos comuns ou nativos da própria abordagem NFR
Framework. No método de elicitação apresentado por nossa pesquisa há uma
162
estrutura voltada para considerar os RFs e o perfil do público alvo para controlar
a elicitação dos requisitos. Esses controles se encontram presentes na primeira
atividade de Análise sobre os requisitos funcionais. Em relação às atividades
comuns ao NFR Framework, houve um encapsulamento dessas atividades em
apenas duas atividades do nosso processo, sendo estas: Seleção dos requisitos
para acessibilidade e Análise para operacionalização dos requisitos de
acessibilidade. E por fim, o fator automatização está presente em boa parte do
nosso processo, primeiro na etapa de Seleção dos requisitos para acessibilidade, e
segundo na quarta e última atividade de Geração de Artefatos, onde são gerados
automaticamente um XML contendo os requisitos elicitados, um Checklist para
controle de implementação e um catálogo de correlações. O processo de Serrano,
M. M. (2013) é basicamente manual.
Adaptação em projetos web: Casteleyn et al. (2006) aborda a necessidade de fazer
adaptações nos projetos de aplicações web, visando atender interesses como:
privacidade, acessibilidade entre outros requisitos não funcionais. Para
exemplificar como seria a execução do projeto utilizam a abordagem HERA
(Vdovjak et al., 2003), a ideia é mostrar como estender aplicações de sistemas já
existentes, cuja necessidade de alteração é complexa e necessária, a técnica é
baseada na implementação de componentes genéricos (GAC). Para tratar a
natureza crosscuting dos requisitos os autores utilizam orientação a aspecto.
Eficácia no uso de catálogos de RNFs: A pesquisa de Cysneiros (2007) aborda
um estudo empírico para comprovar a eficácia da utilização dos catálogos para
elicitação de RNFs. O Framework i* foi escolhido para construção do catálogo de
RNFs utilizado no experimento, para auxiliar na utilização do catálogo o autor
elaborou uma abordagem sistemática de exploração. Essa abordagem
compreende 4 etapas, sendo estas: I Construção do modelo funcional, II
Investigação dos RNFs necessários, III Cópia das alternativas para o modelo i* e
IV Avaliação das alternativas. A primeira atividade compreende a identificação
dos requisitos funcionais da aplicação. A segunda etapa compreende a elicitação
do RNFs e suas operacionalizações. A terceira atividade compreende integrar os
RNFs e as operacionalizações selecionadas com o modelo funcional. E por fim a
163
quarta atividade compreende a análise de conflitos presentes entre os RNFs
elicitados. O experimento consistia em verificar a eficácia dos participantes para
encontrar e criar novas operacionalizações.
A ausência de uma análise sobre a Acessibilidade Web, em relação ao
levantamento e refinamento dos requisitos, citada como limitação nos trabalhos de
Masuwa (2008) e Dias et al (2012), foi abordada em nossa pesquisa através da
definição de um catálogo de RNFs baseado no NFR Framework . Esse catálogo é uma
importante contribuição desta dissertação, pois oferece suporte para aplicarmos os
refinamentos e análise de conflitos entre os requisitos do domínio de acessibilidade e
outros requisitos não-funcionais.
Assim como Cysneiros (2007) e Serrano, M. M. (2013), nossa pesquisa também
define um método de elicitação que utiliza como base catálogos de RNFs. Porém, um
importante fator que essas pesquisas não levaram em consideração foi a análise sobre
os requisitos funcionais do sistema. Nesse contexto nossa pesquisa apresenta uma
importante estratégia que é a análise sobre os tipos de conteúdos (veja seção 4.1.1)
dos RFs, esse procedimento facilitou a compreensão sobre o que deveria ser
implementado de Acessibilidade Web, de acordo com os tipos de conteúdo definidos
no projeto.
Nosso trabalho também leva em consideração a interação dos usuários com as
funcionalidades do sistema, preocupação ausente na pesquisa de Chisholm e
HENRY (2005), efetuando análises sobre o público alvo e suas respectivas limitações,
a fim de gerar funcionalidades mais adequadas ao contexto dos usuários. Outro fator
diferencial, presente em nosso método de elicitação, envolve a definição de um
checklist para o controle de implementação dos requisitos de acessibilidade Web
elicitados. E por fim, o fator automatização promovido pela ferramenta Omnes Web,
se torna um importante diferencial e contribui para facilitar a utilização dos
catálogos.
164
8 Conclusão
Este trabalho define e apresenta uma estratégia para a elicitação dos requisitos
de Acessibilidade Web. Essa estratégia consiste na criação de um método semi-
automatizado e uma ferramenta de apoio, a Omnes Web. Como base para a elicitação
dos requisitos, um catálogo foi criado para armazenar e representar os requisitos e
operacionalizações relacionadas ao domínio da Acessibilidade Web. Esse catálogo
foi elaborado de acordo com as diretrizes contidas no WCAG 2.0, e foi modelado de
acordo com os princípios do NFR Framework.
Para demonstrar o comportamento da estratégia de elicitação contida nesta
pesquisa, foi utilizado um exemplo baseado no documento de requisitos do Sistema
Agendador de reuniões (Lamsweerde et al., 1993). Esse exemplo foi utilizado em
duas situações distintas, na primeira situação, apresentada no Capítulo 4, foi
utilizado para demonstrar a utilização totalmente manual do método de elicitação
proposto. Já na segunda situação, mostrada no Capítulo 5, foi utilizado para
demonstrar o comportamento do método junto a sua ferramenta de apoio Omnes
Web. Para avaliar o método e a ferramenta Omnes Web, um estudo de caso foi
executado e seus resultados foram discutidos no Capítulo 6.
A configuração do estudo de caso permitiu analisar se a nossa a estratégia de
elicitação impacta as atividades de elicitação, prototipagem, e nos protótipos
gerados. Com a execução da etapa de elicitação, verificamos que o método e sua
ferramenta de apoio promoveram melhorias às atividades de elicitação, baseadas no
NFR Framework, otimizando o tempo gasto na extração de informações do catálogo
e geração de artefatos. A ideia de vincular parâmetros aos elementos do catálogo
facilitou a identificação e seleção dos requisitos. Por fim, foi possível perceber erros
na elicitação nos artefatos produzidos pelos participantes que utilizaram somente o
catálogo de RNFs durante a elicitação como, por exemplo, a seleção de requisitos que
não faziam parte do contexto das limitações físicas definidas para o público alvo do
projeto. Esse fato pode indicar que além da automação, as utilizações do método e da
ferramenta de apoio também contribuem qualitativamente na consistência dos
artefatos.
165
Em relação à etapa de prototipação, verificamos o suporte que a
documentação gerada, durante a etapa de elicitação, oferece à implementação dos
requisitos de Acessibilidade Web. De acordo com os implementadores, os catálogos
baseados no NFR Framework permitiram uma maior compreensão sobre o domínio
da Acessibilidade Web e as alternativas para alcançá-la. O controle de
implementação, oferecido através do checklist, permitiu verificar o que faltou ser
implementado de acessibilidade e o motivo pelo qual não foi implementado. Dessa
forma, foi possível constatar de acordo com as informações passadas pelos
participantes dessa etapa, que alguns requisitos não foram implementados devido a
falta de disponibilidade dos participantes e não por limitações relacionadas à
documentação gerada.
Por fim, a execução da etapa de análise da acessibilidade dos protótipos
gerados mostrou que alguns projetos tiveram bom desempenho nos testes manuais e
automatizados. Os projetos implementados pelos participantes 2 e 3, com base na
documentação fornecida por grupos que utilizaram o processo e a ferramenta de
apoio, apresentaram um bom desempenho durante os testes, principalmente o
projeto 2 referente ao aplicativo para gestão de metas.
A seguir são apresentadas as contribuições deste trabalho e sugestões de
trabalhos futuros.
8.1 Contribuições
A principal contribuição desta dissertação é a elaboração de uma estratégia
envolvendo um processo sistematizado para a elicitação dos requisitos de
Acessibilidade Web e sua ferramenta Omnes Web. Essa estratégia de elicitação
promove a inserção da Acessibilidade Web já nas atividades de elicitação e análise de
requisito do processo de desenvolvimento de software. Além dessa contribuição,
destacamos as seguintes:
A definição de um catálogo de RNFs para o domínio dos requisitos de
Acessibilidade Web, que pode servir como guia para os engenheiros de
requisitos, durante a elicitação e análise das alternativas para implementação de
projetos web mais acessíveis. Além de servir como base de conhecimento, esse
166
catálogo contém uma importante estratégia para facilitar a extração de suas
informações, que se trata do vínculo de parâmetros relacionados às limitações do
público alvo e tipos de conteúdo. Essa estratégia permite identificar rapidamente
as alternativas necessárias dentro do catálogo de RNFs.
A Análise sobre os tipos de conteúdos (seção 4.1.1) que facilitou a compreensão
sobre o que deveria ser implementado de Acessibilidade Web em cada requisito
funcional.
A definição de um checklist, usando a estrutura de uma tabela para controle de
implementação dos requisitos de acessibilidade Web. Além de promover o
controle de implementação dos requisitos, o checklist permite gerenciar quais
requisitos não foram implementados. Se por algum motivo ocorrer alguma
omissão na elicitação dos requisitos de Acessibilidade Web, e esse problema for
detectado pelo implementador ou prototipador, o checklist fornece a
possibilidade de registrar quais requisitos foram implementados além daqueles
elicitados.
Automatização de procedimentos da elicitação utilizando a ferramenta Omnes
Web, como a extração de informações do catálogo de RNFs, promovendo um
ganho de tempo substancial para os elicitadores. Outra importante automatização
ocorre na geração de artefatos, promovendo agilidade e o apoio para elaboração
de parte da documentação de requisitos.
A execução de um estudo de caso, que fez uma avaliação do impacto do uso da
estratégia na elicitação e como os requisitos elicitados podem contribuir para
implementação e qualidade do produto desenvolvido. Embora esse estudo não
tenha valor estatístico, ele possibilitou a discussão sobre tópicos importantes e o
levantamento de questões para pesquisa futura.
8.2 Limitações e trabalhos futuros
A utilização do método de elicitação, apresentado por esta pesquisa, junto à
ferramenta de apoio Omnes Web promoveu benefícios relacionados ao custo de
tempo gasto na elicitação e suporte para produzir artefatos como o SIG do produto e
o checklist.
167
A diminuição do tempo gasto foi possibilitada pela automatização da extração
dos elementos do catálogo de RNFs. Os resultados obtidos através do estudo de caso
indicam que a extração automatizada impactou positivamente também no esforço
para realizar a elicitação dos requisitos. Tendo em vista que não foi necessário
efetuar, de forma manual, uma varredura completa no catálogo para extrair os
elementos desejados. Esse fato foi reforçado com base nas opiniões dos participantes
que utilizaram a Omnes Web, registradas nos questionários de pós-execução do
estudo de caso. Dessa forma, o problema da escalabilidade no uso desses artefatos
pôde ser amenizado.
Em relação a produção dos artefatos, o tempo e esforços gastos para criação do
SIG do produto e o checklist também foi perceptível. Tendo em vista que para a
verificação do SIG do produto, basta que o XML gerado pela Omnes Web seja
importado pela StarUML, permitindo assim os ajustes necessários. E no que se refere
ao checklist, a Omnes Web disponibiliza esse artefato de maneira totalmente
automatizada, sem exigir grandes esforços por parte do usuário. Porém, apesar dos
benefícios citados, a estratégia de elicitação aqui apresentada possui algumas
limitações. Inicialmente podemos citar que o método de elicitação e a ferramenta
Omnes Web foram elaborados para atender especificamente ao domínio da
Acessibilidade Web. Ou seja, para trabalhar corretamente com outros RNFs devem
ocorrer estudos que levantem as adaptações necessárias para abranger diferentes
domínios.
Assim sendo, para prosseguir com a pesquisa desenvolvida nesta dissertação,
a primeira sugestão de trabalhos futuros é a adaptação do método proposto e de sua
ferramenta de apoio para a elicitação de qualquer RNF, utilizando a abordagem NFR
Framework. Um possível começo seria a flexibilidade na definição dos parâmetros
que seriam vinculados aos elementos do catálogo. Dessa forma, o engenheiro de
requisitos poderia definir quaisquer parâmetros, obedecendo ao domínio do RNF
definido como meta principal. Assim a estratégia de facilitar a extração das
informações do catálogo estaria encaminhada dentro da nova pesquisa. O próximo
passo seria adaptar a ferramenta para aceitar qualquer catálogo de RNFs, e
consequentemente os parâmetros para extração de suas informações.
168
A utilização da ferramenta de modelagem StarUML foi fundamental para esta
pesquisa, sua funcionalidade de exportar o XML dos catálogos modelados
possibilitou a interação da Omnes Web com a abordagem NFR Framework. Essa
importância é reforçada quando surge a necessidade de editar ou visualizar o SIG do
produto gerado pela nossa estratégia de elicitação, uma vez que a Omnes Web não
contempla essas funcionalidades. Atualmente para realizar esses procedimentos, o
XML do SIG do produto gerado pela Omnes Web deve ser importado pela StarUML.
Assim sendo, compreendemos que promover a visualização e edição do SIG, se torna
uma alternativa a ser considerada para a evolução da estratégia de elicitação
apresentado por esta pesquisa.
Outra limitação foi detectada durante a execução do estudo de caso, onde
alguns participantes da etapa de elicitação reclamaram da quantidade de dados
contida na base de conhecimento, alegando que a análise, mesmo sendo através da
ferramenta, se tornava cansativa. Assim, como trabalho futuro, sugerimos um estudo
para o refinamento dos elementos contidos no catálogo, levando em consideração
sua relevância e os variados contextos das aplicações Web. Visando assim, tentar
diminuir o tamanho dos catálogos de RNFs, ou criar novas estratégias baseadas em
técnicas de visualização para sua exploração.
Além disso, com o estudo de caso constatamos a dificuldade de se avaliar o
impacto de estratégias de elicitação e documentação de requisitos no
desenvolvimento e qualidade do produto final. Para essa questão sugerimos que a
realização de experimentos ou novos estudos de casos, como o conduzido aqui, pode
trazer importantes contribuições na definição e uso de documentos de requisitos.
169
Referências
ABNT. O que é ABTN?. Disponível em:< http://www.abnt.org.br/m2.asp?cod_pagina=963# >. Acesso em 10 de fevereiro de 2014.
Alonso, R. D.; Vazquez, G. A.; Mosqueira, R. E.; Moret, B. V. Usability: A critical
analysis and a taxonomy. International Journal of Human-Computer Interaction, v. 26, n. 1, p. 5374, 2009. Disponível em:<http://www.tandfonline.com/doi/abs/10. 1080/10447310903025552>.
Acesso Brasil. O que é Acessibilidade?. Disponível em:<http://www.acessobrasil.org.br/index.php?itemid=45>. Acesso em 15 de Setembro de 2013.
Baguma, R.; Stone, R. G.; Lubega, J. T.; Weide, T. P.; Van, D. Integrating
Accessibility and Functional Requirements. In Proceedings of the 5th International Conference on Universal Access in Human-Computer Interaction. Part III:
Applications and Services (UAHCI '09), Constantine Stephanidis (Ed.). Springer-Verlag, Berlin, Heidelberg, 635-644. Disponível em :<http://dx.doi.org/10.1007/978-3-642-02713-0_67>.
Boldyreff, C. Determination and Evaluation of Web Accessibility. Proceedings of IEEE 11th Intl. Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2002: p. 36 - 41. Brajnik, G., (2004). Using automatic tools in accessibility and usability assurance
processes. In Proceedings of the Eighth ERCIM Workshop on User Interfaces for All, Vienna, Austria, pages 219–234. Brasil Media. Acessibilidade na Web - Introdução. Disponível em: < http://www.brasilmedia.com/Acessibilidade-na-Web.html#types >. Acesso em 12 de Junho de 2014.
Breffle, W., Morey, E. and Thacher, J. (2011). A joint latent-class model: Combining likert-scale preference statements with choice data to harvest preference heterogeneity, Environmental and Resource Economics pp. 1–28. URL: http://dx.doi.org/10.1007/s10640-011-9463-0
Casteleyn, S., Fiala, Z., Houben, G-J., and van der Sluijs, K. Considering Additional
Adaptation Concerns in the Design of Web Applications. In 4th International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems, Springer 2006.
Cheng, B. H. C.; Atlee, J. M. Research directions in requirements engineering. In: 2007 Future of Software Engineering. Washington, DC, USA: IEEE Computer
170
Society, 2007. (FOSE '07), p. 285303. ISBN 0-7695-2829-5. Disponível em: <http://dx.doi.org/10.1109/FOSE.2007.17>.
Chisholm, W. A.; Henry, S. L. Interdependent components of web accessibility. In: Proceedings of the 2005 International Cross-Disciplinary Workshop on Web Accessibility (W4A). New York, NY, USA: ACM, 2005. (W4A '05), p. 3137. ISBN 1-59593-219-4. Disponível em: <http://doi.acm.org/10.1145/1061811.1061818>.
Chung, L.; Nixon, B.; Yu, E; Mylopoulos, J. Non Functional Requirements in
Software Engineering. Kluwer Academic Publishers, 2000.
Chung, L.; Leite, J. C., 2009. On Non-Functional Requirements in Software
Engineering. In Conceptual Modeling: Foundations and Applications, Alexander T. Borgida, Vinay K. Chaudhri, Paolo Giorgini, and Eric S. Yu (Eds.). Lecture Notes In Computer Science, Vol. 5600. Springer Verlag, Berlin, Heidelberg 363-379. Disponível em:<http://dx.doi.org/10.1007/978-3-642-02463-4_19>
Cysneiros, L. M. Evaluating the effectiveness of using Catalogues to Elicit Non-
Functional Requirements. In: Proc. Workshop em Engenharia de Requisitos, pp 107-115, 2007.
Costa, D., Fernandes, N., Neves, S., Duarte, C., Hijón-Neira, R., & Carriço, L. (2013). Web Accessibility in Africa: A Study of Three African Domains. In Human-Computer Interaction–INTERACT 2013 (pp.331-338). Springer Berlin Heidelberg.
Dias, L. A.; Fortes, M. P. R.; Masiero, P.; Goularte, R. Uma Revisão Sistemática sobre a inserção de Acessibilidade nas fases de desenvolvimento da Engenharia de
Software em sistemas Web. In IHC 2010 – IX Simpósio Sobre Fatores Humanos em Sistemas Computacionais. Outubro 5-8, 2010, Belo Horizonte, MG, Brasil.
Dias, A.; Fortes, R. Pontin de M.; Masiero, P. Increasing the quality of web systems:
By inserting requirements of accessibility and usability. In: Quality of Information and Communications Technology (QUATIC), 2012 Eighth International Conference on the. 2012. p. 224-229.
Fagan, J. C.; Fagan, B. An accessibility study of state legislative web sites. Government Information Quarterly, v. 21, n. 1, p. 65-85, 2004. ISSN 0740-624X. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0740624X03001242>.
Garlan, D. & Shaw, M., An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co. (1993).
171
Governo Eletrônico. eMAG - Modelo de Acessibilidade de Governo Eletrônico.
Disponível em :< http://www.governoeletronico.gov.br/acoes-e-projetos/e-MAG >. Acesso em 01 de Março de 2014.
Hanson, V. L.; Richards, J. T. A web accessibility service: update and findings. SIGACCESS Access. Comput., ACM, New York, NY, USA, n. 77-78, p. 169-176,2003. ISSN 1558-2337. Disponível em: <http://doi.acm.org/10.1145/1029014.1028661>.
Hanson, V. L.; Brezin, J. P.; Crayne, S.; Keates, S.; Kjeldsen, R.; Richards, J. T.; SWART, C.; TREWIN, S. Improving web accessibility through an enhanced open-
source browser. IBM Systems Journal, v. 44, n. 3, p. 573-588, 2005. ISSN 0018 8670.
IEEE. Institute of Electrical and Electronics Engineers. IEEE Recommended practice
for software requirements specifications: IEEE Std 830-1998. New York, 1998.
ISO-IEC For Standardization. Guidelines for Standards Developers to Address the
Needs of Older Persons and Persons with Disabilities. ISO/IEC Guide, International Organization for Standardization (2001). Disponível em <http://books.google.com.br/books?id=Lw7JQgAACAAJ>. Acesso em 1 de Maio de 2013.
ISO-IEC/42010 (IEEE Std) 1471-2000. Systems and Software engineering - Recomended practice for architectural description of softwareintensive systems (2007).
Jaeger, P. T. Assessing section 508 compliance on federal e-government web sites:A multimethod, user-centered evaluation of accessibility for persons with
disabilities.Government Information Quarterly, v. 23, n. 2, p. 169-190, 2006. ISSN 0740-624X. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0740624X06000487>.
Jaeger, P. T. User-centered policy evaluations of section 508 of the rehabilitation act: Evaluating e-government web sites for accessibility for persons with
disabilities. Journal of Disability Policy Studies, v. 19, n. 1, p. 24-33, 2008. Disponível em:<http://dps.sagepub.com/content/19/1/24.abstract>.
Kohana. What is Kohana?. Disponível em < http://kohanaframework.org/3.0/guide/kohana/>. Acesso em 30 de Janeiro de 2014.
Lamsweerde, A. V.; Darimont, K, R; Massonet, P. The Meeting Scheduler System –
Preliminary Definition. Internal Report. Université Catholique de Louvain, 1993.
Lamsweerde, A. van. Goal-oriented requirements engineering: a guided tour. In: Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on. 2001. p. 249-262.
172
Lopes, R.; Gomes, D.; Carriço, L. Web not for all: a large scale study of web
accessibility. In: Proceedings of the 2010 International Cross Disciplinary Conference on Web Accessibility (W4A). New York, NY, USA: ACM, 2010. (W4A '10), ISBN 978-1-4503-0045-2. Disponível em: <http://doi.acm.org/10.1145/1805986.1806001>.
Martín, A.; Cechich, A.; Rossi, G. Accessibility at early stages: insights from the
designer perspective. In: Proceedings of the International Cross Disciplinary Conference on Web Accessibility. New York, NY, USA: ACM, 2011. (W4A '11), ISBN 978-1-4503-0476-4. Disponível em: <http://doi.acm.org/10.1145/1969289.1969302>. Masuwa, M. K. R. Introducing accessonto: Ontology for accessibility requirements
specification. In: Ontologies in Interactive Systems, 2008. ONTORACT'08. First International Workshop. 2008. p. 33-38.
Moreno, L.; Martinez, P.; Ruiz, B. A MDD Approach for Modeling Web
Accessibility. In: 7th Int. Workshop on Web-Oriented Software Technologies. 2008. p. 1-6.
Mylopoulos, J.; Chung, L.; Yu, E. From object-oriented to goal-oriented
requirements analysis. Commun. ACM, ACM, New York, NY, USA, v. 42, n. 1, p.31-37, jan.1999. ISSN 0001-0782. Disponível em: <http://doi.acm.org/10.1145/291469.293165>.
Nuseibeh, B.; Easterbrook, S. Requirements engineering: a roadmap. In:
Proceedings of the Conference on The Future of Software Engineering. New York, NY, USA: ACM, 2000. (ICSE '00), p. 35-46. ISBN 1-58113-253-0. Disponível em:<http://doi.acm.org/10.1145/336512.336523>.
NVDA. What is NVDA?. Disponível em:<http://www.nvaccess.org/>. Acesso em 12 de Fevereiro de 2014.
OpenOme. Tool to support i* modelling and analysis. Disponível < http://sourceforge.net/projects/openome/?source=dlp>. Acesso em 12 de junho de 2013.
Paddison, C.; Englefield, P. Applying heuristics to perform a rigorous accessibility
inspection in a commercial context. SIGCAPH Comput. Phys. Handicap. ACM, New York, NY, USA, n. 73-74, p. 126-133, jun. 2002. ISSN 0163-5727. Disponível em: <http://doi.acm.org/10.1145/960201.957228>.
PHP. O que é PHP?. Disponível em:< http://www.php.net/manual/pt_BR/intro-whatis.php>. Acesso em 20 de agosto de 2013.
Portal Brasil. Acessibilidade. Disponível em:<http://www.brasil.gov.br/menu-de-apoio/sobre-o-site/acessibilidade-1>. Acesso em 01 de agosto de 2013.
173
Potter, A. Accessibility of Alabama government web sites. Journal of Government Information, v. 29, n. 5, p. 303-317, 2002. ISSN 1352-0237. Disponível em:<http://www.sciencedirect.com/science/article/pii/S1352023703000534>.
Power, C.; Petrie, H. Accessibility in non-professional web authoring tools: a
missed web 2.0 opportunity?. In: Proceedings of the 2007 international cross-disciplinary conference on Web accessibility (W4A). New York, NY, USA: ACM, 2007. (W4A '07), p. 116119. ISBN 1-59593-590-8. Disponível em: <http://doi.acm.org/10.1145/1243441.1243468>.
Pressman, R. S. Software Engineering: A Practitioner's Approach. 5th. ed. New York: McGraw-Hill Higher Education, 2001. ISBN 0072496681.
Pressman, R.; Lowe, D. Web engineering: a practitioner's approach. McGraw-Hill Higher Education, 2008. 458 p.
Ross, D. T.; Schoman, K. E. Structured Analysis for Requirements Definition, Software Engineering, IEEE Transactions on, vol.SE-3, no.1, pp.6,15, Jan. 1977.
Section 508. Section 508 Standards Guide. Disponível em: <http://www.section508.gov/index.cfm?fuseAction=stdsdoc>. Acesso em 01 de junho de 2013.
Serrano, M.; Serrano, M. Ubiquitous, pervasive and mobile computing: A reusable-models-based non-functional catalogue. In: Proceedings of Requirements Engineering, Rio de Janeiro, Brazil, 2013 [S.l.]: CEUR-WS.org, 2013. (CEUR Workshop Proceedings, v. 1005). Artigo Disponível em: <http://ceur-ws.org/Vol-1005/erbr2013_submission_7.pdf>. Acesso em 14 de Novembro de 2013.
Sierkowski, B. Achieving web accessibility. In: Proceedings of the 30th annual ACM SIGUCCS conference on User services. New York, NY, USA: ACM, 2002. (SIGUCCS '02), p. 288-291. ISBN 1-58113-564-5. Disponível em:<http://doi.acm.org/10.1145/588646.588725>.
Sommerville, I. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
StarML. The open Source UML/MDA Platform. Disponível em <http://staruml.sourceforge.net/en/>. Acesso em 14 de junho de 2013. Supakkul, S.; Chung, L. The re-tools: A multi-notational requirements modeling toolkit. In: Requirements Engineering Conference (RE), 2012 20th IEEE International . [S.l.: s.n.], 2012. p. 333 334. ISSN 1090-750X
174
TAW. Test for Accessibility Web. Disponível em: <http://www.tawdis.net/>. Acesso em 01 de Novembro de 2013.
Travassos, G. H.; Gurov, D.; Amaral, E. A. G. (2002). Introdução à Engenharia de
Software Experimental. Relatório Técnico. Rio de Janeiro, Brazil.
Vdovjak, R., Frasincar, F., Houben, G.J., Barna, P.: Engineering Semantic Web
Information Systems in Hera. Journal of Web Engineering, Vol. 2, No. 1&2 (2003) 3-26
Wampserver. Installing e Functionalities. Disponível em < http://www.wampserver.com/en/>. Acesso em 23 de Setembro de 2013.
Wave. Web Accessibility evaluation tool. Disponível em: <http://wave.webaim.org/>. Acesso em 26 de Novembro de 2013. WCAG20-TECHS. Techniques for WCAG 2.0. Disponível em: < http://www.w3.org/TR/WCAG20-TECHS/>. Acesso em 05 de Janeiro de 2014. Wegge, K. P.; Zimmermann, D. Accessibility, usability, safety, ergonomics:
concepts, models, and diferences. In: Proceedings of the 4th international conference on Universal access in human computer interaction: coping with diversity . Berlin, Heidelberg: Springer-Verlag, 2007. (UAHCI'07), p. 294-301. ISBN 978-3-540-73278-5.Disponível em: <http://dl.acm.org/citation.cfm?id=1766311.1766345>. World Bank. Disability: Overview. Disponível em:< http://web.worldbank.org/WBSITE/EXTERNAL/TOPICS/EXTSOCIALPROTECTION/EXTDISABILITY/0,,contentMDK:21151218~menuPK:282706~pagePK:210058~piPK:210062~theSitePK:282699,00.html>. Acesso em 10 de junho de 2013.
W3C-MWBP 1.0. Mobile Web Best Practices 1.0. Disponível em <http://www.w3.org/TR/mobile-bp/>. Acesso em 25 de Maio de 2013.
W3C-WAI. How to Meet WCAG 2.0 (WCAG 2.0). Disponível em:<http://www.w3.org/WAI/WCAG20/quickref/#keyboard-operation/>.
Acesso em 03 de junho de 2013.
W3C-WCAG. Web Content Accessibility Guidelines (WCAG) Overview. Disponível em:<http://www.w3.org/WAI/intro/wcag.php/>. Acesso em 01 de junho de 2013.
W3C-WCAG 1.0. Web Content Accessibility Guidelines 1.0. Disponível em: <http://www.w3.org/TR/WCAG10/>. Acesso em 01 de Junho de 2013.
175
W3C-WCAG 2.0. WCAG 2 at a Glance. Disponível em:<http://www.w3.org/WAI/WCAG20/glance/>. Acesso em 02 de Junho de 2013. W3C-WCAG 2.0. Web Content Accessibility Guidelines (WCAG) 2.0. Disponível em:< http://www.w3.org/TR/2008/REC-WCAG20-20081211/ >. Acesso em 03 de Junho de 2013. W3C-WCAG 2.0. Techniques for WCAG 2.0. Disponível em:<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/>. Acesso em 10 de Junho de 2013. Yu, E. Modelling Strategic Relationships for Process Reengineering, PhD Thesis,
Graduate Department of Computer Science, University of Toronto, Toronto, Canada,
1995, Pag. 124.
176
Apêndice A – Questionário para categorização de perfil dos
participantes da etapa de elicitação
Questionário para a categorização do perfil do participante
Avaliação prévia do conhecimento que os participantes possuem em relação aos temas a serem abordados pelo estudo de caso, sendo estes: I Acessibilidade Web, e II Elicitação de requisitos utilizando o NFR Framework ou através de outras abordagens. Nome: ____________________________________________________ Idade: ____ anos Sexo: ( ) Feminino ( ) Masculino
1. De acordo com sua experiência em Acessibilidade Web, classifique de acordo com os critérios acima:
( ) Já trabalhei com Acessibilidade Web;
( ) Costumo trabalhar com a Acessibilidade Web nos meus projetos;
( ) Ao elaborar documentos de requisitos, sempre relaciono os requisitos para a Acessibilidade Web;
( ) Já fiz avaliação de Acessibilidade em sites e aplicações Web;
( ) Costumo fazer avaliação de Acessibilidade em sites e aplicações Web;
( ) Sou capaz de identificar requisitos de Acessibilidade em sites e aplicações Web
( ) Sou capaz de identificar requisitos de Acessibilidade Web em um documento, ainda que ele não esteja explícito e bem definido.
2. De acordo com sua experiência em elicitação de requisitos, utilizando a abordagem NFR Framework ou através de outras abordagens, classifique de acordo com os critérios acima:
( ) Sou capaz de diferenciar requisitos funcionais e não-funcionais
( ) Já fiz elicitação de requisitos;
( ) Costumo fazer elicitação de requisitos;
( ) Sei definir o que é uma abordagem orientada a metas, no que se refere a elicitação de requisitos;
( ) Sei elicitar requisitos através do NFR Framework;
( ) Já fiz alguma elicitação de requisitos através do NFR Framework;
( ) Costumo fazer elicitação de requisitos através do NFR Framework;
( ) Conheço outra (s) abordagem(ns) para elicitação de requisitos;
( ) Já fiz uso de outra (s) abordagem(ns) para elicitação de requisitos.
Caso conheça ou já tenha utilizado outra (s) abordagem (ns) para elicitação de requisitos, cite qual(is):
0 – Discordo Totalmente 1 – Discordo Parcialmente
2 – Nem Concordo Nem Discordo 3 – Concordo Parcialmente 4 – Concordo Totalmente
177
1 – Péssimo 2 – Ruim
3 – Razoável 4 – Bom
5 – Excelente
Apêndice B – Questionário de pós-execução da etapa de
elicitação
Questionário de pós- execução do estudo de caso
Parte 1 - Dados Pessoais
Nome:________________________________________________Idade:____anos Sexo: ( ) Feminino ( ) Masculino
Parte 2 – Configuração do estudo de caso Marque a situação que corresponde a maneira pela qual você executou a atividade de elicitação do estudo de caso
A elicitação foi executada através de:
( ) Ferramenta de apoio a elicitação + Processo de elicitação + Catálogo de requisitos de Acessibilidade Web ( ) Processo de elicitação + Catálogo de requisitos de Acessibilidade Web ( ) Catálogo de requisitos de Acessibilidade Web
Parte 3 – Desempenho Nesta parte do questionário queremos saber sua opinião quanto ao seu desempenho durante a execução da elicitação dos requisitos de Acessibilidade Web
1. De acordo com os critérios acima, como você classifica o desempenho geral da estratégia para a elicitação dos requisitos de Acessibilidade Web apresentada? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
2. De acordo com os critérios acima, como você classifica o aumento do grau de confiabilidade na elicitação dos requisitos de Acessibilidade Web com o uso da estratégia apresentada? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
3. De acordo com os critérios acima, Como você classifica o suporte à atividade de elicitação de requisitos de Acessibilidade Web oferecido pela estratégia apresentada? Justifique.
178
1 – Muito Fácil 2 – Fácil
3 – Razoável 4 – Difícil
5 – Muito Difícil
1 – Muito Fácil 2 – Fácil
3 – Razoável 4 – Difícil
5 – Muito Difícil
( )
____________________________________________________________________________________________________________________________________________________________________________________
4. De acordo com os critérios acima, como você classifica o nível de qualidade da documentação gerada através do uso da estratégia de elicitação apresentada? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
5. De acordo com os critérios acima, como você classifica o tempo despendido com o uso da estratégia de elicitação apresentada? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
6. De acordo com os critérios acima, como você classifica o suporte oferecido pela ferramenta
STARUML junto à aplicação da solução apresentada? Justifique.
( ) ____________________________________________________________________________________________________________________________________________________________________________________
7. De acordo com os critérios abaixo, como você classifica o grau de dificuldade encontrado
no uso da estratégia apresentada para a elicitação dos requisitos de Acessibilidade Web? Justifique.
( ) ____________________________________________________________________________________________________________________________________________________________________________________
8. De acordo com os critérios abaixo, como você classifica cada uma das etapas do processo de elicitação, utilizando a ferramenta de apoio ao processo? Justifique suas respostas.
( ) Atividade 1 – Análise dos requisitos funcionais ( ) Atividade 2 – Seleção dos requisitos de Acessibilidade Web ( ) Atividade 3 – Análise de conflito entre RNFs ( ) Atividade 4 – Geração de artefatos
____________________________________________________________________________________________________________________________________________________________________________________
179
1 – Muito Fácil 2 – Fácil
3 – Razoável 4 – Difícil
5 – Muito Difícil
1 – Muito Fácil 2 – Fácil
3 – Razoável 4 – Difícil
5 – Muito Difícil
9. De acordo com os critérios abaixo, como você classifica cada uma das etapas do processo de elicitação, utilizando somente o processo? Justifique suas respostas.
( ) Atividade 1 – Análise dos requisitos funcionais ( ) Atividade 2 – Seleção dos requisitos de Acessibilidade Web ( ) Atividade 3 – Análise de conflito entre RNFs ( ) Atividade 4 – Geração de artefatos
10. De acordo com os critérios abaixo, como você classifica a elicitação dos requisitos de Acessibilidade Web, utilizando somente o catálogo de requisitos de acessibilidade Web? Justifique suas respostas.
( ) Seleção dos requisitos de Acessibilidade Web; ( ) Análise de conflitos entre os RNFs ( ) Geração de artefatos
11. Caso necessite, no futuro, fazer a elicitação de requisitos de Acessibilidade Web, utilizaria a estratégia apresentada? Justifique.
( ) Sim ( ) Não ____________________________________________________________________________________________________________________________________________________________________________________
12. Você identificou alguma diferença em termos de desempenho ou de dificuldade na elicitação de requisitos através da estratégia apresentada, em relação a outras abordagens que você já utilizou? Justifique.
( ) Sim ( ) Não ____________________________________________________________________________________________________________________________________________________________________________________
Parte 4 – Aprendizado Nesta parte do questionário queremos saber sua opinião quanto ao aprendizado sobre os conceitos básicos, e sobre a solução apresentada para a elicitação dos requisitos de Acessibilidade Web
13. De acordo com os critérios acima (utilizados nas questões 8, 9 e 10), como você classifica a apresentação inicial sobre a estratégia apresentada e os principais conceitos por ela adotados? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
14. De acordo com os critérios acima (utilizados nas questões 8, 9 e 10), como você classifica o grau de dificuldade encontrado no aprendizado da estratégia apresentada em geral? Justifique.
( )
180
____________________________________________________________________________________________________________________________________________________________________________________
15. De acordo com os critérios acima (utilizados nas questões 8, 9 e 10), como você classifica o grau de dificuldade encontrado no aprendizado e no uso da ferramenta StarUML? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
Parte 5 – Sugestões, Críticas e Comentários
Caso tenha alguma sugestão, crítica, comentário ou elogio adicional em relação à estratégia apresentada para a elicitação dos requisitos de Acessibilidade Web, sinta-se a vontade para fazê-lo.
_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Natal, ___ de Janeiro de 2014
Assinatura do participante da pesquisa
181
Apêndice C – Resumo do documento de requisitos do
aplicativo para criação de galeria de fotos interativa
Aplicativo para a criação de galeria de fotos interativa
Escopo do aplicativo:
O aplicativo para a criação de galeria de fotos será disponibilizado na plataforma web, permitindo assim que o usuário possa acessá-lo de qualquer lugar. O objetivo do aplicativo é facilitar a criação de galerias de fotos Web. Assim o sistema provê facilidades para criar, organizar e configurar galerias e gerando automaticamente as páginas Web referentes à galeria criada. A apresentação da galeria deve ser organizada de tal forma que o usuário possa interagir com as fotos
seja para ampliá-las ou para ouvir o som associado a elas.
O aplicativo não terá banco de dados, as galerias criadas pelos usuários deverão ser armazenadas temporariamente na seção de navegação. O usuário poderá salvar as galerias em
formato de webpages, e importá-las posteriormente caso deseje fazer alterações.
Lista de requisitos funcionais:
RF1 - O sistema deve permitir a criação de galerias de fotos (criação, alteração, exclusão)
RF2 - O sistema deve permitir a visualização da galeria durante a sua criação;
RF3 - O sistema deve permitir a criação de temas para vincular a fotos ou galerias (inclusão, alteração, exclusão);
RF4 - O sistema deve permitir inserir e excluir fotos;
RF5 - O sistema deve permitir ampliar fotos para melhor visualização;
RF6 - O sistema deve permitir a operação de rotular fotos para fins de identificação ou descrição;
RF7 - O sistema deve permitir organizar fotos por data, por tema, e alfabeticamente por rótulo;
RF8 - O sistema deve permitir ouvir os rótulos das fotos, temas e galerias;
RF9 - O sistema deve permitir inserir e excluir sons;
RF10 - O sistema deve permitir associar sons a fotos, temas e galerias;
RF11 - O sistema deve permitir o controle sobre a execução de sons (Iniciar, pausar, voltar, adiantar e mudar de faixa);
RF12 - O sistema deve permitir a geração da web page de cada galeria de foto criada;
RF13 - O sistema deve permitir o download da webpage de cada galeria criada;
RF14 - O sistema deve permitir a importação de webpage das galerias de fotos;
RF15 - O sistema deve permitir a edição na galeria de fotos importada a partir de sua web page;
RF16 - O sistema deve permitir configurações nas galerias para os seguintes pontos: o Quantidade fotos: aceitando 1, 4, 9 ou 12 fotos; o Background: alteração de cores do plano de fundo; o Estilo das fotos: colorido, envelhecido, preto e branco o Estilo da galeria: clássico, horizontal, visualização simples, Visualização automática,
visualização com efeitos de inclinação; o Cor e fonte dos rótulos: para galerias, temas e fotos
RF17- O sistema deve permitir configuração nos temas para os seguintes pontos: o Quantidade fotos: aceitando 1, 4, 9 ou 12 fotos; o Background: alteração de cores do plano de fundo; o Estilo das fotos: colorido, envelhecido, preto e branco o Estilo da galeria: clássico, horizontal, visualização simples, Visualização automática,
visualização com efeitos de inclinação;
182
o Cor e fonte dos rótulos: para galerias, temas e fotos
RF18 - O sistema deve permitir configurações nas fotos para os seguintes pontos: o Background: alteração de cores do plano de fundo; o Estilo das fotos: colorido, envelhecido, preto e branco; o Cor e fonte dos rótulos
RF19 - O sistema deve permitir a publicação das galerias de fotos em redes sociais (Facebook, Twitter, Instagram);
RF20 - O sistema deve definir configurações padrões para a galeria, tema e foto que devem ser carregadas sempre que o usuário for criar uma nova galeria.
Lista de requisitos não funcionais
RNF1 - Acessibilidade;
RNF2 - Usabilidade: o RNF2.1 - Fácil memorização das funcionalidades; o RNF2.2 - Fácil utilização; o RNF2.3 - Retorno ao usuário; o RNF2.4 - Suporte as iniciativas do usuário o RNF2.5 - Apresentação separada do conteúdo
RNF3 – Portabilidade: o Cross Browser; o Compatibilidade com dispositivos móveis
RNF4 – Interoperabilidade
183
Apêndice D – Resumo do documento de requisitos do
aplicativo para gestão de metas
Aplicativos para gestão de metas – Metas
Escopo do aplicativo:
O aplicativo Metas será disponibilizado na plataforma web, permitindo assim que os usuários
acessem o programa de qualquer lugar.
O aplicativo Metas tem o propósito de auxiliar na definição e controle de ações importantes
para alcançar determinados objetivos. Além de facilitar a criação de metas, esse aplicativo estimula a
execução de ações, através de alertas (lembretes), não deixando o usuário esquecer as
responsabilidades definidas pelo mesmo.
Os dados dos usuários deverão ser armazenados em um banco de dados, as metas podem ser
compartilhadas em redes sociais (Facebook, Twitter, Google+) caso o usuário deseje.
Lista de requisitos funcionais
RF1 - O sistema deve permitir o cadastro de usuários para efetuar login no sistema;
RF2 - O sistema deve permitir além do login tradicional, utilizando os dados armazenados no banco, a opção de um login alternativo através das credenciais de redes sociais (Facebook, Twitter, Google+);
RF3 - O sistema deve permitir o cadastro de tipos de metas (inclusão, exclusão, alteração e consulta);
RF4 - O sistema deve permitir o cadastro de metas (inclusão, exclusão, alteração e consulta);
RF5 - O sistema deve permitir associar metas com tipos de metas;
RF6 - O sistema deve permitir configurações nas metas durante sua criação para os seguintes pontos:
o Quantidade de ações da meta: o usuário pode ou não limitar a quantidade de ações da meta;
o Definição sobre valores financeiros: o usuário irá informar se a meta necessita de valores financeiros para atingir a meta
RF7 - O sistema deve permitir o cadastro de ações para atingir as metas;
RF8 - O sistema deve permitir associar ações a metas;
RF9 - O sistema deve fornecer alertas para lembrar a execução das ações de cada meta;
RF10 - O sistema deve permitir ativar o alerta de cada meta;
RF11 - O sistema deve permitir configurações do alerta em cada meta para os seguintes pontos:
o Definir se o alerta será ou não sonoro; o Definir dias da semana que o alerta irá funcionar; o Definir frequência do alerta; o Definir a hora de inicio do alerta o Permitir a replicação das definições sobre a hora de inicio e frequência do alerta para
os demais dias ativos
RF12 - O sistema deve informar quantos alertas foram definidos para cada meta;
RF13 - O sistema deve permitir inserir ou excluir sons;
RF14 - O sistema deve permitir associar sons a metas e alertas;
RF15 - O sistema deve permitir cadastrar mensagens (inclusão, exclusão, alteração e consulta);
184
RF16 - O sistema deve permitir associar mensagens a metas e alertas;
RF17- O sistema deve permitir ativar cada meta criada;
RF18- O sistema deve permitir que o usuário informe a execução de cada ação para atualizar a situação da meta;
RF19 - O sistema deve informar a situação e evolução da meta (utilizando gráficos)
RF20 - O sistema deve organizar as metas por tipo, data, situação, e pelo nome da meta em ordem alfabética;
RF21 - O sistema deve permitir ao usuário publicar suas metas em redes sociais (Facebook e
Twitter).
Lista de requisitos não funcionais
RNF1 - Acessibilidade;
RNF2 - Usabilidade: o RNF2.1 - Fácil memorização das funcionalidades; o RNF2.2 - Fácil utilização; o RNF2.3 - Retorno ao usuário; o RNF2.4 - Suporte as iniciativas do usuário o RNF2.5 - Apresentação separada do conteúdo
RNF3 – Portabilidade: o RNF3.1 - Cross Browser; o RNF3.2 - Compatibilidade com dispositivos móveis
RNF4 – Segurança o RNF4.1 – Criptografia de senha o Validação de requisições para publicação em redes sociais
RNF5 – Interoperabilidade
185
Apêndice E – Checklist para controle de implementação dos
requisitos Acessibilidade Web
Checklist gerado manualmente
Nome do Projeto
Desenvolvedor:_______________________________________________________ Data: ..../.../.... Hora inicio:..... : ..... Hora fim: ...... : .....
Só marque implementado se você implementou o requisito funcional junto aos
requisitos de acessibilidade
A) Lista de requisitos funcionais
B) Implementação dos requisitos
Outros RNFs
Acessibilidade Web
Requisito Operacionalização Implementado?
C) Controle da implementação
Informe na Tabela abaixo quais requisitos e respectivas operacionalizações que
foram implementadas por você, além dos disponíveis nesse checklist.
Requisito Operacionalização Motivo
ID Requisito Implementado?
Requisito Operacionalização Implementado?
186
Informe na Tabela abaixo quais requisitos e respectivas operacionalizações presentes
nesse checklist que não foram implementadas por você.
Requisito Operacionalização Motivo
OBSERVAÇÕES:
......................................................................................................................................................
......................................................................................................................................................
Exemplo de um checklist gerado pela Omnes Web
Figura 41 - Exemplo de um checklist gerado pela Omnes Web
187
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
A seguir serão apresentadas as respostas da 3º parte do questionário de pós-execução da
etapa de elicitação, envolvendo as questões de 7 a 10, que se referem ao nível de dificuldade
encontrado pelos participantes em relação as tarefas executadas durante a etapa de elicitação. Essas
questões foram respondidas considerando os seguintes critérios: Muito Fácil, Fácil, Razoável, Difícil e
Muito difícil.
A Tabela 41 apresenta as respostas dos participantes para o questionamento 7 dos
questionários de pós- execução da etapa de elicitaçã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
Pergunta Configuração Muito Fácil Fácil Razoável Difícil Muito difícil
7 - Como você classifica o grau de dificuldade encontrado no uso da estratégia apresentada para a elicitação dos requisitos de Acessibilidade Web?
Situação 1: Ferramenta + processo + catálogo
1 3
Situação 2: Processo + Catálogo
- - 1 1 -
Situação 3: Catálogo
- - - 1 1
Conforme as respostas apresentadas na Tabela 41, dos 4 participantes da situação 1, apenas
um participante classificou como Muito Fácil a utilização da estratégia de elicitação fornecida,
enquanto que os outros 3 participantes classificaram a utilização como “Fácil”. A justificativa
fornecida informava que o nível de informações da ferramenta Omnes Web estava satisfatório. Em
relação aos dois participantes da situação 2, que utilizaram somente o processo sem a ferramenta
Omnes Web, o uso da estratégia de elicitação foi classificada como Razoável e Difícil. Um desses
participantes alegou falta de experiência, enquanto o outro informou que a ferramenta de modelagem
StarUML apresentou variadas limitações, sem citar quais.
Ainda em relação a Tabela 41, os dois participantes vinculados a situação 3, que utilizaram
somente o catálogo de requisitos de Acessibilidade Web, classificaram como Difícil e Muito Difícil o
uso da estratégia de elicitação utilizada. Vale ressaltar que esses participantes realizaram a elicitação
de maneira Ad-hoc, se baseando nos princípios de elicitação da abordagem NFR Framework.
O questionamento 8 foi respondido apenas pelos participantes da situação 1, que utilizaram o
processo proposto junto a sua ferramenta de apoio Omnes Web e o catálogo de RNFs. Essa pergunta
se refere a dificuldade encontrada por cada participante em relação a cada uma das 4 atividades do
188
processo proposto utilizando a ferramenta Omnes Web. A Tabela 42 apresenta as respostas dos
participantes da situação 1 para o questionamento 8.
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
Pergunta Atividade Muito Fácil Fácil Razoável Difícil Muito difícil
8 - Como você classifica o nível de dificuldade de cada uma das etapas do processo de elicitação, utilizando a ferramenta de apoio ao processo?
1 – Análise dos requisitos funcionais
3 1
2 – Seleção dos requisitos de Acessibilidade Web
3 - 1 - -
3 – Análise de conflito entre RNFs
- 3 - 1 -
4 – Geração de artefatos
2 2 - - -
De acordo com as respostas apresentadas na Tabela 42, fornecidas pelos participantes da
situação 1, a primeira atividade referente a Análise dos requisitos funcionais foi classificada como
“Muito fácil” por 3 participantes e “Fácil” por um participante. Em relação a segunda atividade que é
a Seleção dos requisitos de Acessibilidade Web, 3 participantes a classificaram como Muito Fácil,
enquanto um participante classificou como Razoável, sem fornecer justificativas. A execução da
terceira atividade de Análise de conflito entre os RNFs foi classificada como “Fácil” por 3
participantes, enquanto que apenas um classificou essa atividade como “Difícil”, justificando que
analisar o impacto entre os RNFs foi complicado devido a quantidade de requisitos de Acessibilidade
Web. E por fim, em relação a execução da quarta atividade para geração de artefatos, 2 participantes
classificaram sua execução como Muito Fácil, e os outros 2 participantes a classificaram como “Fácil”.
As justificativas dos participantes para a oitava questão apontaram a interface intuitiva da ferramenta
Omnes Web como um fator de uso facilitador.
A pergunta 9 do questionário foi respondida apenas pelos participantes da situação 2, que
utilizaram o processo proposto junto ao catálogo de requisitos de Acessibilidade Web sem a
ferramenta de apoio Omnes Web. Essa pergunta se refere a dificuldade encontrada por cada
participante em relação a cada uma das 4 atividades do processo proposto executado de forma
manual. A Tabela 43 apresenta as respostas dos participantes para o questionamento 9.
189
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
Pergunta Atividade Muito Fácil Fácil Razoável Difícil Muito difícil
9 - como você classifica o nível de dificuldade de cada uma das etapas do processo de elicitação?
1 – Análise dos requisitos funcionais
1 1
2 – Seleção dos requisitos de Acessibilidade Web
- 1 1
- -
3 – Análise de conflito entre RNFs
- - 2 - -
4 – Geração de artefatos
- - 2 - -
Conforme a Tabela 43, dos dois participantes vinculados a situação 2, um participante
classificou a primeira etapa do processo como “Muito Fácil”, já o segundo participante classificou essa
etapa como “Fácil”, justificando que a identificação do tipo de conteúdo para os requisitos funcionais
não se mostrou complicada. A execução da segunda etapa de Seleção dos requisitos de Acessibilidade
Web foi considerada “Fácil” por um participante e razoável pelo segundo participante. As execuções
da terceira e quarta etapa tiveram seus níveis de dificuldade classificados como Razoável. Um dos
participantes justificou as respostas fornecidas para o questionamento 9 afirmando que essas etapas
necessitavam de mais conhecimento, e que seu baixo nível de experiência dificultou a execução.
O questionamento 10 foi respondido apenas pelos participantes da situação 3, que utilizaram
somente o catálogo e realizaram a elicitação de maneira ad-hoc, se baseando nos princípios de
elicitação da abordagem NFR Framewok. De acordo com o treinamento passado aos participantes da
situação 3, antes do inicio do estudo de caso, três atividades foram cobradas, sendo estas: Elicitação
dos requisitos de Acessibilidade Web, Análise de conflitos entre os RNFs, Geração de artefatos.
Tabela 44 mostra as respostas fornecidas pelos participantes para a pergunta 10.
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
Pergunta Atividade Muito Fácil Fácil Razoável Difícil Muito difícil 10 - Como você classifica o nível de dificuldade da elicitação dos requisitos de Acessibilidade Web?
Elicitação dos requisitos de Acessibilidade Web
- - 1 1 -
Análise de conflitos entre os RNFs
- - - 2 -
Geração de artefatos
- - 1 1 -
190
De acordo com as respostas fornecidas pelos participantes da situação 3, apresentadas na
Tabela 44, é possível constatar que o nível de dificuldade mostrado pelos participantes em relação a
execução das atividades de elicitação utilizando somente o catálogo de RNFs não foi satisfatório. Para
a atividade de Elicitação dos requisitos de Acessibilidade Web, um participante classificou a
dificuldade para a execução desta atividade como “Razoável”, enquanto que o outro participante
classificou como a execução como “Difícil”. Em relação a análise de conflito entre os RNFs, os dois
participantes consideraram a execução como “Difícil”. Por fim, em relação a geração de artefatos, um
dos participantes classificou a execução como “Difícil”, enquanto que o segundo participante
classificou como Muito Difícil. A justificativa fornecida se refere ao tempo necessário para executar de
forma manual a geração dos artefatos solicitados.
O questionamento 11 investigou se os participantes tornariam a utilizar a estratégia de
elicitação fornecida para elicitar os requisitos de Acessibilidade Web. A Tabela 45 apresenta as
respostas dos participantes para o questionamento 11 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
Pergunta Configuração Sim Não
11 - Caso necessite, no futuro, fazer a elicitação de requisitos de Acessibilidade Web, utilizaria a solução apresentada?
Situação 1: Ferramenta + processo + catálogo
4
Situação 2: Processo + Catálogo
2
Situação 3: Catálogo - 2
Conforme as respostas apresentadas na Tabela 45, todos os participantes da situação 1 da
etapa de elicitação voltariam a utilizar a estratégia de elicitação fornecida. Ainda em relação aos
participantes da situação 1, as justificativas apontaram que a ferramenta Omnes Web tornou o
processo de elicitação mais ágil e viável em relação a sua execução. Em relação aos participantes da
situação 2, a opinião em relação a estratégia de elicitação fornecida apresentou-se dividida, um
participante afirmou que tornaria a utilizar o processo proposto, enquanto que o segundo participante
afirmou que não utilizaria devido as limitações de uso apresentados pela ferramenta de modelagem
StarUML. E por fim, os participantes da situação 3 da etapa de elicitação informaram que não
utilizaria novamente a elicitação dos requisitos de Acessibilidade Web, utilizando somente o catálogo,
afirmando que a existência de uma abordagem sistemática e uma ferramenta de apoio poderia tornar
mais viável a execução da elicitação.
O último questionamento referente a terceira parte do questionário de pós-execução do
estudo de caso investigou se os participantes utilizaram outras abordagens de elicitação de requisitos
e se detectaram alguma diferença de desempenho e dificuldade em relação as estratégias de elicitação
fornecidas. A Tabela 46 apresenta as respostas dos participantes para o questionamento 12.
191
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
Pergunta Configuração Sim Não
12 - Você identificou alguma diferença em termos de desempenho ou de dificuldade na elicitação de requisitos através da solução apresentada, em relação a outras abordagens que você já utilizou?
Situação 1: Ferramenta + processo + catálogo
2 2
Situação 2: Processo + Catálogo
1 1
Situação 3: Catálogo - 2
Como apresentado na Tabela 46, dos 4 participantes da situação 1 da etapa de elicitação, 2
detectaram diferenças entre a estratégia de elicitação utilizada em relação a outras já utilizadas,
justificando que a ferramenta de apoio fornece um suporte diferenciado a elicitação de requisitos não
funcionais, nesse caso Acessibilidade Web. Ainda em relação aos participantes da situação 1, os outros
dois participantes informaram não terem utilizado outras abordagens, portanto não tinham como
identificar diferenças de desempenho ou dificuldade de execução da elicitação. Em relação aos
participantes da situação 2, apenas um participante detectou diferenças com outra abordagem
utilizada, porém não justificou quais, já o segundo participante não havia utilizado nenhuma outra
abordagem. E por fim, os 2 participantes da situação 3 afirmaram não terem utilizado outra estratégia
de elicitação.
192
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
A seguir serão abordados os 3 questionamentos referentes a parte 4 do questionário de pós
experimento. A parte 4 coletou as opiniões dos participantes quanto ao aprendizado sobre os
conceitos básicos, e sobre a estratégia apresentada para a elicitação dos requisitos de Acessibilidade
Web, com base no treinamento passado. As questões da parte 4 foram respondidas considerando os
seguintes critérios: Muito Fácil, Fácil, Razoável, Difícil e Muito difícil. A Tabela 47 apresenta as
respostas dos participantes para os questionamentos 13, 14 e 15 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
Pergunta Muito Fácil Fácil Razoável Difícil Muito difícil 13 - Como você classifica a apresentação inicial sobre a estratégia
apresentada e os principais conceitos por ela adotados?
4 1 3 - -
14 - Como você classifica o grau de dificuldade encontrado no
aprendizado da estratégia apresentada em geral?
4 2 - 2 -
15 - Como você classifica o grau de
dificuldade encontrado no aprendizado e no uso da ferramenta
StarUML?
1 5 2 - -
Conforme as respostas apresentadas na Tabela 47, em relação a pergunta 13 referente a
apresentação inicial sobre a estratégia apresentada e os principais conceitos por ela adotados, dos 8
participantes 4 classificaram a apresentação como “Muito Fácil”e um participante classificou como
Fácil, as justificando que o treinamento foi simples de compreender. Ainda em relação a pergunta 13,
3 participantes classificaram a apresentação inicial como razoável de compreender, as justificativas se
relacionaram com o tempo utilizado para o treinamento, e também a falta de experiência sobres os
temas abordados. Em relação a pergunta 14, dos 8 participantes, 4 Classificaram como Muito Fácil e 2
classificaram como Fácil o aprendizado da estratégia apresentada em geral, as justificativas
apontaram que mesmo durante a utilização o aprendizado ocorreu de maneira satisfatória. Apenas
dois participantes consideraram o aprendizado da estratégia “Difícil” de maneira geral, justificando
falta de conhecimento sobre os temas abordados.
Ainda de acordo com a Tabela 47, em relação a questão 15, entre os 8 participantes, um
participante considerou a utilização da ferramenta StarUML como “Muito fácil”, e 5 consideraram
“Fácil”. Enquanto 2 participantes classificaram como Razoável a utilização da StarUML. As
justificativas fornecidas relatam que a ferramenta deveria ser mais automatizada.
193
Apêndice H – Questionário para categorização do perfil dos
participantes da etapa de prototipação
Questionário para categorização de perfil do participante
Este questionário tem por objetivo caracterizar sua experiência em desenvolvimento de sistemas Web
e Acessibilidade Web. Por favor, responda todas as questões o mais fielmente possível. Toda
informação é confidencial, sendo que seu nome e quaisquer outros meios de identificação não serão
divulgados em nenhuma hipótese.
Nome:_______________________________________________________Idade: ____anos
Sexo: ( ) Feminino ( ) Masculino
1. Quais as linguagens de programação que você já utilizou para o desenvolvimento de
aplicativos Web?
( ) Java ( ) Java Script ( ) PHP ( ) C#.Net ( ) Python ( ) Visual Basic .NET ( ) Asp.Net ( ) Outra (s) :_________________________________________
2. Há quanto tempo você desenvolve aplicativos Web?
( ) Menos de 1 ano ( ) Menos de 2 anos ( )Acima de 2 anos ( ) 1 Ano ( ) 2 anos
3. Quais padrões de projeto você costuma utilizar?
___________________________________________________________________________________
Critérios:
4. De acordo com sua experiência em Acessibilidade Web, classifique de acordo com os critérios acima:
( ) Sei definir o que é Acessibilidade Web;
( ) Já trabalhei com Acessibilidade Web;
( ) Costumo trabalhar com a Acessibilidade Web nos meus projetos;
( ) Já fiz avaliação de Acessibilidade em sites e aplicações Web;
( ) Costumo fazer avaliação de Acessibilidade em sites e aplicações Web;
( ) Sou capaz de identificar falhas de Acessibilidade em sites e aplicações Web sem utilizar ferramentas de avaliação automática
( ) Conheço as normas e diretrizes para a Acessibilidade Web fornecidas pela W3C;
0 – Discordo Totalmente 1 – Discordo Parcialmente
2 – Nem Concordo Nem Discordo 3 – Concordo Parcialmente 4 – Concordo Totalmente
194
( ) Já trabalhei com as normas e diretrizes para a Acessibilidade Web fornecidas pela W3C;
( ) Costumo implementar a Acessibilidade Web em meus projetos com base nas normas da W3C;
Caso conheça ou já tenha utilizado outra (s) fonte (s) contendo normas e diretrizes para a Acessibilidade Web, cite-as abaixo:
___________________________________________________________________________________________________________________________________________________________________________________
Natal, ___ de Janeiro de 2014.
Assinatura do participante da pesquisa
195
Apêndice I – Questionário para categorização do perfil dos
participantes da etapa de Análise da Acessibilidade
Questionário para categorização de perfil do participante
O objetivo deste questionário é registrar algumas de suas características, assim como sua experiência
no uso de tecnologias relacionadas a Web. Todas as informações contidas nesse documento são
confidenciais, dessa forma, nenhuma identificação sua será divulgada.
Nome:____________________________________________________ Idade:____anos
Sexo: ( ) Feminino ( ) Masculino
1. Qual a sua limitação física?
__________________________________________________________________________________________
2. Sua limitação física teve origem no seu nascimento? Caso não, informe há quanto tempo
você possui essa limitação?
__________________________________________________________________________________________
3. Há quanto tempo você navega na Web?
( ) Há menos de 1 ano ( ) Há menos de 2 anos ( ) Acima de dois anos ( ) Há 1 ano ( ) Há 2 anos 4. Quais as ferramentas de suporte você costuma utilizar durante a navegação na Web?
__________________________________________________________________________________________
__________________________________________________________________________________________
5. Quais desses dispositivos você já utilizou?
( ) Tablets ( ) Smartphones ( ) Notebooks ( ) Desktops ( ) Outro(s):
6. Marque as atividades que você costuma realizar na Web.
( ) Compras ( ) Jogar ( ) Pesquisar /estudar ( ) Ouvir músicas
( ) Uso de redes sociais ( ) Outra(s):
7. De acordo com sua limitação , você considera o nível atual de Acessibilidade Web
satisfatório? Justifique.
( ) Sim ( ) Não ( ) Em parte
8. Cite os principais problemas de Acessibilidade Web encontrados por você atualmente.
__________________________________________________________________________________________
__________________________________________________________________________________________
Natal, ___ de Fevereiro de 2014.
Assinatura do participante da pesquisa
196
1 – Péssimo 2 – Ruim
3 – Razoável 4 – Bom
5 – Excelente
Apêndice J – Questionário de pós-execução dos participantes
da etapa de Prototipação
Questionário de pós- execução do estudo de caso do participante
Parte 1 - Dados Pessoais
Nome: ______________________________________________ Idade: ____ anos
Sexo: ( ) Feminino ( ) Masculino
Parte 2 – Utilização dos artefatos produzidos Nesta parte do questionário, queremos saber sua opinião quanto ao seu desempenho durante a utilização dos artefatos produzidos pela etapa de elicitação.
1. De acordo com os critérios acima, como você classifica a clareza e consistência na especificação de requisitos, com base na documentação recebida? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
2. De acordo com os critérios acima, como você classifica a objetividade na especificação dos requisitos, com base na documentação recebida? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
3. De acordo com os critérios acima, como você classifica o suporte à implementação dos requisitos de Acessibilidade Web oferecido pela documentação? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
4. De acordo com os critérios acima, como você classifica o tempo despendido para a compreensão da documentação recebida? Justifique.
( )
197
1 – Muito Fácil 2 – Fácil
3 – Razoável 4 – Difícil
5 – Muito Difícil
____________________________________________________________________________________________________________________________________________________________________________________
5. De acordo com os critérios acima, como você classifica a viabilidade de implementação dos requisitos, com base na documentação? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
6. De acordo com os critérios abaixo, como você classifica o grau de dificuldade na utilização de cada um dos artefatos da documentação recebida? Justifique suas respostas.
( ) Catálogo de requisitos de acessibilidade Web baseado no NFR Framework ( ) Catálogo de correlações entre os requisitos não-funcionais baseado no NFR Framework ( ) Checklist para controle de implementação dos requisitos de Acessibilidade Web
____________________________________________________________________________________________________________________________________________________________________________________
7. Você identificou algum problema na documentação, em relação a identificação dos requisitos? Cite quais.
( ) Sim ( ) Não ( ) Em parte ____________________________________________________________________________________________________________________________________________________________________________________
Parte 3 – Implementação Nesta parte do questionário queremos saber sua opinião quanto a implementação dos requisitos de Acessibilidade Web
8. De acordo com os critérios acima (utilizados na questão 6), como você classifica o grau de dificuldade para implementação dos requisitos de Acessibilidade Web? Justifique.
( )
_________________________________________________________________________________________________________________________________________________________________________________________________________________________________
9. De acordo com os critérios acima (utilizados na questão 6), como você classifica o grau de dificuldade para testar a acessibilidade web implementada? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________
198
Parte 4 – Sugestões, Críticas e Comentários
Caso tenha alguma sugestão, crítica, comentário ou elogio adicional em relação a documentação dos requisitos de Acessibilidade Web produzida, sinta-se a vontade para fazê-lo. ___________________________________________________________________________________________________________________________________________________________________________________
Natal, ___ de Fevereiro de 2014
Assinatura do participante da pesquisa
199
Apêndice L – Roteiro de tarefas do projeto 1
Roteiro de tarefas a serem executadas
Este documento contém as tarefas a serem executadas na etapa de Análise da Acessibilidade
Web, referente ao projeto 1 do estudo de caso da pesquisa intitulada Um processo semi-automatizado
para a elicitação de requisitos de Acessibilidade Web.
Projeto 1: Aplicativo para a criação de galeria de fotos interativa
Tarefa 1 – Identificar o conteúdo da página inicial: O participante deve identificar o conteúdo da
página inicial, indicando se houve clareza nas informações.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 2 – Criar uma galeria de fotos: O participante deve criar uma galeria de fotos com utilizando o
sobrenome.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 3 – Acessar a galeria criada: O participante deve ser capaz de acessar a galeria durante a
criação, verificando informações, como nome, descrição, tema e as fotos contidas.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 4 – Fazer uploads de fotos: O participante deve efetuar o upload de uma foto para a galeria
criada na tarefa 4.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 5 – Acessar a foto inserida: O participante deve ser capaz de acessar cada foto inserida na
galeria, e identificar as informações fornecidas sobre seu rótulo e a galeria a que pertence.
Numero de tentativas Ajuda? Conclusão
200
Obs.:______________________________________________________________________________________
Tarefa 6 – Rotular fotos: O participante deve fornecer rótulos às fotos inseridas.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 7 – Editar o rótulo da foto inserida: O participante deve efetuar a edição do rótulo da foto
inserida.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 8 – Excluir a foto inserida: O participante deve efetuar a exclusão da foto inserida.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
201
Apêndice M – Roteiro de tarefas do projeto 2
Roteiro de tarefas a serem executadas
Este documento contém as tarefas a serem executadas na etapa de Análise da Acessibilidade Web,
referente ao projeto 2 do estudo de caso da pesquisa intitulada Um processo semi-automatizado para
a elicitação de requisitos de Acessibilidade Web.
Projeto 2: Aplicativo para gestão de metas
Tarefa 1 – Identificar conteúdo não textual: O participante deve identificar as duas imagens
presentes na página inicial do aplicativo e descrevê-las.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 2 – Identificar os tipos de login presentes na aplicação e escolher um deles: O participante
deve identificar os dois tipos de login que a aplicação possui: I - Através do facebook, e II - Através de
credenciais previamente cadastradas na aplicação. Se a escolha de login for através da primeira opção,
o participante deve pular para a tarefa 4. Porém, se a escolha for à segunda opção, o usuário deve
executar a terceira tarefa.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 3 – Efetuar cadastro no sistema: O participante deve efetuar o cadastro para acessar a
aplicação, informando nome, login de usuário e senha.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 4 – Acessar o menu de ajuda da aplicação: após acessar a aplicação, o participante deve
avaliar se as informações do menu de ajuda estão claras.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
202
Tarefa 5 – Retornar a tela inicial: Após acessar o menu de ajuda, o participante deve retornar à
página inicial.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 6 - Cadastrar uma categoria de meta: O participante deve cadastrar uma nova categoria para
as metas.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 7 – Cadastrar uma meta e vincular a uma categoria: O participante deve cadastrar uma meta e
vincular a categoria criada na tarefa 6.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 8 – Cadastrar uma ação para a meta criada: O participante deve cadastrar uma ação para a
meta criada na tarefa 7.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 9 - Agendamento da ação: O participante deve configurar o agendamento para ser lembrado
sobre a execução da ação cadastrada.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
Tarefa 10 – Retornar a tela inicial e aguardar o alerta surgir: o participante deve retornar a tela inicial
e aguardar o alerta referente ao agendamento da ação.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
203
Tarefa 11 – Confirmar a execução da ação: Quando surgir o alerta agendado para lembrar a execução
da ação, o participante deve confirmar a execução para que a meta seja cumprida. O participante deve
identificar qual a mensagem que aparece quando uma meta é cumprida.
Numero de tentativas Ajuda? Conclusão
Obs.:______________________________________________________________________________________
204
1 – Péssimo 2 – Ruim
3 – Razoável 4 – Bom
5 – Excelente
Apêndice N – Questionário de avaliação da Acessibilidade Web
dos aplicativos
Questionário de pós- execução do estudo de caso do participante
Parte 1 - Dados Pessoais
Nome: ______________________________________________ Idade: ____ anos
Sexo: ( ) Feminino ( ) Masculino
Parte 2 – Aplicativo avaliado Marque o aplicativo para o qual você executou a análise da Acessibilidade Web
( ) Aplicativo para gestão de metas – Metas ( ) Aplicativo para a criação de galeria de fotos interativa
Parte 3 – Análise da Acessibilidade Web Nesta parte do questionário queremos saber sua opinião quanto ao seu desempenho e a
Acessibilidade encontrada no aplicativo analisado
1. De acordo com os critérios acima, como você classifica o tempo despendido para a execução das tarefas solicitas no aplicativo? Justifique.
( ) ____________________________________________________________________________________________________________________________________________________________________________________
2. De acordo com os critérios acima, como você classifica o suporte oferecido pela aplicação na execução das tarefas solicitas? Justifique.
( ) ____________________________________________________________________________________________________________________________________________________________________________________ 3. Realizar as tarefas solicitadas na aplicação foi estressante? Justifique.
( )
____________________________________________________________________________________________________________________________________________________________________________________ __________________________________________________________________________________________ __________________________________________________________________________________________
4. Realizar as tarefas solicitadas na aplicação foi cansativo? Justifique.
205
1 – Muito Fácil 2 – Fácil
3 – Razoável 4 – Difícil
5 – Muito Difícil
( ) ____________________________________________________________________________________________________________________________________________________________________________________ __________________________________________________________________________________________ __________________________________________________________________________________________
5. De acordo com os critérios acima, como você classifica de maneira geral o grau de acessibilidade encontrado durante a análise do aplicativo? Justifique.
( ) ____________________________________________________________________________________________________________________________________________________________________________________ __________________________________________________________________________________________ 6. De acordo com os critérios abaixo, como você classifica o nível de dificuldade para a execução das tarefas solicitadas no aplicativo?.
( ) __________________________________________________________________________________________ ____________________________________________________________________________________________________________________________________________________________________________________ __________________________________________________________________________________________
Parte 4 – Sugestões, Críticas e Comentários
Caso tenha alguma observação a fazer sobre o nível de Acessibilidade Web encontrado durante a análise do aplicativo, sinta-se a vontade para fazê-la.
Natal, ___ de Fevereiro de 2014
Assinatura do participante da pesquisa