Documento de Requisitos Agentes Micromundo e Análise do De...

Documento de Requisitos

Agentes Micromundo e Análise do Desenvolvimento no Uso de

Instrumentos MultiMídia (AMADeUs-MM) Cliente: CNPq - Conselho Nacional de Desenvolvimento Científico e Tecnológico

Versão 00.01 21/03/2006

Responsável: Almir Moura

Agentes Micromundo e Análise do Desenvolvimento no Uso de Instrumentos MultiMídia – AMADeUs-MM Pág 2/34


O projeto Agentes M icromundo e Análise do Desenvolvimento no Uso de Instrumentos

MultiM ídia (AMADeUs-MM) é resultado de uma parceria entre a Jynx playware, a

Facape e a UFPE/CIn e conta com o apoio do Conselho Nacional de Desenvolvimento

Científico e Tecnológico – CNPq.


Histórico de Alterações


Data Versão Descrição Último

RF

Último

RNF

Autor

21/03/06 01.00-D1 Elaboração do documento. Almir

Moura

23/03/06 01.00-D2 Inserção de requisitos. Almir

Moura

24/03/06 01.00-D3 Alteração após a revisão

com Fernando Trinta.

Almir

Moura

27/03/06 01.00-D4 Inserção da visão geral do

sistema.

Almir

Moura

28/03/06 01.00-D5 Inserção de termos,

abreviações e convenções.

Almir

Moura

29/03/06 01.00-D6 Inserção de termos,

abreviações e convenções.

Almir

Moura

30/03/06 01.00-D7 Inserção de RNF Almir

Moura

30/03/06 01.00-D8 Revisão do documento Fernando

Trinta

31/03/06 01.00-D9 Revisão do documento.

Modificação Introdução.

Inserção dos Atores

Fernando

Trinta

31/03/06 01.00-D10 Inserção de novos RNF.

Alteração após a revisão de

Fernando Trinta.

Modificação seção 2.2.6

RF24 RNF31 Almir

Moura


03/04/06 01.00-D11 Modificação na seção de

Atores. Inclusão de

referencias.

RF25 NF31 Fernando

Trinta e

Almir

Moura


Lista de Aprovadores

Nome Cargo

Leonardo Medeiros Gerente de projetos – AMADeUs-MM

Fernando Trinta Arquiteto de software – AMADeUs-MM

Fernando Fonseca Coordenador – AMADeUs-MM

Alex Sandro Gomes Colaborador – AMADeUs-MM


1. Introdução

Este documento especifica os requisitos necessários para o desenvolvimento do Agentes

M icromundo e Análise do Desenvolvimento no Uso de Instrumentos MultiM ídia,

abreviadamente AMADeUs-MM a ser desenvolvido com o apoio do CNPq, através de

um consórcio que envolve a Jynx playware, o CIn/UFPE e a Facape. Cada organização

envolvida tem objetivos complementares e bem definidos, desempenhando um papel

importante para o alcance do objetivo final do projeto.

Este documento visa estabelecer um entendimento comum entre os envolvidos no

projeto a respeito das funcionalidades a serem contempladas no ambiente, porém sem

determinar como as mesmas serão implementadas.

1.1 Visão Geral Deste Documento

Esta introdução fornece as informações necessárias para fazer um bom uso deste

documento, explicitando seus objetivos e as convenções que foram adotadas no texto.

As demais seções apresentam a especificação do sistema e estão organizadas como

descrito abaixo.

• Seção 2 – Visão geral do sistema: descreve o que vem a ser o ambiente

AMADeUs-MM, além de apresentar as suas principais características e

objetivos.

• Seção 3 – Requisitos funcionais: lista os requisitos funcionais do sistema,

especificando seus objetivos e prioridades.

• Seção 4 – Requisitos não funcionais: especifica todos os requisitos não

funcionais do sistema, divididos em requisitos de usabilidade, confiabilidade,

desempenho, segurança, distribuição, adequação a padrões e requisitos de

hardware e software.

• Seção 5 – Escopo negativo: especifica as funcionalidades que estão

relacionadas com o sistema, mas que não fazem parte do escopo do projeto e,

portanto, não serão implementadas.


• Seção 6 – Referências: contém uma lista de referências para outros documentos

relacionados.

1.2 Convenções, Termos e Abreviações

Esta seção explica o conceito de alguns termos importantes que serão mencionados no

