• Nenhum resultado encontrado

2. REVISÃO BIBLIOGRÁFICA

3.2. Análise de Requisitos

Com vista a desenvolver um software adequado, eficiente e feito à medida da instituição é importante recolher as necessidades e problemas existentes. Neste sentido foi feita uma análise e especificação de requisitos funcionais e não funcionais. Segundo (Arlow & Neustadt, 2006) uma engenharia de requisitos pobre é a principal causa na falha de desenvolvimento de software.

Neste trabalho foram utilizados diversos métodos para a recolha dos diferentes requisitos do sistema tal como análise sensorial no meio, conversas informais, brainstorming e questionários. O grande contacto e envolvimento tanto na análise como ao longo do desenvolvimento de todos os utilizadores foi algo que se teve em grande

26

importância visto ser, com base em (Arlow & Neustadt, 2006) o segundo fator que mais contribui para o insucesso no desenvolvimento de software.

O requisito é a especificação do que deverá ser implementado, sendo apenas declarações do que o sistema deve fazer e não de como essas funcionalidades devem ser implementadas, contudo segundo (Arlow & Neustadt, 2006) na prática não é possível evitar o “como” em diversos aspetos do sistema.

Existem dois tipos de requisitos: os funcionais que especificam o comportamento desejado para o sistema e os não funcionais que especificam propriedades ou restrições específicas do sistema.

Todos os requisitos foram declarados seguindo as normas especificadas na UML2 (Unified Modeling Language)1.

3.2.1. Requisitos Funcionais

Os requisitos funcionais identificados para o Sistema de Gestão de Oficina de Eletrónica (SGOE) são os seguintes:

- O sistema deve registar e gerir reparações efetuadas para a UTAD;

- O sistema deve registar e gerir reparações efetuadas por clientes externos à UTAD;

- O sistema deve registar e gerir reparações efetuadas por entidades externas à UTAD;

- O sistema deve registar e gerir a requisição de equipamentos informáticos; - O sistema deve registar e gerir a requisição de circuitos impressos;

- O sistema deve registar e gerir a requisição de equipamento de laboratório (de medida e teste);

- O sistema deve registar e gerir a requisição de componentes eletrónicos; - O sistema deve registar e gerir orçamentos para reparação de equipamentos; - O sistema deve permitir registar o estado do material dando baixa do mesmo nos

stocks no caso de se encontrar danificado;

- O sistema deve permitir o registo dos componentes que ficam montados em circuitos e portanto fora do stock de utilização;

Sistema de Gestão Para Oficinas de Eletrónica

27

- Deve permitir dar baixa dos respetivos componentes que se encontram em stock; - Deve associar os respetivos pedidos ao utilizador. No caso de ser aluno deve registar o curso e a respetiva disciplina a que pertence;

- Deve permitir a entrega de componentes por fases e descontar na conta do respetivo utilizador;

- O sistema deve registar um valor por cada tipo de componente ou equipamento e criar um valor total por cada lista de requisição;

- O sistema deve permitir visualizar o rácio de importância/atualização por cada componente;

- O sistema deve registar um stock mínimo por tipo de componente; - O sistema deve permitir inserir e alterar requisições;

- O sistema deve permitir inserir e alterar orçamentos; - O sistema deve permitir inserir e alterar reparações;

- Deve permitir o registo de dívida por utilizador relativo a pedidos de componentes/equipamentos/reparações;

- O sistema deve ter um motor de busca de componentes; - O sistema deve ter um motor de busca de reparações;

- O sistema deve gerar códigos de barras associados a serviços e artigos; - O sistema deve ler códigos de barras;

- O sistema deve permitir a criação de relatórios de apoio à decisão, nomeadamente contagem total de componentes utilizados especificados por tipo e contagem geral, total de componentes usados por utilizador em número e valor, identificação do componente mais utilizado, curso que mais componentes gastou e qual o componente mais gasto no mesmo em número e valor monetário e ainda o funcionário que mais registos efetuou.

3.2.2. Requisitos Não Funcionais

No que diz respeito às características não funcionais foram identificados os seguintes requisitos para o SGOE (Sistema de Gestão de Oficina de Eletrónica):

- O sistema deve ser implementado como uma plataforma Web;

- O sistema deve estar sincronizado com o Sistema de Informação de Apoio ao Ensino (SIDE) e as suas respetivas contas de utilizador;

28

- O sistema deve permitir uma visualização acessível das listas de requisição de modo a que o funcionário tenha facilidade na seleção e preparação dos respetivos pedidos;

- Deve impedir os utilizadores de solicitarem novos componentes/equipamentos caso não tenham entregue os respetivos pedidos anteriores;

- O sistema deve ter um alarme físico e por via de email no local de trabalho para avisar o respetivo funcionário aquando da chegada de novos pedidos ou baixa de stocks;

- O sistema deve permitir o aviso automático do docente responsável via email, no caso de um utilizador danificar um numero máximo de componentes/equipamentos;

- O sistema deve obrigar a que os campos mais relevantes no preenchimento dos requisitos sejam obrigatórios;

- O sistema deve ter os seguintes utilizadores: Administrador, Chefe de Oficina, Convidado, Aluno, Docente e Funcionário;

- O registo e procura de componentes no sistema (sem ser via motor de busca) devem ser feitos da seguinte forma: Família -> Categoria/Tipo -> Nome;

- O sistema deve registar a frequência de utilização de cada tipo de componente ou equipamento;

- O sistema deve calcular a prioridade de compra pela frequência de utilização e rácio de atualização e assim criar uma lista de compras prioritárias por ordem.

- O sistema não deve permitir que os clientes consigam alterar uma requisição depois de esta ser levantada;

- O sistema deve identificar cada encomenda de forma única e associar a mesma ao respetivo cliente ou grupo de clientes;

- O sistema deve permitir ligações a Web-sites com os datasheet relativos a cada componente.

- O sistema deve permitir a definição de quantidades por equipamento/componente nas respetivas requisições e gestão de stocks.

Documentos relacionados