observatÓrio de projetos em empreendedorismo ... - ufpe

OBSERVATÓRIO DE PROJETOS EM EMPREENDEDORISMO UNIVERSITÁRIO (OPEU)

Projeto II: Especificação de Requisitos Funcionais e Não-Funcionais

Por: Edmilson Rodrigues Do Nascimento Junior - [email protected] Emmanuel Barreto De Carvalho - [email protected] Marvin Alexander Lopez Martinez - [email protected] Mateus Camara Pereira - [email protected] PROFESSOR: DR. JAELSON CASTRO - [email protected] DISCIPLINA IN 1020 - ENGENHARIA DE REQUISITOS

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CIN - CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

[email protected] www.cin.ufpe.br/~posgraduacao

RECIFE, Outubro de 2019

mailto:[email protected]

Resumo

A disciplina Projeto de Desenvolvimento, comumente apelidada de 'Projetão' pelos

alunos, é oferecida aos alunos do 5º período do curso de Ciência da Computação e 8º

período do curso de Engenharia da Computação da UFPE, e aos alunos do curso de

Design da UFPE. Ela tem como objetivo o desenvolvimento de um sistema de

computação que use conceitos aprendidos nos semestres anteriores dos cursos,

representando um marco do fim do ciclo básico. Os alunos são estimulados a

desenvolver sistemas multidisciplinares e a trabalhar em equipe. Este especifica os

Requisitos Funcionais e Não-Funcionais baseados no IEEE 830 SRS [IEE84] e IEEE

610.12 [IEE90], do Observatório de Projetos de Empreendedorismo Universitário

(OPEU), como solução proposta, funcional e já existente (www.opeu.com.br), para o

cenário relatado no Projeto I: Especificação de Requisitos da disciplina Projetão.

Palavras-chave: Projeto de Desenvolvimento; Projetão; Requisitos Funcionais, Requisitos Não-

Funcionais, Caso de Uso, Statechart e OPEU.

Agradecimentos especiais a Ricardo Eraldo de Santana - [email protected], por sua

contribuição no OPEU web.

http://www.opeu.com.br/

mailto:[email protected]

[Projeto II]

iv

iv

Índice 1. INTRODUÇÃO ......................................................................................................................................... 9

1.1 JUSTIFICATIVA ....................................................................................................................................................... 9 1.2 IDENTIFICAÇÃO DO PROBLEMA............................................................................................................................... 11 1.3 SOLUÇÃO PROPOSTA ........................................................................................................................................... 12 1.4 ESCOPO ............................................................................................................................................................. 13

2. REQUISITOS ORGANIZACIONAIS .............................................................................................................14

2.1 CONVENÇÕES ..................................................................................................................................................... 15 2.2 REQUISITOS FUCIONAIS ........................................................................................................................................ 16 2.3 REQUISITOS NÃO-FUNCIONAIS .............................................................................................................................. 21

2.3.1 Segurança ............................................................................................................................................. 21 2.3.2 Confiabilidade ....................................................................................................................................... 22 2.3.3 Usabilidade ........................................................................................................................................... 24 2.3.4 Portabilidade ........................................................................................................................................ 25 2.3.5 Performance ......................................................................................................................................... 26 2.3.6 Manutenabilidade ................................................................................................................................ 26 2.3.7 Comunicabilidade ................................................................................................................................. 27

2.4 CASOS DE USO.................................................................................................................................................... 27

3. MODELAGEM ........................................................................................................................................61

3.1 MODELAGEM CASOS DE USO ................................................................................................................................ 61 3.2 MODELAGEM REQUISITOS NÃO-FUNCIONAIS ........................................................................................................... 63 3.3 MODELAGEM DA MÁQUINA DE ESTADO .................................................................................................................. 65

3.3.1 Comportamento do Usário Não Atenticado (Visitante) ....................................................................... 65 3.3.2 Comportamento do Usário Atenticado (Administrador) ...................................................................... 66 3.3.3 Comportamento do Usário Atenticado (Comunidade Acadêmmica) ................................................... 67

4. RELATÓRIO DA EQUIPE - CONCLUSÃO ....................................................................................................69

4.1 CONCLUSÕES ...................................................................................................................................................... 72

5. REFERÊNCIAS .........................................................................................................................................74

[Projeto II]

v

v

Lista de Figuras

FIGURA 1 -SEINGUP, BOTÃO CADASTRE-SE ............................................................................................................................ 29 FIGURA 2 - FORMULÁRIO DE CADASTRO DO USUÁRIO .............................................................................................................. 29 FIGURA 3 - TELA DE LOGIN DO SISTEMA ................................................................................................................................. 30 FIGURA 4 - TELA INICIAL DO USUÁRIO AUTENTICADO ................................................................................................................ 31 FIGURA 5 - TELA DE LOGIN, LINK RECUPERAR ACESSO................................................................................................................ 32 FIGURA 6 - TELA INFORMAR E-MAIL, RECUPERAR ACESSO .......................................................................................................... 33 FIGURA 7 - POPUP CONFIRMAÇÃO E-MAIL ENVIADO,RECUPERAR ACESSO ..................................................................................... 33 FIGURA 8 - E-MAIL DE RECUPERAÇÃO DE SENHA, RECUPERAR ACESSO .......................................................................................... 34 FIGURA 9 - TELA ALTERAR INFORMAÇÕES PESSOAIS .................................................................................................................. 36 FIGURA 10 - TELA CADASTRAR PROJETO ................................................................................................................................. 38 FIGURA 11 - TELA DE MEUS PROJETOS ................................................................................................................................... 39 FIGURA 12 - FORMULÁRIO ALTERAR PROJETO ......................................................................................................................... 40 FIGURA 13 - TELA MEUS PROJETOS, BOTÃO VISUALIZAR PROJETOS .............................................................................................. 41 FIGURA 14 - TELA PROJETOS, FILTRAR PROJETOS...................................................................................................................... 42 FIGURA 15 - TELA EXIBIR PROJETOS, USUÁRIO VISITANTE ........................................................................................................... 43 FIGURA 16 - TELAS MEUS PROJETOS, BOTÃO VISUALIZAR ........................................................................................................... 44 FIGURA 17- TELA VISUALIZAR STAKEHOLDER........................................................................................................................... 45 FIGURA 18 - FORMULÁRIO CADASTRO STAKEHOLDER................................................................................................................ 46 FIGURA 19 - EDITAR STAKEHOLER, VISUALIZAR MEUS PROJETOS ................................................................................................. 47 FIGURA 20 - EDITAR STAKEHOLDER, BOTÃO EDITAR .................................................................................................................. 48 FIGURA 21 - EDITAR STAKEHOLDER, FORMULÁRIO EDITAR ......................................................................................................... 48 FIGURA 22 - EXCLUIR STAKEHOLER, MEUS PROJETOS ................................................................................................................ 49 FIGURA 23 - EXCLUIR STAKEHOLDER, BOTÃO EXCLUIR ............................................................................................................... 50 FIGURA 24 - EXCLUIR STAKEHOLDER, POPUP CONFIRMAÇÃO ...................................................................................................... 50 FIGURA 25 - VISUALIZAR DADOS DO STAKEHOLDER .................................................................................................................. 51 FIGURA 26 - UNIVERCIDADE, CADASTRAR NOVA INSTITUIÇÃO .................................................................................................... 52 FIGURA 27-UNIVERCIDADE, TELA EDITAR INSTITUIÇÃO. ............................................................................................................. 53 FIGURA 28 - UNIVERCIDADE, TELA EXCLUSÃO ......................................................................................................................... 54 FIGURA 29 - UNIVERCIDADE, TELA VISUALIZAR DETALHE ........................................................................................................... 55 FIGURA 30 - BLOG, TELA POSTAR ARTIGO ............................................................................................................................... 56 FIGURA 31 - BLOG, TELA VISUALIZAR ARTIGO .......................................................................................................................... 57 FIGURA 32 - BLOG, VISUALIZAR DETALHE SELEÇÃO ................................................................................................................... 58 FIGURA 33 - BLOG, TELA VISUALIZAR DETALHE CONTEÚDO ........................................................................................................ 58 FIGURA 34 - INSTAGRAM, TELA HOME ................................................................................................................................... 59 FIGURA 35 - INSTAGRAM, TELA DETALHE CONTEÚDO ................................................................................................................ 60 FIGURA 36 - DIAGRAMA DE CASO DE USO OPEU .................................................................................................................... 62 FIGURA 37- MODELAGEM RNF SIG OPEU ........................................................................................................................... 64 FIGURA 38-STATECHART VISÃO GERAL OPEU ........................................................................................................................ 65 FIGURA 39 - STATECHART COMPORTAMENTO DO USUÁRIO NÃO ATENTICADO ............................................................................. 66 FIGURA 40 - STATECHART COMPORTAMENTO DO USUÁRIO AUTENTICADO (ADMINISTRADOR) ....................................................... 67 FIGURA 41- STATECHART COMPORTAMENTO DO USUÁRIO AUTENTICADO (COMUNIDADE ACADÊMICA) ........................................... 68 FIGURA 42 - TURMA DA DISCIPLINA DOP (IN0977) APRESENTANDO OS TRABALHOS .................................................................... 70 FIGURA 43 - E-MAIL DE CONVOCAÇÃO DE TODA COMUNIDADE DO CIN, PARA ASSISTIR APRESENTAÇÃO DO OPEU E DEMAIS

OBSERVATÓRIOS. ..................................................................................................................................................... 70 FIGURA 44 - PROGRAMAÇÃO DAS APRESENTAÇÕES DOS OBSERVATÓRIOS (SISTEMAS) DESENVOLVIDO, SENDO O PRIMEIRO A SER

APRESENTADO O SISTEMA OPEU ................................................................................................................................ 71 FIGURA 45 - REQUISITOS OBSERVATÓRIO – FASE 2 NO GOOGLE DRIVE .............................................................................. 72

[Projeto II]

vi

vi

Lista de Requisitos Funcionais