decorrer deste documento. Estes termos são descritos na tabela a seguir, estando

apresentados por ordem alfabética.

Termo Descrição

API Interface Programática da Aplicação

Atividade Atividades a serem realizadas nos cursos disponibilizadas no

AMADEUS. Exemplo: fórum, SCORM, chat, enquête,

homework.

AVE Ambiente Virtual de Ensino.

CIn-UFPE Centro de Informática da Universidade Federal de Pernambuco.

CNPq Conselho Nacional de Desenvolvimento Científico e

Tecnológico.

CSCL Computer Supported Colaborative Learning.

Facape Faculdade de Ciências Aplicadas e Sociais de Petrolina.

LMS Learning Management System.

Homework Trabalho entregue pelos alunos.

Material Arquivos disponibilizados pelos professores e/ou monitores nos

módulos de um curso.

Micro-mundos São aplicações síncronas do tipo desktop que permitem que

aplicações educativas sejam usadas por pequenos grupos de

usuários - limite de quatro pessoas - para resolverem problemas

de forma colaborativa, expandindo a interação que os usuários

têm com o conteúdo.


Middleware Camada de software situada entre o sistema operacional e a

aplicação, que provê uma abstração comum de programação para

sistemas distribuídos. Também pode ser visto como um conjunto

de serviços, protocolos e utilidades que fazem com que seja

possível o desenvolvimento de sistemas distribuídos modernos.

RF - Requisitos

funcionais

Requisitos técnicos do software que compõem o sistema,

descrevendo ações que o sistema deve estar apto a executar.

RNF - Requisitos não

funcionais

Requisitos técnicos do software que compõem o sistema,

descrevendo atributos que o sistema deve possuir ou restrições

sob as quais ele deve operar.

SCORM Sharable Content Object Reference Model Initiative - criado para

unificar a linguagem de padrões e certificações em e-learning.

SGBD Sistema de Gerenciamento de Banco de Dados.

Tabela 1 – Termos e convenções

1.2.1 Prioridades dos requisitos

Para estabelecer a prioridade dos requisitos foram adotadas as denominações:

“essencial”, “importante” e “desejável”. A prioridade dos requisitos é utilizada no

gerenciamento do escopo das etapas do projeto e na definição das prioridades durante o

desenvolvimento do sistema.

• Essencial: requisito sem o qual o sistema não entra em funcionamento.

Requisitos essenciais são requisitos imprescindíveis, devem ser implementados

desde as primeiras versões do sistema.

• Importante: requisito sem o qual o sistema entra em funcionamento, mas de

forma não satisfatória. Requisitos importantes devem ser implementados o mais

rápido possível; se não o forem, parte do sistema poderá ser implantada mesmo

assim.


• Desejável: requisito que não compromete as funcionalidades básicas do sistema,

isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos

desejáveis são requisitos que podem ser implantados por último, sem

comprometer o funcionamento do sistema.


2. Visão geral do sistema

2.1 Descrição do ambiente

O AMADeUs-MM é um ambiente virtual de aprendizagem baseado na integração de

mídias digitais diversas que visam aproveitar as propriedades destas do ponto de vista

da aprendizagem.

O AMADeUs-MM prevê a disponibilização de cursos a um conjunto de usuários, que

podem assumir diferentes papéis dentro do ambiente, tais como aluno, professor,

monitor, dentre outros. (Vide Seção 3). Cursos são oferecidos por professores aos

alunos, sendo disponibilizados através de materiais confeccionados para divulgação da

ementa do curso. Materiais seriam arquivos disponibilizados pelos professores e/ou

monitores nos módulos de um curso, como por exemplo: documentos em diversos

formatos (PDF, WORD), apresentações (Macromedia Flash, Microsoft Power Point,

SCORM, Áudio e vídeo), dentre outros. Cursos são ainda marcados por interações entre

os envolvidos, além da realização de avaliações dos alunos através de testes. As formas

de interação entre os usuários do AMADeUs-MM ocorre através da interface web da

aplicação, de seus componentes chat, mural, fórum e email, e ainda através de extensões

da interface web (CD ROM, micromundos, aplicações desktop de uma forma geral que

podem ser usadas como ferramentas colaborativas síncronas).

Como boa parte dos atuais ambientes de ensino, AMADeUs-MM utiliza a plataforma

