Mudanças entre as edições de "PJI29006-2014-2-Wiki do Projeto"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
Linha 4: Linha 4:
  
 
==Levantamento de Requisitos==
 
==Levantamento de Requisitos==
−
1. O Administrador pode dar acesso aos professores e alunos.
+
===Funcionais:===
 +
R01. O Sistema deve prever a liberar de portas para usuários autorizados (ver RN03,RN04);
  
−
2. O Professor pode dar acesso aos alunos.
+
R02. A liberação da porta deve ser possível através de um dispositivo móvel.
  
−
3. Pode haver mais de um Administrador.
+
R03. O Sistema deve armazenar em um “log” tanto a entrada quanto a saída das pessoas;
  
−
4. Deve haver um log para guardar os acessos (tanto de entrada quanto de saída).
+
R04. O Sistema deve permitir criar múltiplos perfis de permissões para os usuários (Aluno/Professor/Segurança/Funcionário) (ver RN08);
  
−
5. Todos os usuários devem ter usuário e senha para acesso.
+
R05. Deve haver em cada porta controlada uma tela para passagem de informações/mensagens aos usuários.
  
−
6. Deve haver uma saída de emergência (Sugestão: bateria reserva).
+
R06. O Sistema em sua interface gráfica deve fornecer a opção de criação e edição de mensagens fornecidas na tela de cada porta;
  
−
7. Deve haver um sistema de segurança contra arrombamento.
+
R07. O Sistema deve ser configurado através da interface gráfica;
  
−
8. O Professor só pode entrar ou liberar a sala de aula se estiver com seu horário reservado.
+
R08. O Sistema deve gerenciar cadastro de usuários;
  
−
9. O Aluno somente entra dentro de sala de aula se o Professor estiver.
+
R09. O Sistema deve gerenciar cadastro de portas/salas;
  
−
10. O usuário do tipo Aluno deve ter validade de sua credencial.
+
R10. O Sistema deve bloquear o usuário ao ter a sua autenticação fracassada (ver RN06);
  
−
11. O sistema deve prever a liberação da sala de aula para o Aluno.
+
R11. O Sistema deve permitir aos usuários do tipo Administrador e Professor bloquear e desbloquear um usuário do tipo Aluno;
  
−
12. O sistema deve notificar o Professor dentro de sala de aula durante a aproximação do tempo de saída.
+
R12. O Sistema deve fornecer suporte para “saída de emergência”;
  
−
13. Deve haver mais de uma plataforma (mobile e/ou web).
+
R13. O Sistema notificará os usuários ao término do expediente do campus (RN 11);
  
−
14. O hardware deve ter proteção à ação do tempo.
+
R14. O Sistema deve desligar os equipamentos após todos os usuários saírem da sala.
  
−
15. A plataforma web/mobile deve dar habilitação ao Professor e Administrador dar liberação e entrada da sala de aula.
+
R15. O Sistema deve identificar o arrombamento das portas;
  
−
16. O sistema deve conter o Segurança para liberação de salas de aula sem um professor.
+
===Não-funcionais===
 +
Escalabilidade: pode haver n usuários/portas/administradores.
  
−
17. O hardware do sistema deve conter um display para comunicação do Professor e Alunos.
+
Segurança: somente os usuários autenticados devem ter acesso ao sistema. O hardware deve ser resistente o bastante para assegurar possíveis danos devido a ação do tempo. Os dados internos do sistema devem estar protegidos de acesso não autorizado.
  
−
18. As plataformas mobile/web deve dar a opção de criação de mensagem para comunicação no display.
+
Disponibilidade: o sistema tolera no máximo 2 horas de indisponibilidade por mês;
  
−
19. O usuário pode ser bloqueado quando tiver a autenticação fracassada n vezes.
+
Comunicação: o sistema deve utilizar a infra-estrutura de redes já disponível no campus;
  
−
20. O usuário pode ser bloqueado pelo Administrador/Professor.
+
Requisitos de facilidade de uso: o uso do sistema deve ser intuitivo e prever um mini-tutorial no próprio aplicativo.
  
−
21. Em caso de emergência, abrir todas as salas.
+
Requisitos de eficiência. o sistema deverá dar resposta ao usuário em um tempo limite T, caso expire o tempo o usuário deverá se notificado da falha.
  
−
22. Após fechar a sala, desligar todos os equipamentos.
+
Requisitos de portabilidade. o componente móvel do sistema deve operar em múltiplas plataformas móveis.
 +
 
 +
Obs:
 +
 
 +
* em caso de queda de energia, o hardware contém uma fonte reserva de energia, que assegura um tempo extra de operação;
  
 
==Atores==
 
==Atores==

Edição das 22h53min de 24 de agosto de 2014

Sistema de Controle de Acesso

Descrição

Levantamento de Requisitos

Funcionais:

R01. O Sistema deve prever a liberar de portas para usuários autorizados (ver RN03,RN04);

R02. A liberação da porta deve ser possível através de um dispositivo móvel.

R03. O Sistema deve armazenar em um “log” tanto a entrada quanto a saída das pessoas;

R04. O Sistema deve permitir criar múltiplos perfis de permissões para os usuários (Aluno/Professor/Segurança/Funcionário) (ver RN08);

R05. Deve haver em cada porta controlada uma tela para passagem de informações/mensagens aos usuários.

R06. O Sistema em sua interface gráfica deve fornecer a opção de criação e edição de mensagens fornecidas na tela de cada porta;

R07. O Sistema deve ser configurado através da interface gráfica;

R08. O Sistema deve gerenciar cadastro de usuários;

R09. O Sistema deve gerenciar cadastro de portas/salas;

R10. O Sistema deve bloquear o usuário ao ter a sua autenticação fracassada (ver RN06);

R11. O Sistema deve permitir aos usuários do tipo Administrador e Professor bloquear e desbloquear um usuário do tipo Aluno;

R12. O Sistema deve fornecer suporte para “saída de emergência”;

R13. O Sistema notificará os usuários ao término do expediente do campus (RN 11);

R14. O Sistema deve desligar os equipamentos após todos os usuários saírem da sala.

R15. O Sistema deve identificar o arrombamento das portas;

Não-funcionais

Escalabilidade: pode haver n usuários/portas/administradores.

Segurança: somente os usuários autenticados devem ter acesso ao sistema. O hardware deve ser resistente o bastante para assegurar possíveis danos devido a ação do tempo. Os dados internos do sistema devem estar protegidos de acesso não autorizado.

Disponibilidade: o sistema tolera no máximo 2 horas de indisponibilidade por mês;

Comunicação: o sistema deve utilizar a infra-estrutura de redes já disponível no campus;

Requisitos de facilidade de uso: o uso do sistema deve ser intuitivo e prever um mini-tutorial no próprio aplicativo.

Requisitos de eficiência. o sistema deverá dar resposta ao usuário em um tempo limite T, caso expire o tempo o usuário deverá se notificado da falha.

Requisitos de portabilidade. o componente móvel do sistema deve operar em múltiplas plataformas móveis.

Obs:

  • em caso de queda de energia, o hardware contém uma fonte reserva de energia, que assegura um tempo extra de operação;

Atores

1. Administrador:

2. Professor:

3. Aluno:

4. Banco de dados:

5. Funcionário:

6. Arrombador:

7. Emergência:

Casos de Uso

Documentação no Astah

Link

Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=PJI29006-2014-2-Wiki_do_Projeto&oldid=75108”