ESPECIFICAÇÃO REQUISITOS

(1)

ESPECIFICAÇÃO REQUISITOS

Engenharia Software

Projeto: INV_ID

OCTOBER 13, 2017

UNIVERSIDADE DE AVEIRO ESAN Hugo Barragon nº 84654

(2)

Página 1 de 13

Índice

Controlo de versões...2

Introdução ...3

Escopo ...3

Visão geral ...4

Classes e Características dos Usuários ...4

Requisitos sistema...5

Funcionais ...5

Não funcionais ...6

Usabilidade...6

Confiabilidade...6

Requisitos Negativos...6

Gerenciamento de Requisitos ...7

Gerenciamento de Mudanças de Requisitos ...7

Casos de uso ...8

Gestor de Conteúdo...8

Gestor de Conteúdo – Gerir o sistema modo Admin ...8

Gestor de Conteúdo – Gerir inventário ...9

Gestor de Conteúdo – Gerir registos dos utilizadores ... 10

Utilizador ... 11

Utilizador – Consulta ... 11

Utilizador – Requisita ... 12

Glossário... 13

(3)

Página 2 de 13

Controlo de versões

Data Versão Descrição Autor

13/10/2017 0.1 Inicio da inclusão de requisitos funcionais Hugo Barragon 02/11/2017 0.2 Finalização do sistema de requisitos. Hugo Barragon

(4)

Página 3 de 13

Introdução

Este documento especifica os requisitos contemplados pelo software INV_ID, que integrará o sistema da oficina da ESAN, fornecendo todas as informações necessárias para o projeto, implementação, aprovação do sistema e as restrições associadas a ele.

Escopo

O documento descreve os casos de uso do software para gestão de material da oficina, que permite que um docente ao passar uma ferramenta por cima do leitor, e insira o seu numero mecanográfico, essa mesma fique reservada a ele, para poder trabalhar em casa.

Para devolver é só passar o material no leitor e fica devolvido. Possuirá a componente web para gerir alunos/material mais detalhadamente e a componente mobile para o aluno verificar o material que tem em sua posse onthego.

Também possuirá uma aplicação Windows para comunicar com o kit RFID FX7400 que fará a leitura e associação das tags/material

Os requisitos especificados neste documento estão relacionados com os casos de uso.

Sendo o publico alvo todos os docentes e não-docentes que necessitarem de trabalhar em casa e precisem de material escolar.

(5)

Página 4 de 13

Visão geral

Classes e Características dos Usuários

O INV_ID será utilizado por um perfil de usuário, tido como participante, que terá permissão apenas de visualizar o material que possui a seu nome.

Um segundo perfil de usuários, responsavel, poderá requisitar o material e também visualizar todos os materiais, alunos e material requisitado.

O último perfil de usuário é o administrador que poderá realizar as mesmas ações que o ministrante e ainda alterar e adicionar materiais novos ou seja gerir todo o software.

(6)

Página 5 de 13

Requisitos sistema

Funcionais

Identificar os usuários: Os usuários deverão estar “logados” na app (Android) antes de

acederem os recursos, de modo que o sistema possa mostrar os materiais reservados de cada um.

O sistema deve permitir que os participantes sejam capazes ver os seus materiais em qualquer lado (mobile).

O sistema deve permitir que um responsável, devolva qualquer material caso tenha existido algum engano.

O sistema deve permitir a visualização do material existente. Lembrando que o participante só poderá visualizar o material em seu nome. Apenas o responsável e o administrador poderão gerir e listar o material.

Cada material deve ter uma tag RFID única associada.

O sistema deve permitir a visualização dos materiais que estão requisitados, como por exemplo, mostrar nome do aluno o material, o id referente e a data da ação.

O sistema deve permitir a importação via PACO de todos os docentes/não docentes para associação de material.

No sistema deve ser possível gerir os empréstimos (ex: eliminar, adicionar material) e a cada aluguer registar a data em que o mesmo foi efetuado.

(7)

Página 6 de 13

Não funcionais Usabilidade

