UNIVERSIDADE FEDERAL DE PERNAMBUCO

FANNY CHIEN LEONARDO LOPES MARQUES COUTINHO

SARAH CRISTINA SILVA CRUZ THAÍS FREIRE CAVALCANTE

ESPECIFICAÇÃO DE REQUISITOS Matrícula da Pós­Graduação

Recife 2015

2

FANNY CHIEN LEONARDO LOPES MARQUES COUTINHO

SARAH CRISTINA SILVA CRUZ THAÍS FREIRE CAVALCANTE

ESPECIFICAÇÃO DE REQUISITOS Matrícula da Pós­Graduação

Projeto da disciplina de Especificação de Requisitos e Validação de Sistemas com o objetivo de capturar informações e analisar os requisitos do processo de matrícula da pós­graduação do Centro de Informática da UFPE.

Recife 2015

3

SUMÁRIO

1 INTRODUÇÃO …………………………………………………………………………….4

2 MODELAGEM DE PROCESSOS DE NEGÓCIO ……………………………………..7

3 REQUISITOS ORGANIZACIONAIS …………………………………………………..14

4 REQUISITOS­NÃO FUNCIONAIS …………………………………………………….17

4.1. Requisitos não­funcionais do produto ………………………………………….17

4.1.1 Segurança …………………………………………………………………...17

4.1.2 Performance ………………………………………………………………....18

4.1.3 Usabilidade …………………………………………………………………..19

4.2. Requisitos não­funcionais do processo ………………………………………..19

4.3. Requisitos não­funcionais externos …………………………………………....20

5 REQUISITOS FUNCIONAIS …………………………………………………………...22

6 COMPORTAMENTO …………………………………………………………………....25

7 CONCLUSÃO ……………………………………………………………………………27

REFERÊNCIAS …………………………………………………………………………....28

Apêndice A ­ Regimento interno da pós­graduação …………………………………...29

Apêndice B ­ E­mail de pré­matrícula …………………………………………………...42

Apêndice C ­ Calendário de matrícula da pós­graduação …………………………….43

4

1 INTRODUÇÃO

O projeto visa capturar informações e analisar requisitos do processo de

matrícula da pós­graduação do Centro de Informática (CIn) da UFPE. Este processo

utiliza o sistema de pré­matrícula do CIn e também o SIGA, desenvolvido pelo Núcleo

de Tecnologia da Informação (NTI) e utilizado como principal mecanismo para

realização da matrícula. Porém, há diversas falhas durante o período de matrícula,

principalmente no que se diz respeito à pré­matrícula, pois não há um processo correto

a se seguir a cada semestre, ocorrendo anomalias como, por exemplo, um professor

utilizar o código de uma disciplina que normalmente é ministrada por outro. Para se ter

noção da dimensão do impacto da matrícula da pós­graduação, o CIn já formou mais

de 1.300 mestres e 190 doutores [2] , considerando a duração mínima de 12 meses para

o mestrado e 24 meses para o doutorado [7] , ou seja, o melhor caso, e sabendo que a

matrícula é realizada a cada 6 meses, durante esse tempo já houve no mínimo 3.360

matrículas feitas pelos mais diversos alunos da pós graudação ao longo de seus

cursos.

Atualmente, a pós­graduação do CIn é composta pelos cursos de mestrado e

doutorado em Ciência da Computação, sendo apoiada pela secretaria da

pós­graduação e formada pelos seguintes atores [7] :

Administração acadêmica do programa: por sua vez formada pela câmara de

pós­graduação da UFPE (coordenação central), pelo colegiado do programa

(envolvendo docentes permanentes, um discente representante do mestrado e

um discente representante do doutorado) e pela coordenação do programa

(formada por um coordenador e um vice­coordenador);

Comissão de pós­graduação do programa (CPG): composta pela coordenação e

um representante de cada área de concentracão ou seu suplente, indicados pela

maioria dos docentes da área e aprovados pelo colegiado.

Docentes: podendo ser permanentes, colaboradores ou visitantes.

5