RF 2.1-AUTO CADASTRO .................................................................................................................................................... 16 RF 2.2-RECUPERAR SENHA ................................................................................................................................................ 16 RF 2.3-AUTENTICAR USUÁRIO ............................................................................................................................................ 16 RF 2.4-SAIR DO SISTEMA ................................................................................................................................................... 17 RF 2.5-EDITAR PERFIL PESSOAL .......................................................................................................................................... 17 RF 2.6-POSTAR NOTICIAS EM REDES SOCIAIS........................................................................................................................ 17 RF 2.7-POSTAR NOTÍCIAS NO BLOG .................................................................................................................................... 17 RF 2.8-CADASTRAR PROJETOS............................................................................................................................................. 18 RF 2.9-GERENCIAR PROJETO .............................................................................................................................................. 18 RF 2.10-CADASTRAR UNIVERSIDADES ................................................................................................................................. 19 RF 2.11-GERENCIAR UNIVERSIDADES .................................................................................................................................. 19 RF 2.12-CADASTRAR STAKEHOLDER .................................................................................................................................... 19 RF 2.13-GERENCIAR STAKEHOLDER ...................................................................................................................................... 20 RF 2.14-EXIBIR PROJETOS ................................................................................................................................................. 20 RF 2.15-EXIBIR PROJETOS USUÁRIO AUTENTICADO ............................................................................................................... 20 RF2.16-CANCELAR CADASTRO ........................................................................................................................................... 20

Lista de Requisitos Não Funcionais

RNF 2.1-CONFIDENCIALIDADE DO SISTEMA .......................................................................................................................... 21 RNF 2.2-AUTENTICAÇÃO DOS USUÁRIOS. ............................................................................................................................. 21 RNF 2.3-AUTORIZAÇÃO DO USUÁRIO .................................................................................................................................. 22 RNF 2.4-INTEGRIDADE DO SISTEMA .................................................................................................................................... 22 RNF 2.5-DISPONIBILIDADE ................................................................................................................................................ 22 RNF 2.6-INTEGRIDADE DOS DADOS ..................................................................................................................................... 23 RNF 2.7-BANCO DE DADOS ............................................................................................................................................... 23 RNF2.8-BACKUP DOS DADOS ............................................................................................................................................. 23 RNF 2.9-VERIFICAÇÃO DE USUÁRIO NÃO HUMANOS.............................................................................................................. 23 RNF 2.10-LEGIBILIDADE .................................................................................................................................................... 24 RNF 2.11-USO FÁCIL ....................................................................................................................................................... 24 RNF 2.12-SIMPLICIDADE ................................................................................................................................................... 24 RNF 2.13-RESPONSIVIDADE............................................................................................................................................... 24 RNF 2.14-ACESSIBILIDADE ................................................................................................................................................ 25 RNF 2.15-COMPATIBILIDADE COM BROWSERS ...................................................................................................................... 25 RNF 2.16-COMPATIBILIDADE COM DISPOSITIVOS MÓVEIS ...................................................................................................... 25 RNF 2.17-COMPATIBILIDADE PARA PLATAFORMAS MOBILE..................................................................................................... 25 RNF 2.18-COMPATIBILIDADE COM SMART TV E TVBOXES ...................................................................................................... 26 RNF 2.19-EFICIÊNCIA ....................................................................................................................................................... 26 RNF 2.20-IMPLEMENTAÇÃO MVC..................................................................................................................................... 26 RNF 2.21-USO DE LINGUAGEM ÁGIL ................................................................................................................................... 26 RNF 2.22-DOCUMENTAÇÃO .............................................................................................................................................. 27 RNF 2.23-CANAL DE CONTATO .......................................................................................................................................... 27

[Projeto II]

vii

vii

Lista de Casos e Uso UC 2.1 - SIGNUPNO SISTEMA ............................................................................................................................................. 28 UC 2.2 - LOGIN NO SISTEMA ............................................................................................................................................... 29 UC 2.3 - RECUPERAR SENHA ............................................................................................................................................... 31 UC 2.4-SAIR DO SISTEMA ................................................................................................................................................... 34 UC 2.5-ALTERAR INFORMAÇÕES PESSOAIS ............................................................................................................................ 34 UC 2.6-CADASTRAR PROJETO ............................................................................................................................................. 36 UC 2.7 - EDITAR PROJETO .................................................................................................................................................. 39 UC 2.8 - EXCLUIR PROJETO ................................................................................................................................................. 40 UC 2.9-VISUALIZAR PROJETOS DO USUÁRIO ........................................................................................................................... 41 UC 2.10- VISITANTE VISUALIZAR PROJETOS ........................................................................................................................... 42 UC 2.11-CADASTRAR STAKEHOLDER .................................................................................................................................... 43 UC 2.12-EDITAR STAKEHOLDER ........................................................................................................................................... 46 UC 2.13 - EXCLUIR STAKEHOLDER ........................................................................................................................................ 49 UC 2.14 - VISUALIZAR STAKEHOLDER ................................................................................................................................... 50 UC 2.15 - CADASTRAR UNIVERCIDADE .................................................................................................................................. 51 UC 2.16 - EDITAR UNIVERCIDADES ...................................................................................................................................... 52 UC 2.17 -EXCLUIR UNIVERCIDADES ...................................................................................................................................... 54 UC 2.18 - VISUALIZAR UNIVERCIDADE .................................................................................................................................. 55 UC 2.19 - POSTAR ARTIGO BLOG ........................................................................................................................................ 55 UC 2.20 -EDITAR ARTIGO BLOG .......................................................................................................................................... 56 UC 2.21-EXCLUIR ARTIGO BLOG ......................................................................................................................................... 57 UC 2.22 - VISUALIZAR POSTAGENS ...................................................................................................................................... 57 UC 2.23 - EXIBIR ARTIGO DO INSTAGRAM .............................................................................................................................. 59

Lista de tabelas

TABELA 1 - TABELA DE REQUISITOS ORGANIZACIONAIS .............................................................................................................. 15 TABELA 2 - TABELA DE CASO DE USO (MODELO) ..................................................................................................................... 28

Principais Abreviações

OPEU - Observatório de Projetos Empreendedorismo Universitário.

IBGE - Instituto Brasileiro de Geografia e Estatistica.

CESAR – Centro de Estudos Avançados do Recife.

IOT – Internet Of Things - (Internet das Coisas).

InLocoMedia - Empresa Marketing Digital.

CInove – Encubadora de Projetos (Centro de Informática).

Citi - Empresa de desenvolvimento de sistemas.

RF – Resquisitos Funcionais.

RFN – Requisitos Não-Funcionais.

MVC - Model, View and Control.

[Projeto II]

viii

viii

[Projeto II]

9

Capítulo

1

1. Introdução

Este capítulo relata as principais motivações para realização deste trabalho,

sua justificativa, lista os objetivos de pesquisa almejados e, descreva a organização

estudada, o problema identificado e, o processo utilizado. Finalmente, mostra como está

estruturado o restante do relatório.

1.1 Justificativa

O empreendedorismo universitário como matéria inspiradora de reestruturações

organizacionais, passa a ser apontado como uma das formas das instituições

universitárias voltarem suas ações para o desenvolvimento econômico e social,

aproximando-se das demandas da sociedade [1]. Essa demanda vêm crescendo em

função das necessidades de pessoas aptas ao mercado de trabalho, do quantitativo de

recém formados, 3 milhões entre Instituições de Ensino Superior público e privado [2].

Do mesmo lado estão os brasileiros desempregados, 13.1 Milhões entre janeiro e março

de 2019 [3], entre eles graduados e pós-graduados. Segundo o IBGE [3] cerca de 46%

dos recém-formados do Brasil são afetados pelo desemprego, assim que concluem o

ensino superior, além 20% da alocação desses profissionais atuarem em áreas

diferentes de sua formação [4].

[Projeto II]

10

Outro dado relevante são as previsões otimistas, por exemplo, quanto ao setor de

tecnologia, em especial IOT (Internet Of Things) movimentará cerca de US$ 1,3 trilhões

ate 2019 [5]. Para 2025, a estimativa do potencial econômico da IoT varia entre US$4

trilhões no pior caso, e US$ 11 trilhões no melhor caso [6]. Considerando o câmbio

favorável a investimentos nos últimos 4 anos, o Real Brasileiro face a um Dólar

Americano, esteve entre R$ R$3,20 à R$4,00 [7]. Isto é, somos competitivos, mas somos

competentes? Em resposta temos o (CIn) Centro de Informática da Universidade Federal

de Pernambuco (UFPE) que apesar dos entraves inerentes a arena pública, ele vem

apresentando indícios de ações empreendedoras. Este caso de sucesso em especial

vem dês de sua formação em 1999, fomentando diversas iniciativas empreendedoras

realizada pelo próprio centro ou seus professores a exemplo do CESAR, Porto Digital,

CInove, Recife BEAT, CITi, Alumni entre outros [1].

Não há duvida que estas ações e empreendimentos são uma grande referência,

contudo algumas iniciativas aplicadas em disciplinas como “Projetão” apresentam um

funcionamento orgânico, diretamente associado aos seus criadores ou aos envolvidos

em cada um dos projetos, que após embarcados sob o formato de startups ou novas

empresa, levam grande parte de seu legado e conhecimento consigo. Conforme

questionamento feito ao próprio idealizador do projeto Prof. Dr. Geber Ramalho, - “há a

necessidade de se mapear seu funcionamento, compreende-lo, documentá-lo,

aprimorando-o em um formato replicável a outras instituições, faculdades ou

universidades sejam públicas ou privadas.”

O empreendedorismo se consolida na contemporaneidade, por ser um fenômeno

capaz de provocar mudanças em todas as áreas da vida humana. Impulsionado por

diversos fatores, entre eles: variações econômicas, políticas, tecnológicas e sociais [8].

O empreendedorismo está sendo estudado por empresários, pesquisadores e agentes

do governo, não é recente, como visto em Schumpeter [9], porém o empreendedorismo

universitário sim [10] [11], dentro do contexto da universidade pública federal. Discutir

empreendedorismo e inovação em universidades públicas é desafiador, pelo fato de sua

administração ser complexa e a burocracia ser característica inerente a elas [12] [1]. O

grande desafio consiste em identificar as potencialidades intra-empreendedoras

existentes na instituição e canaliza-las a construção de um ambiente inovador,

[Projeto II]

11

superando para tanto as barreiras decorrentes do formato organizacional público, sem

infringir os aspectos legais [12].

De acordo com Marques [1], estudo sobre esse tema requer compreensão em