WEB como base infra-estrutural. Entretanto, o AMADeUs-MM não se restringe apenas

às possibilidades de interação comuns a estes tipos de ambiente (chat, mural, fórum e

email). Como um diferencial, o projeto propõe a possibilidade de estender a interface

web da mesma com aplicações desktop. Essas aplicações podem ser tão variadas como

CD ROM ou programas colaborativos síncronos que utilizam os serviços de

comunicação do AMADeUs_MM. Essas integram-se ao AMADeUs-MM mediante

utilização de um conjunto de funcionalidades presentes em uma API; disponibilizada


através de um middleware para desenvolvedores dessas aplicações. Essas aplicações

podem ser jogos educativos, leitores de áudio e vídeo, simuladores, e outros tipos de

aplicações. Como exemplos de micromundos temos as aplicações de CSCL – Física e o

Gérard. Os materiais criados pelos usuários da aplicação serão compartilhados em uma

base de dados que gerencie este conteúdo multimídia. Dada a envergadura dos objetivos

e as dificuldades técnicas a serem suplantadas, este projeto tem uma duração prevista de

dois anos.

2.2 Características

2.2.1 Gestão de Conteúdos (Learning Management System)

Esse módulo visa permitir a gestão de componentes de aprendizagem (módulos de

conteúdos) e sua integração com as funcionalidades de avaliação, permitindo assim, o

acompanhamento dos alunos, dentro de uma perspectiva formativa e construtivista. O

gerenciamento de conteúdos favorecerá: (i) a edição de um formato padrão (por

exemplo, SCORM, definido pela ADL Inc.) de apresentação dos conteúdos de um curso

(existem ferramentas de autoria para criação dos mesmos), (ii) a reutilização dos

módulos em vários ambientes e plataformas, e, (iii) a flexibilização no manuseio.

2.2.2 Servidor de jogos multi-usuários

Os jogos serão desenvolvidos em dois módulos: o servidor e o cliente. O servidor cuida

das conexões, das regras dos jogos e da comunicação entre alunos e professores. O

cliente, desenvolvido em linguagem que possa ser utilizada com o navegador, é o

responsável pela interface entre os usuários e o servidor. Inicialmente, está previsto o

desenvolvimento de seis jogos, todos inéditos, cada um cobrindo um assunto diferente

da Matemática. Todos contarão com uma interface rica em gráficos.

2.2.3 Componentes síncronos de aprendizagem

Muitos dos problemas da utilização de recursos de educação a distância vêm da

desmotivação dos alunos no uso do ambiente, causada pela falta de integração com

instrutores/monitores, o que leva ao sentimento de estarem abandonados à própria sorte.


A vantagem de se trabalhar com aplicações síncronas é a possibilidade de a interação

com os instrutores ocorrer de forma síncrona, utilizando-se para tal, formas de interação

via texto, diagramas interativos e mesmo vídeo (webcam).

2.2.4 Arquitetura de software de ambientes micromundo de interação síncrona

Na proposta original do projeto AMADeUs foi proposta a construção de agentes

micromundo. A sua construção e sua integração com o ambientes AMADeUs depende

da definição de uma arquitetura de software que permita o acoplamento com aplicações

educativas diversas, sendo ativadas a partir do ambiente virtual de ensino. O

desenvolvimento desse módulo inicia-se com a análise de competidores, pesquisa

bibliográfica sobre requisitos de CSCL, e metodologia de cenários.

2.2.5 Transparência social aplicada em Ambiente Virtual de Ensino

Transparência social, ou percepção social, é a possibilidade de representar aspectos da

interação social na interface do usuário. Estes aspectos cobrem a possibilidade de os

usuários perceberem a atividade social em cinco dimensões: social, espaço de trabalho,

conceito, objeto e tarefa.

• A percepção social é a representação de aspectos dos comportamentos e

atividades passadas, presentes e futuras da turma e do grupo de usuários.

• A percepção de espaço de trabalho deve favorecer aos usuários a visualização da

distribuição de recursos (funcionalidades) do espaço distribuído de trabalho.

• A percepção de conceito são técnicas de representar e manipular o conteúdo

utilizado no ensino.

• A percepção de objeto facilita a visualização e manipulação dos mesmos

relevantes à realização das atividades (materiais, lembretes, avisos, mensagens

internas).

• A percepção de tarefa favorece a visualização de ações realizadas, em realização

e a serem realizados pelos usuários do grupo.


