A an´alise dos dados contou com a participa¸c˜ao de dois pesquisadores mestrandos em Ciˆencia da Computa¸c˜ao e mais dois professores doutores, todos pesquisadores da ´area de IHC e ES.
Figura 3.2: US descrita por um participante
A Figura 3.2 apresenta um exemplo de uma US elaborada por um participante e as justifi- cativas de uso das t´ecnicas escolhidas por ele. Ao todo foram geradas 94 US e seus respectivos AC.
Todas as US e seus respectivos AC foram analisadas pelos dois pesquisadores mestrandos de forma redundante. Primeiro, cada pesquisador mestrando analisou as US e AC para verifi- car a corretude da escrita e descobrir a vis˜ao dos desenvolvedores quanto as t´ecnicas/m´etodos utilizados. Numa segunda etapa, os pesquisadores discutiram suas descobertas para avaliar os resultados coletados. Uma terceira etapa de consolida¸c˜ao foi realizada com os dois professores doutores, que refinaram os resultados encontrados.
Antes de explorar os dados, os pesquisadores fizeram uma pr´e an´alise da qualidade da escrita das US utilizando o framework proposto por Lucassen et al. (LUCASSEN et al., 2015). Esse framework avalia a qualidade da escrita das US a partir de trˆes dimens˜oes: Sint´atica, Semˆantica e Pragm´atica. Dentro dessas dimens˜oes existem crit´erios. Os crit´erios foram descritos com nome
em inglˆes para evitar que haja uma perda de sentido com a tradu¸c˜ao. As dimens˜oes e crit´erios do framework s˜ao explicadas abaixo:
A) Sint´atica: dimens˜ao relativa `a estrutura do texto da US sem considerar seu significado; 1. Atomic: uma US deve referir-se apenas a uma funcionalidade, exatamente um requisito; 2. Minimal: uma US deve conter apenas sua fun¸c˜ao, significado e, opcionalmente, uma fina-
liza¸c˜ao. Informa¸c˜oes adicionais e coment´arios devem ser capturados em notas adicionais; 3. Well-formed: para ser considerada uma US, o principal requisito deve ser definido como
sua fun¸c˜ao e o que ´e esperado daquela funcionalidade, ou seja, o seu significado. Desse modo, para ser considerada uma US, ela deve conter pelo menos uma principal fun¸c˜ao e seu significado.
B) Semˆantica: dimens˜ao relativa `as rela¸c˜oes e significados do texto das US;
1. Conceptually sound: Um requisito expressa uma fun¸c˜ao e uma finalidade expressa uma raz˜ao;
2. Conflict-free: para evitar erros de implementa¸c˜ao e retrabalho, uma US n˜ao deve ser inconsistente com nenhuma outra US no banco de dados para n˜ao haver conflitos;
3. Problem-oriented: uma US deve especificar somente o problema, n˜ao a solu¸c˜ao; 4. Unambiguous: uma US deve evitar termos que podem ter diferentes interpreta¸c˜oes. C) Pragm´atica: dimens˜ao relativa `a efic´acia de comunicar os requisitos dentro das US;
1. Complete: implementar um conjunto de US deve criar uma aplica¸c˜ao por completo, ne- nhuma funcionalidade deve estar faltando;
2. Explicit Dependencies: se houver dependˆencias entre as US, essas precisam estar juntas e explic´ıtas;
3. Full Sentence: uma US deve ser uma senten¸ca bem formulada, sem erros gramaticais ou erros de digita¸c˜ao;
4. Independent: uma US deve ser independente, evitando dependˆencias com outras US. As US n˜ao devem se sobrepor e devem ser implement´aveis em qualquer ordem;
5. Scalable: uma US deve exigir o mesmo esfor¸co de implementa¸c˜ao de outras US para a estimativa de implementa¸c˜ao ser a mesma entre elas;
6. Uniform: as US devem seguir todas o mesmo template;
Para a an´alise realizada neste estudo, n˜ao foram consideradas os crit´erios “Conflict-free” e “Complete”, pois estavam fora do escopo. O crit´erio “Conflict-free” refere-se a preven¸c˜ao de erros de implementa¸c˜ao e retrabalho, as US n˜ao devem entrar em conflito com nenhuma das outras US no banco de dados. Esse crit´erio n˜ao foi utilizada visto que a aplica¸c˜ao utilizada neste estudo teve um escopo pequeno, n˜ao havendo a necessidade de um crit´erio para uma an´alise de conflito no banco de dados com outras US. O escopo utilizado foi simples, porque n˜ao era o foco deste estudo. O crit´erio “Complete” refere-se a implementa¸c˜ao de um conjunto de US que deve levar a uma aplica¸c˜ao completa. Como o foco do estudo foi o uso dos artefatos de IHC para apoiar a escrita das US, a an´alise n˜ao se concentrou em recursos da aplica¸c˜ao. E como o escopo das aplica¸c˜oes eram simples, n˜ao houveram dificuldades para descri¸c˜ao da aplica¸c˜ao ser completa. Desse modo, n˜ao foi utilizado esse crit´erio na an´alise presente.
Para condu¸c˜ao da an´alise usou-se uma categoriza¸c˜ao classificando as US, quanto: “Total- mente Atendido” (TA), “Parcialmente Atendido” (PA) e “N˜ao Atendido” (NA). Uma US foi classificada como PA quando atendia um crit´erio, por´em n˜ao de forma completa. Como exem- plo, a US: “Como um <estudante>, eu quero <ter a possibilidades de conversar com outros estudantes que estudaram o mesmo conte´udo> para que []” com o AC: “Teste de verificar as pontua¸c˜oes anteriores nos jogos”. Essa US/AC obteve como PA no crit´erio “Conceptually Sound”, pois o objetivo dele ´e se comunicar com outros estudantes, por´em n˜ao ´e transmitido como fazer isso e n˜ao h´a mais informa¸c˜oes. Apesar disso, um desenvolvedor consegue entender e implementar essa US, por isso ela n˜ao ´e considerada NA.
Na Figura 3.3 ´e apresentado o resultado da an´alise a partir dos crit´erios do framework. No gr´afico, a quantidade de US ´e representada pelos n´umeros ao meio e os resultados pelas trˆes cores (NA - azul, PA - vermelho, TA - laranja).
De uma maneira geral, as US obtiveram mais resultados atendendo totalmente os crit´erios apresentados. A dimens˜ao Pragm´atica apresentou um n´umero maior de PA e NA comparando as outras dimens˜oes, por´em esse n´umero n˜ao ultrapassou os TA. Ou seja, as US apresentaram problemas de comunica¸c˜ao dos requisitos quanto os crit´erios“Scalable” e“Full Sentence”. Por´em, esses problemas foram m´ınimos e n˜ao prejudicaram o entendimento das US.