Figura 1 ­ Descrição da organização da pós­graduação.

Para haver o entendimento da organização e funcionamento da pós­graduação,

principalmente no que se diz respeito ao processo de matrícula, foram feitas pesquisas

no site institucional, diversas entrevistas e o levantamento de documentos que dão

suporte ao entendimento do contexto. A princípio, foram feitas entrevistas na secretaria

da pós­graduação com as funcionárias Maria do Socorro Chaves de Oliveira

(msco@cin.ufpe.br) e Maria Lilia Pinheiro de Freitas (mlpf@cin.ufpe.br), tanto para

entender o processo, quanto validar o que foi entendido e tirar dúvidas. Além disso, foi

possível receber instruções do vice­coordenador de pós­graduação, Jaelson Castro, ao

apresentar em sala de aula o processo mapeado utilizando BPMN (Notação de

Modelagem de Processos de Negócio) e ao entrevistá­lo a respeito do processo de

pré­matrícula. Por fim, também foi feita uma entrevista com o discente Renato Moura

Dantas (rmd2@cin.ufpe.br), mestrando do CIn, visto que os discentes podem ser

considerados clientes do processo de matrícula oferecido pela pós­graduação. Com

isso, foi possível fazer um levantamento de documentações que dão suporte ao

processo, presentes nos Apêndices A, B e C deste projeto.

A partir do entendimento da organização e funcionamento pós­graduação, foi

possível organizar o desenvolvimento deste projeto em seções que abordam processos

e requisitos da matrícula de mestrandos e doutorandos do Centro de Informática.

6

Sendo assim, em primeiro lugar a seção 2 trata dos processos de negócio, exibindo o

processo de matrícula mapeado utilizando BPMN. Em segundo lugar, a seção 3 trata

dos requisitos organizacionais, sendo utilizada a notação i* (iStar) para mostrar os

modelos de dependências estratégicas e razões estratégias. Além disso, a seção 4

aborda os requisitos não­funcionais, utilizando a modelagem com NFR framework . A

seção 5 apresenta os requisitos funcionais da matrícula através do Diagrama de Casos

de Uso. Por fim, a seção 6 apresenta o comportamento do sistema utilizando um

diagrama de estados (statechart) .

7

2 MODELAGEM DE PROCESSOS DE NEGÓCIO

A Modelagem de Processos de Negócio consiste em desenvolver diagramas

que representem as atividades em uma sequência de execução, permitindo entender o

funcionamento de processos de uma área de negócio ou de uma empresa como um

todo [3] . Sendo assim, é possível identificar no diagrama as is , isto é, o diagrama que

representa o processo da forma como é executado na atualidade, onde há ineficiência,

complexidade, redundâncias, anomalias, entre outros. Com isso, é possível sugerir

otimizações gerando um novo diagrama do processo denominado to be . Uma

abordagem amplamente utilizada nestes casos é o BPMN (Notação de Modelagem de

Processos de Negócio), também utilizado durante este projeto.

Ao realizar entrevistas e pesquisar o processo realizado para a matrícula da

pós­graduação, foi possível perceber que este processo não está claro, pois: as

atividades e suas sequências de execução não familiares para alguns colaboradores;

alguns documentos do regimento interno (Apêndice A) não foram nem ao menos

citados em entrevistas; há falha de comunicação entre atores; e hoje é um processo

composto por inúmeras anomalias, principalmente no que se diz respeito à alocação de

professores em disciplinas durante a pré­matrícula. Desta forma, foi desenvolvida a

modelagem de um processo to be a partir das informações coletadas e de sugestões

dadas pelo vice­coordenador da pós­graduação, Jaelson Castro, visando

principalmente facilitar a pré­matrícula ao remover o sistema anteriormente existente e

utilizar o histórico de ofertas para auxiliar na alocação de professores em disciplinas.

8

Figura 2 ­ Processo geral da pós­graduação.

9

Figura 3a ­ Processo to be da matrícula da pós­graduação.

10

Figura 3b ­ Processo to be da matrícula da pós­graduação.