detalhe sobre o arcabouço teórico, demanda uma pesquisa cuidadosa em uma área

ainda pouco explorada do empreendedorismo universitário no CIn.

1.2 Identificação do Problema

Apesar de um cenário extremamente favorável e um processo que vêm produzindo

resultados incríves, como inLocoMedia que possue negócios avaliados em mais de US$

1 Bilhão ser resultado do Projetão em 2011, ainda não foi possível criar um modelo que

replicasse essa fórmula.

A disciplina está evoluindo e sua metodologia também, entretanto de forma

empírica e relacionada a um conjunto de professores, que ao longo do tempo, possuem

o know-how e conhecimento tácito sobre vários processos não documentados como:

▪ A evolução metodológica, conceitual e de resultados do Projetão;

▪ O modelos de incentivo à inovação e ao empreendedorismo dentro da academia;

▪ A unificação conceitual e metodológica de abordagens como design thinking, lean

startup, business.

Além do processo há uma carência não explorada amplamente quanto ao

ferramentário de suporte e apoio, como:

▪ O uso de metodologias;

▪ E ferramentas de ensino, aprendizagem de inovação e empreendedorismo.

Algumas iniciativas de replicar o projeto do Projetão em outras instituições, através

da observação de professores convidados, trouxe resultados bons, mas ainda não

suficiente aos clientes envolvidos.

Isto reforça, que cada ação empreendedora tem um comportamento diferente onde

é aplicado. Sendo decorrente de fatores geográficos, políticos, regulamentais,

econômicos, sociais e educacionais. Este último fator é chave para uniformização de

um corpo de conhecimento, como um conceito indissociável do quadrinômio ciencia-

tecnologia-inovacão-empreendedorismo, necessário a organização da pesquisa na

[Projeto II]

12

universidade com foco nas demandas da sociedade; fomento a inovação através do

estímulo das pesquisas prioritárias; proteção da propriedade intelectual e a transferência

de tecnologia para a sociedade; formação de empreendedores, não apenas

profissionais para serem empregados em órgãos públicos ou grandes

corporações, mas pessoas que tenham a oportunidade de criar algo relevante,

empreender se quiserem em projetos inovadores ou poucos explorados.

Suportados por processos, ferramentas e parceiros que possibilitem essa caminhada [1].

1.3 Solução Proposta

O Observatório [13] [14] [15] [16] de Projetos em Empreendedorismo Universitário

(OPEU) é um espaço de observação, análise e reflexão dos movimentos em

empreendedorismo e iniciativas empreendedoras, nos centros universitários. Que

estimulam a colaboração entre professores, estudantes, pesquisadores e

empreendedores para construção de conteúdo e conhecimento a cerca do tema,

impulsionados por casos inspiradores.

Um dos objetivos é observar ações de forma ativa, dinamizando a interface entre as

instituições universitárias e o seu entorno socioeconômico.

O empreendedorismo se consolida na contemporaneidade, por ser um fenômeno capaz

de provocar mudanças em todas as áreas da vida humana. Impulsionado por diversos

fatores, entre eles: variações econômicas, políticas, tecnológicas e sociais. O

empreendedorismo está sendo estudado por empresários, pesquisadores e agentes do

governo, isto não é recente. Porém o empreendedorismo universitário sim!

Principalmente no dentro do contexto da universidade pública federal.

Discutir empreendedorismo e inovação em universidades é desafiador, pelo fato de sua

administração ser complexa e a burocracia ser característica inerente a elas. O grande

desafio consiste em identificar as potencialidades intra-empreendedoras existentes na

instituição e canaliza-las a construção de um ambiente inovador, superando para tanto

as barreiras decorrentes do formato organizacional, sem infringir os aspectos legais.

Surgem assim a curiosidade e necessidade de entender, acompanhar e, quando

possível, influenciar esse fenômeno

[Projeto II]

13

É preciso conhecer as configurações originais criadas para viabilizar novos papeis da

universidade. E, também, reconhecer as tensões geradas pelas expectativas, quer da

própria comunidade acadêmica como de outras partes interessadas, de que a

universidade venha a assumir papeis distintos dos já tradicionais.

O OPEU se propõe, a partir da concepção de planos e articulação de diversas

organizações e instâncias, convergir objetivos, organizar e produzir conteúdo, realizar

eventos, promover conexões, gerar impulsos e elementos para políticas públicas.

1.4 Escopo

Após entrega da Projeto I: Especificação de Requisitos, desta mesma disciplina,

no qual foi documentado todo o levantamento de requisitos através das notações BPMN

e iStar, em relação ao processo da disciplina “Projetão”, no CIn – UFPE, agora nesta

nova entrega, Projeto II: Requisitos Funcionais e Não-Funcionais, serão identificados os

Requisitos Funcionais e Não-Funcionais do Observatório de Projetos de

Empreendedorismo Universitário (OPEU), solução proposta como melhoria para

elicitação descrita no Projeto I (supracitado), além do próprio observatório implementado

no endereço http://www.opeu.com.br .

[Projeto II]

14

Capítulo

2 2. Requisitos Organizacionais

Segundo o Institute of Electrical and Electronics Engineers – IEEE, os requisitos para um

sistema de software, estabelecem o que o sistema deve fazer, definindo restrições sobre

sua operação e implementação [17]. Os requisitos ainda descrevem as possíveis

funcionalidades, serviços oferecidos e suas restrições de funcionamento, sendo possível

refletir as necessidades dos possíveis clientes do sistema [18]

Neste capítulo serão listados os Requisitos Funcionais (RF) e os Requisitos Não-

Funcionais (RNF) do sistema. Estes requisitos foram elicitados através da observação,

pesquisa documental e entrevista com os stakeholders do Sistema Observatório de

Projetos de Empreendedorismo Universitário (OPEU).

As convenções adotadas neste documento são baseadas no entendimento dos campos

da Tabela 1. O documento com a especificação de requisitos visa facilitar a manutenção

e rastreabilidade dos requisitos em versões posteriores deste documento. É importante

citar que estes requisitos podem evoluir e o rastreamento dinâmico oferecido pelo

suporte da ferramenta Microsft Word é requisitado.

[Projeto II]

15

2.1 Convenções

Um conjunto de convenções é adotado conforme descrição a seguir:

• Título, os requisitos apresentam um identificador único para rastreamento

(atomicidade), e podem ser do tipo RFXXX quando se referir ao Requisito

Funcional, ou, RNFXXX, quando se referir ao Requisito Não Funcional. O símbolo

XXX representa a numeração do requisito;

• Descrição, relata uma breve explicação sobre o que o sistema deve fazer, em

acordo com o cliente e usuários;

• Importância, podendo ser do tipo Alta, Média ou Baixa:

o Alta, quando é essencial para todo o processo, servindo de base para

outros requisitos. Sua falta representa um grande impacto para o seu

funcionamento;

o Média, são requisitos importantes para o processo, sua falta impacta

menos no desempenho, ou, na limitação do processo;

o Baixa, são requisitos adicionais ou desejáveis. Sua falta não causa

impacto no processo, mas sua adição agrega valor;

• Caso de Uso Relacionado (UC Relacionado), relaciona o requisito a possíveis

Casos de Uso (UC), possibilitando o seu detalhamento com uma visão mais

profunda dos seu atores, sua prioridade, pré e pós condições, fluxos e outras

informações relevantes.

A seguir um mockup de tabela, como exemplo:

Tabela 1 - Tabela de requisitos organizacionais

Título: Identificador–Nome

Descrição:

Importância:

UC Relacionado

Tabela de requisitos organizacionais anexo 1

[Projeto II]

16

É importante citar que quando houver descritos esses termos, devemos considerar os

atores que estão dentro dos parênteses:

• USUÁRIO AUTENTICADO:

o Administrador (Responsáveis por gerenciar o sistema).

o Comunidade Acadêmica (Professor, Aluno, Pesquisadores, outros stakeholders

do projeto);

• USUÁRIO NÃO AUTENTICADO

o Visitante (qualquer usuário que visite o sistema);

2.2 Requisitos Fucionais

Todo sistema deve forncer valor ao cliente e seus respectivos usuários, sendo

necessário que os requisitos identificados e implementados, estejam direcionados de

forma acertiva e de fácil entendimento usuários. Diante disso, os Requisitos Funcionais

abrangem do geral (o que o sistema faz) ao específico (forma de trabalho), em uma

determinada organização. Desta forma, estão descritos os Requisitos Funcionais do

Sistema proposto para o OPEU, tabela a seguir:

Título: RF 2.1-Auto Cadastro

Descrição: Os usuários são capazes de realizar auto cadastro no sistema, criando sua conta, cadastrando obrigatoriamente um e-mail válido de qualquer provedor e uma senha, para liberação de acesso.

Importância: ALTA

UC Relacionado UC 2.1 - SignUpno Sistema

Título: RF 2.2-Recuperar Senha

Descrição: Os usuários são capazes de recuperar sua senha, recebendo um e-mail com instruções e link para restabelecer o acesso ao sistema.

Importância: ALTA

UC Relacionado UC 2.3 - Recuperar Senha

UC 2.1 - SignUpno Sistema

Título: RF 2.3-Autenticar Usuário

[Projeto II]

17

Descrição: Autoriza o acesso dos usuários cadastrados ao sistema, através do imput do e-mail e senha, previamente cadastrados, liberando seu acesso aos serviços disponíveis em seu perfil. Não deve existir outro meio de ingresso ao sistema, uma vez que é a única forma de controlar o acesso do usuário ao sistema.

Importância: ALTA

UC Relacionado UC 2.2 - Login no Sistema

Título: RF 2.4-Sair do Sistema

Descrição: Permite que o usuário que esteja autenticado no sistema, realize logoff através da solicitação de um comando SAIR, ou, por tempo de inatividade, finalizando sua sessão e encerrando o acesso às funcionalidades do sistema.

Importância: ALTA

UC Relacionado UC 2.4-Sair do Sistema

Título: RF 2.5-Editar Perfil Pessoal

Descrição: Permite que o usuário autenticado altere suas informações pessoais, a qualquer momento. Com exceção do e-mail de cadastro principal. O usuario pode realizar a exclusão “Lógica” do perfil. Esta opção deve estar disponível no menu do usuário em Meus Dados.

