Sistema de Gerenciamento de Dados da Organização "Politiquê?

Universidade Federal de Pernambuco Centro de Informática Sistema de Gerenciamento de Dados da Organização "Politiquê? Documento de Especificação de Requisitos Professor Jaelson Freire Brelaz de Castro Equipe: Anaury Norran Passos Rito ( anpr@cin.ufpe.br ) Natanael Souza dos Santos ( nss@cin.ufpe.br ) Rafael Nunes Galdino da Silveira ( rngs@cin.ufpe.br ) Tomás Arruda de Almeida ( taa2@cin.ufpe.br ) Recife, 20 de junho de 2015

Histórico de Revisão Data Versão Autor 17/06/2015 1.8 Conclusão e revisão rngs, taa2, anpr, nss 11/06/2015 1.7 Diagrama Statechart taa2, anpr 09/06/2015 1.6 Atualização da descrição do processo e do problema 08/06/2015 1.5 Modelagem NFR com NFR Framework 06/06/2015 1.4 Casos de Uso e diagramas adicionais 03/06/2015 1.3 Requisitos organizacionais, funcionais e nao funcionais 03/06/2015 1.2 Modelo do processo atual BPMN e istar rngs nss anpr, taa2 rngs, nss rngs 02/06/2015 1.1 Introdução rngs, taa2, nss 29/05/2015 1.0 Crição do documento rngs, taa2, anpr, nss Formulário do relatório da equipe Nome Papel Esforço (%) Assinatura Anaury Norran Introdução, Caso de Uso, Conclusão 100 Natanael Santos Introdução, NFR, Conclusão 100 Rafael Nunes Introdução, BPMN, istar 100 Tomás Arruda Introdução, Caso de Uso e Statechart, Conclusão 100 1

Sumário 1. Introdução 1.1. Motivação 1.2. A Organização 1.3. Modelo do Processo Interno (BPMN) 1.4. Identificação do Problema 1.5. A solução proposta 2. Modelagem Organizacional (istar) 3. Especificação dos Requisitos 3.1. Requisitos Organizacionais 3.2. Requisitos Funcionais 3.3. Requisitos Não Funcionais 3.3.1. Requisitos de Processo 3.3.2. Requisitos de Produto 3.3.3. Requisitiso Externos 4. Modelagem de Requisitos Funcionais (Use Case) 5. Modelagem de Requisitos Não Funcionais (NFR Framwork) 6. Modelagem Comportamental do Sistema (Statecharts) 7. Conclusão 8. Glossário 9. Apêndices 9.1. Apêndice A Entrevistas 9.2. Apêndice B Documentos e formulários consultados 9.3. Apêndice C Diagramas complementar e descrições dos casos de uso. 9.3.1. Gerar Relatório 9.3.2. Inserir Dados 9.3.3. Editar Dados 2

1. Introdução O objetivo deste documento é elaborar uma documentação do problema encontrado e uma especificação da solução proposta, contando que já foi feito um estudo de viabilidade para a solução. Através das documentações e modelagens presentes neste documento, o sistema proposto é especificado, e a posteriori validado o que guiará o processo de desenvolvimento. 1.1. Motivação Organizações têm procurando cada vez mais soluções tecnológicas para otimizar seu próprio ambiente profissional que muitas vezes está extremamente saturado de processos burocráticos. Agilizar a busca por informações de gerência interna é um outro fator que faz com que as organizações, por todo o mundo, invistam em tecnologia. Um grande exemplo disso é o fato de muitas organizações ainda utilizarem enormes arquivos de papeis e documentos que retardam os processos administrativos, necessitando drasticamente de um sistema de armazenagem e controle de informações. Em resumo, a modernização da empresas também é um fator essencial na melhoria do produto e serviço fornecido pela empresa, agilizando os processos administrativos e reduzindo gargalos de produtividade. 1.2. A Organização A organização Politique? é uma organização não governamental sem fins lucrativos, é um projeto que se baseia na construção de um conhecimento imparcial sobre o que é política, como ela funciona e para que ela serve. Hoje a ONG conta com diversos setores que possuem processos e ações internas (ver organograma na FIGURA 1), mas a Politiquê? tem como principal diferencial sua área de P&D (Pesquisa e Desenvolvimento). Onde ao invés de focar em apenas uma forma específica de espalhar a educação política, a ONG visa sempre executar ações diferentes, inovadoras e abrangentes. Para tal, a área de P&D tem que estar constantemente buscando iniciativas inovadoras para poder adaptá-las às ideias da ONG e escrevendo-as em forma de planejamento de projetos. Esses projetos podem contar com financiamento de outros órgãos ou empresas parceiras (tornando crucial também que tais editais de financiamento sejam armazenados). Alguns dos projetos e iniciativas catalogados pela Politiquê? podem ser de caráter mais interno, sendo revertidos como capacitações (quer sejam internas ou externas) para os membros ou mudanças e melhorias na estrutura da empresa. Possíveis parceiros e eventos externos também são estudados para possibilitar atuação mais direcionada da ONG no meio em que ela está inserida(seja através de parcerias ou capacitações em congressos). Conversamos com Robertson (Contato: +55 81 981666603) membro do setor de P&D para o maior entendimento do que é a organização e de como ela atua (Perguntas da entrevista disponível no apêndice A como Entrevista 1). 3

