FACULDADE DE BALSAS – UNIBALSAS
RELATÓRIO FINAL DE ESTÁGIO Análise e projeto de um sistema para geração automática de horários docentes da Faculdade de Balsas
Jadson José Monteiro Oliveira
Balsas - MA 2015
JADSON JOSÉ MONTEIRO OLIVEIRA
Análise e projeto de um sistema para geração automática de horários docentes da Faculdade de Balsas
Relatório de estágio apresentado como exigência parcial para obtenção do titulo de Bacharel em Sistemas de Informação à Faculdade de Balsas. Orientador (a): Jairo Menezes Ferraz
Supervisão do Estágio Supervisionado: Alexandre Maia Lima Coordenação do Curso: Junior Marcos Bandeira Empresa: Unibalsas Educacional LTDA. Período de estágio: 09/03/2015 a 27/04/2015 Total de horas mínima de estágio: 80 horas Total de horas realizadas: 80 horas
JADSON JOSÉ MONTEIRO OLIVEIRA
Análise e projeto de um sistema para geração automática de horários docentes da Faculdade de Balsas
Relatório de estágio apresentado como exigência parcial para obtenção do titulo de Bacharel em Sistemas de Informação à Faculdade de Balsas. Orientador (a): Jairo Menezes Ferraz Aprovado em:__/__/__
BANCA EXAMINADORA
A Comissão Examinadora, abaixo assinada, aprova o Relatório Final de Estágio ___________________________________________ Nome do Professor Orientador com titulação Instituição
___________________________________________ Nome do Professor ou Profissional com titulação Instituição
___________________________________________ Nome do Professor ou Profissional com titulação Instituição
AGRADECIMENTOS Agradeço primeiramente a Deus, pela vida, saúde, força e fé concedidos a mim, para superar todas as dificuldades enfrentadas ao longo do tempo. A minha família, especialmente minha mãe, e meus irmãos, que sempre me motivaram e acompanharam meu esforço ao longo da minha formação acadêmica. Agradeço aos professores pelo conhecimento repassado a mim e a todos os colegas de sala de aula, especialmente ao professor Junior Marcos Bandeira pelo espaço concedido para que eu pudesse realizar o levantamento de requisitos necessário para a realização deste estágio supervisionado. Agradeço também ao orientador de atividades Alexandre Maia Lima, pela paciência, preocupação e orientação em vários aspectos relacionados à realização deste trabalho e ao meu orientador Jairo Menezes Ferraz pelas dicas e o apoio necessário para sanar alguma dificuldade técnica encontrada.
RESUMO O presente trabalho tem como objetivo realizar uma análise e projeto de um sistema para geração automática de horários docentes destinados à Faculdade de Balsas, propondo no projeto um algoritmo para solucionar o problema da tabela de horários, conhecido internacionalmente por TimeTabling Problem. Diversas metodologias de engenharia de software foram utilizadas ao longo da análise e projeção do sistema, desde técnicas de levantamento de requisitos à técnicas utilizadas para construção de diagramas de UML e DER. Através dos requisitos funcionais obtidos, optou-se por propor a meta heurística GRASP, para aplicar ao problema da tabela de horários. Serão descritos ainda, todas as técnicas e os meios utilizados para a conclusão deste projeto, além de etapas para a fundamentação e o desenvolvimento, ressaltando dificuldades e/ou facilidades encontradas. Palavras-Chave: GRASP; Projeto; UML; TimeTabling
LISTA DE FIGURAS Figura 1. Exemplo de um diagrama de caso de uso …............................................... 20 Figura 2. Exemplo de um diagrama de classes …....................................................... 21 Figura 3. Exemplo de um diagrama de entidade e relacionamento …........................ 22 Figura 4. Diagrama de caso de uso para visão geral do sistema ..............….............. 25 Figura 5. Caso de uso: Acessar Sistema .............................................................. ... 26 Figura 6. Caso de uso: Importar Dados ............................................................... ... 26 Figura 7. Caso de uso: Manter Cursos ................................................................. ... 27 Figura 8. Pseudocódigo funcionamento GRASP .................................................. ... 29
LISTA DE TABELAS Tabela 1. Estrutura Administrativa e Acadêmica da Faculdade de Balsas …............. 12 Tabela 2. Principais requisitos funcionais do sistema ................................…............. 24 Tabela 3. Principais requisitos não funcionais do sistema .......................................... 24
GLOSSÁRIO DER
Diagrama de Entidade e Relacionamento
IES
Instituição de Ensino Superior
OMG
Object Management Group
UML
Unified Modeling Language
GRASP
Greedy Randomized Adaptive Search Procedure
SUMÁRIO
1
IDENTIFICAÇÃO ................................................................................................ 11 1.1 Área do Estágio............................................................................................ 11 1.2 Histórico da Empresa ................................................................................... 11 1.2.1 Missão .................................................................................................... 12 1.2.2 Visão ...................................................................................................... 12 1.2.3 Diretriz .................................................................................................... 12 1.3 Ramo de Atuação ........................................................................................ 12 1.4 Público Atendido .......................................................................................... 13 1.5 Serviços Oferecidos ..................................................................................... 13 1.6 Orientador de Atividades.............................................................................. 13
2
INTRODUÇÃO .................................................................................................... 14
3
OBJETIVO .......................................................................................................... 15 3.1 Objetivo Geral ............................................................................................... 15 3.2 Objetivo Específicos...................................................................................... 15
4
JUSTIFICATIVA ................................................................................................. 16
5
EMBASAMENTO TEÓRICO .............................................................................. 17 5.1 Engenharia de software ............................................................................. 17 5.1.1 Levantamento de requisitos ................................................................ 17 5.1.1.1 Requisitos Funcionais .................................................................... 18 5.1.1.2 Requisitos Não-Funcionais ............................................................ 19 5.2 UML – Unified Modeling Language ............................................................ 19 5.2.1 Diagrama de caso de uso .................................................................... 20 5.2.2 Diagrama de classe ............................................................................. 21 5.3 DER – Diagrama de entidade e relacionamento ........................................ 21 5.4 Meta heurística GRASP ............................................................................. 22
6
ATIVIDADES DESENVOLVIDAS ....................................................................... 23 6.1 Levantamento bibliográfico ........................................................................ 23 6.2 Levantamento de requisitos do sistema ..................................................... 23 6.3 Estudo e montagem de diagramas de UML ............................................... 25 6.4 Estudo e montagem de DER ...................................................................... 28
6.5 Estudo e levantamento de algoritmos já existentes utilizados para solucionar o problema da geração do horário docente e proposta de um algoritmo a ser utilizado ..................................................................................... 29 6.6 Elaboração da documentação do software ................................................ 30 7
CONCLUSÃO .................................................................................................... 31
8
REFERÊNCIAS .................................................................................................. 32
9
ANEXOS ............................................................................................................ 34
1
IDENTIFICAÇÃO
1.1 Áreas do Estágio:
Engenharia de Software Banco de Dados Análise e Complexidade de Algoritmos
1.2 Históricos da Empresa: A Faculdade de Balsas é uma Instituição de Ensino Superior que está localizada na BR 230, Km 5, Fazenda Malidere IV, no município de Balsas, estado do Maranhão, mantida pela Unibalsas Educacional Ltda, também denominada pela sigla UNIBALSAS. A falta de oferta de cursos de nível superior na região de influência geopolítica da cidade de Balsas, obrigava os jovens a se deslocarem para outras regiões do país no intuito de obter a formação superior almejada. Visando modificar essa realidade e contribuir com o crescimento econômico e regional, a Faculdade de Balsas foi concebida. Seu credenciamento aconteceu no ano de 2006, através da Portaria nº 1.744, de 24 de outubro de 2006, no qual iniciou com quatro cursos de níveis superiores, são eles: Administração, Ciências Contábeis, Direito e Sistemas de Informação, respectivamente através das portarias nº 778, de 25 de outubro de 2006, nº 779, de 25 de outubro de 2006, nº 780, de 25 de outubro de 2006 e nº 103, de 02 de fevereiro de 2007. Foram autorizadas 100 vagas anuais para cada curso. Logo após, no ano de 2011 a Faculdade de Balsas lançou o vestibular para dois novos cursos Superiores Tecnólogos de graduação em Agronegócio e Gestão Comercial, com as respectivas portarias de autorização de funcionamento, nº 178 de 19 de novembro de 2010 e nº 179 de 19 de outubro de 2010, respectivamente. Recentemente no ano de 2015, o curso de Pedagogia deu início a suas atividades, abrindo 100 vagas anuais para o vestibular. A Faculdade de Balsas possui atualmente no regimento a seguinte estrutura administrativa e acadêmica:
11
Cargo
Nome
Diretor Geral
Fábio Roberto Pillatt
Diretor Acadêmico
Cleverton Marlon Possani
Direto Administrativo
Renan Francisco Honaiser
Coordenador do curso de Administração
Emerson Paulo Rodrigues Santos
Coordenadora do curso de Agronegócio
Núbia Micheli Zavaglia Pereira
Coordenador do curso de Ciências Contábeis
Hamilton Nogueira Makosky
Coordenador do curso de Direito
Tatiana Morais Cosate
Coordenador do curso de Gestão Comercial
Emerson Paulo Rodrigues Santos
Coordenadora do curso de Pedagogia
Maria Cecília de Melo Silva
Coordenador do curso de Sistemas de Informação
Junior Marcos Bandeira
Tabela 1: Estrutura Administrativa e Acadêmica da Faculdade de Balsas.
1.2.1 Missão: “Promover a educação necessária para que as pessoas possam edificar a própria vida”. 1.2.2 Visão: “Ser a ponte para o conhecimento e desenvolvimento regional”. 1.2.3 Diretriz: “Combinar comprometimento, seriedade, inteligência e disciplina com inovação acadêmica e pedagógica, mediante o desapego a paradigmas acadêmicos e pedagógicos superados”.
12
1.3 Ramo de Atuação: O ramo de atuação da Faculdade de Balsas é Educação de Ensino Superior. 1.4 Público Atendido: O público-alvo atendido pela Faculdade de Balsas, são os jovens do Sul do estado do Maranhão que desejam ingressar em algum curso de ensino superior abrangido pela Faculdade. 1.5 Serviços Oferecidos: Cursos de níveis superiores são os principais serviços oferecidos pela Faculdade de Balsas. 1.6 Orientador de Atividades:
Nome: Alexandre Maia Lima
E-mail:
[email protected]
Telefone: (99) 9 8808-2265
13
2
INTRODUÇÃO TimeTabling Problem é um problema bastante conhecido na área de otimização
combinatória. Dado um conjunto de professores, turmas, cursos e disciplinas, e definir algumas restrições (fortes e fracas), o problema consiste em alocar aulas em horários limitados. É considerado por Widjaja (2004), um problema NP – Completo. Sendo assim, uma
solução
exata
somente
funcionaria
para
instâncias
pequenas,
que
não
correspondem às instâncias reais da maioria das Instituições de Ensino. No caso específico da Faculdade de Balsas, o problema vem sendo discutido a bastante tempo. Atualmente os coordenadores (responsáveis por tal função), demoram semanas para conseguir finalizar a tarefa. Este trabalho propõe a análise e projeto de um sistema capaz de gerar automaticamente a tabela de horários docentes para a Faculdade de Balsas, com o objetivo de facilitar e diminuir a quantidade de tempo para exercer a atividade destacada anteriormente. O sistema foi projetado através da documentação de requisitos funcionais e não funcionais e de alguns diagramas de UML e DER, mais especificamente os diagramas de caso de uso, diagramas de classe e diagrama de entidade e relacionamento, sendo que após toda a etapa de levantamento de requisitos uma meta heurística conhecida por GRASP foi proposta para a solução do problema da geração da tabela de horários. De maneira sucinta a meta heurística GRASP tem o objetivo de encontrar soluções de modo guloso, aleatório e adaptativo. O GRASP consiste em construir uma solução inicial e depois realizar uma busca em outras soluções aleatórias e gulosas, de forma a otimizar a solução gerada inicialmente, tornando o horário gerado diversificado e atendendo a quantidade máxima de restrições impostas.
14
3
OBJETIVO
3.1 Objetivo Geral Realizar a análise e projeto de um software gerador de horários docentes da Faculdade de Balsas e através destes propor um algoritmo para solucionar o problema da tabela de horários. 3.2 Objetivos Específicos
Realizar o levantamento bibliográfico para estudo e elaboração do embasamento teórico
Levantar os requisitos do sistema a ser desenvolvido para elaborar posteriormente o documento de requisitos necessário para a projeção do software
Propor um algoritmo para solucionar o problema da tabela de horários seguindo as restrições da Instituição de Ensino que foram consideradas através do levantamento de requisitos.
Elaborar a documentação do software, abordando os requisitos levantados, diagramas montados e algoritmo proposto.
Montar os diagramas de UML (Diagramas de caso de uso e diagramas de classe) e DER para anexar à documentação do software
15
4 JUSTIFICATIVA Atualmente o processo de montagem de um horário docente na Faculdade de Balsas é realizado manualmente, no qual muitas vezes os coordenadores dos cursos (responsáveis por tal função) demoram semanas para finalizar a tarefa. A dificuldade deve-se ao fato de que podem ocorrer diversos conflitos na alocação de professores em determinado curso, disciplina e horário. O problema a ser solucionado tem grande destaque na área de otimização combinatória e pode ser generalizado por um problema conhecido internacionalmente como Time-Tabling Problem. O presente trabalho tem como objetivo propor um algoritmo para solucionar o problema em questão e realizar o projeto de software para geração automática dos horários docentes da Faculdade de Balsas. Visa beneficiar os coordenadores da instituição, diminuindo o tempo destinado a realizar tal operação, para que os mesmos possam utilizar o tempo economizado em outras atividades que possam beneficiar a qualidade de ensino aplicada aos cursos da IES.
16
EMBASAMENTO TEÓRICO 5.1
Engenharia de Software A engenharia de Software está diretamente relacionada a qualidade no
desenvolvimento de um software. É uma área da tecnologia da informação que aplica diversas metodologias ao processo de desenvolvimento de um sistema, envolvendo etapas como a especificação, desenvolvimento e manutenção do mesmo. A engenharia de software é uma metodologia de desenvolvimento e manutenção de sistemas modulares, com as seguintes características: processo (roteiro) dinâmico, integrado e inteligente de soluções tecnológicas; adequações aos requisitos funcionais do negócio do cliente e seus respectivos procedimentos pertinentes; efetivação de padrões de qualidade, produtividade e efetividade em suas atividades e produtos; fundamentação na Tecnologia da Informação disponível, viável, oportuna e personalizada; planejamento e gestão de atividades, recursos, custos e datas. (REZENDE; 2005, p. 2).
Para Carvalho e Chiossi (2001) a engenharia de software é uma disciplina que faz a união de metodologias, métodos e ferramentas a serem utilizados, no momento em que o problema é compreendido até o momento em que o sistema desenvolvido deixa de ser utilizado, ou seja, até o fim do ciclo de vida do software, com o objetivo de resolver os problemas inerentes ao processo de desenvolvimento e ao produto do software. 5.1.1 Levantamento de Requisitos
O levantamento de requisitos é uma etapa fundamental para o desenvolvimento de um software, tendo como princípios a qualidade e a funcionalidade do sistema a ser desenvolvido. Para Junior e Campos (2008), o levantamento de requisitos é uma etapa do desenvolvimento de sistemas de informação responsável por identificar e modelar as necessidades do negócio a serem atendidas pelos sistemas de informação, e é, portanto, uma atividade cada vez mais relevante em um cenário dinâmico. O principal objetivo na etapa de levantamento de requisitos é entender o problema a ser resolvido, destacando os detalhes que deveram ser abordados pelo sistema e que ao final do desenvolvimento, quando o produto estiver pronto, o mesmo possa solucionar o problema em questão. Seguindo este princípio Rezende (2005), afirma que existem diversas técnicas para que o levantamento de requisitos seja realizado, todas as técnicas possuem um conceito
17
próprio e suas vantagens e desvantagens, mas que podem ser utilizadas juntas. Abaixo estão listadas algumas das principais técnicas para o levantamento de requisitos.
Observação Pessoal o É uma técnica que permite vivenciar o problema ou situação abordada no dia a dia. Questionário o É uma técnica que geralmente utiliza-se um formulário para levantamento de informações pertinentes à solução do problema. Entrevista o A entrevista é considerada a melhor técnica para o levantamento dos requisitos, bastante utilizada pelos engenheiros de software, com esta técnica as outras também podem ser abordadas. Seminário o É uma técnica que consiste na realização de uma reunião geral com as pessoas que estão diretamente envolvidas ao problema, com o objetivo de obter informações precisas sobre a organização e o problema a ser solucionado. Pesquisa o A técnica da pesquisa consiste na busca física de informações ou processos anteriores que possam auxiliar no desenvolvimento da solução. Técnica Mista o Como o próprio nome sugere é a união das técnicas citadas anteriormente, é a mais indicada pelo fato de que podem ser abordados as principais vantagens de todas as outras.
5.1.1.1
Requisitos Funcionais
Requisitos funcionais é o tipo de requisito mais comum, basicamente os requisitos funcionais serão responsáveis por identificar o que o software realizará quando desenvolvido. Os requisitos funcionais são melhores descritos quando é utilizado casos de usos. Abaixo estão listados alguns exemplos de requisitos funcionais:
O sistema deve permitir que o usuário padrão, edite o horário gerado pelo software.
O sistema deve permitir que o administrador, importe as informações a serem utilizadas para a geração do horário, como: Turmas, Professores, etc. “Os requisitos funcionais são fundamentais para elaborar um sistema ou software
que atenda e satisfaça plenamente a equipe desenvolvedora e os clientes ou usuários”. (REZENDE, 2005, p. 123). Para facilitar o levantamento e conhecimento dos requisitos
18
funcionais,
são
utilizadas
as
técnicas
de
levantamento
de
requisitos
citadas
anteriormente. 5.1.1.2
Requisitos Não-Funcionais
Para Falbo (2012), Na engenharia de software, ao contrário dos requisitos funcionais, eles não descrevem o que o software deverá realizar, entretanto descreverá como o software realizará. Abaixo estão listados alguns exemplos de requisitos não funcionais:
O sistema deverá ter alta disponibilidade e funcionar na web.
O sistema deverá gerar a tabela de horários docentes em no máximo 5 minutos. Os requisitos Não-Funcionais são fundamentais para o funcionamento do software,
tendo em vista que a partir deles são delimitados os limites globais da solução.
5.2
UML – Unified Modeling Language
A UML foi desenvolvida por vários contribuintes, entretanto existiram 3 pessoas que se destacaram no processo de criação da mesma, são eles: Grady Booch, James Rumbaugh e Ivar Jacobson. A notação definida para UML é uma união de diversas notações preexistentes, com alguns elementos removidos e outros
elementos
adicionados com o objetivo de torná-la mais expressiva. (BEZERRA, 2007, p. 13). Em 1997 a UML foi aprovada como padrão pelo OMG1, desde então tem sido utilizada frequentemente pelos engenheiros de software, para a projeção de sistemas orientados a objetos, apesar disso sua definição ainda está em desenvolvimento, tendo em vista que várias modificações com o intuito de torná-la mais prática e útil vem sendo aplicadas ao longo do tempo. Segundo Rezende (2005), UML é uma linguagem visual utilizada para modelar sistemas que são orientados a objetos, ressaltando que UML constitui-se em uma
1 O OMG é um consórcio internacional de empresas que define e ratifica padrão na área da Orientação a Objetos (www.omg.org).
19
linguagem de modelagem e não em uma metodologia de desenvolvimento de sistemas. O seu objetivo não é de solucionar os problemas no desenvolvimento de um software, mas mostrar os limites de um sistema e suas funções principais, para isso utiliza-se diagramas como os de caso de uso, classes, etc.
5.2.1 Diagrama de caso de uso
Para Rezende (2005), o modelo de caso de uso é descrito pela UML por meio de um diagrama de caso de uso, e pode ser dividido em diversos diagramas. Um diagrama de caso de uso é composto basicamente por atores e casos de usos, além de diversos relacionamentos, associações, generalizações e dependências. É possível definir através deste diagrama todas as funções do sistema, além dos limites que definem o problema a ser solucionado. A notação utilizada para representar um diagrama de caso de uso é a figura de um boneco, que representa um ator do sistema, e a figura de uma elipse que representa um caso de uso, utilizam-se também retângulos para representar as fronteiras de um sistema. A Figura 1 exemplifica um diagrama de caso de uso.
Figura 1: Exemplo de um diagrama de caso de uso
Quanto a descrição dos casos de uso, existem muitas variações. Para Rezende (2005), uma das possibilidades é a utilização do português estruturado, pois dessa forma os envolvidos podem entender plenamente o sistema, ao tempo em que pode participar ativamente do mesmo. Na associação dos casos de uso, 3 são bastante relevantes: inclusão (include), que ocorre quando há uma parte do comportamento que é de certa forma obrigatório
20
acontecer em um determinado caso de uso, generalização (generalization), ocorre quando um caso de uso é semelhante a outro, porem com mais funções e a extensão (extends), que é semelhante à generalização, mas contém mais regras, podendo acrescentar outros comportamentos.
5.2.2 Diagrama de classe
Diagramas de classe para um modelo conceitual é a implementação de um diagrama de classe onde os atributos e as operações ainda não estão completamente definidos. (REZENDE, p. 206, 2005). Para Bezerra (2007), de todos os diagramas de UML o diagrama de classe é o mais rico em termos de notação, é utilizado na construção do modelo de classes desde o nível de análise até o nível de especificação. O principal elemento do diagrama de classes utilizado para a construção do modelo de classes é a Classe, representada através de uma “caixa”, com no máximo três partições exibidas, representando o nome da classe, os atributos da classe e os métodos, respectivamente. A Figura 2 demonstra um exemplo simples de diagrama de classes.
Figura 2: Exemplo de um diagrama de classes
21
5.3
DER – Diagrama de entidade e relacionamento
Segundo Piva e Oliveira (2010), O DER é o diagrama de documentação do banco de dados relacionais, é responsável por mostrar de maneira gráfica (através de diagramas) os relacionamentos entre as entidades no banco de dados. Ainda em conformidade com Piva e Oliveira (2010), o DER é composto por poucos elementos gráficos, os principais são: Retângulo – representa uma entidade do banco de dados; Losango – representa um relacionamento entre duas entidades do banco; Círculos – representam os atributos de uma entidade; Triangulo – representam especializações de uma entidade. Logo abaixo na Figura 3, segue um exemplo simples de DER.
Figura 3: Exemplo de um diagrama de entidade e relacionamento
5.4
Meta heurística GRASP
GRASP – Greedy Randomized Adaptive Search Procedure é um algoritmo bastante utilizado em problemas que envolve otimização combinatória. Com diversos métodos para construção, o algoritmo de GRASP constrói uma solução inicial baseado em três tipos de geração: Gulosa, aleatória e adaptativa. Depois que a solução inicial é gerada, o próximo procedimento é uma busca local, a procura de uma solução melhor que a inicialmente encontrada. Segundo Rocha (2013), algoritmos totalmente aleatórios conseguem obter soluções diversificadas, porém no geral são soluções ruins. Entretanto algoritmos gulosos tendem a gerar soluções de melhor qualidade, mas não conseguem produzir soluções diversificadas devido a sua natureza, nesse sentido, para encontrar boas soluções, uma meta
heurística
precisa
de
duas
características
importantes:
diversificação
e
intensificação, na qual a meta heurística GRASP se encaixa.
22
6
ATIVIDADES DESENVOLVIDAS
6.1
Levantamento bibliográfico – duração: 10 horas Nesta etapa foi realizado um levantamento geral da bibliografia a ser utilizada, tal
como livros, revistas, artigos, dentre outros documentos e sites de origem nacional e internacional. Através do levantamento bibliográfico, foi possível identificar quais os principais aspectos a serem levados em consideração quanto à análise e projeção do sistema a ser desenvolvido, ao mesmo tempo em que se foi necessário um profundo levantamento sobre algoritmos que atualmente são utilizados pelos desenvolvedores para a geração automática da tabela de horários. 6.2
Levantamento de requisitos do sistema – duração: 10 horas O levantamento de requisitos foi a segunda etapa realizada durante o período
referente à prática. As técnicas utilizadas para o levantamento dos requisitos foram: Entrevista, pesquisa e observação pessoal, essas são as técnicas mais indicadas pelos engenheiros de software. - Entrevista A técnica foi abordada com o professor e coordenador do curso de Sistemas de Informação Junior Marcos Bandeira, que descreveu todo o problema que atualmente a Faculdade de Balsas vivencia na geração dos horários docentes, sendo que boa parte dos requisitos funcionais e não funcionais foram levantados através dessa entrevista. - Pesquisa A técnica de pesquisa foi utilizada com auxilio do levantamento bibliográfico realizado anteriormente, alguns softwares que realizam uma tarefa próxima ao que se deseja foram testados e a partir daí listados os pontos fortes para auxílio na determinação dos requisitos funcionais e não funcionais. - Observação pessoal A técnica de observação pessoal se deu pelo fato de que durante o início de semestre, desde que a Faculdade de Balsas foi fundada, os coordenadores dos cursos têm dificuldades na geração dos horários acadêmicos. Através de tal observação, foi
23
possível compreender parte do problema e da necessidade de existência de um software que o resolva. Alguns dos requisitos funcionais e não funcionais mais importantes serão listados logo abaixo por meio de tabelas, entretanto todos os requisitos levantados serão documentados e poderão ser encontrados na documentação do software. Os requisitos listados nas tabelas abaixo estão identificados por duas abreviações PRFXX, onde PRF significa principais requisitos funcionais e XX indica a numeração do requisito, e a abreviação PRNFXX também é utilizada, onde PRNF significa principais requisitos não funcionais e XX indica a numeração do requisito.
Principais requisitos funcionais
Identificação
Descrição
PRF01
O software deverá realizar o cadastro de cursos, turmas, professores, disciplinas e usuários.
PRF02
O software deverá ter a opção de importação de cadastros (cursos, turmas, professores, disciplinas e usuários), através de documentos de texto.
PRF03
O software deverá permitir que um usuário com acesso padrão, realize a geração automática de horários docentes.
PRF04
O software deverá permitir que o usuário edite e/ou salve o horário gerado.
PRF05
O software deverá permitir atualização e exclusão de cursos, turmas, professores, disciplinas, usuários e horários salvos.
Tabela 2: Principais requisitos funcionais do sistema
Principais requisitos não funcionais
Identificação
Descrição
PRNF01
O software deverá gerar a tabela de horários em no máximo 5 minutos, caso contrário deverá abortar a operação e informar ao usuário que não pode finalizar a geração.
PRNF02
O software deverá ter alta disponibilidade e funcionar na web.
PRNF03
Os usuários só terão acesso às funcionalidades do sistema, se os mesmos estiverem autenticados.
PRNF04
O software deverá ser desenvolvido na linguagem JAVA EE, utilizando o SGBD MySQL.
PRNF05
A documentação online incluirá tutoriais, para auxiliar os usuários.
Tabela 3: Principais requisitos não funcionais do sistema
24
6.3
Estudo e montagem de diagramas de UML – duração: 15 horas Dois tipos de diagramas de UML foram escolhidos para projetar o software,
diagrama de caso de uso e diagrama de classe. Para a construção desses diagramas utilizou-se a ferramenta de modelagem Astah2. Foi criado um diagrama de caso de uso com o objetivo de demonstrar as funcionalidades gerais do sistemas, a partir desse diagrama, outros foram criados com o objetivo de detalhar pequenos casos de uso do diagrama geral. Logo abaixo, na figura 4, está uma imagem do diagrama de caso de uso geral do sistema, entretanto para melhor visualização a imagem está disponível nos anexos deste trabalho.
Figura 4 Diagrama de caso de uso para visão geral do sistema
2
Site oficial da ferramenta Astah: (www.astah.net)
25
A partir do diagrama de caso de uso para visão geral do sistema, outros diagramas foram criados com o objetivo de realizar um maior detalhamento das funcionalidades e limites do sistema. Segue algumas imagens dos principais casos de uso citados anteriormente, para melhor visualização, as imagens podem ser encontradas nos anexos deste trabalho.
Detalhamento caso de uso: Acessar Sistema
Figura 5: Caso de uso: Acessar Sistema
Detalhamento caso de uso: Importar Dados
Figura 6: Caso de uso: Importar Dados
26
Detalhamento caso de uso: Manter Cursos
Figura 7: Caso de uso: Manter Cursos
Os outros diagramas de caso de uso podem ser encontrados nos anexos deste trabalho. O diagrama de classe também foi projetado, as classes estabelecidas são: Tutoriais, UsuarioPadrao, Horario, Administrador, Curso, Turma, Disciplina e Professor. O diagrama de classes geral do sistema está disponível para visualização no anexo 9.11.
6.4
Estudo e montagem de DER – duração: 5 horas Nesta etapa foi realizado um estudo breve sobre DER, com o objetivo de identificar
as entidades que serão utilizadas no banco de dados e os seus relacionamentos. As entidades principais do banco de dados serão descritas logo abaixo. O diagrama DER, está disponível para visualização no anexo 9.1.
Entidades do banco de dados: Curso – Turma – Disciplina – Professor – HorarioDisponivel – Horario – Usuario - Tutoriais
Para construir o diagrama utilizou-se a ferramenta BRModelo3, que segundo o site oficial é uma ferramenta freeware voltada para o ensino de modelagem em banco de
3
Site oficial da ferramenta BRModelo: (www.sis4.com/brModelo)
27
dados relacionais. Para modelagem do banco de dados foi necessário a definição das entidades responsáveis, seus atributos e as devidas relações entre as tabelas ou entidades. Infelizmente a ferramenta BRModelo é limitada quanto a plataforma em que será executada, o site oficial disponibilizou somente o aplicativo compatível com o sistema operacional Windows. Por esse motivo foi necessário a utilização de outra ferramenta para realizar a emulação do BRModelo no sistema operacional Linux, a ferramenta utilizada para emulação é conhecida como Wine4. 6.5
Estudo e levantamento de algoritmos já existentes utilizados para solucionar o problema da geração do horário docente e proposta de um algoritmo a ser utilizado no sistema – duração: 20 horas O processo de estudo e levantamento de algoritmos já existentes para solucionar o
problema da tabela de horários docentes, pode ser considerado uma das principais atividades realizadas ao longo deste projeto. Tendo em vista que o principal problema a ser resolvido com a implantação do sistema é a geração da tabela de horários docentes. Por ser um problema NP – Completo, uma solução exata somente funcionaria com instâncias pequenas, o que não é o caso da Faculdade de Balsas. Por esse motivo, optou-se por utilizar uma solução aproximada, através de uma meta heurística. Diversos algoritmos foram estudados, a fim de encontrar qual melhor se enquadra nos requisitos levantados e nas restrições consideradas para a geração da tabela. A meta heurística GRASP foi considerada a melhor opção para a solução do problema. O algoritmo de GRASP funciona como uma busca adaptativa utilizando um paradigma guloso aleatório, capaz de criar diversas soluções que atendam as restrições fortes e algumas ou todas as restrições fracas. O funcionamento do algoritmo pode ser visualizado no pseudocódigo representado pela figura 8 logo abaixo.
4
Site oficial da ferramenta Wine: (www.winehq.org)
28
Figura 8 Pseudocódigo funcionamento GRASP Fonte: ROCHA, 2013, p. 29.
O algoritmo gera uma solução inicial de boa qualidade para que logo após realize uma busca local, com o objetivo de gerar outras soluções com maior qualidade. O GRASP não especifica como será gerada uma solução inicial, nem a busca realizada após a solução inicial gerada. Por esse motivo também propôs-se que para a geração da solução inicial uma estratégia chamada Hill Climbing, onde seu objetivo é explorar a vizinhança enquanto são encontradas melhores soluções. 6.6
Elaboração da documentação do software – duração: 20 horas
Nesta etapa foi iniciada a documentação dos requisitos do software. Todos os requisitos funcionais e não funcionais serão descritos no documento, ressaltando suas prioridades, atores, entradas e saídas para cada caso de uso informado. O documento será subdividido em 3 seções: 1ª Seção: Especificará a descrição geral do sistema, publico alvo, objetivo, etc. 2ª Seção: Especificará todos os requisitos funcionais levantados do sistema. 3ª Seção: Especificará todos os requisitos não funcionais levantados do sistema. Observou-se que a documentação dos requisitos do sistema é de fundamental importância para o projeto do software, desde a organização à melhoria em diversos aspectos, como por exemplo, a facilidade que o desenvolvedor do sistema terá em entender funcionalidades e realizar a codificação. A documentação dos requisitos pode ser consultada no anexo 9.12.
29
7
CONCLUSÃO A análise e projeto de sistemas é uma área bastante importante para o
desenvolvimento de softwares, tendo em vista que a qualidade em que um software desempenha suas funcionalidades é o principal fator contribuidor para uma empresa que utiliza a solução. Ao longo do período referente a este projeto, algumas atividades realizadas tiveram destaque pelo fato de sua extrema importância no desenvolvimento de softwares. O correto levantamento de requisitos é uma atividade essencial para que uma solução esteja qualificada e resolva com eficiência um determinado problema, ao mesmo tempo em que a utilização de diagramas de UML e DER para projetar as funcionalidades de um sistema, garantem uma visão ampla da solução a ser definida e do problema a ser resolvido. O estudo e análise da complexidade de vários algoritmos para resolver o problema
da
tabela
de
horários
proporcionaram
um
conhecimento
bastante
diversificado em relação ao desenvolvimento de outros algoritmos e consequentemente soluções. Neste mesmo sentido a realização da documentação dos requisitos levantados, também mostrou relevância no âmbito da qualidade de um software. Observou-se neste projeto, que o sistema proposto solucionará um problema que muitas outras instituições de ensino, não somente a Faculdade de Balsas, convivem periodicamente. Demonstrando que a aplicação a ser desenvolvida em etapas futuras, poderá servir como base para uma solução genérica e com alcance internacional.
30
8
REFERÊNCIAS
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML: Um guia prático para modelagem de sistemas orientados a objetos através da Linguagem de Modelagem Unificada. 2ª ed, Rio de Janeiro: Elsevier, 2007. BLOG CMMI. Levantamento de requisitos: Visão prática do que você deve saber. Disponível
em:
. Acessado em: 02 de Maio de 2015. CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução à engenharia de software. Campinas: Unicamp, 2001. DEVMEDIA.
Modelo
Entidade
Relacionamento
(MER)
e
Diagrama
Entidade-
Relacionamento (DER). Disponível em: . Acessado em 03 de Maio de 2015. FALBO,
Ricardo
de
Almeida.
Engenharia
de
Requisitos.
Disponível
.
em:
UFES
–
Universidade Federal de Espírito Santo, 2012. Acessado em 10 de Maio de 2012. IMASTERS.
Documentação
de
Projetos
Web
–
DER.
Disponível
em:
. Acessado em 03 de Maio de 2015. JUNIOR, Delmir Peixoto de Azevedo; CAMPOS, Renato. Definição de requisitos de software baseada numa arquitetura de modelagem de negócios. Disponível em: . Acessado em: 02 de Maio de 2015. LIMA, Alexandre Maia. Implementando gerência de projetos baseado no modelo MPS.BR no desenvolvimento de um software gerenciador de escritórios de advocacia. Gurupi: Fundação UNIRG – TO, 2007.
PIVA, Gustavo Dibbern; OLIVEIRA, Wilson José de. Informática:
Análise e
gerenciamento de dados. 3ª ed, São Paulo: Fundação Padre Anchieta, 2010. PRESSMAN, Roger S. Engenharia de Software: Uma abordagem profissional. 7ª ed, Porto Alegre, 2011. PROFISSIONAIS TI. Levantamento de Requisitos: Você sabe o que é?. Disponível em: . Acessado em: 02 de Maio de 2015. REZENDE, Denis Alcides. Engenharia de Software e sistemas de informação. 3ª ed, Rio do Janeiro, 2005. ROCHA, Walace de Souza. Algoritmo GRASP para o Problema de Tabela-horário de Universidades. Espirito Santo: Universidade Federal do Espírito Santo - ES, 2013. WIDJAJA, Anthony. The Limits of Computation. Melbourne University, 2004. Disponível em: < http://homepages.inf.ed.ac.uk/v1awidja/papers/comp.pdf >. Acessado em: 11 de Maio de 2015.
9
ANEXOS
Anexo 9.1
DER - Diagrama de entidade e relacionamento do banco de dados
Anexo 9.2
Diagrama de caso de uso para visão geral do sistema
Anexo 9.3
Diagrama de caso de uso: Acessar Sistema
Anexo 9.4
Diagrama de caso de uso: Importar Dados
Anexo 9.5
Diagrama de caso de uso: Manter Cursos
Anexo 9.6
Diagrama de caso de uso: Manter Disciplinas
Anexo 9.7
Diagrama de caso de uso: Manter Professores
Anexo 9.8
Diagrama de caso de uso: Manter Turmas
Anexo 9.9
Diagrama de caso de uso: Manter Usuario Comum
Anexo 9.10 Diagrama de caso de uso: Visualizar Informações Gerais
Anexo 9.11 Diagrama de classes: Visão geral do sistema
Anexo 9.12 Documento de requisitos do sistema UBHorários
Documento de Requisitos UBHorários
Versão 1.0 - Maio de 2015
Documento de Requisitos
Ficha Técnica Equipe Responsável pela Elaboração Jadson José Monteiro Oliveira Acadêmico do curso de Sistemas de Informação Público Alvo Este manual destina-se aos stakeholders do projeto, tais como coordenadores, que é o público-alvo do software, desenvolvedores e aos alunos que posteriormente queiram utilizar o projeto como guia ou base para outros projetos, ou até mesmo implementar o projeto aqui documentado.
Versão 1.0 – Balsas - MA, Maio de 2015 Dúvidas, críticas e sugestões devem ser encaminhadas por escrito para o seguinte endereço eletrônico:
[email protected] Recomendamos que o assunto seja identificado com o título desta obra. Alertamos ainda para a importância de se identificar o endereço e o nome completos do remetente para que seja possível o envio de respostas.
Documento de Requisitos
Sumário INTRODUÇÃO ......................................................................................................... P2 Visão geral deste documento .............................................................................................P2 Convenções, termos e abreviações ....................................................................................P2 1.Identificação dos Requisitos......................................................................................P2 2.Prioridades dos Requisitos ........................................................................................P2 Referências ..........................................................................................................................P2
CAPÍTULO 1 - DESCRIÇÃO GERAL DO SISTEMA ....................................... C1 . P2 Abrangência e sistemas relacionados........................................................................ C1 . P2 Descrição dos usuários............................................................................................... C1 . P2 1.Usuario Comum ................................................................................................ C1 . P2 2.Usuario Padrao ................................................................................................. C1 . P2 3.Administrador… ................................................................................................ C1 . P2
CAPÍTULO 2 - REQUISITOS FUNCIONAIS (CASOS DE USO) ..................... C2 . P2 Visão Geral do Sistema ............................................................................................... C2 . P2 [RF001] Acessar Sistema..................................................................................... C2 . P2 [RF002] Listar Horário .......................................................................................... C2 . P2 [RF003] Excluir Horário ........................................................................................ C2 . P2 [RF004] Editar Horário ......................................................................................... C2 . P2 [RF005] Gerar Horário ......................................................................................... C2 . P2 [RF006] Salvar Horário ........................................................................................ C2 . P2 [RF007] Visualizar Informações Gerais do Sistema .............................................. C2 . P2 [RF008] Manter Cursos ........................................................................................ C2 . P2 [RF009] Manter Turmas ....................................................................................... C2 . P2 [RF010] Manter Usuário Padrão ........................................................................... C2 . P2 [RF011] Manter Professores ................................................................................ C2 . P2 [RF012] Manter Disciplinas .................................................................................. C2 . P2 [RF013] Importar Dados....................................................................................... C2 . P2
CAPÍTULO 3 - REQUISITOS NÃO FUNCIONAIS ........................................... C3 . P2
Versão 1.0
Maio/2015
Documento de Requisitos
Usabilidade .................................................................................................................. C3 . P2 [NF001] Facilidade de uso ................................................................................... C3 . P2 Confiabilidade .............................................................................................................. C3 . P2 [NF001] Backup automático realizado regularmente ............................................ C3 . P2 Desempenho ................................................................................................................ C3 . P2 [NF001] Gerar tabela de horário em no máximo 5 minutos................................... C3 . P2 Segurança .................................................................................................................... C3 . P2 [NF001] Credenciais criptografadas ..................................................................... C3 . P2 Hardware e software .................................................................................................... C3 . P2 [NF001] Adaptabilidade a vários navegadores...................................................... C3 . P2
Versão 1.0
Maio/2015
Documento de Requisitos
Introdução – P1 / 1
Introdução Este documento especifica o sistema UBHorários, fornecendo aos desenvolvedores as informações necessárias para o projeto e implementação, assim como para a realização dos testes e homologação do sistema.
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, além de conter uma lista de referências para outros documentos relacionados. As demais seções apresentam a especificação do sistema UBHorários e estão organizadas como descrito abaixo. Seção 2 – Descrição geral do sistema: apresenta uma visão geral do sistema, caracterizando qual é o seu escopo e descrevendo seus usuários. Seção 3 – Requisitos funcionais (casos de uso): especifica todos os requisitos funcionais do sistema, descrevendo os fluxos de eventos, prioridades, atores, entradas e saídas de cada caso de uso a ser implementado. 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.
Convenções, termos e abreviações A correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos, que são descritos a seguir.
1. Identificação dos Requisitos Por convenção, a referência a requisitos é feita através do nome da subseção onde eles estão descritos, seguido do identificador do requisito, de acordo com o esquema abaixo: [nome da subseção.identificador do requisito] Por exemplo, o requisito [Visão Geral do Sistema.RF001] está descrito em uma subseção chamada “Visão Geral do Sistema”, em um bloco identificado pelo número [RF001]. Já o requisito não funcional [Confiabilidade.NF001] está descrito na seção de requisitos não funcionais de Confiabilidade, em um bloco identificado por [NF001].
2. Prioridades dos Requisitos Para estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável”. Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente.
Documento de Requisitos
Introdução – P2 / 2
Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim. Desejável é o 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 deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.
Documento de Requisitos
Descrição geral do sistema – C1. P1 / 1
Capítulo
Descrição geral do sistema
1
O sistema UBHorários tem como principal objetivo, realizar de forma automática a geração da tabela de horários docentes da Faculdade de Balsas. Beneficiando principalmente os coordenadores dos cursos da Instituição de Ensino, que atualmente são responsáveis por tal função. Para a geração da tabela de horários docentes, o sistema utilizará uma meta heurística conhecida por GRASP – Greedy Randomized Adaptive Search Procedure, que basicamente construirá soluções diversificadas e com boa qualidade. A meta heurística funciona da seguinte forma: Primeiramente é gerada uma solução inicial utilizando uma busca gulosa e aleatória, logo após será realizado uma busca local para tentar encontrar soluções com qualidade melhor que a primeira gerada, caso encontre, a atual solução será substituída pela encontrada na busca local. O sistema funcionará na web, aumentando a acessibilidade para com os usuários. Logo abaixo segue uma imagem representando o diagrama de caso de uso da visão geral do sistema.
Versão 1.0
Maio / 2015
Documento de Requisitos
Descrição geral do sistema – C1. P2 / 2
Abrangência e sistemas relacionados O sistema UBHorários terá como principal objetivo realizar a geração automática dos horários docentes da Faculdade de Balsas. Sendo assim deverá ser capaz de realizar o cadastro de cursos, turmas, professores, disciplinas, além de realizar a importação dos dados através de um documento de texto
Descrição dos usuários 1. Usuario Comum Poderá acessar o endereço do sistema, porem só terá acesso a tela de login.
2. Usuario Padrao Será responsável pela manutenção dos horários docentes e poderá visualizar as informações gerais do sistema, como versão, tutoriais, etc.
3. Administrador Será responsável pela manutenção e controle dos dados do sistema, desde o cadastro e importação de dados ao controle de usuários.
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P1 / 1
Capítulo
Requisitos funcionais (casos de uso)
2
Visão Geral do Sistema Esta subseção definirá os requisitos gerais do sistema, desde o acesso ao mesmo, até a manutenção dos dados do mesmo.
[RF001] Acessar Sistema Ator: Usuario Comum, Usuario Padrao e Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá acessar o sistema.
Fluxo de eventos principal O usuário deverá digitar suas credenciais (usuário e senha) e depois clicar em entrar.
Fluxos secundários (alternativos e de exceção) Credenciais inválidas Caso o usuário digite suas credencias erradas o sistema irá exibir uma mensagem de credenciais invalidas.
Enviar e-mail de recuperação Caso o usuário esqueça suas credencias, o mesmo poderá solicitar um e-mail de recuperação.
[RF002] Listar Horário Ator: Usuario Padrao e Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário listará os horários docentes já cadastrados.
Fluxo de eventos principal O caso de uso inicia quando o usuário clicar na opção listar horários cadastrados.
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P2 / 2
[RF003] Excluir Horário Ator: Usuario Padrao e Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário excluirá os horários docentes já cadastrados.
Fluxo de eventos principal O caso de uso inicia quando o usuário após listar e selecionar um determinado usuário clica no botão excluir horário
[RF004] Editar Horário Ator: Usuario Padrao e Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá editar os horários docentes já cadastrados.
Fluxo de eventos principal O caso de uso inicia após o usuário ter listado e selecionado determinado horário e clicado no botão editar horário.
[RF005] Gerar Horário Ator: Usuario Padrao e Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá gerar os horários docentes já cadastrados.
Fluxo de eventos principal Este fluxo inicia após o usuário estar logado no sistema e clicar no botão gerar horário
Fluxos secundários (alternativos e de exceção) Tempo limite excedido Caso o sistema demore mais de 5 minutos para gerar o horário docente, o sistema exibirá uma mensagem informando que não pode gerar o horário docente e que o tempo limite foi excedido.
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P3 / 3
[RF006] Salvar Horário Ator: Usuario Padrao e Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá gerar os horários docentes já cadastrados.
Fluxo de eventos principal Este caso de uso inicia após o usuário ter gerado um horário docente e o mesmo ter clicado na opção salvar horário.
[RF007] Visualizar Informações Gerais do Sistema Ator: Usuario Padrao e Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário visualizará as informações gerais do sistema.
Fluxo de eventos principal Este caso de uso inicia quando o usuário clicar no botão visualizar informações gerais do sistema.
Fluxos secundários (alternativos e de exceção) Listar tutorial O usuário terá a opção de listar os tutoriais disponíveis no sistema
Imprimir Tutorial Após listar um determinado tutorial, o usuário terá a opção de imprimir o mesmo.
[RF008] Manter Cursos Ator: Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá manter os cursos no sistema
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P4 / 4
Fluxo de eventos principal O caso de uso inicia quando o usuário clicar no botão manter cursos.
Fluxos secundários (alternativos e de exceção) Cadastrar Curso O usuário terá a opção de cadastrar cursos no sistema
Listar Curso O usuário terá a opção de listar todos os cursos cadastrados no sistema
Excluir Curso O usuário terá a opção de excluir um determinado curso listado no sistema
Editar Curso O usuário terá a opção de editar um determinado curso listado no sistema
Descartar Alterações O usuário terá a opção de descartar as alterações após editar um determinado curso listado no sistema
Salvar Alterações O usuário terá a opção de salvar as alterações após editar um determinado curso listado no sistema
Curso já cadastrado O sistema exibira uma mensagem de erro após o usuário tentar inserir um curso já existente.
[RF009] Manter Turmas Ator: Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá manter as turmas no sistema
Fluxo de eventos principal O caso de uso inicia quando o usuário clicar no botão manter turmas.
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P5 / 5
Fluxos secundários (alternativos e de exceção) Cadastrar Turma O usuário terá a opção de cadastrar turmas no sistema
Listar Turma O usuário terá a opção de listar todas as turmas cadastradas no sistema
Excluir Turma O usuário terá a opção de excluir uma determinada turma listada no sistema
Editar Turma O usuário terá a opção de editar uma determinada turma listada no sistema
Descartar Alterações O usuário terá a opção de descartar as alterações após editar uma determinada turma listada no sistema
Salvar Alterações O usuário terá a opção de salvar as alterações após editar uma determinada turma listada no sistema
Turma já cadastrada O sistema exibira uma mensagem de erro após o usuário tentar inserir uma turma já existente.
[RF010] Manter Usuário Padrão Ator: Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá manter os usuários padrões no sistema
Fluxo de eventos principal O caso de uso inicia quando o usuário clicar no botão manter usuários padrões.
Fluxos secundários (alternativos e de exceção) Cadastrar Usuário Padrao O usuário terá a opção de cadastrar usuários padrões no sistema
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P6 / 6
Listar Usuário Padrao O usuário terá a opção de listar todos os usuários padrões cadastrado no sistema
Excluir Usuário Padrao O usuário terá a opção de excluir um determinado usuário padrão listado no sistema
Editar Usuário O usuário terá a opção de editar um determinado usuário padrão listado no sistema
Descartar Alterações O usuário terá a opção de descartar as alterações após editar um determinado usuário padrão listado no sistema
Salvar Alterações O usuário terá a opção de salvar as alterações após editar um determinado usuário padrão listado no sistema
Usuário Padrão já cadastrado O sistema exibira uma mensagem de erro após o usuário tentar inserir um usuário padrão já existente.
[RF011] Manter Professores Ator: Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá manter os professores no sistema
Fluxo de eventos principal O caso de uso inicia quando o usuário clicar no botão manter professores.
Fluxos secundários (alternativos e de exceção) Cadastrar Professor O usuário terá a opção de cadastrar professores no sistema
Listar Professor O usuário terá a opção de listar todos os professores cadastrados no sistema
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P7 / 7
Excluir Professor O usuário terá a opção de excluir um determinado professor listado no sistema
Editar Professor O usuário terá a opção de editar um determinado professor listado no sistema
Descartar Alterações O usuário terá a opção de descartar as alterações após editar um determinado professor listado no sistema
Salvar Alterações O usuário terá a opção de salvar as alterações após editar um determinado professor listado no sistema
Professor já cadastrado O sistema exibira uma mensagem de erro após o usuário tentar inserir um professores já existente.
[RF012] Manter Disciplinas Ator: Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá manter as disciplinas no sistema
Fluxo de eventos principal O caso de uso inicia quando o usuário clicar no botão manter disciplinas.
Fluxos secundários (alternativos e de exceção) Cadastrar Disciplina O usuário terá a opção de cadastrar disciplinas no sistema
Listar Disciplina O usuário terá a opção de listar todas as disciplinas cadastradas no sistema
Excluir Disciplina O usuário terá a opção de excluir uma determinada disciplina listada no sistema
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos funcionais – C2. P8 / 8
Editar Disciplina O usuário terá a opção de editar uma determinada disciplina listada no sistema
Descartar Alterações O usuário terá a opção de descartar as alterações após editar uma determinada disciplina listada no sistema
Salvar Alterações O usuário terá a opção de salvar as alterações após editar uma determinada disciplina listada no sistema
Disciplina já cadastrada O sistema exibira uma mensagem de erro após o usuário tentar inserir um disciplina já existente.
[RF013] Importar Dados Ator: Administrador Prioridade:
Essencial
Importante
Desejável
Descrição do requisito: Este requisito é responsável por definir e descrever como o usuário irá importar dados no sistema
Fluxo de eventos principal O caso de uso inicia quando o usuário escolhe a opção importar dados no sistema.
Fluxos secundários (alternativos e de exceção) Erro na importação A exceção ocorre se o usuário importar algum arquivo no formato errado ou formatado incorretamente.
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos não funcionais – C3. P1 / 1
Capítulo
Requisitos não funcionais
3
Usabilidade Esta seção descreve os requisitos não funcionais associados à facilidade de uso da interface com o usuário, material de treinamento e documentação do sistema.
[NF001] Facilidade de uso Um novo usuário deverá ser capaz de utilizar as principais funcionalidades do sistema após não mais que 30 minutos de orientação. Prioridade:
Essencial
Importante
Desejável
Confiabilidade Esta seção descreve os requisitos não funcionais associados à frequência, severidade de falhas do sistema e habilidade de recuperação das mesmas, bem como à corretude do sistema.
[NF001] Backup automático realizado regularmente O sistema deverá ser composto por um mecanismo capaz de realizar o backup dos dados automaticamente. Prioridade:
Essencial
Importante
Desejável
Desempenho Esta seção descreve os requisitos não funcionais associados à eficiência, uso de recursos e tempo de resposta do sistema.
[NF001] Gerar tabela de horário em no máximo 5 minutos O sistema deverá gerar a tabela de horários em no máximo 5 minutos. Por ser um problema NP – Completo este tempo é razoavelmente pequeno. Prioridade:
Essencial
Importante
Desejável
Segurança Esta seção descreve os requisitos não funcionais associados à integridade, privacidade e autenticidade dos dados do sistema.
Versão 1.0
Maio / 2015
Documento de Requisitos
Requisitos não funcionais – C3. P2 / 2
[NF001] Credenciais criptografadas Todas as credenciais dos usuários, principalmente a senha para acesso, deverão ser criptografadas no banco de dados. Prioridade:
Essencial
Importante
Desejável
Hardware e software Esta seção descreve os requisitos não funcionais associados ao hardware e software usados para desenvolver ou para executar o sistema.
[NF001] Adaptabilidade a vários navegadores Por se tratar de um sistema web, o mesmo deverá ser responsivo. Podendo ser visualizado corretamente nos seguintes navegadores: Google Chrome – versão 42.0.2311.135 ou superior; Mozilla Firefox – versão 38.0 ou superior; Internet Explorer – versão 9.0 ou superior. Prioridade:
Versão 1.0
Essencial
Importante
Desejável
Maio / 2015