Importância: ALTA

UC Relacionado UC 2.5-Alterar Informações Pessoais

UC 2.2 - Login no Sistema

Título: RF 2.6-Postar Noticias em Redes Sociais

Descrição: O sistema deve possuir interação com as Redes Sociais Instagram e Facebook. As postagem do administrador nesta rede devem ser integradas e visíveis no site na página inicial do sistema.

Importância: MÉDIA

UC Relacionado UC 2.23 - Exibir artigo do Instagram


Título: RF 2.7-Postar Notícias no Blog

[Projeto II]

18

Descrição: O sistema deve possuir uma página para postagem de notícias, no formato de Blog, para os usuários interagirem com as postagem através do: envio de mensagens, favoritando o site, ou, curtindo as postagens. Uma conta deve ser criada no Disqus, usando um novo usuário, ou, perfil de contas de Redes Sociais já existentes do Facebook, ou, Twitter. Um campo para cadastro de novos usuários deve constar página do Blog. Os usuários podem interagir com as postagens, contudo as publicações só podem ser alteradas, excluídas e até mesmo geradas pelo Administrador do sistema.


UC Relacionado UC 2.19 - Postar Artigo Blog

UC 2.20 -Editar Artigo Blog

UC 2.21-Excluir Artigo Blog

UC 2.22 - Visualizar Postagens


Título: RF 2.8-Cadastrar Projetos

Descrição: Os usuários cadastrados no sistema, podem publicar projetos. Esta funcionalidade deve estar presente no menu, quando o usuário estiver autenticado. Ao finalizar o cadastro, o usuário poderá visualizar os dados em uma página de relatório, que será exibida após esta ação. O usuário deve ter acesso a escrita, edição e exclusão, apenas em os projetos que cadastrou. Os projetos devem estar visíveis a todos os usuários. O sistema deve impedir que o usuário cadastre projetos em branco (sem informações).

Importância: ALTA

UC Relacionado UC 2.6-Cadastrar Projeto


Título: RF 2.9-Gerenciar Projeto

Descrição: Os usuários cadastrados no sistema, poderá visualizar, alterar e excluir os projetos por eles cadastrados. Estas opções devem estar disponíveis atraves de uma opcão “Meus Projetos” no menu do usuário. Uma mensagem de confirmação deve ser exibida após cada ação. O usuário também deverá ter a opção de cancelar qualquer. O usuário administrador do sistema deve ter a opção de gerenciar o projeto da mesma forma que os usuários não administradores, sendo que apenas o administradores pode Gerenciar Projetos de outros usuários.

Importância: ALTA

UC Relacionado UC 2.7 - Editar Projeto

[Projeto II]

19

UC 2.8 - Excluir Projeto

UC 2.9-Visualizar Projetos do usuário

Título: RF 2.10-Cadastrar Universidades

Descrição: Os usuários cadastrados no sistema, pode cadastrar as Universidades, ou, Instituições associadas aos Projetos cadastrados. Esta funcionalidade deve estar presente no Menu da página, no momento que o usuário estiver autenticado. Ao finalizar o cadastro, o usuário pode ver os dados em uma página de relatório, exibida logo após a ação. O usuário deve ter acesso de escrita, edição e exclusão apenas das Universidades que cadastrou. As universidades devem estar visíveis a todos os usuários. O sistema deve impedir que o usuário cadastre Universidades em branco (sem informação).

Importância: ALTA

UC Relacionado N/A

Título: RF 2.11-Gerenciar Universidades

Descrição: Os usuários cadastrados no sistema, podem visualizar, alterar e excluir as instituições que cadastrou. Estas ações devem estar disponíveis através da opção Universidades, localizada no menu do sistema. Uma mensagem de confirmação deverá ser exibida após cada ação. O usuário também deverá ter a opção de cancelamento para qualquer uma das ações. O usuário do tipo administrador do sistema, deve ter a opção de gerenciar as Universidades da mesma forma, mas apenas este tipo de usuário que pode gerenciar as Universidades cadastradas pelos outros tipos de usuários.

Importância: ALTA

UC Relacionado N/A

Título: RF 2.12-Cadastrar Stakeholder

Descrição: Os usuários cadastrados no sistema, podem incluir os stakeholders envolvidos nos projetos. Após o cadastro do projeto, o usuário deve ser direcionado a página de confirmação do cadastro do projeto. Uma opção para cadastrar os stakeholders deve ser exibida, como botão. O cadastro dos stakeholders não deve ser obrigatório. O usuário deve ter a opção de avançar sem necessariamente ter que cadastrar um stakeholder. A opção de cancelamento deve estar disponível para o usuário utilizar a qualquer momento, durante essa ação.

Importância: ALTA

UC Relacionado UC 2.11-Cadastrar Stakeholder UC 2.4-Sair do Sistema

[Projeto II]

20

Título: RF 2.13-Gerenciar Stakeholder

Descrição: Os usuários cadastrados no sistema, podem visualizar, alterar e excluir os stakeholders que ele cadastrou. Esta opções devem estar disponíveis no menu do projeto do usuário. Uma mensagem de confirmação deverá ser exibida após cada ação. O usuário também deverá ter a opção de cancelar a qualquer momento essas ações. O usuário do tipo administrador do sistema também deve ter a opção de gerenciar as os stakeholders, mas apenas este tipo de usuário que poderá gerenciar os stakeholders dos outros tipos de usuários.

Importância: ALTA

UC Relacionado UC 2.12-Editar Stakeholder UC 2.13 - Excluir Stakeholder UC 2.14 - Visualizar Stakeholder UC 2.2 - Login no Sistema

Título: RF 2.14-Exibir Projetos

Descrição: Todos os tipos de usuário podem visualizar e filtrar todos os projetos cadastrados no sistema, por categorias pré-definidas em páginas específicas do perfil de acordo com o tipo de usuário. A página de relatório com os filtros também pode ser aplicada ao ambiente que o usuário estiver autenticado, como opção de visualização dos projetos..

Importância: ALTA

UC Relacionado UC 2.10- Visitante Visualizar Projetos

Título: RF 2.15-Exibir Projetos Usuário Autenticado

Descrição: O usuário deve ter a opção de ver em seu ambiente apenas os seus projetos. Um conjunto de filtros devem estar disponíveis para o usuário, com a finalidade de filtrar analiticamente os projetos. Também devem estar disponíveis para os usuários autenticados a visualização dos relatórios.

Importância: ALTA

UC Relacionado UC 2.9-Visualizar Projetos do usuário


Título: RF2.16-Cancelar Cadastro

Descrição: Qualquer ação de cadastro ou alteração no sistema poderá ser cancelada, a qualquer momento, antes de sua confirmação, com

[Projeto II]

21

um comando de cancelamento próprio disponível em cada formulário.

Importância: ALTA

UC Relacionado UC 2.4-Sair do Sistema

2.3 Requisitos Não-Funcionais

Os Requisitos Não-Funcionais, estão diretamente relacionados com as funcionalidades

do sistema, mas se aplicam as restrições internas do produto, relacionados ao processo

de desenvolvimento, ou, externas ligados aos aspectos de qualidade. Para este tipo de

requisito, são considerados itens como: Segurança, Confiabilidade, Usabilidade,

Portabilidade, Perfomance, Manutenabilidade e Comunicabilidade.

Para esta seção, utilizamos a referência IEEE-Std 830-1998 [IEE84], ao listar os 23

Requisitos Não-Funcionais (RNF), que foram identificados em neste trabalho, mediante

as entrevista realizadas com os usuário, por item:

2.3.1 Segurança

Título: RNF 2.1-Confidencialidade do Sistema

Descrição: O sistema deve garantir a privacidade dos usuários e seus dados. O acesso as informações pessoais do usuário deve ser feitas apenas por ele mesmo e administradores do sistema previamente autorizados. Todo acesso a informações privadas do sistema deve ser feita apenas com autenticidade comprovada do usuário.

Importância: ALTA

Título: RNF 2.2-Autenticação dos Usuários.

[Projeto II]

22

Descrição: Todo acesso a informações privadas do sistema, deve ser realizada com autenticidade comprovada do usuário, garantida pelos mecanismos que relacionem apenas informações de conhecimento restrito ao usuário durante sua autenticação.

Importância: ALTA

Título: RNF 2.3-Autorização do Usuário

Descrição: O sistema deve possuir mecanismos que restrinjam o acesso do usuário autenticado apenas as áreas relacionadas ao seu tipo de perfil, sendo aplicado um conjunto de restrições de visualização, alteração e exclusão de informações. Essa autorização deve se propagar a todo o sistema, com o usuário logado ou não.

Importância: ALTA

Título: RNF 2.4-Integridade do Sistema

Descrição: O sistema deve possuir mecanismos para garantir a integridade de seu sistema, impedindo que falhas exponham informações dos usuários ou de seus projetos, como também impossibilitem qualquer alteração ou exclusão de seus dados.

Importância: ALTA

Título: RNF 2.5-Disponibilidade

Descrição: O sistema deve ser suportado em uma plataforma ou serviço que garanta sua operacionalidade durante 24hs/dia, 7dias/semana e 365/dias no ano, a todos os seus usuários e visitantes.

Importância: ALTA

2.3.2 Confiabilidade

[Projeto II]

23

Título: RNF 2.6-Integridade dos Dados

Descrição: O sistema deve garantir a consistência de todos os seus dados, em todas as operações internas, ou, aos seus agentes que estejam envolvidos nele, de forma íntegra, devendo ser verificável e auditável.

Importância: ALTA

Título: RNF 2.7-Banco de Dados

Descrição: O sistema deve possuir um banco de dados para armazenagem e gerenciamento de suas informações, que seja rápido e confiável.

Importância: ALTA

Título: RNF2.8-Backup dos Dados

Descrição: O sistema deve possuir um serviço de backup para garantia e segurança de seus dados. Esse backup deve ser atualizado a cada 60 minutos, 24 horas por dia, 7 dias por semana semana, possuindo ainda um log de registro dos últimos backups realizados.

Importância: ALTA

Título: RNF 2.9-Verificação de Usuário Não Humanos

Descrição: O sistema deve garantir a autenticidade dos usuários humanos, evitando que outros sistemas ou robôs realizar cadastrados.

Importância: MEDIA