FIGURA 1 - Organograma da Politiquê? 1.3. Modelo do Processo Interno O processo inicia quando um membro da diretoria envia para um membro do setor de P&D o no novo case de introdução a política através de debates e pesquisa em escolas, para ser analisado. Com a intenção que o setor de P&D possa estudar a nova iniciativa. Dessa forma, o membro da P&D deve procurar em seus registros se já existe uma iniciativa que seja nesse formato desejado, caso não exista ele registrará essa nova iniciativa. Caso exista ele apontará para o membro da diretoria a iniciativa já existente. O membro da diretoria então decidirá a aprovação da iniciativa, caso a iniciativa não seja aprovada no formato atual, o próprio membro a edita ao formato interessado e a salva. Quando a iniciativa for aprovada o membro da diretoria solicitará ao membro de P&D um relatório com possíveis financiamentos (financiamentos muitas vezes são lançados em editais do governo e empresas privadas) que caberiam no prazo da iniciativa. O setor de P&D analisa os possíveis financiamentos e envia a lista para o membro da diretoria. Se não existirem financiamentos cabíveis então procura-se as empresas parceiras que poderiam querer patrocinar. Caso não existam possíveis empresas parceiras gera-se o relatório final. Caso existam financiamentos cabíveis a diretoria então vai procurar possíveis eventos onde a nova inciativa poderia ser publicada e divulgada. Por fim, o setor de P&D gera o relatório com o resultado desse processo de análise. Tal relatório servirá de base para a criação de um projeto futuramente. O modelo atual do processo empresa é ilustrado nos diagramas a seguir (FIGURAS 2 e 3). 4

FIGURA 2 - Modelagem BPMN do processo atual da Poliquê? 5

FIGURA 3 - do subprocesso buscar eventos do tipo ad hoc. 1.4. Identificação do Problema Por termos delimitado a investigação dos processo a área de P&D entrevistamos Robertson Novelino e Camila Alencar (perguntas das entrevistas disponíveis no apêndice A como entrevista 2), membros do setor de P&D, para entender dos processos internos como o processo descrito acima. Foram consultados também documentos como formulários onlines usados para a produção dos artefatos (disponíveis no apêndice B). Identificamos inúmeros gargalos presentes no modelo de processo atual, os resultados da entrevista e a modelagem apontam uma descentralização de informações, pois muitos dos artefatos procurados estavam em repositórios diferentes como arquivos de papel, anotações e Google Docs (por vezes tarefas manuais e outras vezes tarefas de usuário). Os artefatos produzidos não eram compartilhados com toda organização, só podiam ser acessados fisicamente. Uma complexidade de cadastro e edição de artefatos. Problemas esses que interferem diretamente no desempenho e na velocidade de execução do processo, de forma que é de fundamental importância uma restruturação e padronização do modelo atual da gerência de artefatos. 1.5. A solução proposta Após o estudo de viabilidade e de uma validação com os respectivos membros do setor de P&D chegou-se ao consenso que o ideal para a organização seria o desenvolvimento de um sistema de informação. O sistema estará disponível em uma plataforma Web o que proporcionaria um acesso remoto e portavel da gerência e o compartilhamento dos dados. Integrado a um banco de dados que armazenaria os dados dos artefatos elaborados no processo, o que concentra os dados, com garantia de consistência e versão. Com uma interface amigável que facilitasse o processo de iteração com as consultas, cadastros, manipulação dos dados e geração dos relatórios a partir do cruzamento destes dados. Esta solução oferece de forma eficiente meios que otimizarão e facilitarão os processos internos do setor de P&D. 6