11

Figura 3c ­ Processo to be da matrícula da pós­graduação.

12

Como foi possível perceber através do processo, é sugerido que no início da

matrícula a coordenação solicite ao SIGA o calendário acadêmico para que possa

saber os prazos do calendário. Após isso, ela irá solicitar o histórico das disciplinas

ofertadas para apenas confirmar com os professores a alocação em cada uma delas,

reduzindo a possibilidade de falhas durante esta etapa da pré­matrícula. Ao receber a

solicitação de confirmação, os professores irão confirmar a alocação, informando se

está irão manter ou alterar alguma informação. Sendo assim, ao receber a confirmação

dos professores, a coordenação irá disponibilizar a oferta das disciplinas no SIGA e

enviar um e­mail informando aos alunos que a matrícula está aberta. Ao receber o

e­mail, se o aluno não for veterano ele deverá entregar uma série de documentações

disponíveis no Anexo A (Art. 21), podendo então se matricular no SIGA. Caso o aluno

seja veterano, ele terá a opção de trancar o curso, que já envolve um outro sub

processo junto com o colegiado, ou então efetuar a matrícula no SIGA. Sendo assim,

será papel da secretaria receber os documentos entregues pelos alunos e verificar se

eles são válidos, cancelando a matrícula dos que não entregaram uma documentação

válida. Após essa etapa, a coordenação irá verificar a quantidade de alunos por

disciplina no SIGA, para saber se cada disciplina atingiu uma quantidade mínima de

alunos, cancelando no sistema as que não tiverem alcançado essa quantidade. Por fim,

a coordenação irá solicitar ao sistema a lista de disciplinas que serão ofertadas para

então enviar para a secretaria, pois assim será possível alocar as salas e finalizar o

processo.

Para demonstrar a descrição de tarefas utilizando o BPMN, as quatro tarefas a

seguir foram escolhidas para servirem de exemplo.

Tarefa Solicitar histórico de disciplinas ofertadas

Papel Coordenação

Participante SIGA

Procedimento O coordenador irá realizar o login no sistema SIGA e solicitar a visualização do histórico de disciplinas previamente ofertadas.

13

Tarefa Entregar documentos

Papel Aluno

Participante Secretaria

Saída Documentos de matrícula

Procedimento O aluno irá entregar na secretaria da pós­graduação os documentos descritos no Anexo A (Art. 21).

Tarefa Matricular no SIGA

Papel Aluno

Participante SIGA

Procedimento O aluno irá realizar o login no SIGA, atualizar seus dados caso necessário, escolher as disciplinas a serem cursadas no próximo semestre e finalizar a solicitação de matrícula.

Tarefa Alocar salas

Papel Secretaria

Entrada Lista de disciplinas ofertadas

Procedimento A secretaria irá visualizar a lista de disciplinas ofertadas e irá fazer a correspondência entre as salas e as disciplinas, levando em consideração os horários, o tamanho da turma e a capacidade da sala.

14

3 REQUISITOS ORGANIZACIONAIS

A consideração de requisitos organizacionais ao se tratar de sistemas

computacionais é de extrema importância, visto que os sistemas são desenvolvidos

para executar dentro de organizações. Dessa forma, é preciso avaliar as relações e

dependências entre os diversos atores da organização, avaliando quais objetivos

devem ser alcançados, quais atividades devem ser executadas e quais recursos devem

ser fornecidos (Modelo de Dependências Estratégicas). Além disso, de forma mais

aprofundada, também é necessário entender as razões ou motivações de cada ator

sobre suas metas ou relacionamentos com outros atores (Modelo de Razões

Estratégicas) [1] . A abordagem i* (iStar) utiliza o Modelo de Dependências Estratégicas

(RD) e o Modelo de Razões Estratégicas (SD) para situar sistemas dentro das

organizações, sendo utilizado durante este projeto.

15

Figura 4 ­ Modelo de Dependências Estratégicas da matrícula da pós­graduação

16

Figura 5 ­ Modelo de Razões Estratégicas da matrícula da pós­graduação