2.2.6 Módulo de avaliação de ambiente virtual de ensino

Os modelos e perspectivas de avaliação implementados em AVE atuais reproduzem

propostas somativas e formativas de avaliação.

A primeira diz respeito a uma avaliação de medida quantitativa realizada ao final do

curso. Esta é uma forma de produzir retorno sobre o desempenho dos participantes ao

final do curso. Por tal razão, seus resultados não influenciam o andamento do curso

atual, podendo melhorar o planejamento e a forma de intervenção nos cursos futuros.

No segundo caso, a avaliação é feita a qualquer momento do curso, permitindo a

adaptação do mesmo - forma de intervenção e de retorno para os alunos - durante o

curso. Essa modalidade de avaliação tem o caráter de contribuir com a formação dos

alunos.

Esse módulo gerará especificação e o suporte à atividade de avaliação do ambiente

AMADeUs-MM. A avaliação dos alunos será realizada através de provas, trabalhos e

nível de participação nas atividades (chat, fórum, SCORM); poderá ser feita tanto pelo

professor como pelos alunos monitores dos cursos1.

2.2.7 Desenvolver formas e integrar CDROM, rádio e TV com o AVE

Com a participação da AESO, com seus laboratórios de fotografia, rádio e televisão,

serão desenvolvidas formas de disponibilizar aulas ministradas por meio do AVE,

ampliando o sentido de módulo e incorporando alternativas à realização de encontros

presenciais. Os conteúdos serão organizados dentro do ambientes e utilizados de forma

complementar, com emissão direta para refinamento de modelos de ensino a distância

com integração de mídias, resgatando as vantagens e resolvendo as limitações de cada

uma das mídias por meio de complementaridades de aplicação.

2.2.8 Ambientes de suporte a atividade docente

Visa à identificação de requisitos para os módulos básicos de suporte à atividade

docente. Os requisitos foram identificados por meio de dois tipos principais de técnicas:

análise de competidores e análise qualitativa de entrevistas com usuários atuando como

1 Cavalcanti, J., Dissertação de mestrado UFPE, 2006;


docentes em ambientes virtuais de ensino. Os resultados desse trabalho geraram

módulos de coordenação e gestão dos cursos do ambientes. Serão tratados problemas

relacionados com planejamento, gestão dos materiais, acompanhamento e a integração

com o módulo de avaliação.

2.3 Objetivos do projeto

O presente projeto tem por objetivo geral implementar um ambiente virtual de

aprendizagem baseado na integração de mídias digitais diversas que visam aproveitar as

propriedades destas do ponto de vista da aprendizagem.

Os objetivos específicos são:

(1) Resolver problemas de isolamento e motivação observados regularmente nas

análises de desempenho e participação de alunos em educação a distância;

(2) Integrar diversas mídias (áudio, vídeo, CDROM e jogos multi-usuários) a um

ambiente virtual de ensino de modo a permitir uma expansão da experiência dos

usuários de ensino a distância quanto ao uso de um numero maior de canais de

comunicação e interação.

(3) Implementar um servidor de jogos e uma metodologia2 de desenvolvimento de

aplicações educativas para áreas específicas do ensino fundamental para uso

integrado com o ambiente AMADeUs-MM.

(4) Definir um modelo de middleware customizável para ambientes colaborativos de

ensino que viabilize a interação de diferentes modalidades (assíncrona e

síncrona) através de diferentes mídias. A customização neste caso refere-se à

forma de composição dos serviços fornecidos pelo middleware visando atender

os requisitos não-funcionais:

• Definir um conjunto básico de serviços necessários às aplicações distribuídas

que possam ser combinados em serviços mais avançados;

2 Braga, M. M., Dissertação de mestrado, CIn/UFPE, 2006.


• Implementar o modelo proposto e analisar o uso de arquitetura de software

dinâmica distribuídas que podem ser implementadas em middleware

customizado para área de educação a distância.

(5) Criar uma camada de persistência para uso do amadeus independente de um

SGBD específico, permitindo:

� Inclusão de novos tipos de dados e novos dispositivos de armazenamento e

edição;

� Flexibilidade no armazenamento, transferência e edição das informações

multimídia;

� Modelo de dados adequado;

� A realização de tarefas complexas de manipulação cooperativa de diferentes

mídias;

� A modelagem de objetos complexos.


3. Atores

