De acordo com Sommerville (2007), a análise de requisitos apresenta as descrições dos serviços fornecidos pelo sistema, bem como suas restrições operacionais. Pfleeger (2004) explica que se trata de características ou descrições do que o sistema é capaz de realizar para alcançar seus objetivos. Já Robertson e Robertson (2006) interpretam como 'coisas' que o produto tem que fazer ou qualidade que precisa apresentar. Em resumo, os requisitos incluem especificações das funcionalidades que o sistema provê, restrições sob as quais opera e propriedades do sistema.
Ainda segundo Sommerville (2007), os requisitos podem ser classificados com base no tipo de informação documentada, distinguindo-se entre requisitos funcionais e requisitos não funcionais. Os requisitos funcionais são considerados declarações de serviços que o sistema deve prover, descrevendo as funções que realizará. Já os requisitos não funcionais referem-se às restrições dos serviços que serão oferecidos e que limitam as opções para criar
uma solução para o problema. Dessa forma, a fim de delimitar as principais funcionalidades que a arquitetura deve prover, bem como algumas restrições, são apresentados os requisitos funcionais e não funcionais representativos.
A princípio, são previstos como requisitos funcionais da arquitetura GOA: gerenciar perfil de usuário, gerenciar SGs/AVs, gerenciar atividades, gerenciar alunos e utilizar sequências. A seguir, eles são apresentados juntamente com os casos de uso que representam sua unidade funcional.
<RF001>Gerenciar perfil de usuário
Esse requisito descreve o serviço de cadastro do usuário. Assim, um usuário pode preencher um cadastro e selecionar o perfil apropriado (desenvolvedor, mediador, aluno) para registrar-se. Após o cadastro, o usuário pode alterar dados cadastrais ou excluir seu cadastro. As modificações realizadas exigem que o sistema altere informações contidas em seu banco de dados, de acordo com o perfil.
A figura 12 apresenta a notação gráfica do caso de uso <UC01>. Ela mostra o cenário de possível atuação entre usuário e sistema para gerenciamento do perfil do usuário.
Figura 12 - Caso de uso <UC01>
<RF002>Gerenciar jogos/ambientes
Após realizar seu registro, um usuário com o perfil de desenvolvedor pode preencher um cadastro de SG ou AV, selecionando o meio de associação do recurso ao sistema. O novo SG/AV é submetido ao administrador que avalia sua inclusão no sistema. O desenvolvedor também pode visualizar os SGs/AVs, alterar dados cadastrais ou excluir SGs/AVs cadastrados por ele.
A figura 13 apresenta a notação gráfica do caso de uso <UC02>. Ela mostra o cenário de possível atuação entre desenvolvedor, administrador e sistema para gerenciamento dos serious games e ambientes virtuais.
Figura 13 - Caso de uso <UC02>
A fim de auxiliar o cadastro de novos SGs e AVs, será disponibilizada ao desenvolvedor uma cartilha para inclusão de recursos. Essa cartilha deverá conter explicações e advertências para inserção dos aplicativos, como a necessidade de informar quais objetivos educacionais serão considerados na avaliação interna do SG ou AV, de acordo com a taxonomia dos objetivos educacionais. Além disso, será fornecido um formulário padrão de dados necessários, incluindo espaço adequado para inclusão do jogo.
<RF003>Gerenciar atividades
Esse requisito descreve o serviço de gerência de atividades que pode ser realizado pelo mediador. Essa gerência inclui a pesquisa de SGs/AVs cadastrados, visualização de detalhes sobre os SGs/AVs de interesse, criação de sequências de atividades, relação entre sequência de atividades e alunos mediados, bem como possibilidade de exclusão ou alteração de sequências de atividades criadas pelo próprio mediador.
A figura 14 apresenta a notação gráfica do caso de uso <UC03>. Ela mostra o cenário de possível atuação entre mediador e sistema para gerenciamento de atividades.
Figura 14 - Caso de uso <UC03>
<RF004>Gerenciar alunos
Esse requisito descreve o serviço de gerência de alunos que é realizado pelo mediador. Essa gerência possibilita que um usuário com perfil de mediador possa listar, buscar, selecionar, visualizar detalhes e convidar alunos para participar de sua orientação. Além disso ele poderá avaliar convites de alunos que desejam ser orientados por ele, bem como criar, alterar e remover turmas.
A figura 15 apresenta a notação gráfica do caso de uso <UC04>. Ela mostra o cenário de possível atuação entre mediador e sistema para gerenciamento de alunos.
Figura 15 - Caso de uso <UC04>
<RF005>Utilizar Sequências
Esse requisito descreve o serviço que permitirá a um usuário com perfil de aluno, listar as sequências de atividades que foram elaboradas para seu treinamento. Ao visualizar uma sequência de atividades, o aluno possui acesso a detalhes de seu desempenho e poderá optar por continuar a sequência (caso não esteja concluída). O aluno também é capaz de realizar busca por jogos que estão fora da sequência e jogá-los. Além disso, ele pode solicitar que um mediador oriente suas atividades.
A figura 16 apresenta a notação gráfica do caso de uso <UC05>. Ela mostra o cenário de possível atuação entre aluno e sistema para utilização de sequências.
Figura 16 - Caso de uso <UC05>
A arquitetura GOA também prevê alguns requisitos não funcionais referentes à usabilidade, desempenho, expansibilidade e segurança. Esses requisitos são apresentados no quadro 9.
Quadro 9 - Requisitos não funcionais previstos
Requisito não funcional Descrição
<RNF001> Usabilidade
O sistema deve apresentar uma interface amigável, intuitiva e de fácil utilização, garantindo uma boa comunicação entre utilizador e sistema. As ações devem ser transparentes, de modo que o utilizador compreenda todos os seus efeitos.
<RNF002> Desempenho O sistema deve apresentar um tempo de resposta às ações do usuário reduzido dentro da plataforma.
<RNF004> Segurança O sistema deve prover a integridade dos dados e liberação de acesso aos usuários cadastrados.
Fonte: Elaborado pela autora.