[Projeto II]

24

2.3.3 Usabilidade

Título: RNF 2.10-Legibilidade

Descrição: O sistema deve possuir uma interface de fácil leitura, com informações claras e menus que representem suas funções, serviços ou informações, de forma objetiva, preferencialmente em uma única palavra. As palavras usadas devem ser em idioma local, com uso de expressões cotidianas em sua redação ou relacionadas ao domínio de conhecimento de seu público.

Importância: MEDIA

Título: RNF 2.11-Uso Fácil

Descrição: O sistema deve ter sua usabilidade fluída, navegação intuitiva e possuir interações, utilizando funções do cotidiano similar a sites e sistemas mais populares.

Importância: ALTA

Título: RNF 2.12-Simplicidade

Descrição: O sistema deve ser simples de usar, não deve possuir botões animados ou funções que não sejam populares e sua interface deve ser intuitiva.

Importância: ALTA

Título: RNF 2.13-Responsividade

Descrição: O sistema deve possuir a interface gráfica responsiva, utilizando os modelos visuais e de cores já amplamente padronizados. Sua interface deve se ajustar ao dispositivo que o usuário estiver utilizando, inclusive podendo ser também via dispositivo mobile.

Importância: ALTA

[Projeto II]

25

Título: RNF 2.14-Acessibilidade

Descrição: As cores do sistema deve possuir alto contraste, entre os textos e o plano de fundo, facilitando a leitura dos usuários que possuam alguma dificuldade visual. Também deve possuir a possibilidade de aumentar a fonte dos textos, sem gerar prejuízos da disposição gráfica de seus elementos e conteúdo.


2.3.4 Portabilidade

Título: RNF 2.15-Compatibilidade com Browsers

Descrição: O sistema deve ser funcional e acessível através dos browsers web mais populares do mercado, como: IE, Chrome, Firefox, Safari e Mozilla.

Importância: ALTA

Título: RNF 2.16-Compatibilidade com Dispositivos Móveis

Descrição: O sistema deve ser funcional e acessível através dos browsers web de dispositivos móveis como: Celulares, Palmtops, Tablets e Smartphones. Também deve manter o seu fluxo de navegação, informação e funcionalidades em operação nesses tipos de dispositivo, ficando assim acessível ao usuário.

Importância: ALTA

Título: RNF 2.17-Compatibilidade para Plataformas Mobile.

Descrição: O sistema deve ser funcional e acessível através das duas plataformas mobile mais difundidas: iOS e Android.

Importância: ALTA

[Projeto II]

26

Título: RNF 2.18-Compatibilidade com Smart TV e TvBoxes

Descrição: O sistema deve ser funcional e acessível através dos browsers web de dispositivos, como Smart TVs. Nesses tipos de dispositivos, o sistema deve manter seu fluxo de navegação, informação e funcionalidades operacionais, sendo acessível ao usuário. Também deve preservar uma resolução aceitável de suas imagens para TV’s de alta resolucão.

Importância: ALTA

2.3.5 Performance

Título: RNF 2.19-Eficiência

Descrição: Qualquer acesso ao menu, sistema ou link disponível no sistema, em condições mínimas de largura de banda e velocidade de acesso igual ou superior a 512kb/s, deve garantir uma resposta de até 1 segundo.

Importância: MEDIA

2.3.6 Manutenabilidade

Título: RNF 2.20-Implementação MVC

Descrição: O sistema deve ser desenvolvido sob a arquitetura de camadas usando o padrão MVC, (Model, View and Control), facilitando sua manutenção, tanto para modularização de novos serviços e páginas, como também para possíveis correções.

Importância: ALTA

Título: RNF 2.21-Uso de Linguagem Ágil

[Projeto II]

27

Descrição: O sistema deve ser desenvolvido em uma linguagem de programação altamente difundida e com abordagem ágil, podendo ser em: PHP5, Ruby on Rails, ou, Grovy on Grails.

Importância: ALTA

2.3.7 Comunicabilidade

Título: RNF 2.22-Documentação

Descrição: O sistema deve possuir em seu código, registros de e texto que documentem suas funções e principais variáveis, de forma. detalhada e de fácil compreensão. Um documento formal deve informar ao Administrador do sistema sobre sua arquitetura, conexões com banco, interconexões com outros sistemas, locais de contato e contrato com fornecedores de serviços do sistema..

Importância: MEDIA

Título: RNF 2.23-Canal de Contato

Descrição: O sistema deve disponibilizar um canal de contato entre os seus Usuários e o Administrador do sistema, através de e-mail, chat ou contatos telefônicos informados na página local destinado ao contato.

Importância: ALTA

Dependência: N/A

UC Relacionado

N/A

2.4 Casos de Uso

Os Casos de Usos (UC), são detalhamento de como ocorrerá o uso do sistema mediante

execução de determinadas funcionalidades já definidas, sendo considerado uma

unidade que demonstra sequências de troca de informações ou mensagens dos usuários

externos e o sistema, sinalizando ainda possíveis excessões executadas do sistema.

[Projeto II]

28

Nos Casos de Uso do Sistema OPEU, foram identificados como usuários: Aluno,

Professor, Executor do Projeto e Visitante do Site. Sendo assim, estão relacionados a

seguir os respectivos Casos de Uso do Sistema OPEU, ilustrados no modelo a seguir

Tabela 2:

Tabela 2 - Tabela de Caso de Uso (modelo)

Identificador - Título

Descrição

Atores

Prioridade

Pré-condições

Fluxo Principal 1. 2.

Pós-condições

Requisitos Func.

UC 2.1 - SignUpno Sistema

Descrição O sistema deve permitir que qualquer usuário possa realizar o cadastro no mesmo.

Atores Aluno, Professor, Administrador, Visitante do site.

Prioridade Alta.

Pré-condições Os atores possuírem uma conta de e-mail válida, de qualquer provedor.

Fluxo Principal 1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita.

3. Clicar na opcão “Cadastre-se”.Figura 1

4. Preencher os campos, conforme Figura 2

a. Nome Completo*. b. Email* c. Senha* d. Confirmar Senha*

5. Clicar em “Cadastrar”.

Pós-condições 1. Usuário obtém permissão para realizar login no sistema. 2. Usuário será direcionado para uma tela de boas vindas. 3. Usuário terá várias opções de acesso: Meus Dados, Meus

Projetos, Projetos, Universidades. 4. Usuário poderá sair do sistema.

[Projeto II]

29

Requisitos Func. RF 2.1-Auto Cadastro

Figura 1 -SeingUp, Botão Cadastre-se

Figura 2 - Formulário de Cadastro do Usuário


Descrição O sistema deve permitir ao o usuário cadastrado no sistema, a realização do login e autenticação, para obter acesso a área restrita.

Atores Usuário Autenticado

[Projeto II]

30

Prioridade Alta

Pré-condições Possuir cadastro no sistema

Fluxo Principal 1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”.

4. Preencher os campos, conforme Figura 3

a. E-mail b. Senha.

5. Clicar no botão Entrar.

Fluxo Alternativo 1. No passo 5, caso o usuário tenha digitado nome ou e-mail errados, uma mensagem de erro será exibida, informando que "Usuário ou Senha Incorretos ou Não cadastrados"

2. No passo 5, caso um dos campos não tenha sido preenchido o sistema solicita a necessidade de seu preenchimento.

Pós-condições 1. Usuário estará autenticado no sistema. 2. Usuário terá acesso a sua área de trabalho, com visibilidade dos

menus referente ao tipo do seu perfil. 3. Usuário irá visualizar uma mensagem de boas vindas, com seu o

nome. 4. Usuário irá visualizar uma mensagem de confirmação do sistema,

que está logado, conforme Figura 4

Requisitos Func. RF 2.3-Autenticar Usuário

Figura 3 - Tela de login do sistema

[Projeto II]

31

Figura 4 - Tela inicial do usuário autenticado

UC 2.3 - Recuperar Senha

Descrição O usuário poderá recuperar sua senha, ao receber um e-mail de notificação com as instruções e link para restabelecer seu acesso ao sistema.

Atores Usuário Cadastrado

Prioridade Alta

Pré-condições SingUp no Sistema. Possuir e-mail relacionado ao Cadastro.


4. Clicar no link "Esqueceu a sua senha?" - Figura 5

5. Informar o e-mail cadastrado - Figura 6

6. Clicar no botão "Enviar".

7. Na janela de confirmação de envio, clicar no botão OK. Figura 7

[Projeto II]

32

Fluxo Alternativo N/A

Pós-condições 1. Um e-mail é enviado ao usuário, contendo as seguintes informações:

Ola,{NOME COMPLETO DO USUÁRIO}, o procedimento de recuperar dados, foi efetuado com sucesso ! Seu email = {EMAIL DO USUARIO CADASTRADO} Senha de acesso = {SENHA DO USUÁRIO} Nao responda esse email, e-Mail automatizado Conforme Figura 8

Requisitos Func. RF 2.1-Auto Cadastro RF 2.3-Autenticar Usuário

Figura 5 - Tela de login, link recuperar acesso

[Projeto II]

33

Figura 6 - Tela informar e-mail, recuperar acesso

Figura 7 - PopUp confirmação e-mail enviado,recuperar acesso

[Projeto II]

34

Figura 8 - E-mail de recuperação de senha, recuperar acesso

UC 2.4-Sair do Sistema

Descrição O sistema deve permitir que o usuário logado, possa finalizar sua sessão quando desejar. Fechando todas as suas consultas e impedindo o acesso à área pessoal seja realizada quando a sessão estiver finalizada. Uma página de confirmação deve ser exibida.


Prioridade Alta

Pré-condições SignUp no Sistema Login no Sistema

Fluxo Principal 1. Clica em “Sair”. 2. Será redirecionado para a tela de Login.


Pós-condições Redirecionar usuário para a tela de Login.

Requisito RF 2.4-Sair do Sistema

UC 2.5-Alterar Informações Pessoais

Descrição O sistema deve permitir que os dados pessoais do usuário sejam alterados ou atualizados, com exceção do ID e e-mail que foi cadastrado.

[Projeto II]

35


Prioridade Alta

Pré-condições SignUp no Sistema Login no Sistema


4. Clicar em "Meus Dados", conforme Figura 9