Um usuário do ambiente AMADEUS-MM possui diferentes perfis e papéis, de acordo

com as funcionalidades disponíveis a este usuário. Os perfis possíveis são visitante,

usuário ou administrador. Estes perfis designam as permissões sobre funcionalidades

dentro do sistema. Em relação aos papéis são identificados três possibilidades: Aluno,

Monitor e Professor. A tabela abaixo explana sobre as características destes perfis e

papéis no ambiente AMADEUS-MM.

Ator Descrição

Visitante Perfil que representa um usuário do sistema, porém sem cadastro no

ambiente ou não logado no ambiente. Suas ações são limitadas à busca

de conteúdo público.

Usuário Representa qualquer usuário do sistema, com cadastro no ambiente.

Aluno Usuário com cadastro no sistema e apto para ingressar em cursos

oferecidos. Esse é o perfil padrão após o primeiro cadastramento. É o

papel de todo usuário que se cadastre no sistema. A partir deste papel, o

aluno pode solicitar a inclusão de outros papéis a seu usuário, como

Professor ou Monitor de um curso.

Professor Usuário do ambiente, apto a criar cursos, bem como nomear monitores

para os mesmos.

Monitor Usuário do ambiente, que pode realizar certas operações em nome do

professor da disciplina do qual responde pela monitoria.

Administrador Usuário do ambiente com direitos de realização de qualquer ação, como

exclusão de usuários, nomeação de professores, dentre outras. Equivale

a idéia de um administrador (usuário root) em sistema convencional de

suporte.


4. Requisitos Funcionais

[RF001] Fazer Logon

O ambiente disponibiliza uma operação que autentica um usuário e verifica as

funcionalidades do ambiente que estão disponíveis ao mesmo de acordo com a política

de autenticação e autorização.

Prioridade: � Essencial � Importante � Desejável

[RF002] Fazer Logoff

O ambiente disponibiliza uma funcionalidade de encerrar a sessão do usuário com o

ambiente.


[RF003] Buscar curso

O ambiente deve permitir que usuários e visitantes possam buscar cursos de acordo com

critérios como: nome do curso, nome do professor e keywords.


[RF004] Editar dados pessoais

O ambiente deve permitir que usuários cadastrados possam modificar seus dados

pessoais.



[RF005] Alterar dados cadastrais de um usuário

O ambiente deve disponibilizar um mecanismo para que os administradores possam

modificar os dados de um usuário cadastrado.


[RF006] Desativar conta de usuário


desativar a conta de usuários existentes.


[RF008] Visualizar dados gerais do curso

O ambiente deve permitir que qualquer usuário possa visualizar dados gerais do curso

tais como nome do curso, nome do professor, nome do monitor, objetivos do curso e

cronograma.


[RF009] Enviar mensagem

O ambiente deve permitir que usuários e visitantes possam enviar mensagens para

usuários do sistema.


[RF010] Solicitar docência

O ambiente deve permitir que um usuário possa solicitar docência sujeita a aprovação

pelo administrador (tornar-se um professor).



[RF011] Lembrar senha

O ambiente deve disponibilizar um mecanismo que possibilite a um usuário lembrar sua

senha.


[RF012] Atribuir papel de professor


atribuir o papel de professor a um usuário cadastrado.


[RF013] Desativar papel de professor

Ao administrador deve ser disponibilizada uma função para desativar o papel de

professor de um usuário. Neste caso, os dados referentes ao docente devem ser salvos

para posteriormente o papel de professor ser reativado.


[RF014] Remover papel de professor

Deve ser disponibilizado ao administrador um modo de remover o papel de professor de

um usuário. As informações relativas ao papel “professor” para este usuário não serão

salvas.



[RF015] Desativar conta de usuário

O ambiente deve disponibilizar um mecanismo que permita aos administradores

desativar a conta de um usuário. Os dados relativos a este usuário serão salvos.


[RF016] Atribuir papel de monitor

O ambiente deve disponibilizar um mecanismo para que os professores possam atribuir

o papel de monitor a um aluno.


[RF017] Criar curso

O ambiente deve permitir que o professor ou administrador possam criar um curso.


[RF018] Inserir atividade

O ambiente deve permitir que o professor possa inserir uma atividade no curso que ele

tenha criado.


[RF019] Inserir material

O ambiente deve permitir que o professor ou monitor possam inserir um material a um