2. Modelagem Organizacional (istar) O modelo organizacional é construído no chamado early step da elicitação dos requisitos, que trata de uma fase inicial. O modelo de Dependência Estratégica e modelo Estratégico de Razão estão presentes neste tipo de modelagem e constam nesta seção do documento. O modelo istar existe para se ter um melhor entendimento a respeito dos relacionamentos de metas, tarefas e recursos entre os agentes da organização. O modelo de Dependência Estratégica (Modelo SD - FIGURA 4) é usado para descrever as dependências das relações entre os atores em um contexto organizacional. A Diretoria possui goals a serem atendidos a nível de organização, assim como recursos que provêm do trabalho executado pelo setor de P&D da ONG. Atualmente não existe um padrão para o gerenciamento de artefatos produzidos pela P&D, de forma que utilizam-se muitas vezes e-mails, documentos em papel e online. Tendo isso a modelagem representa o "sistema" atual como um Agent, por hora é papel de uma pessoa, outrora é utilizado algum sistema, pois pensamos em representar as principais características que um sistema (solução do problema) teria. Para uma melhor visualização e o não poluimento do modelo foram priorizadas e resumidas as principais relações entre os atores e agentes. FIGURA 4 - Modelo de Dependência Estratégica - SD Já o modelo Estratégico de Razão (Modelo SR - FIGURA 5) é usado para detalhar os interesses dos stakeholders. Relacionando seus recursos, atividades internas e decomposições e colaborações que envolvem as tarefas, softgoals e goals. Foram priorizados uma modelagem voltada ao sistema e sua relação com o setor de P&D, para poder descrever melhor as necessidades do problema e modelagem da solução. De forma que para não poluir o diagrama com excessivo detalhamento foram priorizados alguns goals, softgoals, tasks e resources que são considerados os mais importante para o entendimento da aplicação e do que ela deve tratar. As modelagens istar foram inspiradas no que foi identificado no modelo do processo bem como da conversas com os usuários, de forma que esse primeiro passo traz mais informações a respeito do domínio e servirá para dar suporte as próximas fases como a de elicitação de requisitos. 7

FIGURA 5 - Modelo Estratégico de Razão - SR 8