5. Alterar um dos campos disponíveis: a. Nome b. Telefone c. Data de Nascimento d. Descrição

6. Clicar no botão "SALVAR"

Pós-condições Alterações serão feitas com sucesso. Usuario retorna para página inicial.

Requisito RF 2.3-Autenticar Usuário

RF 2.5-Editar Perfil Pessoal

[Projeto II]

36

Figura 9 - Tela alterar informações pessoais

UC 2.6-Cadastrar Projeto

Descrição O sistema deve permitir que usuários possam cadastrar novos projetos.

[Projeto II]

37


Prioridade Alta

Pre-condições Login no sistema

Fluxo Principal 1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”. 4. Clicar no botão "Meus Projetos". 5. Clicar no botão "+Novo Projeto".

6. Preencher os campos, conforme Figura 10 - Tela cadastrar projeto

7. Clicar na opção cadastrar.

Fluxo Alternativo 1. No passo 6, caso o usuario desista do cadastro, clica no botão voltar.

2. No passo 7, caso um dos campos obrigatórios seguidos de (*) asterisco, não sejam preenchidos, uma mensagem indica a falta de preenchimento do campo, um destaque é feito ao campo em branco.

Pós-condições Projeto adicionado, pode ser visto na página de meus projetos.

Requisito Func. RF 2.3-Autenticar Usuário

RF 2.8-Cadastrar Projetos

[Projeto II]

38

Figura 10 - Tela cadastrar projeto

[Projeto II]

39

UC 2.7 - Editar Projeto

Descrição O sistema deve permitir que usuários possam editar apenas seus projetos. Todos os projetos devem estar listados para o usuário, que escolhe apenas um projeto por vez para edição.


Prioridade Alta

Pre-condições Login no Sistema Ter projeto cadastrado

Fluxo Principal 1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”. 4. Clicar no botão "Meus Projetos", o usuário é direcionado para um

página de Meus projetos, conforme Figura 11.

5. Selecione o botão "Editar", no projeto escolhido. O formulário de projeto é exibido com os campos disponíveis para edição. conforme

Figura 12

6. Edite o campo desejado. 7. Clicar no botão "SALVAR".

Fluxo Alternativo 1. No passo 6, caso o usuário deseje, ele pode cancelar a edição clicando no botão "Voltar".

Pós-condições Projeto editado, pode ser visto na página de meus projetos.

Requisito Func. RF 2.3-Autenticar Usuário RF 2.8-Cadastrar Projetos RF 2.9-Gerenciar Projeto

Figura 11 - Tela de meus projetos

[Projeto II]

40

Figura 12 - Formulário alterar projeto

UC 2.8 - Excluir Projeto

Descrição O sistema deve permitir que usuários possam editar apenas seus projetos. Todos os projetos devem estar listados para o usuário, que escolhe apenas um projeto por vez para edição.


Prioridade Alta

Pre-condições Login no Sistema Cadastrar Projeto

Fluxo Principal 8. Acessar a pagina “Início”. 9. Clicar no botão “Mais▼”, no menu superior a direita. 10. Clicar na opcão “Login”. 11. Clicar no botão "Meus Projetos", o usuário é direcionado para um página de Meus projetos. 12. Selecione o botão "Editar", no projeto escolhido. O formulário de projeto é exibido com os campos disponíveis para edição. 13. Edite o campo desejado. 14. Clicar no botão "SALVAR".

Fluxo Alternativo No passo 6, caso o usuário deseje, ele pode cancelar a edição clicando no botão "Voltar".

Pós-condições Projeto excluido, não pode ser mais visto.

Requisito Func. RF 2.9-Gerenciar Projeto

[Projeto II]

41

UC 2.9-Visualizar Projetos do usuário

Descrição O sistema deve permitir a visualização dos projetos existentes, bem como filtrá-los, por um conjunto de critérios. Os projetos são exibidos e podem ser editados, caso você tenha criado o projeto.


Prioridade Alta

Pre-condições Login no Sistema Ter projeto cadastrado no sistema

Fluxo Principal 1. Clica no link “Projetos”, uma lista de projetos e exibida ao

usuário.Conforme a Figura 13 - Tela meus projetos, botão visualizar projetos

2. Clica em “Visualizar” ao lado do projeto escolhido.

Fluxo Alternativo 1. Após o passo 1, o usuário pode clicar no botão o ou link "Projetos" e optar por selecionar um dos campos do filtro, fazer a melhor combinação para sua busca e clicar no botão "Consultar".

Conforme a Figura 14 - Tela projetos, filtrar projetos.

Pós-condições Usuário passa a poder visualizar a lista de projetos no sistema.

Requisito Func. RF 2.15-Exibir Projetos Usuário Autenticado

Figura 13 - Tela meus projetos, botão visualizar projetos

[Projeto II]

42

Figura 14 - Tela projetos, filtrar projetos.

UC 2.10- Visitante Visualizar Projetos

Descrição O sistema deve permitir a visualização dos projetos existentes, bem como filtrá-los, por um conjunto de critérios. Os projetos são exibidos, mas não há possibilidade de editá-los.

Atores Usuário não autenticado

Prioridade Alta

Pre-condições

Ter projetos cadastrados

Pós-condições

Usuário passa a poder visualizar a lista de projetos no sistema.

Fluxo Principal

1. Clicar no link “Projetos”

2. Clicar em “Visualizar” ao lado do projeto escolhido. Conforme a Figura 15

Fluxo Alternativo

1. Após o passo 2, o usuário pode optar por selecionar um dos campos do filtro, fazer a melhor combinação para sua busca e clicar no botão

"Consultar". Conforme a a Figura 15

Requisito RF 2.14-Exibir Projetos

[Projeto II]

43

Figura 15 - Tela exibir projetos, usuário visitante

UC 2.11-Cadastrar Stakeholder

Descrição O sistema deve permitir que usuários possam cadastrar stakeholders associando-os ao um projeto.


Prioridade Alta

Pre-condições Login no Sistema Cadastrar Projeto


página de Meus projetos.conforme Figura 16

5. Selecione o botão "Visualizar", no projeto escolhido. O Relatório de projeto é exibido, com botão para cadastrar "+Novos Stakeholder"

abaixo. conforme Figura 17

6. Clique no botão "+Novos Stakeholder".

7. Preencha os campos conforme a descrição da Figura 18

8. Clicar no botão "Cadastrar".

Fluxo Alternativo

1. No passo 7, caso o usuario desista do cadastro, clica no botão voltar.

[Projeto II]

44


Pós-condições 1. StakeHolder associado ao projeto. 2. Pode ser visto na parte inferior do projeto estando listado lá.

Requisito Func. RF 2.12-Cadastrar Stakeholder

Figura 16 - Telas meus projetos, botão visualizar

[Projeto II]

45

Figura 17- Tela visualizar Stakeholder

[Projeto II]

46

Figura 18 - Formulário cadastro stakeholder

UC 2.12-Editar Stakeholder

Descrição O sistema deve permitir que usuários possam editar stakeholders de um projeto.

Atores Aluno, Professor, Administrador

Prioridade Alta

Pre-condições Login no Sistema Projeto cadastrado Stakeholder cadastrado

Fluxo Principal 1. Acessar a página “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”. 4. Clicar no botão "Meus Projetos", o usuário é direcionado para um

página de Meus projetos. 5. Selecione o botão "Visualizar", no projeto escolhido. O Relatório de

projeto é exibido, com botão para editar "Editar" abaixo. conforme

Figura 19

6. Clique no botão "Editar" Figura 20.

7. Altere os campos conforme a descrição da Figura 21

8. Clicar no botão "Salvar".

[Projeto II]

47

Fluxo Alternativo

1. No passo 7, caso o usuario desista do cadastro, clica no botão voltar.


Pós-condições Dados do stakeholder selecionado podem ser visualizados.

Requisito Func. RF 2.13-Gerenciar Stakeholder

Figura 19 - Editar stakeholer, visualizar meus projetos

[Projeto II]

48

Figura 20 - Editar stakeholder, botão editar

Figura 21 - Editar stakeholder, formulário editar

[Projeto II]

49

UC 2.13 - Excluir Stakeholder

Descrição O sistema deve permitir que usuários possam excluir stakeholders de um projeto.


Prioridade Alta

Pre-condições Login no Sistema Projeto cadastrado Stakeholder cadastrado


página de Meus projetos.

5. Selecione o botão "Visualizar", no projeto escolhido. Figura 22 - Excluir Stakeholer, meus projetos

6. O Relatório de projeto é exibido, com botão para Excluir "Excluir"

abaixo. conforme Figura 23

7. Clique no botão "Excluir". 8. Um popup de confirmação informando o id do stakeholder é exibido

conforme Figura 24, duas opções são exibidas (sim) e (não)

9. Clicar no botão "Sim".

Fluxo Alternativo 1. No passo 7, caso o usuário desista da exclusão, clica no botão não.

Pós-condições Dados do stakeholder são apagados e não podem ser visualizados.

Requisito RF 2.13-Gerenciar Stakeholder

Figura 22 - Excluir Stakeholer, meus projetos

[Projeto II]

50

Figura 23 - Excluir stakeholder, botão excluir

Figura 24 - Excluir stakeholder, popup confirmação

UC 2.14 - Visualizar Stakeholder

Descrição O sistema deve permitir que usuários possam visualizar os stakeholders de um projeto.


Prioridade Alta

Pre-condições

Login no Sistema Projeto cadastrado Stakeholder cadastrado

[Projeto II]

51

Fluxo Principal

1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”. 4. Clicar no botão "Meus Projetos", o usuário é direcionado para um página

de Meus projetos. 5. Selecione o botão "Visualizar", no projeto escolhido. O Relatório de projeto

é exibido, os usurários associados ao projeto estão listados abaixo, e possuem 3 botões (Visualizar, Editar e Excluir), cada

6. Clique no botão "Visualizar". Uma tela com a visualização dos dados do

stakeholder é mostrada conforme Figura 25,.

Fluxo Alternativo

N/A

Pós-condições

Dados do stakeholder podem ser vistos, sob o formato de lista e em detalhe

conforme Figura 25,.

Requisito RF 2.13-Gerenciar Stakeholder

Figura 25 - Visualizar dados do stakeholder

UC 2.15 - Cadastrar Univercidade