curso que ele tenha criado.



[RF020] Visualizar dados completos de um aluno

O ambiente deve permitir que administradores (de todos os cursos), professores e

monitores (ambos apenas nos cursos dos quais atuam) possam visualizar todos os dados

dos alunos. Esses dados também podem ser visualizados pelo próprio aluno.


[RF021] Matricular-se em curso

O ambiente deve permitir que um usuário cadastrado no sistema possa se matricular em

um curso.


[RF022] Visualizar dados públicos de outro aluno

O ambiente deve permitir a visualização dos dados públicos do aluno por qualquer

usuário cadastrado do sistema.


[RF023] Solicitar monitoria

O ambiente deve permitir que um usuário cadastrado possa solicitar ao professor

monitoria em um curso.


[RF024] Editar dados gerais do curso

O ambiente deve permitir que o professor possa editar os dados gerais de um curso.



[RF025] Bloquear recebimento de mensagens

O ambiente deve permitir que um usuário cadastrado possa bloquear o recebimento de

mensagens por critérios como exemplo, emissor da mensagem.



5. Requisitos Não-Funcionais

5.1 Flexibilidade

Com o objetivo de tornar o ambiente mais flexível, os requisitos não funcionais citados

nesta subseção devem ser atendidos.

[NF001] Política de criação de contas de usuários

Obrigatoriamente, dois dados devem ser fornecidos: um login e uma senha.


[NF002] Uso de software e padrões abertos, de código não proprietário

O ambiente deve utilizar software e padrões abertos de forma a não onerar custos aos

desenvolvedores do AMADeUs-MM e permitir sua adequação a esforços existentes nas

comunidades industrial e acadêmica.


[NF003] Tecnologias a serem utilizadas

O ambiente a ser desenvolvido será em plataforma WEB, sendo implementado em

linguagem Java. A aplicação será dividida em camadas ficando de responsabilidade do

framework Struts[2] para a camada de visão e o Hibernate[1] para a camada de

persistência. No cliente WEB serão realizadas validação usando javascript[4] e

AJAX[3].



[NF004] Sistema Operacional do ambiente

Os servidores do ambiente utilizarão um sistema operacional open source. Na

implantação serão utilizados servidores Linux.


[NF005] Uso de softwares de terceiros

O uso de software de terceiros deve ser restrito aos softwares “livres” utilizando licença

LGPL ou semelhante. Não irão ser utilizados softwares que possuem licenças GPL.


5.2 Confiabilidade

O sistema AMADeUs-MM deve funcionar como serviços 24x7, onde a confiabilidade

do mesmo deve ser prioritária. Desta forma, os requisitos não funcionais citados nesta

subseção devem ser atendidos.

[NF006] Disponibilidade do Serviço

O ambiente deve estar sempre disponível na web aos usuários que o utilizam, 24 horas

por dia, 7 dias por semana, podendo haver paradas estratégicas para manutenção. Estas

paradas devem ser programadas, e avisadas aos usuários do ambiente.


[NF007] Facilidade para recuperação de falhas

No caso de falhas, como queda de um servidor, o processo de recuperação do ambiente

deve ser simples e rápido, se possível, realizado de forma automática.



5.3 Segurança

O ambiente permitirá o acesso a um grande número de usuários, guardando informações

de cada um destes. Estas informações devem estar protegidas contra ataques que

comprometam a segurança das informações.

[NF009] Política de criação de senhas

Deve haver regras para a criação de senhas do usuário, que devem ser seguidas no

procedimento de criação das senhas.


[NF010] Política de criptografia de dados

Dados sensíveis, como por exemplo, a senha do usuário, devem ser criptografados.


[NF011] Obrigatoriedade do Logon

Todo usuário autorizado deverá efetuar logon no sistema para realizar quaisquer

operações.


[NF012] Finalizar sessão

Ao fechamento do Browser a sessão deverá ser finalizada.


[NF013] Sigilo das informações

O sistema deve garantir o sigilo das informações cadastradas, de modo que apenas

usuários com permissão possam acessar os dados do ambiente.



[NF014] Integridade dos dados

O sistema deve preservar a integridade dos dados cadastros, de maneira que apenas

usuários com permissão possam modificar as informações cadastradas.


[NF015] Disponibilidade

O sistema deve garantir a disponibilidade das informações de cadastro, de forma que os