17

4 REQUISITOS­NÃO FUNCIONAIS

Requisitos não­funcionais descrevem as qualidades de sistemas que são

importantes para a comunidade de usuários e desenvolvedores. No caso da matrícula

da pós­graduação, é possível destacar os requisitos não funcionais abaixo [4] .

4.1. Requisitos não­funcionais do produto

4.1.1 Segurança

4.1.1.1 [NFR01] Disponibilidade

ID [NFR01] Disponibilidade

Descrição O sistema não deverá ficar indisponível, principalmente durante o período de matrícula, quando é amplamente utilizado. Dessa forma, ele deverá estar no ar 99% do tempo durante dias úteis ou em todo o período de matrícula.

Prioridade Essencial

4.1.1.2 [NFR02] Integridade

ID [NFR02] Integridade

Descrição Apenas os usuários com permissão poderão alterar o sistema

durante a matrícula. Essas permissões variam de acordo com

o perfil: aluno, secretaria ou coordenação.

Prioridade Essencial

18

4.1.1.3 [NFR03] Privacidade

ID [NFR03] Privacidade

Descrição Apenas os usuários com permissão poderão visualizar os

dados do sistema durante a matrícula. Essas permissões

variam de acordo com o perfil: aluno, secretaria ou

coordenação.

Prioridade Essencial

4.1.2 Performance

4.1.2.1 [NFR04] Tempo de resposta

ID [NFR04] Tempo de resposta

Descrição Nenhuma consulta deverá exceder o tempo de 10 segundos

de resposta, mesmo contando com um grande banco de

dados de disciplinas, professores e alunos.

Prioridade Essencial

4.1.2.2 [NFR05] Armazenamento

ID [NFR05] Armazenamento

Descrição O código executável do sistema está limitado a 512Kb.

Prioridade Essencial

19

4.1.2.3 [NFR06] Processamento

ID [NFR06] Processamento

Descrição O sistema deverá ser capaz de processar ao menos 10

solicitações de matrícula por segundo.

Prioridade Essencial

4.1.3 Usabilidade

4.1.3.1 [NFR07] Simplicidade

ID [NFR07] Simplicidade

Descrição A interface do sistema deverá ser simples para facilitar o

acesso de dados e para permitir o acesso rápido a todas as

suas funcionalidades.

Prioridade Essencial

4.2. Requisitos não­funcionais do processo

4.2.1 [NFR08] Utilizar a metodologia SCRUM

ID [NFR08] Utilizar a metodologia SCRUM

Descrição Os incrementos do sistema deverão ser desenvolvidos

segundo a metodologia ágil SCRUM.

Prioridade Essencial

20

4.2.2 [NFR09] Utilizar a linguagem JAVA

ID [NFR09] Utilizar a linguagem JAVA

Descrição Os incrementos do sistema deverão ser desenvolvidos

utilizando a linguagem de programação JAVA, visto que é

esta a linguagem de programação do sistema original.

Prioridade Essencial

4.3. Requisitos não­funcionais externos

4.3.1 [NFR10] Prazo de Entrega

ID [NFR10] Prazo de Entrega

Descrição Os incrementos do sistema devem ser entregues em até 40

dias úteis, já sendo utilizado durante a próxima matrícula.

Prioridade Essencial

Para representar sistematicamente e globalmente os requisitos não funcionais

de sistemas, foi criado o NFR framework . Dessa forma, é possível encontrar a

representação dos requisitos não­funcionais do sistema de matrícula da pós­graduação

na figura 5 da próxima página.

21

Figura 6 ­ NFR Framework do sistema de matrícula

22

5 REQUISITOS FUNCIONAIS

Para representar requisitos funcionais deste projeto, será utilizado o Diagrama

de Casos de Uso. Este diagrama descreve as principais funcionalidades de um sistema

proposto e a interação dessas funcionalidades com os usuários do sistema [6] . No caso

da matrícula da pós­graduação do Centro de Informática, o sistema a ser descrito é o