Descrição O sistema deve permitir que usuários possam cadastrar novas instituições de ensino superior, associando-as aos seu projeto.


Prioridade Alta

Pre-condições Usuário logado


[Projeto II]

52

4. Clicar no botão "Universidades". Uma janela de Nova Instituição

é exibida, conforme Figura 26 - Univercidade, cadastrar nova instituição

5. Preencher os campo., 6. Clicar na opção cadastrar.



Pós-condições Universidade adicionada, pode ser exibida na página de minhas instituições.

Requisito RF 2.10-Cadastrar Universidades

Figura 26 - Univercidade, cadastrar nova instituição

UC 2.16 - Editar Univercidades

Descrição O sistema deve permitir que usuários possam editar instituições de ensino superior.

[Projeto II]

53


Prioridade Alta

Pre-condições Usuario logado

Univercidade cadastrada

Fluxo Principal 1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”. 4. Clicar no botão "Universidades". Uma tela de instituições é

exibida. 5. Clicar no botão "Editar", referente a universidade que vai ser

alterada. Um formulário, conforme a Figura 27-Univercidade, tela editar instituição.é exibido.

6. Alterar os campos desejados, 7. Clicar no botão "SALVAR"



Pós-condições Universidade editada, seus campos atualizados, e seu registro pode ser exibido na página de minhas instituições.

Requisito RF 2.11-Gerenciar Universidades

Figura 27-Univercidade, tela editar instituição.

[Projeto II]

54

UC 2.17 -Excluir Univercidades

Descrição O sistema deve permitir que usuários possam excluir instituições de ensino superior.

Atores Usuário Atutenticado

Prioridade Alta

Pre-condições Estar logado

Ter univercidade cadastrada

Fluxo Principal 1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”. 4. Clicar no botão "Universidades".

5. Uma tela de instituições é exibida, conforme Figura 28 - Univercidade, tela exclusão

6. Clicar no botão "Excluir", referente a universidade que

vai ser removida. conforme a Figura 28,Uma janela vai ser exibida confirmando o ID da faculdade, a opção de exclusão (SIM) E cancelamento (NÃO)

7. Clique no botão "SIM", sistema volta para tela de instituições a faculdade não é mais visualizada.

Fluxo Alternativo 1. No passo 7, caso o usuário desista do cadastro, clica no botão voltar.


Pós-condições Universidade excluída não é mais exibida na listagem do usuário .


Figura 28 - Univercidade, tela exclusão

[Projeto II]

55

UC 2.18 - Visualizar Univercidade

Descrição O sistema deve permitir que usuários possam listar instituições de ensino superior.


Prioridade Alta

Pre-condições Estar logado no sistema Ter univercidades cadastradas

Fluxo Principal 1. Acessar a pagina “Início”. 2. Clicar no botão “Mais▼”, no menu superior a direita. 3. Clicar na opcão “Login”. 4. Clicar no botão "Universidades". Uma tela de instituições é

exibida. 5. Clique no botão visualizar, um formulário com os dados da

universidade é exibido conforme a Figura 29


Pós-condições Tela dados da instituição é exibida, informando todos os dados da univercidade.


Figura 29 - Univercidade, tela visualizar detalhe

UC 2.19 - Postar Artigo Blog

Descrição O sistema deve permitir postagem de artigos na página de blog.

Atores Administrador

[Projeto II]

56

Prioridade Alta

Pre-condições Usuário Cadastrado.

Fluxo Principal 1. Clicar na opcão “Login”. 2. No menu de administração, clicar na opção Blog.

3. Preencha os dados dos formulários do Blog, conforme Figura 30

4. Clique no botão, Post as {nome do usuario}


Pós-condições Postagem é concluída e exibida na pagina Blog.

Requisito RF 2.7-Postar Notícias no Blog

Figura 30 - Blog, tela postar artigo

UC 2.20 -Editar Artigo Blog

Descrição O sistema deve permitir edição de artigos na página de blog.


Prioridade Alta

Pre-condições Usuário Cadastrado. Blog postado

Pós-condições A edição é concluída e exibida na pagina Blog.

Fluxo Principal 1. Clicar na opcão “Login”. 2. No menu de administração, clicar na opção Blog.

3. Selecione a postagem que deseja editar. Figura 31 - Blog, tela visualizar artigoFigura 31Altere os dados dos

formulários do Blog. 4. Clique no botão, Post as {nome do usuario}

Fluxo Alternativo


[Projeto II]

57

Figura 31 - Blog, tela visualizar artigo

UC 2.21-Excluir Artigo Blog

Descrição O sistema deve permitir exclusão de artigos na página de blog.


Prioridade Alta

Pre-condições Usuário Cadastrado. Blog postado

Fluxo Principal 1. Clicar na opcão “Login”. 2. No menu de administração, clicar na opção Blog. 3. Selecione a postagem que deseja editar. 4. Clique na opção excluir. 5. Um pop-up de confirmação é exibido. 6. Selecione a opção sim.

Fluxo Alternativo No passo 5, o usuário pode optar por não excluir a postagem clicando na opção cancelar.

Pós-condições Após a exclusão o post não pode mais ser listado ou exibido nas páginas do sistema.

UC 2.22 - Visualizar Postagens

Descrição O sistema deve permitir a visualização das postagens na página blog, o usuário pode visualizar o detalhe da postagem.

Atores Visitante da página

Prioridade Alta

[Projeto II]

58

Pre-condições Postagens no blog

Pós-condições As postagens vão ser apresentadas resumidamente, podem ser visualizadas em detalhe.

Fluxo Principal 1. Clicar na opcão “Blog”, menu principal do Sistema,

Figura 32 - Blog, visualizar detalhe seleção.

2. Selecione uma postagem, Figura 33 - Blog, tela visualizar detalhe conteúdo.



Figura 32 - Blog, visualizar detalhe seleção

Figura 33 - Blog, tela visualizar detalhe conteúdo

[Projeto II]

59

UC 2.23 - Exibir artigo do Instagram

Descrição O sistema deve permitir exibição das postagem no Instagram, na página principal, podendo ser exibido em detalhe quando solicitado, as cinco postagens mais recentes serão exibidas.

Atores Administrador, Instagram

Prioridade Alta

Pre-condições Possuir conta na rede social Instagram. Fazer postagem no Instagram.

Fluxo Principal 1. Página recebe a postagem do Instagram. 2. Postagem é exibida na página principal, conforme

Figura 34 - Instagram, tela home

3. Clicar sobre a postagem. 4. Postagem em detalhe é exibida na página da rede

social, conforme Figura 35 - Instagram, tela detalhe conteúdo


Pós-condições Post é exibido na página inicial do sistema.

Requisito RF013

Figura 34 - Instagram, tela home

[Projeto II]

60

Figura 35 - Instagram, tela detalhe conteúdo

[Projeto II]

61

Capítulo

3 3. Modelagem

Neste capítulo são desmonstradas as modelagens realizada para facilitar a visualização

dos Requisitos Funcionais, Requisitos Não-Funcionais e Estados do Sistema OPEU,

através de três formatos: Diagrama de Casos de Uso, Framework NRF e Statecharts.

3.1 Modelagem Casos de Uso

A Modelagem de Casos de Uso, é útil para visualizar o modo que o sistema é utilizado

através das execuções de suas funcionalidades. Através deste dipo de modelagem, é

possível correlacionar a sequência de mensagens trocadas entre o sistema e seus

possíveis usuários. Para o Sistema OPEU, foi modelado o seguinte diagrama, Figura 36:

[Projeto II]

62

Figura 36 - Diagrama de caso de uso OPEU

Nesta modelagem, foram identificados 4 atores: Adiministrador, OPEU, Usuários

Autenticado e Usuário Não Autenticado e 24 funções, como sequências de ações que

são executadas pelo sistema, para gerar diversos resultados. Observa-se que a maioria

das funções (67%) , estão concentradas no Usuário Autenticado, diante de ser o

principal ator do sistema, com a possibilidade assim de executar mais ações do sistema,

seguido do Administrador (17% das funções), Usuário Não Autenticado (12%) e OPEU

(4%), completando assim toda cobertura do sistema.

[Projeto II]

63

3.2 Modelagem Requisitos Não-Funcionais

Inicialmente proposto e desenvolvido pelo Dr. Lawrence Chung, o NFR é uma

abordagem orientada a processos, onde seus Requisitos Não-Funcionais são

explicitamente representados como metas a serem obtidas (CHUNG, 1995). Esta

orientação está relaciona ao comportamento do sistema e não as suas funcionalidades,

sendo representadas por gráficos SIG (Softgol Interdendency Graph), para descrever

suas dependências e possíveis decomposições. Com isso, pode-se viabilizar a

visualização das relações desses Requisitos Não-Funcionais a satisfação dos

stakeholders, auxiliando inclusive nas descobertas de possíveis conflitos entre eles.

Sendo assim, a Figura 37 demonstra a modelagem desse tipo de requisito no sistema

OPEU.

Na modelagem, foram identificadas 7 grandes áreas e mapeados 29 Requisitos Não-

Funcionais (incluindo as áreas). Destes 5 foram classificados como “Operationalization”,

sendo eles: Autenticação dos Usuários, Backup dos Dados, Verificação de Usuário Não

Humanos, Responsividade e Implementação MVC. Além disso, é observado 5

influências do tipo positiva suficiente e 2 do tipo parcial, além 2 influencias do tipo

negativa parcial.

[Projeto II]

64

[Projeto II]

65

3.3 Modelagem da Máquina de Estado

Diante da dificuldade de visualizar e validar diagramas que representem grandes

sistemas com elevado nível de complexidade, Harel [19] propôs uma representação

gráfica comportamental do sistema, demonstrando o formalismo de máquinas de

estados finidos e seus componentes visuais. Esquematicamente, entende-se como

STATECHART = Diagrama de Estados + Hierarquia + Concorrência + Mecanismo de

Comunicação. Sendo assim, A Figura 37 representa o Statechart do Sistema OPEU:

Figura 38-StateChart visão geral OPEU

A Figura 37 – Comportamento do sistema entre as interfaces web estática e páginas

dinâmicas para os usuários: Não autenticados (Visitante), Autenticados (Administrador e

Comunidade Acadêmica).

