Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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
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.
[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
UC 2.2 - Login no Sistema
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.
Importância: MÉDIA
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
UC 2.2 - Login no Sistema
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
UC 2.2 - Login no Sistema
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
UC 2.2 - Login no Sistema
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.
Importância: MÉDIA
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
UC 2.2 - Login no Sistema
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.
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 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.
Atores Usuário Autenticado
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.
Fluxo Alternativo N/A
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
Atores Usuário Autenticado
Prioridade Alta
Pré-condições SignUp no Sistema 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 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
Atores Usuário Autenticado
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.
Atores Usuário Autenticado
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.
Atores Usuário Autenticado
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.
Atores Usuário Autenticado
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.
Atores Usuário Autenticado
Prioridade Alta
Pre-condições Login no Sistema Cadastrar Projeto
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 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
2. No passo 8, 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 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.
2. No passo 8, 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 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.
Atores Usuário Autenticado
Prioridade Alta
Pre-condições Login no Sistema Projeto cadastrado Stakeholder 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.
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.
Atores Usuário Autenticado
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.
Atores Usuário Autenticado
Prioridade Alta
Pre-condições Usuário logado
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”.
[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.
Fluxo Alternativo 1. No passo 6, caso o usuario desista do cadastro, clica no botão voltar.
2. No passo 6, 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 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
Atores Usuário Autenticado
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"
Fluxo Alternativo 1. No passo 7, 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 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.
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 Universidade excluída não é mais exibida na listagem do usuário .
Requisito RF 2.11-Gerenciar Universidades
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.
Atores Usuário Autenticado
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
Fluxo Alternativo N/A
Pós-condições Tela dados da instituição é exibida, informando todos os dados da univercidade.
Requisito RF 2.11-Gerenciar Universidades
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}
Fluxo Alternativo N/A
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.
Atores Administrador
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
Requisito RF 2.7-Postar Notícias no Blog
[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.
Atores Administrador
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.
Fluxo Alternativo N/A
Requisito RF 2.7-Postar Notícias no Blog
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
Fluxo Alternativo N/A
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
[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.