SIGA, através da sugestão algumas novas funcionalidades no sistema para que se

possa abstrair o sistema de pré­matrícula que possui diversas falhas atualmente.

Figura 7 ­ Diagrama de casos de uso do sistema de matrícula

Para demonstrar a descrição dos casos de uso, os exemplos a seguir foram

escolhidos.

23

ID [UC01] Matricular no SIGA

Descrição Caso de uso no qual o aluno logado realiza a sua matrícula no

SIGA.

Atores Aluno

Condições O aluno deverá estar devidamente logado no sistema SIGA

Fluxo Fornecimento de usuário e senha na página inicial do sistema

para autenticacão, depois deverá escolher a opção realizar

matrícula.

ID [UC02] Solicitar histórico de disciplinas ofertadas

Descrição Caso de uso no qual o Coordenador solicita a lista de horários

e disciplinas ofertadas nos semestres anteriores.

Atores Coordenação

Condições O Coordenador deverá estar devidamente logado no sistema

SIGA.

Fluxo Após a autenticação no sistema, o usuário deverá escolher no

menu de opções “Histórico de disciplinas ofertadas”.

24

ID [UC03] Cancelar matrícula

Descrição Caso de uso no qual a secretaria cancela a matrícula de um

aluno no sistema SIGA após verificar a documentação de

matrícula recebida.

Atores Secretaria

Condições O funcionário da Secretaria deverá estar devidamente logado

no sistema SIGA.

Fluxo Após a autenticação no sistema, o funcionário deverá

escolher no menu de opções “Cancelar matrícula”, e

selecionar o aluno matrículado que deverá ter sua matrícula

cancelada.

ID [UC04] Cancelar disciplina

Descrição Caso de uso no qual o coordenador do curso cancela a oferta

de uma disciplina no SIGA.

Atores Coordenação

Condições O Coordenador deverá estar devidamente logado no sistema

SIGA e ter Verificado se a quantidade de alunos por disciplina

está inferior ao pré­estabelecido.

Fluxo Após a autenticação no sistema, o coordenador deverá

escolher no menu de opções “Cancelar disciplina”, e

selecionar a disciplina que deverá ter sua oferta cancelada.

25

6 COMPORTAMENTO

Para descrever o comportamento do sistema, é possível utilizar um diagrama de

estados ( statechart ). Este diagrama também é conhecido como diagrama de transição

de estado ou como máquina de estados, permitindo modelar o comportamento interno

de um determinado objeto ou sistema. Dessa forma, o diagrama de estados é utilizado

para representar os possíveis estados de um objeto, as transições entre esses estados,

os eventos que fazem desencadear essas transições e as operações (ações e

atividades) que são executadas dentro de um estado ou durante uma transição. Sendo

assim, é possível acompanhar a evolução dos objetos ao longo do tempo, através de

um conjunto de estados que são consequências de eventos e da passagem de

tempo [5] . No caso do sistema que está sendo trabalhado neste projeto, o diagrama de

estados correspondente é demonstrado abaixo.

26

Figura 8 ­ Statechart do sistema de matrícula da pós­graduação

27

7 CONCLUSÃO

Através do desenvolvimento deste projeto, foi possível colocar em prática

conhecimentos obtidos durante a disciplina de Especificação de Requisitos e Validação

de Sistemas do Centro de Informática da UFPE. Essa simulação prática foi de

essencial importância para o aprendizado da equipe, principalmente tratando­se de

alunos da graduação sem tanta experiência de mercado na área de requisitos. Sendo

assim, foi possível capturar informações e analisar requisitos do processo de matrícula

da pós­graduação, entendendo todas as dificuldades vividas na prática durante cada

etapa da engenharia de requisitos.

Como resultado da realização deste projeto, houve um maior conhecimento da

organização e funcionamento da pós­graduação. Dessa forma, foi possível mapear os

processo de negócio utilizando o BPMN, analisar requisitos organizacionais utilizando a

notação i* (iStar), representar requisitos não funcionais através da modelagem com

NFR framework , representar requisitos funcionais através do diagrama de casos de uso