Diante da limitação visual da figura anterior, expandimos em partes para facilitar a

visualização da diagramação e suas respectivas divisões de acordo com os Atores e

suas respectivas funcionalidades.

3.3.1 Comportamento do Usário Não Atenticado (Visitante)

No site do sistema OPEU, as páginas estáticas de usuário não autenticado permitem a

todos uma visão e consumo de informações a cerca do site nas páginas Início, Sobre,

Blog, Eventos, Projetos, Publicações e Contato. Em seguida o usuário não autenticado

pode mofidicar seu estato, após um cadastro efetivando seu login ele passa estar logado

no sistema, como pode ser visto na Figura 39

[Projeto II]

66

Figura 39 - StateChart Comportamento do usuário não atenticado

3.3.2 Comportamento do Usário Atenticado (Administrador)

Este usuário herda todas as possibilidade de visualização do usuário não autenticado e

também possue controle total sobre o sistema. Mas seu acesso a área restrita só é

permitido após login e autenticação pelo sistema, suas ações podem ser observadas na

Figura 40, a seguir.

[Projeto II]

67

Figura 40 - StateChart Comportamento do Usuário Autenticado (Administrador)

3.3.3 Comportamento do Usário Atenticado (Comunidade Acadêmmica)

Este usuário possue todas as visões do Visitante e alguns acessos limitados em relação

ao usuário administrador, que são: O controle de usuários do sistema; A capacidade de

[Projeto II]

68

Gestão do Blog; Capacidade de Postar no Istagram. Como pode ser visto na Figura 41

a seguir.

Figura 41- StateChart Comportamento do Usuário Autenticado (Comunidade Acadêmica)

[Projeto II]

69

Capítulo

4 4. Relatório da Equipe - Conclusão

Neste capítulo é relatada a experiência da equipe no desenvolvimento do projeto e suas

evidências produzidas durante esse período.

Para elaboração deste projeto, a equipe desenvolveu diversas atividades, como:

✓ Reunião de brainstorm, que ocorreram durante e após as aulas da disciplina;

✓ Reunião de status das atividades, que ocorreram na Sala de reunião da

Associação de Pós-Graduandos (APG) do Centro de Informática (CIn – UFPE);

✓ Levantamento de Requisitos Funcionais e Requisitos Não-Funcionais, assim

como dos Casos de Uso (UC) do Sistema OPEU, em paralelo a disciplina

Desenvolmento de Observatório de Projetos (IN0977), para desenvolvimento de

uma versão com um MVP (Minimum Viable Product) real e funcional;

✓ Modelagem do Diagrama de Casos de Uso, com o uso do framework Visual

Paradigm nos computadores pessoais da equipe, realizadas Home Office e no

Laboratório da Pós-Gradução;

✓ Modelagem do Diagrama dos Requisitos Não-Funcionais, com o uso do NFR

Framework (da DSM3-goals), nos computadores pessoais da equipe, realizadas

Home Office e no Laboratório da Pós-Gradução;

✓ Modelagem do Diagrama de Máquina de Estado, com o uso do Yakindu, nos

computadores pessoais da equipe, realizadas Home Office e no Laboratório da

Pós-Gradução;

[Projeto II]

70

✓ Revisão das modelagens dos Casos de Uso, Requisitos Não-Funcionais (NFR) e

Máquina de Estado (Statecharts), que ocorreram Home Office e na Sala de

Reunião da APG;

✓ Elaboração do documento final do projeto, utilizando o editor de textos Microsoft

Word, Home Office e na Sala de Reunião da APG;

✓ Validação das modelagens representadas na versão real do Sistema OPEU,

através da apresentação do resultado da primeira versão funcional no dia 20/11,

no Anfiteatro do Cin, durante a culminância da Disciplina Desenvolvimento de

Observatório de Projetos – DOP (IN0977):

Figura 42 - Turma da Disciplina DOP (IN0977) apresentando os trabalhos

Figura 43 - E-mail de convocação de toda comunidade do Cin, para assistir apresentação do OPEU e demais Observatórios.

[Projeto II]

71

Figura 44 - Programação das apresentações dos Observatórios (sistemas) desenvolvido, sendo o primeiro a ser apresentado o sistema OPEU

Para gestão das informações, documentações coletadas e geradas ao longo do trabalho,

a equipe criou uma pasta compartilhada entre os membros, no GoogleDrive do CIn

chamada “REQUISITOS OBSERVATÓRIO – FASE 2”1, organizando todos esses

artefatos em diveras subpastas, parte destes artefatos estão disponíveis no GoogleDrive.

1 Link da pasta Google Drive - https://drive.google.com/drive/u/1/folders/1huz8SJRislXpjzO2EzbKIkMT5mJax7h5

[Projeto II]

72

Figura 45 - REQUISITOS OBSERVATÓRIO – FASE 2 no Google Drive

Participação no projeto dos mebros

Nome Parcipação % Assinaturas

Emmanuel Barreto De Carvalho - [email protected]

40%

Mateus Camara Pereira - [email protected]

40%

Edmilson Rodrigues Do Nascimento

Junior - [email protected] 15%

Marvin Alexander Lopez Martinez - [email protected]

5%

4.1 Conclusões

Com a primeira fase do projeto “Projeto I: Especificacão de Requisitos”, foi possível

entender a dinâmica do problema, modelar o ASIS e propor o TO BE que resultou no

Repositório sob o formato de Observatório de Projetos “OPEU”. Com a segunda fase do

projeto “Projeto II: Especificacão de Requisitos Funcionais e Não-Funcionais, este

trabalho da Disciplina Engenharia de Requisitos (IN-1020) e unificando a oportunidade

da disciplina Desenvolvimento de Observatório de Projetos (IN-0977), com membros

desta equipe comum as duas disciplinas, foi possível desenvolver a primeira versão real

do OPEU (www.opeu.com.br). Diante disso, este trabalho, demonstra a real importância

dos assuntos assimilados nas aulas teóricas e práticas (nos laboratórios), para o

levantamentos dos requisitos e sua implementação de forma real em um sistema que foi

http://www.opeu.com.br/

[Projeto II]

73

desenvolvido durante esta disciplina. Além deste documento escrito, a equipe, de fato,

disponibilizou os sistema (real) que foi modelado e especificado neste documento. Este

foi um grande mérito desta equipe, pois o sistema proposto existe, o que demonstra a

real importância da Engenharia de Requisitos no universo do desenvolvimento de

sistemas, bem como a geração de valor aos seus respectivos clientes e usuários.

[Projeto II]

74

Capítulo

5

5. Referências

[1] T. W. R. Marques, O Empreendedorismo Universitario pela Dinamica da Acao Empreendedora no Centro de Informatica da Universidade Federal de Pernambuco, vol. 658 CDD, Recife: CCSA, 2016.

[2] DiretoriadeEstatísticasEducacionais (DEED), “Censo da Educacão Superior,” INEP, 2017. [Online]. Available: http://portal.inep.gov.br/web/guest/censo-da-educacao-superior. [Acesso em 01 06 2019].

[3] IBGE, “IBGE,” Agencia IBGE de Notícias, 31 05 2019. [Online]. Available: https://agenciadenoticias.ibge.gov.br/agencia-noticias/2012-agencia-de-noticias/noticias/24283-desemprego-sobe-para-12-7-com-13-4-milhoes-de-pessoas-em-busca-de-trabalho. [Acesso em 13 06 2019].

[4] IBGE, Síntese de Indicadores Sociais, vol. 38, Rio de Janeiro, RJ: IBGE, 2018, p. 151.

[5] VERIZON, “State of the Market: Internet of Things,” New Jersey, 2016.

[6] MCKINSEY GLOBAL INSTITUTE, “The Internet of things: Mapping the value beyond the hype,” 2015.

[7] BNDS, “ Taxa de câmbio media vigente,” [Online]. Available: https://www.bndes.gov.br/wps/portal/site/home/financiamento/servicos-online/credenciamento-de-equipamentos/taxa-cambio-media-vigente. [Acesso em 13 06 2019].

[8] D. L. T. BOAVA e M. F. MACEDO, “Estudo sobre a essencia do empreendedorismo.,” SALVADOR, BA, 2006.

[9] J. A. Schumpeter, Capitalism, socialism, and democracy., New York: Harper & Brothers, 1942.

[10] ETZKOWITZ e H. ETZKOWITZ, Porto Alegue : EdiPUCRS, 2009.

[11] H. ETZKOWITZ, “Anatomy of the entrepreneurial university.,” Social Science Information, vol. 52, nº 3, pp. 486-511, 2013.

[Projeto II]

75

[12] R. P. R. e. a. FERRAS, “Empreendedorismo corporativo em organizacoes publicas: um estudo em uma universidade publica.,” Rio de Janeiro, 2014.

[13] N. S. Schmidt and C. L. Da Silva, Observatório como instrumento de prospectiva estratégica para as Instituições de Ciência e Tecnologia (ICTs), 2 ed., vol. 19, Campo Gd., 2018, p. 153.

[14] A. R. R. B. C. a. M. H. M. R. Santiago Scarpin, Proposta de indicadores para um observatório de empreendedorismo no Brasil,, 3 ed., vol. 5, Rev. Eletrônica Estratégia Negócios, 2012, p. 90.

[15] X. W. R. T. a. W. H. T. Tiropanis, “Building a Connected Web Observatory Architecture and Challenges,,” em 2nd Int. Work. Build. Web Obs. (B-WOW14), 2014.

[16] K. McKelvey and F. Menczer, “Design and prototyping of a social media observatory,,” em WWW 2013 Companion - Proc. 22nd Int. Conf. World Wide Web, 2013.

[17] IEEE Std. 610.12 , “Std. 610.12 IEEE Standard Glossary of Software Engineering Terminology,” The Institute of Electrical and Electronics Engineers., New York, 1990.

[18] SOMMERVILLE, Ian., Software engineering, Yorkshire: Addison-Wesley/Pearson. , 2011.

[19] I. A. G. BOAVENTURA, Propriedades Dinâmicas de Statecharts, São Carlos: USP, 2013.

[20] IEEE Std. 830. , “IEEE Guide to Software Requirement Specification.,” he Institute of Electrical and Electronics Engineers., New York, 1984.

observatÓrio de projetos em empreendedorismo ... - ufpe

Documents