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