usuários possam acessar e modificar dados aos quais tenham permissão.


5.4 Usabilidade

[NF016] Mensagens de erros precisas

É essencial que o sistema exiba mensagens de erros explicativas que auxiliem os

desenvolvedores na utilização da API, e os usuários na utilização dos serviços do

ambiente.


[NF017] Adequação com Navegadores

O sistema deve ter uma interface compatível com o Internet Explorer, Netscape e

Mozilla Firefox.



[NF018] Interface de fácil utilização

O sistema deve ter uma interface de fácil utilização. Os critérios sobre o grau de

facilidade do sistema deverão ser definidos pela equipe de usabilidade, em acordo com

as possibilidades técnicas do sistema.


[NF019] Mensagens de erro

O sistema deve apresentar mensagens de erro e mensagens de advertência apropriadas e

inteligíveis.


[NF020] Distinção entre campos obrigatórios

É importante que o sistema faça distinção entre os campos obrigatórios e facultativos no

preenchimento dos formulários de cadastro provendo, desta forma, a opção do usuário

só preencher o que ele achar necessário.


[NF021] Campos de formulário intuitivos e auto-explicativos

É essencial que os campos do formulário de cadastro do Sistema sejam intuitivos e

auto-explicativos o suficiente, de modo a impedir que o usuário não preencha os

mesmos por não saber do que se tratam.


[NF022] Tamanha máximo de Upload

As áreas do sistema que apresentem upload de arquivos como central de documentos,

cadastro de foto, entre outras, devem informar o tamanho máximo do arquivo e os seus

formatos possíveis.



[NF023] Permitir entrada via teclado e mouse

O sistema deve aceitar entradas do usuário via teclado e mouse.


[NF024] Uso da ferramenta de email

Campos de preenchimento de mensagens de e-mail devem ser expostas na própria

interface do sistema. Deve-se evitar uso de aplicativos externos como o Outlook para

este tipo de operação.


[NF025] Favorecer a orientação do usuário

O sistema deve ter uma interface de fácil utilização que favoreça a orientação do

usuário. As opções voltar e sair devem estar presentes, de modo que o usuário não

precise utilizar o navegador quando desejar retornar a uma tela ou sair do sistema. Não

deve haver links quebrados e eles devem apontar exatamente para onde indicam.


5.5 Desempenho

[NF026] Espaço em disco suficiente

O sistema deve ser implantado em um ambiente que ofereça espaço em disco suficiente

para a armazenagem das informações. Em caso da necessidade de aumento da área do

banco, o sistema deve alertar aos administradores desta necessidade.



5.6 Robustez

[NF027] Quantidade mínima de acessos simultâneos

O sistema deve suportar pelo menos 50 acessos simultâneos.


5.7 Requisitos Externos

[NF028] Direitos autorais

O sistema deve proteger os direitos autorais sobre os cursos oferecidos e todo o material

de apoio utilizado.


[NF029] Relação entre Custo de desenvolvimento e Valor estimado

O custo de desenvolvimento do sistema não deve exceder em mais de 10% o valor

estimado.


5.8 Requisitos Operacionais

[NF030] Disponibilidade das tecnologias utilizadas

As tecnologias utilizadas no desenvolvimento do sistema devem estar disponíveis no

Centro de Informática da UFPE (CIn).



[NF031] Integração ao ambiente de servidores do CIn

O sistema deve integrar-se ao ambiente de servidores do CIn, de maneira a não onerar

sua manutenção por parte da equipe de suporte.



6. Escopo Negativo

• Não haverá suporte a correções de questões discursivas de forma automática. Ressalva-

se que haverá suporte a questões discursivas, mas a correção será realizada diretamente

pelo Professor ou Monitor;


7. Referências

[1] Hibernate. URL: www.hibernate.org

[2] Jakarta Struts. http://struts.apache.org/

[3] AJAX. http://pt.wikipedia.org/wiki/AJAX_(Web)

[4] Javascript. http://pt.wikipedia.org/wiki/Javascript

[5] SCORM. http://www.rhassociates.com/scorm.htm

[6] Transparência Social em Ambientes Colaborativos de Ensino: Interação e Percepção no

Ambiente EnsinarNET.

[7] Plano de Projeto AMADEUS.

Documento de Requisitos Agentes Micromundo e Análise do De...

Documents

Transcript of Documento de Requisitos Agentes Micromundo e Análise do De...