3. Especificação dos Requisitos Foram analisados os modelos BPMN e i*, além de consultar os membros da ONG para elicitar os principais requisitos com bases nas exigências e no workflow do processo. Os requisitos estão identificados no formato [ROxx] quando são requisitos organizacionais, [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não-funcionais, em que xx é o número de identificação do requisito. Dessa forma os requisitos poderão ser rastreados no documento. Além disso, os requisitos funcionais e não-funcionais também estão relacionados aos casos de uso a que pertencem. 3.1. Requisitos Organizacionais Os requisitos organizacionais existem para representar a necessidade de se satisfazer as metas e objetivos da ONG. Como também representar as limitações do sistema e o porquê do sistema ser desenvolvido. Identificação [RO01] Armazenagem e Rastreamento de dados Criar uma base de dados para os dado de membros, iniciativas, eventos, parcerias, financiamentos, e torná-la acessível. Identificação [RO02] Facilitar a geração de relatórios Tornar fácil e rápido a geração dos relatórios pertinentes aos dados armazenados e aos processos. Identificação [RO03] Otimizar o tempo de análise Otimizar o tempo de estudo das iniciativas e financiamentos da organização. Identificação [RO04] Melhorar o rendimento das ações Agilizando o processo de elaboração de novas ações e iniciativas. Identificação [RO05] Produzir mais iniciativas Aumentar o número de iniciativas concretizadas pela organização. Identificação [RO06] Avaliar engajamento Medir como está o engajamento de cada membro/área com as iniciativas criadas. Identificação [RO07] Avaliar o retorno das inciativas Catalogar opções de retorno para a organização das iniciativas catalogadas 9

3.2. Requisitos Funcionais Requisitos funcionais de um sistema representam as funcionalidades que sistema deve dispor para a completude da solução. 3.2.1. Organização Identificação [NF01] Cadastrar Membro Casos de Uso Relacionados A aplicação deve ter suporte para cadastrar funcionários de diferentes áreas da empresa que terão o papel de usuário do sistema. Identificação [NF02] Gerenciar Perfil Casos de Uso Relacionados Membros podem visualizar seu perfil, modificando informações, login e senha, e podem visualizar atividades relacionadas a eles. Identificação [NF03] Cadastrar Setor Casos de Uso Relacionados Cadastro de setor com suas devidas permissões sobre o sistema. Identificação [NF04] Gerência do Setor Casos de Uso Relacionados Membros podem visualizar o setor, alterar o membros e permissões do mesmo. 3.2.2. Autenticação Identificação [NF05] Realizar Login Casos de Uso Relacionados Membros devem efetuar o login para a utilização do sistema, para isso devem informar o login e senha e ciclar em "entrar". Identificação [NF06] Realizar Logoff Casos de Uso Relacionados Membros podem sair do sistema apertando o botão de realizar logoff. 10

3.2.3. Armazenagem e Consulta Identificação [NF07] Inserir dados Casos de Uso Relacionados Membros podem inserir: Iniciativas, Financiamento, Evento(Evento Institucional, Capacitação Interna e Capacitação Externa) e Empresa Parceira. Identificação [NF08] Editar dados Casos de Uso Relacionados Membros podem alterar dados cadastrais de: Iniciativas, Financiamento, Evento(Evento Institucional, Capacitação Interna e Capacitação Externa) e Empresa Parceira. Identificação [NF09] Remover dados Casos de Uso Relacionados Membros podem remover os registros de: Iniciativas, Financiamento, Evento(Evento Institucional, Capacitação Interna e Capacitação Externa) e Empresa Parceira. Identificação [NF10] Consultar dados Casos de Uso Relacionados Membros podem consultar por n parâmetros os registros de: Iniciativas, Financiamento, Evento(Evento Institucional, Capacitação Interna e Capacitação Externa) e Empresa Parceira. 3.2.4. Relatórios Identificação [NF11] Gerar Relatório Casos de Uso Relacionados Membros podem gerar relatório sobre qualquer consulta aos dados. Identificação [NF12] Análise de Financiamento Casos de Uso Relacionados Membros podem gerar relatório sobre financiamentos que caibam em inciativas cadastradas pela organização. 11

( ) Essencial ( x ) Importante ( ) Desejável Identificação [NF13] Relatório iniciativas Casos de Uso Relacionados Membros podem gerar relatório sobre a distribuição das iniciativas por setor e membros vinculados. ( ) Essencial ( x ) Importante ( ) Desejável 3.3. Requisitos Não Funcionais 3.3.1. Requisitos de Processo Banco Identificação [NRF01] Banco SQLite Casos de Uso Relacionados Todos O sitesma a ser desenvolvido deve ser feito para executar em um banco SQLite. Hospedado no Heroku. ( ) Essencial ( x ) Importante ( ) Desejável Linguagem Identificação [NRF02] HTML/CSS + JS Casos de Uso Relacionados Todos O frontend do sistema deve ser desenvolvido em HTML/CSS com JavaScript. ( ) Essencial ( x ) Importante ( ) Desejável Metodologia Identificação [NRF02] SCRUM Casos de Uso Relacionados Todos A metodologia de desenvolvimento a ser implementada deve ser SCRUM. ( ) Essencial ( x ) Importante ( ) Desejável Servidor Identificação [NRF04] Django Casos de Uso Relacionados Todos O backend, servidor da aplicação, deve ser desenvolvido em Django hospedado no Heroku. ( ) Essencial ( x ) Importante ( ) Desejável 3.3.2. Requisitos de Produto Backup Identificação [NRF05] Realizar backcup Casos de Uso Relacionados Todos 12

Realizar backup dos dados periodicamente. ( ) Essencial ( x ) Importante ( ) Desejável Confiabilidade Identificação [NRF06] Confiabilidade Casos de Uso Relacionados Todos O sistema responder sempre tanto em situações de rotina como extremas. Consistência Identificação [NRF07] Consistência Casos de Uso Relacionados Todos Os dados armazenados deverão estar atualizados e corretos. Disponibilidade Identificação [NRF08] Disponibilidade Casos de Uso Relacionados Todos O sistema deve estar disponível sempre que necessário. Notificar erros Identificação [NRF09] Notificar erros Casos de Uso Relacionados Todos O sistema deverá notificar os erros ao usúario de forma simples e objetiva. Padronização Identificação [NRF10] Padronização Casos de Uso Relacionados Todos O sistema deverá obedecer a padronização de código e arquitetura MVC. Permissão Identificação [NRF11] Padronização Casos de Uso Relacionados Todos Membros de diferentes setores possuem diferentes permissões no sistema. Portabilidade Identificação [NRF12] Portabilidade Casos de Uso Relacionados Todos O sistema deve estar disponível e acessível via qualquer browser. 13

Privacidade Identificação [NRF13] Privacidade Casos de Uso Relacionados Todos Os dados veiculados no sistema não podem ser acessados fora do sistema. Robustez Identificação [NRF14] Robustez Casos de Uso Relacionados UC DE CADASTRO O sistema não deve permitir invalidez dos dados cadastrados. Segurança Identificação [NRF15] Segurança Casos de Uso Relacionados Todos Os dados veiculados no sistema não podem ser acessados sem a autenticação. Tempo de cadastro dos dados Identificação [NRF16] Tempo execução Casos de Uso Relacionados UC DE CADASTRO O tempo e cadastro dos dados deve ser um tempo regular. ( ) Essencial ( x ) Importante ( ) Desejável Tempo de resposta Identificação [NRF17] Tempo resposta Casos de Uso Relacionados Todos O sistema não deve demorar às requisções feitas pelo o usuário. ( ) Essencial ( x ) Importante ( ) Desejável Tolerância a falhas Identificação [NRF18] Tolerância Casos de Uso Relacionados Todos O sistema deve gerenciar as falhas ocorridas no processo. Usabilidade Identificação [NRF19] Usabilidade Casos de Uso Relacionados Todos Sistema de fácil uso para qualquer tipo de membro. 14

3.3.3. Requisitiso Externos Obedecer restrições do dominio Identificação [NRF20] Dominio Casos de Uso Relacionados Todos O sistema deve corresponder às restrições legais do domínio da ONG. Tempo de desenvolvimento Identificação [NRF21] Desenvolvimento Casos de Uso Relacionados Todos O tempo de desenvolvimento não pode ultrapassar mais que 30% do estimado. 4. Modelagem de Requisitos Funcionais (Use Case) O diagrama completo dos casos de uso da aplicação do sistema de gerenciamento interno da organização Politique?, engloba todas as funcionalidades do sistema, refletindo os requisitos funcionais, e a interação de um determinado ator com o mesmo. Todos as tasks identificadas na modelagem BPMN do processo que envolviam tarefas do usuário com alguma plataforma já existente ou tarefas manuais, de cadastro, busca, edição e geração de formulário, foram traduzidas em funcionalidades do diagrama de casos de uso. Como a proposta do sistema é otimizar o processo e melhorar o gerenciamento dos artefatos, foi identificada a necessidade de modelar funcionalidades que não estão presentes no processo (BPMN) atual, mas que são extremamente importantes para atender aos RNF e a completude da aplicação, permitindo aos membros de P&D mais ações, como por exemplo: armazenar artefatos e consultas que antes não existiam anteriormente, como também permissões diferenciadas para o uso do sistema e manutenção dos dados, dentre outros quesitos. O modelo do diagrama de caso de uso seguinte (FIGURA 6). E para uma descrição mais detalhada, foram escolhidos três casos de uso, selecionados tendo em vista as diferenças de comportamento com o sistema. Foram escolhidos para serem detalhados os casos de uso de Gerar Relatório, Inserir dados e Editar Dados. As descrições, diagramas de atividades, diagramas de classe e diagramas de sequência podem ser encontrados no apêndice C desse documento. 15

FIGURA 6 - Diagrama de Casos de Uso 16

5. Modelagem de Requisitos Não-Funcionais Os requisitos não funcionais descritos na seção 3 deste documento estão modelados nesta seção 5. São apresentadas as interdependências, os refinamentos e as operacionalizações dos NFR, de forma a modelar o comportamento ideal que aplicação deve implementar (FIGURA 7). 17

FIGURA 7 - Modelagem NFR com NFR Framework 18

6. Modelagem Comportamental do Sistema (Statecharts) Foi utilizada o método Statechart para a modelagem do diagrama de estados do sistema, representando todo do fluxo comportamental da aplicação, de acordo com as possibilidades de acesso de um usuário completo do sistema (FIGURAS 8, 9 e 10). FIGURA 8 - Visão geral Após o Login o sistema entra em estado de espera e pode partir para o estado de cadastro ou o estado de consulta, a qualquer momento o estado pode ser modificado entre consulta e cadastro. Em detalhes cada um dos estado. 19

FIGURA 9 - Detalhes do cadastro 20

FIGURA 10 - Detalhes da consulta e edição 21

7. Conclusão Este documento possui como principal finalidade a compreensão dos requisitos necessários para se chegar a uma solução viável para o problema da empresa Politique?. Inicialmente foi identificado problemas de caráter administrativo e organizacional do processo atual da Politique? e para se chegar a resolução desse problema uma série da passos foi necessário. Primeiramente, o processo de elicitação de requisitos foi feito através de entrevistas com membros da organização, tanto da diretoria quanto do setor de P&D, gerando, assim, informação suficiente para se iniciar um processo de análise, especificação e definição de requisitos. Para uma melhor visualização dos requisitos do sistema solução foram utilizadas diversas ferramentas ao longo de diversas etapas da especificação dos requisitos. Foram utilizadas várias metodologias de criação de diagramas de descrição dos requisitos da solução. Através da ferramenta Bizagi foi desenvolvido o diagrama BMPN para facilitar o entendimento do processo de negócio na organização, auxiliando na compreensão de como a solução proposta atuaria nala. Foi feito o diagrama istar para fornecer uma visão mais abrangente das interações entre atores na organização e na solução. Foi desenvolvido também um diagrama de Casos de Uso para ilustrar as funcionalidades do sistema e como os atores interagiriam com ele. Para se ter um melhor direcionamento no processo de desenvolviment criou-se, através do NFR Framework, o diagrama de requisitos não funcionais, de formar a proporcionar um guina na abordagem de desenvolvimento orientada ao processo ou ao produto. Por ultimo, para estabelecer os estados do sistema, detalhando o comportamento do sistema isoladamente, foi projetado um diagrama Statechart. Em resumo, é extremamente importante a especificação de requisitos claros, concisos e coerentes no projeto de software, para que o processo de desenvolvimento seja eficiente e que o resultado englobe a solução de todas as necessidades do cliente. 8. Glossário ONG Organização não Governamenta. P&D Projeto e Desenvolvimento. Google Docs Ferramenta colaborativa de edição de texto do Google. SQLite Biblioteca em C que implementa um banco de dados SQL. HTML/CSS + JS Liguagens utilizadas para o desenvolvimento de aplicações web. SCRUM Metodologia ágil de gerencia de projetos em engenharia de software. Django Framework de desenvolvimento web implementado na linguagem Python. NFR Requisito não funcional 22

9. Apêndices 9.1. Apêndice A - Entrevistas Entrevista Semi Estrutrada 1 Com Robertson Novelino 1. O que é o Politique e quais os seus objetivos? 2. Existem setores diferentes, como é a organização da empresa? 3. Como a organização funciona? 4. Quais as principais ações da ONG? Entrevista Semi Estrutrada 2 Com Robertson Novelino e Camila Alencar 1. Quem vai usar o sistema? Membros da própria ONG. 2. Qual o perfil de quem vai usar o sistema? Uma pessoa de TI e duas pessoas estudantes de direito. 3. Existem níveis de permissão de acesso aos artefatos hoje? Membros da ONG no geral terão menos permissões que os responsáveis de P&D. 4. Como vocês resolvem hoje? Quais os principais gargalos? Catalóga se as ações, iniciativas, parcerias e projetos em documentos de papel e as vezes usamos formulários online. Para cruzar as informações dos catálogos para promover ações futuras e projetos da ONG atualmente utilizasse planilha do excel. O gargalo principal é a gerência dos artefatos. 5. Qual seria a solução ideal? Um sistema web de fácil inserção de dados e consulta. 6. Quais dados precisarão ser realmente guardados? Os dados pertinentes aos formulários de iniciativas, eventos, parcerias, projetos e membros. 7. Quais funcionalidades são necessárias? Quais as funcionalidades desejáveis? Necessário que o sistema armazene todos os dados, permita consultas e cruzamento de dados. Promova permissões de acesso diferenciadas. É desejável que o sistema permita inserção de novas tabelas e estruturas quando surja uma possível alteração na política e na estruturação dos projetos. 9.2. Apêndice B - Documentos e formulários consultados Exemplo de form de Empresa Parceira: http://goo.gl/forms/w4sg1mdcct Exemplo de form de Banco de iniciativa: http://goo.gl/forms/qe7l3d3oto Exemplo de form de Financiamento: http://goo.gl/forms/7yzsqxzy76 23

9.3. Apêndice C - Diagramas complementar e descrições dos casos de uso. As descrições dos diagramas 9.3.1. Gerar Relatório 9.3.1.1. ID UC4 Nome Gerar Relatório Status OK Autor rngs Data de criação 15/04/2015 Data de revisão 17/04/2015 Comportamento do sistema quando gerar relatório de uma consulta for solicitado. Requisito Gerar Relatório Requisitos Envolvidos Consulta, Consulta Iniciativa, Consulta Eventos, Consulta Empresas. Atores Membro Entrada Dados retornados de uma consulta Pré Condições 1. Servidor estar disponível 2. Usuário estar logado no sistema 3. Membro ter realizado uma consulta Fluxo Principal 1. Inicia com a solicitação do relatório 2. O sistema recolhe os dados da consulta realizada 3. Exporta os dados da consulta 4. Fim do caso de uso Fluxo Alternativo 1. Problema durante a exportação dos dados, passo 3, enviasse mensagem ao usuário. 24

Saída e Pós Condição 1. Relatório devidamente exportado para o usuário. 9.3.1.2. Diagrama de Atividade 25

9.3.1.3. Diagrama de Classes 9.3.1.4. Diagrama de Sequência 26

9.3.2. Inserir Dados Para o caso de uso de inserção de dados foi utilizada a inserção de eventos no sistema para exemplificar. 9.3.2.1. ID UC5 Nome Inserir Evento Status OK Autor rngs Data de criação 15/04/2015 Data de revisão 17/04/2015 Comportamento do sistema quando se insere um novo Evento Requisito Inserir Evento Requisitos Envolvidos Consultar Evento, Atualizar Evento, Remover Evento Atores Membro Entrada Preenchimento dos dados do evento Pré Condições 1. Servidor estar disponível 2. Usuário estar logado no sistema 3. Evento nao previamente regitrado Fluxo Principal 1. Inicia quando o usuário clica em inserir um novo evento. 2. Usuário preenche o form com os dados do evento. 3. O sistema valida os dados do usuário. 4. Inserir o novo Evento e Fim do caso de uso. Fluxo Alternativo 1. Caso os dados sejam inválidos, passo 3, um alerta é enviado ao usuário. Saída e Pós Condição 1. Mensagem de evento inserido com sucesso. 27

9.3.2.2. Diagrama de Atividade 28

9.3.2.3. Diagrama de Classes 9.3.2.4. Diagrama de Sequência 9.3.3. Editar Dados Para o caso de uso de edição de dados foi utilizada a inserção de eventos no sistema para exemplificar. 9.3.3.1. 29

ID UC6 Nome Editar Evento Status OK Autor rngs Data de criação 15/04/2015 Data de revisão 17/04/2015 Comportamento do sistema quando o usuário solicita a modificação dos dados. Requisito Editar Evento Requisitos Envolvidos Consultar Evento, Inserir Evento, Remover Evento Atores Membro Entrada Dados a serem atualizados do evento. Pré Condições 1. Servidor estar disponível 2. Usuário estar logado no sistema 3. Usuário estar visualizando um evento Fluxo Principal 1. Iniciasse quando o Membro consulta um evento e clica em editar evento 2. Alterações dos dados 3. Validação dos dados e Atualização no sistema 4. Mensagem para cliente que encerra o Caso de Uso Fluxo Alternativo 1. Se algum campo obrigatório for deixado em branco no passo 3 uma alerta será enviada. 2. Se os dados forem inválidos gera uma mensagem de alerta par ao usuário. Saída e Pós Condição 1. Alteração feita com sucesso e Mensagem para o usuário 30

9.3.3.2. Diagrama de Atividade 31

9.3.3.3. Diagrama de Classes 9.3.3.4. Diagrama de Sequência 32