Interface WEB: O responsável utilizará o sistema através de um web browser/aplicação local.

Facilidade de Uso: O usuário do sistema deve ter facilidade de uso do sistema, ou seja, realizar tarefas (inserção, alteração, consulta) em tempo muito reduzido de aprendizagem. Para confirmação disso, será realizado um teste de usabilidade.

Confiabilidade

O sistema deve informar ao usuário quando ele tentar fazer uma operação de risco ou quando ele está preste a realizar uma operação que pode ser “perigosa”. Ex: apagar registo de um material.

Requisitos Negativos

Não será permitido fazer buscas, reutilização de informações (clonagem), gerar relatórios de dados pessoais de usuários apenas apagar ou inserir novos.

(8)

Página 7 de 13

Gerenciamento de Requisitos

O gerenciamento de requisitos será feito a partir de uma informação constante entre o cliente e o estado atual do software.

Gerenciamento de Mudanças de Requisitos

O gerenciamento de mudanças de requisitos trata as seguintes etapas:

• O cliente solicita uma mudança de requisito ao responsável pelo projeto;

• O responsável pelo projeto receberá essa mudança e será conversada, com neste caso o diretor de curso/professor projeto;

• Os responsáveis pelo projeto analisarão a mudança sugerida e avaliarão o impacto da mesma no sistema;

• Como resultado dessa análise ocorrerá ou não a mudança solicitada.

(9)

Página 8 de 13

Casos de uso

Gestor de Conteúdo

Figura 1 - Gestor de conteúdo

Gestor de Conteúdo

– Gerir o sistema modo Admin

Figura 2 - Gere Sistema em modo Admin

Prés condições:

O gestor de conteúdo tem que ser administrador do sistema.

Ativação de eventos:

Autenticação através de página específica Cenário Primário:

Entrar no sistema.

Cenário Secundário:

Cancelar a autenticação ao sistema.

Pós-Condições:

O gestor de conteúdo está conectado como administrador.

(10)

Página 9 de 13

Gestor de Conteúdo

– Gerir inventário

Figura 3 - Gestor conteúdo gerir inventário

O gestor de conteúdo tem que ser administrador do sistema.

1. Visualização de todos os produtos que já foram registados.

Cenário Primário:

1. Pedido de eliminação de registo de um produto.

2. Apresenta uma mensagem de validação ao gestor.

3. Confirma (S | N) Cenário Secundário:

1. Não aceitar o pedido de remoção.

2. Envia uma mensagem ao utilizador de que o pedido não foi validado e a justificação.

1. A remoção foi validada.

2. Será enviada uma mensagem ao utilizador a informar que foi removido com sucesso.

(11)

Página 10 de 13

Gestor de Conteúdo

– Gerir registos dos utilizadores

Figura 4 – Gerir registos de utilizadores

O gestor tem que estar autenticado como administrador Ativação de eventos:

Visualização de todos os registos de utilizadores.

1. Criar, modificar e remover registos de utilizadores.

Não existe cenário secundário.

Registo criado, modificado ou removido.

(12)

Página 11 de 13

Utilizador

Figura 5 – Utilizador geral

Utilizador – Consulta

Figura 6 – Utilizador faz uma consulta

O utilizador vai entrar no sistema para consultar os seus materiais requisitados.

O utilizador é autenticado.

Visualiza os materiais que possui requisitados em seu nome.

1 – O utilizador fecha a janela/app.

Não existe pós-condições.

(13)

Página 12 de 13

Utilizador – Requisita

Figura 7 – Utilizador requisita material

O utilizador pretende requisitar.

O utilizador passa o material por um leitor/pórtico.

Recebe feedback em como requisitou material com sucesso (som/mensagem) Cenário Secundário:

1. O utilizador não conclui o processo.

1. Material registado

(14)

Página 13 de 13

Glossário

Requisitos Funcionais - Funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente.

Requisitos Não-Funcionais - Aspetos não-funcionais do sistema, como restrições nas quais o sistema deve operar.