e, por fim, exibir o comportamento do sistema utilizando um diagrama de estados.

28

REFERÊNCIAS [1] CASTRO, Jaelson; ALENCAR, Fernanda. Uso de Modelagem Social na Engenharia de Requisitos . Disponível em: <http://www.cin.ufpe.br/~if716/arquivos/leitura/CASTRO­ALENCAR­UsoDeModelagemSocialNaEngenhariaDeRequisitos.pdf>. Acesso em: 13 jun. 2015. [2] CENTRO DE INFORMÁTICA (Org.). Sobre a Pós­Graduação. 2015. Disponível em: http://www2.cin.ufpe.br/site/secao.php?s=3&c=31. Acesso em: 10 jun. 2015 [3] LEAL, André Luiz de Castro; BRAGA, José Luis. Modelagem de Processos de Negócio: Uma abordagem baseada em Business Process Management Notation (BPMN), Business Process Execution Language (BPEL) e XML Process Definition Language (XPDL). Engenharia de Software Magazine , ed. 4, p.12­21. Disponível em: <http://www.devmedia.com.br/revista­engenharia­de­software­4/9868>. Acesso em: 13 jun. 2015. [4] International Institute Of Business Analysis (Org.). Um Guia para o Corpo de Conhecimento de Análise de Negócios : Guia BABOK. Toronto, 2011. p. 191. [5] RAMOS, Ricardo Argenton. UML: Diagramas de Estado, Atividades, Componentes e Instalação. 2013. Disponível em: <http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2013_1/UML_Aula3.pdf>. Acesso em: 18 jun. 2015. [6] RIBEIRO, Leandro. O que é UML e Diagramas de Caso de Uso: Introdução Prática à UML. Disponível em: <http://www.devmedia.com.br/o­que­e­uml­e­diagramas­de­caso­de­uso­introducao­pratica­a­uml/23408>. Acesso em: 16 jun. 2015. [7] UNIVERSIDADE FEDERAL DE PERNAMBUCO (Org.). Regimento interno do programa de pós­graduação em Ciência da Computação da Universidade Federal de Pernambuco. 2014. Disponível em: http://www2.cin.ufpe.br/site/uploads/arquivos/31/20150130163524_regimento2014publicadoBO.pdf. Acesso em: 12 jun. 2015.

29

Apêndice A ­ Regimento interno da pós­graduação

30

31

32

33

34

35

36

37

38

39

40

41

42

Apêndice B ­ E­mail de pré­matrícula ­­­­­­­­­­ Mensagem encaminhada ­­­­­­­­­­ De: Edna Natividade da Silva Barros < ensb@cin.ufpe.br > Data: 9 de junho de 2015 10:07 Assunto: [msc] [IMPORTANTE] ­ Pre­matrícula de disciplinas da pós­graduação 2015­2 Para: posgrad < posgrad@cin.ufpe.br >, docentes < docentes@cin.ufpe.br > Cc: Secretaria da Pos­Graduacao < posgraduacao@cin.ufpe.br >, Edna Natividade da Silva Barros < ensb@cin.ufpe.br >, Jaelson Castro < jbc@cin.ufpe.br > Pessoal, estamos iniciando o processo de pré­matricula para disciplinas da graduação e pós­graduação para o semestre 2015­2. Os alunos da pós­graduação que ainda precisam cursar disciplinas devem acessar o link abaixo e preencherem os dados com as disciplinas eletivas que desejam cursar em 2015.2. Os alunos da pós­graduação devem ser matricular apenas em disciplinas que tenham código começando por IN pois são disciplinas da pós­graduação. Os alunos de mestrado devem observar se a disciplina é eletiva básica ou eletiva especifica pois o regimento define o numero mínimo de disciplinas a serem cursadas para cada grupo. https://sistemas.cin.ufpe.br:8443/PreMatricula/ Prazo para o preenchimento: 12/06/2015 Atenciosamente, Edna e Jaelson

43

Apêndice C ­ Calendário de matrícula da pós­graduação

44