UNIP APS 7 SEMESTRE

Prévia do material em texto

Impresso por Kevin Lima Cruz, CPF 356.743.788-78 para uso pessoal e privado. Este material pode ser protegido por direitos autorais e não pode ser reproduzido ou repassado para terceiros. 17/05/2021 16:48:57
Impresso por Kevin Lima Cruz, CPF 356.743.788-78 para uso pessoal e privado. Este material pode ser protegido por direitos autorais e não pode ser reproduzido ou repassado para terceiros. 17/05/2021 16:48:57
 
UNIP – UNIVERSIDADE PAULISTA 
Curso de Ciência da Computação 
 
 
 
 
 
 
 
 
ATIVIDADES PRÁTICAS SUPERVISONADAS – APS 
APLICAÇÃO DA ENGENHARIA DE REQUISÍTOS EM UM PROJETO DE SOFTWARE 
 
 
 
 
 
 
Kevin de Lima Cruz N231FC2
 
 
 
 
 
 
 
 
São Paulo SP 26 de maio de 2021
 
UNIP – UNIVERSIDADE PAULISTA 
Curso de Ciência da Computação 
 
 
 
 
 
 
 	 
 
 
ATIVIDADES PRÁTICAS SUPERVISONADAS – APS 
APLICAÇÃO DA ENGENHARIA DE REQUISÍTOS EM UM PROJETO DE SOFTWARE 
 
 
 
 
Atividades Práticas Supervisionadas do e 7º Semestres do Curso de Ciência da Computação da Universidade Paulista – UNIP. 
 
Coordenador: Prof. Mario Quintella
 
 
 
 
 
 
 
 
 São Paulo SP 26 de maio de 2021
 
SUMARIO 
 
 
 
 
1. OBJETIVO... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. 4 
2. INTRODUÇÃO.. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. .. 5 
3. CONCEITOS GERAIS.. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. 7 
1. Requisitos de Software.......................................................................... 7 
2. Engenharia de Requisitos....................................................................... 7 
3. Descrição de Requisitos......................................................................... 8 
4. DESCRIÇÃO DAS ATIVIDADES (Elicitação) ...................... .. ... .. ............... 10 
	 	1. Introdução................................................................................................. 10 
	 	1.1 Referencias.. .. .. ... .. .. .. ... .. .. .. ... .. ...... ... .... .. ..... .. .. ... .. ...... ... .... .. ... .. .. ..... .. .... 10 
	 	2. Posicionamento.. .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... 10 
2.1 Declaração do Problema.................................................................. 10 
2.2 Declaração de Produção do Produto...............................................11 
2.3 Descrição dos usuários e envolvidos............................................... 11 
 
		2.3.1 	Resumo dos envolvidos..........................................................
	12
		2.3.2 	Resumo dos usuários.............................................................
	13
		2.3.3 	Ambiente dos usuários...........................................................
	14
	2.3.4 Necessidades dos envolvidos ou usuários finais.................... 
	15
		2.3.5 	Alternativa e Concorrência.....................................................
	16
	2.4 Visão Geral dos Produtos............................................................... 
	17
		2.4.1 	Perspectivas do Produto........................................................
	17
		2.4.2 	Suposições e Dependências.................................................
	17
	2.5 Recursos do produto...................................................................... 
	17
	 	 	2.5.1 Outros Recursos do Produto....................................
	18
	4.1 DESCRIÇÃO DAS ATIVIDADES (Regra de negócio) ... ... .. ... ... ... ... .. ... ... . 
	19
	1. Introdução .... ... .. ... ... ... ... ... .. ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ...	19 
1.1 Fi n al ida de. .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... 19 
1.2 Esco po.... .. ... .. .. .. ... .. .. .. ... .. .. .. ..... .. .... ... .... .. ..... .. .. ... .. .. .. ..... .. .... ... .... . 19 
1.3 R e fe rên c i a.. .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. 20 
1.4 Visão Geral.................................................................................... 20 
	2. D ef i n iç õe s. . . . . . . . . . . . . . . . .. . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . 	21 
2.1 Área administrativa...................................................................... 21 
 
2.2 Área acadêmica......................................................................... 21 
4.2 DESCRIÇÃO DAS ATIVIDADES (Especificação)... .. ... ... ... ... ... .. ... ... ... .. 22 
1. Introduçao. ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... .. 22 
2. Objetivo .. ... ... ... ... ... .. ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... . 22 
3.Escopo ... ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... . 22 
4.Definições, acrônimos e abreviações..................................................23 
	 	4.1Referências ............................................................................23 
	 	4.2Visão Geral............................................................................. 23 
5.Descrição Geral...................................................................................23 
6.Requisitos Específicos ........................................................................ 24
	 	6.1Requisitos funcionais............................................................... 24 
	 	6.2Requisitos não-funcionais........................................................ 24 
	 	6.3 Funcionalidades. .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... .. ... ... ... ... ... .. ... 24 
7.Utilidades ............................................................................................. 25 
	 	7.1Confiabilidade.. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. .. 25 
	 	7.2 Desempenho... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... .. 25 
	 	7.3Suportabilidade. .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... . 25 
8. Requisitos de licença............................................................................ 26 
9.Observações legais, sobre direitos autorais e outras observações...... 26 
4.3 DESCRIÇÃO DAS ATIVIDADES (Modelagem) ... .. ... ... ... ... .. ... ... ... ... ... .. 27 
1. Descrição.. ... ... .. ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. .. 27 
2.Fluxo Basico de Eventos ...................................................................... 27 
4.4 DESCRIÇÃO DAS ATIVIDADES (Validação) ... .. ... ... ... ... ... .. ... ... ... ... ... .. 28 
4.5 DESCRIÇÃO DAS ATIVIDADES (Gestão) . ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. .. 30 
5. CONCLUSÃO. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. 31 6 
ANEXOS. ......... ..... ...........................................................................................................32 
 	 
	7.BIBLIOGRAFIAS... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ..	46
3 
 
 
 
Lista de Diagramas 
 
 
Diagramas de Casos de Uso.....................................................................................................46 
Diagramas de Fluxo de Dados .................................................................................................49
4 
 
 
 
Lista de Tabelas 
 
 
Tabela 1 - Analise sobre asresponsabilidades de acordo com os usuários ........ 14 
 
Tabela 2 - Descrição dos usuários com papel direto no desenvolvimento ............ 15 
 
Tabela 3 - Identificação das necessidades dos envolvidos............................................... 16 
 
Tabela 4 - Requisitos solicitados para o sistema Fusion ...................................................17 
 
Tabela 5 - Erros e medidas de solução para o sistema Fusion ....................................18 
5 
 
 
 
1. OBJETIVO DO TRABALHO 
 
 
 
O trabalho tem por finalidade realizar a análise e estudo sobre a engenharia de requisitos a respeito do desenvolvimento do software Fusion, destinado a administração de informações e controle sobre a produção e venda de brinquedos realizados pela ONG Jovens Ambientalistas, que através de programas sociais junto de ex-professores realizam um trabalho de desenvolvimento de brinquedos que visa atender as exigências ambientais. 
6 
 
 
 
2. INTRODUÇÃO 
 
 
 
O processo por traz de um desenvolvimento de software é muito complexo exige muito estudo e trabalho. Uma das razões para lidar com tal afirmação é a ampla gama de soluções distintas para se realizar uma engenharia de requisitos. O que torna também o processo muitas vezes mais complicado, é que a todo momento lidamos com pessoas para realizar tal trabalho, necessitando assim formar uma equipe muito bem preparada e focada a realizar a melhor pesquisa possível e atingir o melhor resultado aos requisitos propostos para tal desenvolvimento. No processo de levantamento dos requisitos é fundamental os entendimentos de ambas as partes envolvidas (desenvolvedor, cliente, usuários, etc.), desta forma é que o software atenderá as necessidades que forem solicitadas e realizará as funções para ele destina da. 
 
Realizar a engenharia de requisitos na elaboração de um software, hoje em dia, é altamente recomendada para aquelas empresas que buscam a excelência no seu trabalho e os caminhos que ela pretende percorrer durante sua existência. Obter uma estrutura capaz de realizar as tarefas necessárias e manter a base de funcionalidade e informação da empresa funcionando de maneira a não se perder tempo e principalmente dinheiro é o que faz a buscar a alternativa de trabalhar com a engenharia de requisitos. 
 
A finalidade deste processo de análise é obter um software de qualidade, em que não seja afetado por falhas constantes e fragilidade na segurança de seus dados. Um software de qualidade necessariamente realiza suas tarefas sem afetar de nenhuma maneira qualquer outro departamento da empresa, basicamente tudo o que ele precisa realizar é altamente avaliado durante a engenharia de requisitos, transformando assim esse software em uma ótima ferramenta de trabalho. 
 
Obter um desenvolvimento produtivo e mais tarde não ter problemas com as manutenções também é um fator crucial presente na engenharia. Atualmente o que mais causa transtornos nas grandes empresas com relação a seus softwares é retrabalho, em que um dado instante do desenvolvimento não foi realizado a devida analise, fazendo assim com que futuramente o software passe a apresentar problemas. Muitos casos conhecidos indicam que empresas gastam o dobro do 
7 
 
 
 
Valor inicial do software para corrigir falhas de processos, que uma eventual engenharia realizada com qualidade, teria evitado. 
 
Este trabalho tem como objetivo auxiliar no desenvolvimento de um software que será fundamental para o controle e a melhor administração durante a fabricação de brinquedos ambientalmente corretos, trabalho esse realizado por uma ONG com poucos recursos financeiros e que necessariamente precisa de um software que a ajude muito a diminuir o máximo seus gastos e aproveitar dos recursos que a mesma tem a disposição através de doações e programas sociais que fazem parceria com tal projeto. 
 
O software que será desenvolvido terá a função de auxiliar os usuários da ONG na melhor forma de trabalhar e conseguir matérias para o desenvolvimento de seus produtos, analisando as informações que foram obtidas através da elicitação realizada durante a engenharia de requisitos praticada para realizar o desenvolvimento da ferramenta. 
8 
 
 
 
3. CONCEITOS GERAIS 
 
 
3.1 Requisitos de Software 
 
A ONG Jovens Ambientalistas solicita o desenvolvimento de uma ferramenta computacional que será destinada a contribuir para o programa social praticado por ela que reúne jovens sem lar e os capacita a desenvolver brinquedos que atendem a normas ambientais para que sejam comercializados para o Brasil e o exterior. O objetivo em si desta ONG é dar uma vida melhor a esses desamparados, oferecendo uma maneira de ensinar algo a eles e a realizarem um trabalho, que por sua vez os remuneram por suas horas de atividades. Em razão desse seguimento, o software em questão terá como finalidade auxiliar para a manutenção deste projeto social, contribuindo para que a ONG consiga manter seu projeto de pé e evoluindo com relação ao seu trabalho. 
 
 
Baseado nas informações coletadas, o software terá por finalidade disponibilizar um sistema de cadastro e manutenção das informações destes alunos e professores, criar uma relação de projetos realizados servindo assim como portfolio até para empresas do ramo, um sistema de controle financeiro para que a administração possa trabalhar com mais segurança e organização e uma interação social, através de redes sociais, captando assim mais recursos realizando campanhas e recebendo doações através de usuários que apoiam a instituição. 
 
 
 
3.2. Engenharia de Requisitos 
 
Para o desenvolvimento do projeto ficou definido que serão seguidos alguns conceitos da engenharia de requisitos, são eles: Utilização dos templates da Microsoft disponíveis para realizar tal avaliação, relatórios e análises realizadas junto do cliente sobre as melhores estruturações do software para atender as necessidades apresentadas, analise do custo benefício evitando que o cliente pague muito por algo que necessariamente não esta ajudando. 
 
 
De início foram realizados vários encontros com o cliente em que tais reuniões servissem para colocar em pauta as necessidades que a ONG tem, junto 
as idéias e soluções para realização de uma ferramenta que auxilie e contribuía para a manutenção e o crescimento da mesma. Foi realizada uma análise da forma que a empresa trabalha, de quantos alunos ela possui, do espaço deslocado para a realização dos trabalhos por eles praticados, do quanto a empresa possui de problemas que seriam necessárias discussões sobre tais resoluções, identificação dos requisitos apresentados, projeções sobre como tornar as idéias acessíveis, encontros com alunos no intuito de também ouvir novas idéias e abordagens que talvez os responsáveis pela ONG passem despercebidos. 
 
3.3. Descrição dos Requisitos 
 
 
O primeiro passa a ser apresentado é a forma de cadastro destes alunos. O software disponibilizara uma tela de cadastro básica para que a ONG controle os alunos que fazem parte de seu projeto. Uma tela simples com os seguintes campos: 
 
NOME, DATA DE NASCIMENTO, ESCOLARIDADE, GRAU DE DESENVOLVIMENTO, SALÁRIO, será responsável por receber as informações e salva-las em um banco de dados do próprio sistema. 
 
 
Também existira uma tela cadastro para salvar as informações dos professores que fazem parte da instituição, onde receberam uma matricula que servira de auxílio na elaboração de aulas e cursos ministrados individualmente sendo que cada um fique responsável por um ensino. 
 
 
A ferramenta disponibilizara um espaço dentre suas funções que servira para que os professores cadastrem os projetos que forem realizados pelos alunos, esse cadastro apenas conterá o nome do projeto e sua finalidade. Através dessas informações será possível elaborar apresentações que visam a exibir um portfólio do que já foi desenvolvido pela ONG com a intenção de conquistar novos mercados e a venda de tais trabalhos. 
 
 
Também será desenvolvido um sistema de controle financeiro,para que a ONG prestas contas do que está sendo faturado, inserindo os valores que recebe de doações, lucro com a venda dos produtos, entre outros créditos que a mesma possa a vir se beneficiar. Também existira uma janela para que sejam lançados os 
 
 
 
valores que representem as despesas da instituição, os gastos com as despesas fixas (aluguel, energia elétrica, água, salários, etc.) e os gastos variáveis (compra de materiais, fretes dos envios dos produtos, manutenções administrativas e físicas do local, etc.). 
 
 
Um recurso do software, que foi bastante discutido e visto como uma ótima maneiras de se obter sucesso no negócio, foi a elaboração de uma tela que ficara destinada a fazer o marketing, a publicidade, da ONG por meio das redes sociais. Essa interação afetara diretamente o projeto desenvolvido pela instituição, pois ali ela poderá mostrar os trabalhos realizados pelos alunos, realizar campanhas para captação de doações e recursos vindos do governo ou membros dispostos a ajudar tal finalidade. 
 
 
Todo o projeto será desenvolvido no ambiente da web fazendo o uso da linguagem de programação JAVA e HTML5, contribuindo assim para que a ferramenta seja facilmente acessada e contribua de forma significativa para a melhoria das práticas e atividades realizadas pela ONG. 
4. DESCRIÇÃO DAS ATIVIDADES 
 
 
Elicitaçã o 
 
 
 
1. INTRODUÇÃO 
 
 
O objetivo deste documento é coletar, analisar, e definir as necessidades e características de auto nível do Fusion. Ele incide sobre os recursos necessários para as partes interessadas e os usuários-alvo e sobre as razões que os levam a essas necessidades. O detalhe de como o Fusion satisfaz essas necessidades detalhadas no uso de caso e especificações complementares. 
 
 
 
1.1 Referencias 
 
Esta elicitação foi desenvolvida através do modelo de 	tamplate rup_vision_sp.dot disponibilizado pela Microsoft. Para mais detalhes, consulte os anexos no final do documento ou acesse o link abaixo: 
 
<http://www.cinufpe.br/~i f682/RUP/webtmpl/templates/req/rup_vision_sp.htm> 
 
 
2. POSICIONAMENTO 
 
 
2.1 Declaração do Problema 
 
 
O problema de não possuir um sistema de controle sobre seus alunos e gerenciamento de suas atividades administrativas é o que tem afetado negativamente a ONG Jovens Ambientalistas. Esse problema gera um impacto devastador para uma instituição que trabalha com jovens que não tem moradia e necessitam de um auxilio, assim sendo varias entidades governamentais ficam realizando avaliações sobre as atividades da ONG e muitas vezes a mesma sofreu ameaças sobre as atividades por ela praticadas. Enfim, através dessa analise é que surgiu a ideia da ferramenta Fusion, para trazer as soluções dos problemas e auxiliar de forma geral em todos os processos da instituição. 
2.2 Declaração de posição do produto 
 
 
Para uma empresa que necessita de controle organizacional e administrativo, o Fusion atende essas necessidades e tem seus recursos voltados para os mais diversos problemas, sendo essencial para a melhoria e organização de informações importantes da empresa. 
 
 
Muitas vezes empresários optam por organizar suas informações de formas antigas, escrevendo em cadernos, utilizando agendas, mais recente dados salvos em planilhas que por sua vez não dão qualquer segurança de informação sendo que um clique em falso pode se perder anos de informações e dados salvos. 
 
 
Nos dias atuais com a inovação e evolução da tecnologia, varias ferramentas não profissionais estão disponíveis pela internet, porem sempre mantendo um padrão básico de inserção e controle de dados, o que também não é aconselhável para empreendedores confiarem seus dados a um software básico. 
 
 
A necessidade de se realizar uma consulta e a entrevista para verificar as reais necessidades do cliente é o que faz do Solution ser a melhor escolha para seu gerenciamento interno. Segurança de informações, fácil interação, métodos sociais e estabilidade durante sua execução é apenas alguns dos recursos que foram implantados na ferramenta fazendo assim alcançar um ótimo mercado. 
 
 
3. DESCRIÇÃO DOS USUARIOS ENVOLVIDOS 
 
 
A abordagem realizada referente aos usuários envolvidos intensificou-se em atender as necessidades dos administradores da ONG e os professores que lecionaram suas aulas. De modo geral os envolvidos junto ao projeto também estão os alunos, que de uma maneira ou outra também disponibilizarão de recursos do software para se cadastrar junto a instituição, publicar seus trabalhos, organizar seus cronogramas de fabricação, entre outros fatores importantes para seus desenvolvimentos pessoais. 
Para melhor especificar a utilização do Fusion por parte de seus usuários, segue abaixo houve uma divisão entre os administradores (Professores e os responsáveis pela ONG) e os alunos (jovens sem lar que necessitam de um apoio). 
 
 
As pessoas que gerenciam a instituição e os professores que lecionam as aulas para os jovens, terão acesso a toda ferramenta, porem existirá certas restrições para que se obtenha a segurança das informações e evite um descontrole por parte do gerenciamento. Os professores terão acesso as informações jurídicas e fiscais da ONG, porém não possuíram permissões de alteração dessas informações, sendo destinada apenas aos responsáveis pela gerencia. Seguindo o mesmo padrão os gerentes e administradores terão acesso as informações dos alunos e dos professores porem não poderão alterar ou realizar qualquer procedimento que não seja avaliado pelos professores, podendo assim impedir que de alguma maneira um descuido possa atrapalhar o trabalho realizado por esses professores. 
 
 
Em nenhum momento os jovens alunos terão acesso ao sistema de cadastro e os recursos de controle financeiro. Para eles existirá apenas um acesso destinado as redes sociais, sendo que através de uma conta da empresa eles possam publicar seus trabalhos e interagir com outras pessoas sobre o que eles vêm aprendendo e suas conquistas diante do auxílio da ONG. 
 
 
3.1 Resumo dos Envolvidos 
 
Através de uma interação e várias entrevistas realizadas com os responsáveis da ONG, foram levantadas questões sobre o nível do conhecimento sobre informática de cada um, as dificuldades em cada usuário entender os recursos do software e melhorias que poderiam ser realizadas, ouvindo ideias e recebendo um feedback sobre as principais necessidades para serem implantadas no projeto. De acordo com os resultados obtidos foram possíveis justificar as necessidades para cada usuário. 
 
 
 
 
Tabela 1: Analise sobre as responsabilidades de acordo com os usuários. 
 
Fonte: Próprio autor. 
 
 
3.2 Resumo dos Usuários 
 
 
Após a realização das pesquisas e entrevistas citadas anteriormente foram obtidos resultados com relação as classes de usuários que terão papel importante para o desenvolvimento do projeto. Abaixo encontra-se um resumo que descreve as participações diretas dos envolvidos para obter o produto final. 
 
Tabela 2 – Descrição dos usuários com papel direto no desenvolvimento 
 
Fonte: Próprio autor. 	 	 
 
 
3.3 Ambiente do Usuário 
 
 
A organização dos trabalhos dentro da ONG é definida da seguinte maneira. Atualmente a instituição possui 20 pessoas destinadas a administração da empresa e ministrar as aulas e trabalhos para os jovens. Dentre elas 3 pessoas são responsáveis pelo setor financeiro, realizando tarefas administrativas, 8 pessoas tem a responsabilidade de coordenar os jovens, controlar seus cadastros e documentações e realizar trabalhos de recursos humanos, visando sempre agir corretamente diante da lei e buscando sempre o melhor para os alunos. Os profissionais restantes ficaram a cargo de ministrar as aulas, orientar durante os trabalhos, realizar os processos de venda e publicação dos produtos, entre outros fatores ligados diretamente com a mercadoria final. 
 
Analisando as funções descritas obtemos uma tabela que mostra todo o processo divido em sessões, que são eles: 
 
1. Controle Administrativo 
2. Atividades voltadas na área de RecursosHumanos. 
 
3. Atividades acadêmicas e comerciais. 
 
Os tempos para realização de cada tarefa é ilimitado, com o intuito de manter a instituição organizada e visando sempre trabalhar de forma a lidar com a maior serenidade possível com relação aos jovens, que em suas vidas já enfrentam problemas e transmitir isso aos alunos seria algo muito negativo com relação ao que a ONG propõe para a vida dessas pessoas. 
 
O tempo gasto para realizar as tarefas atende de forma excelente as expectativas da empresa em busca de seus objetivos considerando que o sistema execute de forma rápida e com ótimo desempenho não ocorrendo falhas. 
 
O sistema em si, nada mais é que um sistema de controle interativo capaz de realizar tarefas distintas afim de determinada atividade. Atualmente está programado para a plataforma web, trabalhando com mais segurança de informações, acesso rápido e fácil e área remota disponível para rápida manutenção. Num futuro nem tão distante, a migração para novas plataformas já está sendo projetada e inicialmente as primeiras ideias são os sistemas mobiles, o que poderá trazer ainda mais interação entre professores e alunos e clientes e empresa. 
 
 
 
 
 
3.4 Necessidades dos Envolvidos ou Usuários Finais 
 
Tabela 3 – Identificação das necessidades dos envolvidos 
 
Ne ce s si da de 
 
 	 	 
 	 	 	 	 
Fonte: Próprio autor. 
 
 
 
 
3.5 Alternativas e Concorrência 
 
 
 
Os recursos que foram identificados para resolução dos processos administrativos da instituição não são considerados irregulares, porem são definidos de forma amadora. Até o presente momento a ONG trabalhava utilizando os produtos do pacote Office da Microsoft. Seus controles eram bem realizados porem não garantiam um recurso mais profissional e que atendesse a requisitos como segurança das informações, acesso, organização, entre outros. 
 
 
Trabalhar com as ferramentas disponibilizadas pela Microsoft tem muita utilidade quando se busca forma de inserir e administrar informações. Hoje em dia com muitas melhorias a empresa conseguiu atingir resultados ótimos com relação a seus produtos. Pessoas do mundo todo as vezes preferem realizar suas atividades administrativas através de uma planilha do que um software considerando a ferramenta Office como sendo algo mais fácil de lidar. Mas há quem fosse mais exigente com relação a interface de trabalho e segurança, o que faz não ser uma saída tão viável para se controlar um grande e valioso número de dados. 
 
 
Considerando que a empresa fazia uso de um produto de uma concorrente porem algo genérico e não especifico e destinado a um usuário final, o software Fusion traz o de melhor desses recursos atendendo as necessidades especificas da i nsti tui ção. 
 
 
 
 
4. VISÃO GERAL DOS PRODUTOS 
 
4.1 Perspectiva do Produto 
 
 
 
A ferramenta Fusion quando comparada com os recursos que a ONG vinha utilizando para administrar seus serviços e informações, obtém um resultado considerável quando avaliada no âmbito de anteder as necessidades da instituição. Tal resultado visa a melhoria da interface de controle, da maneira em como organizar tais informações, desempenho com relação à um grande número de informações a serem administradas e a plataforma utilizada o que mantém a utilização do software mais atraente e segura. 
 
4.2 Suposições e Dependências 
 
O projeto basicamente terá apenas a necessidade de conexão com a internet, porem existe também um sistema de trabalho off-line para que o usuário que necessite de um registro ou execução de alguma tarefa obtenha seu resultado. Com relação a necessidade do acesso à internet, este foi desenvolvido e implementado desta maneira visando que a web é considerada uma forma muito mais rápida e de melhor desempenho para se trabalhar do que softwares desktop, sendo que também meios de backup disponíveis na web foram fatores que levaram a tal desen vol vi mento. 
 
5. RECURSOS DO PRODUTO 
 
O Fusion, como toda e qualquer ferramenta que gerencie informações e necessite de um responsável para tais, contara com um sistema de login para acesso. Cada acesso será configurado de acordo com suas restrições e disponibilidades. A interface para controle será bem simples de se visualizar, evitando com que o usuário se confunda durante a utilização da ferramenta. O sistema irá trabalhar com acesso via rede com impressoras para quando da necessidade de impressões de relatórios. 
 
Para área de administração e gestões financeiras o software disponibilizara uma interface semelhante a uma planilha porem altamente desenvolvida e conectada com outras categorias, fazendo com que a informações flutue e sincronize-se com outros dados para realização de cálculos e comparações. O sistema utiliza também 
 
de um banco de dados vinculado para salvar suas informações, atualmente este recurso faz uso do Microsoft SQL SERVER para web. Além do banco de dados o software disponibilizará ao cliente um sistema de backup direto na nuvem fazendo com que a segurança dos dados caso ocorra algum problema na ferramenta se mantenha intacta e evite eventuais perdas de informações. 
 
Nas áreas dos professores, o sistema disponibiliza recursos de avaliação pessoal de cada aluno, considerando suas atividades, seu desempenho, controle de faltas e avaliações. Um sistema de gerenciamento de matérias e trabalhos será destinado quando o professor dor realizar suas avaliações e projetos acadêmicos. O trabalho social realizado através das redes sociais utilizara os serviços do Facebook e do Instagram, ambos com a finalidade de publicações e marketing dos produtos que serão desenvolvidos. 
 
Aqui foram exibidos os recursos disponíveis de forma básica e não tão complexa para o entendimento, porem junto do software disponibilizamos um manual de instruções onde explica cada função e demonstra um tutorial para utilização dos recursos disponíveis. Lembrando também que será realizado vários treinamentos para a liberação definitiva do projeto para ONG e também será deixado claro que para eventuais dúvidas e esclarecimentos um profissional estará disponível para o atendimento. 
 
5.1 OUTROS RECURSOS DO PRODUTO 
 
Para se obter um melhor desempenho do Fusion vale ressaltar que uma boa conexão com a internet é aconselhada pois para realização de backups e impressão de relatórios muitas vezes necessitam de um consumo considerável para realização de suas execuções. 
Regras de Negócio 
 
 
1. INTRODUÇÃO 
 
 
O documento aqui descrito se trata de um sistema web destinado a controle e gestão de informações relacionadas a aspectos administrativos e pessoais. 
Inicialmente os problemas enfrentados e que favoreceram para o desenvolvimento do projeto foram que vinham sendo realizadas maneiras amadoras de gestão de dados da ONG Jovens ambientalistas, pois trata-se de uma instituição destinada ao auxílio de jovens que não tem lar e necessitam de alguma ajuda para se desenvolver socialmente. A empresa não dispunha de uma ferramenta profissional e definida para realizar seus controles internos, desde de dados financeiros a venda de produtos. Contudo o desenvolvimento do software Fusion se deu após entrevistas realizadas com os envolvidos e os usuários que farão uso de tais ferramentas. 
 
 
1.1. 	 Finalidade 
 
Fornecer uma visão geral da necessidade do desenvolvimento do projeto Fusion visando atender as necessidades da ONG para realização de sua admini stração. 
 
1.2. 	 Escopo 
 
A necessidade de atender o problema de organização e administração de suas atividades por parte da ONG foi o que destinou ao desenvolvimento de um software capaz de atender os requisitos solicitados por tal. Assim sendo o projeto em si visa auxiliar no entendimento da utilização do projeto entre os usuários a que se destina facilitando assim a execução de suas tarefas e o desenvolvimento da empresa de forma geral. 
 
O que temos por influência em realizar tal projeto é o trabalho realizado com os jovens sem lar, que necessitam de algum recurso de acesso a sociedade e é desta maneira quea instituição buscou a implantação desta ferramenta em sem âmbito de negócio. 
Abaixo segue uma lista de motivos identificados que visão a realização desta ferramenta. 
 
Qual o problema identificado? 
 
Uma fraqueza no setor organizacional da ONG Jovens Ambientalistas com relação a suas atividades administrativas. 
 
Qual o papel da ferramenta Fusion para atender a necessidade da ONG? 
 
Disponibilizar uma ferramenta capaz de atender os requisitos de uma boa administração, visando uma facilidade e uma melhor interação por parte dos envol vi d os. 
 
Quem serão os beneficiados ? 
 
Gestores, Professores e essencialmente os alunos. 
 
Quais os resultados esperados? 
 
Manter vivo o trabalho da ONG para com esses jovens. 
 
 
 
 
1.3. 	Referências 
 
O tópico apresentado foi desenvolvido com base no modelo de template rup_brul.dot da Microsoft. Este template está disponível no ícone abaixo e também nos anexos do trabalho. 
 
<http: // www.wthree x.com/r up/por tug ues/web tmp l/te mplates /bm/r up_br ul .htm> 
 
 
 
1.4. 	 Visão Geral 
 
De forma breve e bem definida o tópico acima teve por finalidade esclarecer sobre o problema que a instituição enfrentava e sobre a utilização do software Fusion. O documento encontra-se muito bem escrito e não sucinta de muitas defini çõ es. 
2. DEFINIÇÕES 
 
2.1. Áreas administrativas 
 
Sobre o desenvolvimento do sistema de administração: 
 
[RN 2.1.1] Área de acesso: o software inicialmente solicitara que os responsáveis cadastrem um usuário e senha para realização de um login configurado para suas atividades relacionadas. 
 
[RN 2.1.2] Controle Financeiro: essa aplicação irá conter “planilhas” estruturadas de forma a receber valores financeiros para realização de cálculos e analises com base em todo o seguimento considerado administrativo. 
 
[RN 2.1.3] Relatórios: ferramenta disponível para visualização ou impressão de relatórios para realização de analises. 
 
[RN 2.1.4] Sessão professores e alunos: Aqui o gestor apenas poderá visualizar as informações sobre tal seguimento porem não terá permissão de realizar quaisquer alterações sem a consciência dos professores. 
 
2.2. Área acadêmica 
 
Sobre o desenvolvimento do sistema acadêmico: 
 
[2.2.1] Área de acesso: assim como na área administrativa também será necessário que os professores cadastrarem um login para acesso, portanto a novidade neste caso é que os alunos também poderão acessar este ambiente e receberão também seus logins. 
 
[2.2.2] Área acadêmica sobre as aulas: este recurso estará disponível apenas para os professores, desta maneira eles poderão controlar os alunos, as atividades a serem exercidas, o lançamento das notas sobre as avaliações dos projetos e controle dos arquivos que serão armazenados virtualmente. 
 
[2.2.3] Área acadêmica para os alunos: será liberado acesso para os alunos os materiais de estudos que serão utilizados durante as aulas, os seus dados pessoais como nome, documentos e nota da avaliação de desempenho. Além destes recursos também terão acesso ao sistema de compartilhamento e publicidade realizado através das redes sociais, porem cada publicação será avaliada antes por um professor e autorizada a publicação. 
Esp ecificação 1. INTRODUÇÃO 
 
 
O fundamento deste documento é expor as necessidades gerais do sistema, sendo que através dos usuários finais possa se definir alguns requisitos. 
 
2. OBJETIVO 
 
Através das análises e entrevistas realizadas foram levantados alguns requisitos para o sistema Fusion. O sistema é composto por três áreas distintas, administrativa, academia e acadêmica para alunos. Cada área deverá possuir restrições para certas utilidades que são visíveis para ambas as interfaces. Dessa forma o controle geral realizado pela gestão tera acesso também as outras áreas porem não poderá efetuar alterações antes de uma aprovação do setor responsável. 
 
Sobre as ferramentas e interface a ser trabalhada os requisitos são os mínimos devido que os usuários não entendem tanto de desenvolvimento, porem alguns fatores como a facilidade de interação entre telas, atalhos, entre outras coisas funcionais simples, foram solicitadas. 
 
2.1 Requisitos não-funcionais: 
 
Requisitos de acesso do sistema: 
 
O sistema disponibiliza para os usuários 3 tipos específicos de cadastros de logins, em que cada um através de um comando são restritos a algumas funcionalidades e acessíveis a outras. Isso foi bastante discutido durante as entrevistas para manter uma certa solidez com relação a segurança das informações da ONG. 
 
3. ESCOPO 
 
Para a realização de implantação dos requisitos será realizado alguns passos importantes para entender o que precisará ser trabalho na ferramenta: 
 
 
Analise do atual desenvolvimento e administração da empresa: 
 
Um estudo sobre o atual momento de gestão e as atividades diárias da instituição será realizado, assim avaliando o que realmente precisa existir no software para suprir tal necessidade. 
Análise e especificação do sistema: 
 
Através das informações coletadas e através deste procedimento, a especificação geral será elaborada. 
 
Reuni ões: 
 
Reuniões semanais serão necessárias para que possa estar sendo demonstrado e discutido alguns fatores que já estarão sendo implantados assim sendo fazendo com que exista um melhor acompanhamento do projeto. 
 
Testes: 
 
Testes serão realizados para que possa ser melhor administrados e também verificar os erros que estiverem acontecendo durante a implantação. 
 
 
4. DEFINIÇÕES, ACRÔNIMOS E ABREVIAÇÕES 
 
ONG – organização não governamental. 
 
 
 
 
4.1 Referências 
 
A documentação necessária para elaboração deste conteúdo poderá ser encontrada no link abaixo que segue o modelo de template rup_srs.dot. 
 
<http: //w ww .wthreex.co m /r up/p or t ugues/webtmpl/templa tes/req/ rup_ srs. htm > 
 
 
4. 2. Visão Geral 
Especificações representam uma descrição de um item, mas não um item real. Funcionam basicamente como lista de itens que são necessários para o desenvolvimento de um software. 
 
 
5. DESCRIÇÃO GERAL 
 
Perspectiva do software: O software tem como objetivo estabelecer uma melhor administração das atividades dentro da empresa, melhorando a forma de gestão e realização de suas finalidades. 
Funções do software: funções administrativas e gestão de atividades. 
 
 
Características dos usuários: Aluno s–não terão qualquer responsabilidade com relação ao desenvolvimento do sistema. Professores – detém de um papel importante para o desenvolvimento do software com relação a sua área de atividades. Gestores – total responsabilidade para o desenvolvimento do projeto abrangendo fatores gerais para realização do mesmo. 
 
 
6. REQUISITOS ESPECÍFICOS 
 
6.1 Requisitos funcionais: O sistema deve possibilitar a gestão de atividades relacionadas a todos os setores praticados pela ONG, desde fatores administrativos, educacionais ou trabalhos específicos. 
 
6.2 Requisitos não-funcionais: 
 
O sistema será implementado utilizando a plataforma JAVA fazendo uso de frameworks que de algum modo auxilia neste desenvolvimento. Esta tecnologia faz com que o sistema seja robusto e ganhe em desempenho e consi stênci a. 
 
O banco de dados será o Microsoft SQL SERVER destinado a desenvolvimento WEB. O tempo de resposta do sistema não deverá ultrapassar 20 segundos. 
 
Deverá ser compatível com interface acessível para mobile, tablets ou desktop. 
 
6.3 Funcionalidade 
 
Cadastro de usuários e alunos. 
 
Controle por login de acesso para cada usuário Controle financeiro e de atividades academias. 
Acesso a redes sociais para publicidade e interação. 
7. UTILIDADE 
 
Foi estimado um tempo de 40 minutos de atividade e treinamento necessários para que os usuários aprendam as funcionalidades do sistema. 
 
7.1 Confiabilidade 
 
O projeto tem uma confiabilidade estimada em 0.94 (94%) por 10 horas quando atendendo uma carga de até 75% de sua capacidade. 
 
7.2 Desempenho 
 
5 segundos o tempo estimado para que o sistema acesso o login especificado e entreno recurso especifico. 
 
Quando a resposta de acesso a telas e recursos, estima-se um tempo de 3 segundos para que cada uma envie sua resposta. 
 
O projeto ocupara apenas 1.3 Gb do espaço de armazenamento da plataforma que o mesmo está sendo instalado. 
 
Sobre a memória principal o mesmo requisitará no máximo 70 MB do seu uso. 
 
7.3 Suportabilidade 
 
O que mais se preza no desenvolvimento de modo geral nos trabalhos de hoje em dia é a forma de codificação de seu código. Isso se dá pelo fato de que exista uma facilidade ao realizar um suporte no software em que não seja o próprio desenvolvedor que esteja acessando. 
 
Este padrão de codificação que é solicitado visa facilitar a compreensão e entendimento da linha de programação que define um comando ou um requisito. Abaixo é apresentado o padrão de codificação para este projeto. 
 
Classes - As classes são divididas em pacotes destinados a cada tipo de exercício praticado pelo cliente e no que foi definido nas reuniões sobre os requisitos. 
 
Métodos - Os nomes dados aos métodos seguira um padrão de formatação com abreviações similares para melhor visualização. Apenas os métodos receberam comentários de funcionalidade também visando a rápida compreensão. 
 
Documentação de pacotes - é de suma importância que seja especificado a relação de pacotes com suas classes. 
 
Espaços em branco e tabulações - a utilização de uma estruturação mais “limpa”com relação ao código também favorece a melhor visualização de suas funcionalidades, portanto utilizar linhas em branco quando dividi os métodos e funções e uma tabulação padronizada só tendem a acrescentar. 
 
Visibilidade - manter a visibilidade tão acessível é muito importante. 
 
 
 
 
8. REQUISITOS DE LICENÇA 
 
O código do software estará disponível de acordo com a licença GPL (General Public License). 
 
9. OBSERVAÇÕES LEGAIS, SOBRE DIREITO-AUTORAIS AUTORAIS
 	E OUTRAS 
 
OBSERVAÇÕES 
 
As leis de proteção dos direitos autorais proíbem a comercialização do software por parte do usuário, também como locação sem a autorização do desenvolvedor detentor dos direitos autorais. 
 
A ferramenta por sua vez só poderá auxiliar nas atividades praticadas pela empresa, sendo completamente proibido realizar o uso do mesmo para serviços de tercei ros. 
 
Não será responsabilidade do desenvolvedor qualquer problema que o usuário venha a ter caso o mesmo não tenha lido corretamente o manual e/ou analisado o contrato de venda antes de concordar com os termos. 
 
Modelagem 1. DESCRIÇÃO 
 
 
 
O diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e os usuários. Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. 
 
 
2. FLUXO BASICO DE EVENTOS 
 
 
Caso de Uso: Cadastros de envolvidos e usuários Atores: Gestores, professores e alunos. 
 
Descrição: Esta etapa é referente ao cadastro dos usuários envolvidos com o projeto, organizando de maneira profissional suas informações e registro de suas atividades, além de poderem ser alteradas, excluídas, etc. 
 
 
Caso de Uso: Gestão e controle financeiro Atores: Gestores. 
 
Descrição: Este procedimento visa disponibilizar um sistema de controle e gerenciamento da empresa conforme as necessidades e atividades da mesma. Aqui é realizado todo o controle financeiro e de gestão pessoal da instituição. Também é de acesso aos gestores as outras etapas do software que visão atender as atividades praticadas por alunos e professores, porem o acesso é apenas visual sendo que qualquer alteração deverá ser autorizada pelos responsáveis. 
 
 
Caso de Uso: Controle de alunos e 
atividades Atores: Professores 
 
Descrição: Este procedimento visa atender as necessidades de trabalho dos professores que estão envolvidos com o projeto. Essa etapa disponibiliza um gerenciamento das atividades, avaliações, controle dos dados dos jovens e realização e organização de seus projetos. A importância deste recurso é manter a máxima organização pois se tratando de jovens a responsabilidade com o trabalho é fundamental para se obter o resultado esperado. 
 
 
 
Caso de Uso: Interação e publicação de projetos Atores: Alunos. 
 
Descrição: Este recurso disponibiliza para os alunos uma maneira de interagir e apresentar seus trabalhos para diversas pessoas interessadas pelo intuito da ONG no trabalho que realiza. Os alunos terão acesso a suas informações pessoais e as redes sociais voltadas para divulgação dos trabalhos. Não será de qualquer responsabilidade dos alunos qualquer atividade que seja envolvida com gestão e administração de atividades, ambas são executadas e verificadas por seus respectivos profissionais requisitados. 
 
 
Diagrama de Casos de Uso: 
 
 
 
 
 
Va lidação 
 
 
Através das reuniões e avaliações realizadas junto dos profissionais da ONG, alguns requisitos foram solicitados visando atender as necessidades de gerenciamento e contrato de serviço, requisitos esses funcionais que o programa devera possuir. 
 
Estes requisitos foram trabalhados e definidos de forma a atender a solicitação da ONG para o Fusion. 
 
 
 
Tabela 4 – Requisitos solicitados para o sistema Fusion. 
 
Requisitos Solicitados 	Requisitos Atendidos 
Cadastro de informações (Dados de gestores, 	O software disponibiliza uma área de cadastro 
professores e alunos) dividida em 3 departamentos visando atender os 	cargos específicos. 
Controle financeiro e administrativo O software tem o recurso de gerenciamento de 	valores semelhante a uma planilha excel porem 	de forma profissional e melhor desenvolvida para 	facilitar o acesso e controle de dados. 
Controle de avaliação e notas dos alunos 	Acesso do recurso para gerenciamento de 
 	projetos, avaliações e analises de desempenho 	através de sistemas desenvolvidos propriamente 	para tal função. Também estará disponível uma 	área para elaboração de questões baseando em 	resultados de busca diretos da internet, 	trabalhados de forma acadêmica profissional. 
Divulgação e interação dos alunos para com as 	Na área do aluno foi desenvolvido um recurso 
pessoas interessadas. para acesso a mídias sociais com o fundamento 	de publicar os trabalhos e realizar a interação de 
 	jovens que produzem os brinquedos com os 	c lientes . 
 	 Fonte: Próprio autor. 	 
 
 
 
Gestão 
 
 
Neste tópico são abordados possíveis erros relacionados ao desenvolvimento e utilização da ferramenta e suas medidas preventivas de reparação. 
 
 
Tabela 5 – Erros e medidas de solução para o sistema Fusion. 
 
 
 
Todo o projeto foi desenvolvido visando evitar os erros citados logo acima porem se tratando de uma ferramenta, pode ocorrer de algumas falhar vierem a se manifestar durante a execução do software sendo assim fundamental que o cliente entre em contato com o suporte e solicite as melhorias necessárias. 
 
 
 
5. CONCLUSÃO 
 
 
Após todo o desenvolvimento dissertativo por parte da equipe para apresentar a importância de um software do seguimento do Fusion para atender as necessidades uma instituição que por não ser governamental e por se tratar de um programa de auxílio a jovens carentes, será apresentada uma breve consideração final a respeito da idéia praticada para o desenvolvimento de tal ferramenta. Tudo que foi realizado durante o desenvolvimento foi apresentado de forma clara e objetiva na dissertação com o intuito de fazer com que o usuário visualize e considere a importância de se desenvolver uma ferramenta com tais funções. Considerando sua estruturação e desenvolvimento o projeto foi muito bem elaborado por seus desenvolvedores e também pelos envolvidos que foram de suma importância para a troca de informações e idéias. 
 
Todos os requisitos e métodos utilizados para o desenvolvimento do projeto seguem as técnicas da engenharia de software. Todo o trabalho contribuiu de forma acintosa no nosso desenvolvimento e aprendizado relacionado a disciplina adotada. Seguindo o que foidiscutido e absorvido em sala de aula o trabalho foi todo elaborado seguindo os requisitos solicitados. 
 
Sendo assim, alcançamos de forma positiva os resultados que eram esperados, entendendo mais sobre a técnica de engenharia, métodos de interação com clientes, importância de seguir os requisitos que nos foram solicitados, entre outros fatores que acrescentaram no nosso aprendizado. 
Impresso por Kevin Lima Cruz, CPF 356.743.788-78 para uso pessoal e privado. Este material pode ser protegido por direitos autorais e
não pode ser reproduzido ou repassado para terceiros. 17/05/2021 17:01:29
29 
32 
31 
 
 
 
 
 
6. ANEXOS 
 
 
Fusion 
 Visão 
 
 
Versão 1.0 
 
 
 
 
 
 
 
 
 	Histórico da Revisão 
De sc r iption D
a te
 
V
e r s
i
on
 
A
ut h o
r
 
 
 
 
 
2
0
/
0
5
/
17
 
1
.
0
 
V
e
r
s
ão
 I
n
i
c
ial
 
Jo
ão 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Índice Analítico 
 
1. Introdução ................................................................................................................................................................................... 37 
1.1 Referências ............................................................................................................................................................... 37 
2. Posicionamento.......................................................................................................................................................................... 37 
2.1 Descrição do Problema ........................................................................................................................................... 37 2.2 	Sentença de Posição do Produto ........................................................................................................................... 37 
2.3 Descrições dos Envolvidos e Usuários ................................................................................................................ 38 
2.4 Resumo dos Envolvidos ......................................................................................................................................... 38 
2.5 Resumo dos Usuários.............................................................................................................................................. 38 
2.6 Ambiente do Usuário .............................................................................................................................................. 39 
2.7 Resumo das Principais Necessidades dos Envolvidos ou Usuários................................................................ 39 
3. Visão Geral do Produto ............................................................................................................................................................ 40 
3.1 Perspectiva do Produto ........................................................................................................................................... 40 
3.2 Suposições e Dependências ................................................................................................................................... 40 
4. Recursos do Produto ................................................................................................................................................................. 40 5. Outros Requisitos do Produto ................................................................................................................................................. 40 6. Restrições............................................................................................................................... Error! Bookmark not defined. 
 
Visão 
 
1. Introdução 
 
A finalidade deste documento é coletar, analisar e definir as necessidades e características do Projeto Fus ion. Ele enfoca os recursos de que os envolvidos e usuários-alvo precisam e mostra por que essas necessidades existem. Os detalhes de como o sistema atende a essas necessidades estão descritos nas especificações suplementares e de caso de uso. 
 
1.1 Referências 
 
As informações aqui dispostas foram coletadas durante visita e entrevista com o cliente e os colaboradores envolvidos. 
 
2. Posicionamento 
 
2.1 Descrição do Problema 
 
	O problema 	O sistema atual, desenvolvido em C, está quase não-operacional e 
possui pouca eficiência no atendimento das necessidades do negócio. 
Afeta Controle de pessoal, produtos e financeiro cujo impacto é Administrativo, Financeiro e Recursos Humanos uma boa solução seria Desenvolver um novo sistema de controle 
 
2.2 Sentença de Posição do Produto 
 
	Para 	ONG Jovens Ambientalistas 
	Quem 	Responsáveis pelas funções de Recursos Humanos e Administração 
	O (nome do produto) 	Fusion 
	Que 	Realiza o controle de pessoal, produtos e financeiro 
	Diferente de 	Sistema atual 
Nosso produto Possui tecnologia de ponta, amplamente utilizada pelo mercado atual e visa suprir as necessidades do negócio atual assim como adicionando novos recursos, maior controle e maior produtividade. 
 
2.3 Descrições dos Envolvidos e Usuários 
 
Serão envolvidos neste projeto: 
 
· Equipe de Desenvolvimento e Implantação do sistema, assim como Recursos Humanos. 
· Responsável pela gestão do projeto Fusion. 
· Responsável pelo controle de pessoal da empresa cliente. 
 
2.4 Resumo dos Envolvidos 
 
	Nome 	Descrição 	Responsabilidades 
	João Fodan 	Chefe de Seção 	Supervisionará as atividades do 
desenvolvimento da nova solução 
	Ragnar Lothbrok 	Chefe de Seção 	Supervisionará a implantação do sistema 
	Ben Tennyson 	Analista de TI 	Modelagem e desenvolvimento 
 
 
2.5 Resumo dos Usuários 
 
	Nome 	Descrição 	Responsabilidades 	Envolvido 
Usuário 	Responsáveis pelo 
Administrador 	Controle de Pessoal. 
do Controle de Pessoal 
 
Prover informações necessárias 	Não se aplica. 
para as bases de dados do Sistema; Zelar para que os dados armazenados permaneçam confiáveis, Efetuar correções nos dados cadastrados quando não houver ações do prórprio Sistema que permitam realizar tais ações 
	2.6 Ambiente do Usuário 
 
O Sistema atualmente em uso emprega a Plataforma MS-DOS / Windows, e foi desenvolvido em Linguagem C conjuntamente com Banco de Dados MICROSOFT SQL SERVER. Não dispõe de 
documentação por nenhuma das partes envolvidas e, por se tratar de tecnologia obsoleta, é de difícil manutenção. Adicionalmente, em visita, identificou-se que o software é utilizado em um computador/servidor Intel Pentium 4, equipamento de pouca capacidade de processamento, o qual dispõe de pouco espaço em disco para que a base de dados continue expandindo. Ainda sobre o equipamento, ele apresenta picos de super-aquecimento, congelando o qualquer ação do Sistema Operacional. Dessa forma, o hardware tornou-se o ponto único de falha e, em caso de falha, poderá ser perdida toda base de dados – atualmente sem backup. 
 
O Sistema proposto empregará Plataforma Web, podendo ser acessado por meio de qualquer computador conectado à internet. Tal solução utiliza Softwares Livres, dispensando a aquisição de licenças. Toda essa estrutura está apoiada nas tecnologias: Java (Linguagem de Programação), Microsoft SQL SERVER (Banco de Dados) e Jetty (Servidor Web), hospedadas no servidor cloud IBM Bluemix.. 
 
2.7 Resumo das Principais Necessidades dos Envolvidos ou Usuários 
 
Necessidade Prioridade Preocupações Controle de Pessoal Alta Controle de 
cadastro de colaboradores e estudantes. 
Controle de Financeiro 	Alta 	Controle de 
custos de colaboradores e estudantes. 
Controle de Produtos 	Alta 	Controle 
Interno. 
 
 
 
 
 
 
 
 
 
 
 
 
Solução Atual 	Soluções Propostas 
Provê suporte à 	Desenvolvimento de necessidade porém 	um novo Sistema com baixa 	que supra a 
eficiência, com necessidade com riscos de diversas eficiência, cobrindo naturezas. as lacunas deixadas pelo legado. Provê suporte à Desenvolvimento de necessidade porémum novo Sistema com baixa que supra a 
eficiência, com necessidade com riscos de diversas eficiência, cobrindo naturezas. as lacunas deixadas pelo legado. Provê suporte à Desenvolvimento de necessidade porém um novo Sistema com baixa que supra a 
eficiência, com necessidade com riscos de diversas eficiência, cobrindo naturezas. as lacunas deixadas pelo legado. 
3. Visão Geral do Produto 
Prover acesso a controle de pessoal, controle financeiro e controle de produtos. 
 
3.1 Perspectiva do Produto 
 
Produto que proporciona maior controle e produtividade para a empresa que o utiliza. Sendo um sistema/aplicação, requer um servidor ou serviço de hospedagem, assim como profissionais treinados em sua utilização. 
3.2 Suposições e Dependências 
Caso ocorra imprevistos durante a contratação do serviço de hospedagem IBM Bluemix, deverá ser contratado outro serviço semelhante, e o documento visão deverá ser atualizado. 
 
4. Recursos do Produto 
· Controle de Pessoal: 
Proporcionar o cadastro de colaboradores e estudantes para acesso as aulas. 
· Controle Financeiro 
 	Proporcionar o controle de gastos para manter a operação da ONG 
· Controle de Produtos: 
 Proporcionar ferramentas e facilidades para controle dos produtos e itens necessários para o funcionamento da ONG e suas atividades. 
 
 
5. Outros Requisitos do Produto 
 
Plano do servidor de hospedagem com que ofereça um processador Intel i7 Quarta Geração, armazenamento de 1TB e backup mensal da base de dados. 
Prover garantia de total disponibilidade e realocação de domínio caso a conexão com o sistema saia temporariamente do ar devido a problemas na máquina hospedeira. 
Disponibilidade de máquinas, horários e pro atividade do cliente e seus colaboradores para treinamento sobre o sistema e sua utilização. 
Criar um manual do usuário para explicação do passo a passo da utilização e uma base de conhecimento para dúvidas mais comuns e soluções de erros. 
 
 
 
 
Fusion 
 
Regras de Negócios 
 
Versão 1.0 
 
 
 
 
 	Histórico da Revisão 
De sc r iption D
a te
 
V
e r s
i
on
 
A
ut h o
r
 
 
 
 
 
2
0
/
0
5
/
17
 
1
.
0
 
V
e
r
s
ão
 I
n
i
c
ial
 
Jo
ão 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Ín
d
ice
 
A
n
alí
t
i
co
 
 
1
. 
 
I
ntr
o
d
uçã
o 
 
1.1
 
Fin
a
li
dade
 
 
1.2
 
E
sco
po
 
 
1.3
 
R
ef
erên
c
ias
 
 
1.4
 
Visão
 Ger
a
l 
 
 
 
2
. 
 
Def
in
iç
õ
es
 
 
2.1
 
C
o
ntr
o
le d
e Pessoa
l 
2.2
 
C
o
ntr
o
le F
in
a
nceiro
 
2.3
 
C
o
ntr
o
le d
e Pr
o
d
utos
 
 
 
 
 
 
 
 
 
 
 Regras de Negócios 
 
1. Introdução 
 
Esse documento tem como finalidade a apresentação das regras de negócios necessárias para a criação do software, afim de atingir todos os requisitos necessários esperados pelo cliente. 
 
1.1 Finalidade 
 
Apresentar as regras de negócio do projeto Fusion 
 
1.2 Escopo 
 
Esse documento refere-se ao projeto Fusion e tem como finalidade documentar e expor as regras de negócio referentes ao mesmo. 
 
1.3 Referências 
 
Para mais informações sobre o projeto, vide o documento Visão. 
 
1.4 Visão Geral 
 
Definir as regras de negócios e necessidades do software de controle de pessoal, financeiro e de produtos 
Fu si o n . 
 
2. Definições 
 
2.1 Controle de Pessoal: 
Proporcionar o cadastro de colaboradores e estudantes para acesso as aulas, desde que sejam jovens sem lares ou ex-alunos (para cadastro de professores). 
2.2 Controle Financeiro 
 	Proporcionar o controle de gastos para manter a operação da ONG 
2.3 Controle de Produtos: 
 Proporcionar ferramentas e facilidades para controle dos produtos e itens necessários para o funcionamento da ONG e suas atividades. 
 
 
 
 
Fusion 
Especificação de Requisitos de 
Software 
 
 
 
 
Versão 1.0 
 
 
 
 
 
 
 	Histórico da Revisão 
Description 
 
 
 
Especificação de Requisitos de Software 
 
 
1. 	Introdução 
 
 
1.1 Finalid ad e 
 
Descrever e especificar os requisitos que devem ser atendidas pelo produto Fusion, de forma a satisfazer as necessidades de seu cliente, bem como definir o produto a ser feito, para os desenvolvedores. 
 
1.2 E s c opo 
 
Produto – Fusion 
Missão do produto - Apoio informatizado ao controle de pessoal, financeiro e de produtos. Permitirá o cadastramento de professores que serão ex-alunos, alunos, colaboradores, disciplinas, turmas e períodos.
43 
 
 
 
1.3 Definições, Acrônimos e Abreviações 
 
Cadastro de Professores – Cadastro de professores, que foram ex-alunos, para lecionar matérias e contribuir com a ONG. 
Cadastro de Alunos – Cadastro de alunos, que não possuem lares e irão ser beneficiados pelas atividades oferecidas pela ONG. 
Controle Financeiro – Controle de contas a pagar, a receber, doações e custos relativos a continuidade do projeto social exercido pela ONG. 
 
 
 
1.4 Re fe rênc i as 
 
Vide documento Visão e de Regras de Negócio para mais informações sobre o projeto. 
 
1.5 Visão Geral 
 
De acordo com o Padrão para Especificação de Requisitos, ou seja: 
· Parte 2: Descrição geral do produto 
· Parte 3: Requisitos específicos 
· Parte 4: Informação de suporte 
 
2. 	Descrição Geral 
 
 
• O produto deve fornecer telas e funções capazes de efetuar o cadastro e controle (inclusão, edição e exclusão) de professores, alunos e colaboradores, administração de recursos financeiros e de produtos. 
 
3. 	Requisitos Específicos 
 
Cadastro de Professores (ex-alunos) 
Cadastro de Estudantes 
Cadastro de Colaboradores 
Cadastro de Disciplinas 
Cadastro de Turmas 
Controle de Financeiro 
Controle de Produtos 
 
3.1 Funcion alid ade 
 
Cadastro de Professores (ex-alunos) – Incluir, Alterar, Excluir 
 
Cadastro de Estudantes - Incluir, Alterar, Excluir 
 
Cadastro de Colaboradores – Incluir, Alterar, Excluir 
 
Cadastro de Disciplinas – Incluir, Alterar, Excluir 
 
Cadastro de Turmas – Incluir, Alterar, Excluir 
 
Controle de Financeiro – Contas a Pagar, Contas a Receber, Recepção de Doações 
 
Controle de Produtos – Incluir no estoque, Alterar no estoque, Excluir no estoque 
44 
 
 
4. 	Informações de Suporte 
 
 
4 .1 	Casos de Uso: 
 	 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4.2 	Diagramas de Fluxo de Dados: 
 
 
 
 
 
 
Caso de Uso: Interação e publicação de projetos Atores: Alunos. 
Descrição: Este recurso disponibiliza para os alunos uma maneira de interagir e apresentar seus trabalhos para diversas pessoas interessadas pelo intuito da ONG no trabalho que realiza. Os alunos terão acesso a suas informações pessoais e as redes sociais voltadas para divulgação dos trabalhos. Não será de qualquer responsabilidade dos alunos qualquer atividade que seja envolvida com gestão e administração de atividades, ambas são executadas e verificadas por seus respectivos profissionais requisitados. 
 
Diagrama Uso de Casos: 
 
 
 
Validação 
 
Através das reuniões e avaliações realizada junto dos profissionais da ONG, alguns requisitos foram solicitados visando atender as necessidades de gerenciamento e contrato de serviço, requisitos esses funcionais que o programa devera possuir. 
Estes requisitos foram trambalhados e definidos de forma a atender a solicitação da ONG para o Solutions. 
 
 
Tabela 4 – Requisitos solicitados para o sistema Solutions. 
Requisitos Solicitado
s 
 
Cadastro 
de 
i
nformações 
(
Dados de 
gestores,
 
professores e
 alunos) 
 
 
Controle financeiro e 
administrativo
 
 
 
 
 
Controle de avaliação 
e notas dos alunos
 
 
 
 
 
 
 
 
Divulgação 
e 
interaçã
o 
dos 
alunos 
para
 
com 
as 
pessoas interessadas. 
 
Requisitos 
A
tendidos
 
 
O 
software 
disponibiliza 
um
a 
área 
de 
cadastro 
dividida 
em 
3
 
depart
amentos 
visando 
atender 
os 
cargos específicos. 
 
 
O 
software 
tem 
o 
recurso 
de 
gerenciamento 
de 
valores 
sem
elhante 
a 
um
a 
planilha 
excel 
porem 
de form
a profiss
ional e m
elhor desenvolvid
a para 
facilitar o acesso e co
ntrole de dados.
 
 
Acesso 
do 
recurso 
para 
ge
renciam
ento 
de 
projetos, 
aval
iações 
e 
ana
lises 
de 
desem
penho 
através 
de 
sistemas 
desenvolvidos 
propriamente 
para 
tal 
f
unção. 
Tam
bém 
estará 
disponível 
um
aárea 
para 
elaboraç
ão 
de 
q
uestões 
baseando 
em 
resultados 
de 
busc
a 
diretos 
da 
internet, 
trabalhados de f
orma acadêm
ica profissional. 
 
Na 
área
 
do 
a
luno 
foi 
desenvolvido 
um 
recurso 
para 
acesso 
a 
m
ídias 
sociais 
com 
o 
fundamento 
de 
publicar 
os 
tra
balhos 
e 
realizar 
a
 
interação 
de 
jovens 
que
 
produ
zem 
os 
brinquedos 
com
 
os 
clientes. 
Fonte: Próprio autor. 
 
 
 
 
 
 
 
 
 
 
 
 
Gestão 
 
Neste tópico são abordados possíveis erros relacionados ao desenvolvimento e utilização da ferramenta e suas medidas preventivas de reparação. 
 
Tabela 5 – Erros e medidas de solução para o sistema Solutions. 
ERROS 
 
ERRO 101 
 
 
 
 
 
ERRO 102’
 
 
 
 
ERRO 103 
Informações do ERRO 
 
Falha 
a
o 
acessar 
o 
servidor 
para login 
 
 
 
Falha 
ao 
sal
var 
os 
dad
os 
e 
acessar as inform
ações 
 
 
 
Problemas 
com 
o 
desem
pen
ho 
do software 
Medidas de Solução 
 
 
-
Verificar 
se 
os 
servidores
 
estão acessíveis. 
 
-
 
Analisar 
os 
dados 
digitados 
pelo usuário. 
 
 
-
Verificar 
a 
co
nexão 
c
om 
a 
internet. 
-
 
Verificar 
se 
o 
servidor
 
apresenta algum
 problema. 
 
-
 
Verificar 
o 
consum
o 
de 
banda
 
da 
internet 
realizado 
pel
o 
software 
 
Todo o projeto foi desenvolvido visando evitar os erros citados logo acima porem se tratando de uma ferramenta, pode ocorrer de algumas falhar vierem a se manifestar durante a execução do software sendo assim fundamental que o cliente entre em contato com o suporte e solicite as melhorias necessárias. 
 
 
 
 
 
 	 
5. CONCLUSÃO 
 
Após todo o desenvolvimento dissertativo por parte da equipe para apresentar a importância de um software do seguimento do Solutions para atender as necessidades uma instituição que por não ser governamental e por se tratar de um programa de auxílio a jovens carentes, será apresentada uma breve consideração final a respeito da ideia praticada para o desenvolvimento de tal ferramenta. Tudo que foi realizado durante o desenvolvimento foi apresentado de forma clara e objetiva na dissertação com o intuito de fazer com que o usuário visualize e considere a importância de se desenvolver uma ferramenta com tais funções. Considerando sua estruturação e desenvolvimento o projeto foi muito bem elaborado por seus desenvolvedores e também pelos envolvidos que foram de suma importância para a troca de informações e ideias. 
Todos os requisitos e métodos utilizados para o desenvolvimento do projeto seguem as técnicas da engenharia de software. Todo o trabalho contribuiu de forma acintosa no nosso desenvolvimento e aprendizado relacionado a disciplina adotada. Seguindo o que foi discutido e absorvido em sala de aula o trabalho foi todo elaborado seguindo os requisitos solicitados. 
Sendo assim, alcançamos de forma positiva os resultados que eram esperados, entendendo mais sobre a técnica de engenharia, métodos de interação com clientes, importância de seguir os requisitos que nos foram solicitados, entre outros fatores que acrescentaram no nosso aprendizado. 
 	 
6. ANEXOS 
 
<Project Name> 
Vision (Small Project) 
 
Version <1.0> 
 
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] 
 
 
 
Revision History 
Description 
Date
 
Version
 
Author
 
<
dd/mmm/yy> 
<
x.x> 
<
details> 
<
name> 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Table of Contents 
1.
 
Introduction
 
 
1.1
References
 
 
 
2.
 
Positioning 
 
 
2.1
 
Prob
lem
 Statement
 
 
2.2
 
 
Product Position St
atement
 
 
3.
 
Stakeholder and User Descr
iptions
 
 
3.1
 
Stakeholder Sum
mary
 
3.2
 
 
User Summary
 
 
3.3
 
User Environment
 
 
3.4
 
Summary o
f Key Stakeholder or User Nee
ds
 
 
3.5
 
Alternatives and Co
mpetition
 
 
4.
 
Product Overview
 
 
4.1 Product Perspective 
4.2 Assumptions and Dependencies 
5. Product Features 
6. Other Product Requirements 
 
 
Vision 
1. Introduction 
[The purpose of this document is to collect, analyze, and define high-level needs and features of the <<System Name>>. It focuses on the capabilities needed by the stakeholders, and the target users, and why these needs exist. The details of how the <<System Name>> fulfils these needs are detailed in the use-case and supplementary specifications.] 
 [The introduction of the Vision document provides an overview of the entire document. It includes the purpos,and references of this Vision document.] 
1.1 References 
[This subsection provides a complete list of all documents referenced elsewhere in the Vision document. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.] 
2. Positioning 
2.1Problem Statement 
[Provide a statement summarizing the problem being solved by this project. The following format may be used:] 
The problem of 	[describe the problem] affects 	[the stakeholders affected by the problem] 
the impact of which is 	[what is the impact of the problem?] a successful solution would be 	[list some key benefits of a successful solution] 
2.2 Product Position Statement 
[Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. The following format may be used:] 
	For 	[target customer] 
	Who 	[statement of the need or opportunity] 
	The (product name) 	 is a [product category] 
	That 	[statement of key benefit; that is, the compelling reason to buy] 
	Unlike 	[primary competitive alternative] 
	Our product 	[statement of primary differentiation] 
[A product position statement communicates the intent of the application and the importance of the project to all concerned personnel.] 
3. Stakeholder and User Descriptions 
[To effectively provide products and services that meet your stakeholders’ and users' real needs it is necessary to identify and involve all of the stakeholders as part of the Requirements Modeling process. You must also identify the users of the system and ensure that the stakeholder community adequately represents them. This section provides a profile of the stakeholders and users involved in the project, and the key problems that they perceive to be addressed by the proposed solution. It does not describe their specific requests or requirements as these are captured in a separate stakeholder requests artifact. Instead, it provides the background and justification for why the requirements are needed.] 
3.1Stakeholder Summary 
[There are a number of stakeholders with an interest in the development and not all of them are end users. Present a summary list of these non-user stakeholders. (The users are summarized in section 3.2.)] 
Name
 
Description
 
Responsibilities
 
[
Name the stake
holder 
type.] 
[
Briefly describe the 
stakeholder.] 
[
Summarize th
e stakeholder's key 
responsibilities with r
egard to the 
system being develo
ped; that is, 
their interest as a stakeh
older. For 
example, this stakeh
older: 
-
 ensures that th
e system will be 
maintainab
le 
-
 ensures that th
ere will be a 
market deman
d for the product's 
features 
-
 monitors the 
project's progress 
-
 approve
s funding 
-
 and so forth
]
 
3.2
 User Summ
ary 
[
Present a summa
ry list of all identified u
sers.
]
 
Name
 
Description
 
Responsibilities 
 
Stakeholder
 
[
Name the 
user type.] 
[
Briefly 
describe what 
they represent 
with respect to 
the system.][
List the user's key respo
nsibilities 
with regard to the 
system being 
developed
; for example: 
-
 captures d
etails 
 produce
-
s reports 
-
 coordin
ates work 
 and so on] 
-
[
If the user is not d
irectly 
represented, iden
tify which 
stakeholder is respon
sible for 
representing th
e user's interests.] 
 
3.3 User Environment 
[Detail the working environment of the target user. Here are some suggestions: 
· Number of people involved in completing the task? Is this changing? 
· How long is a task cycle? Amount of time spent in each activity? Is this changing? 
· Any unique environmental constraints: mobile, outdoors, in-flight, and so on.? 
· Which system platforms are in use today? Future platforms? 
· What other applications are in use? Does your application need to integrate with them? 
This is where extracts from the Business Model could be included to outline the task and business workers involved, and so on.] 
3.4 Key Stakeholder or User Needs 
[List the key problems with existing solutions as perceived by the stakeholder or user. Clarify the following issues for each problem: 
· What are the reasons for this problem? 
· How is it solved now? 
· What solutions does the stakeholder or user want?] 
[It is important to understand the relative importance the stakeholder or user places on solving each problem. Ranking and cumulative voting techniques indicate problems that m ust be solved versus issues they would like addressed. 
Fill in the following table—if using Rational RequisitePro to capture the Needs, this could be an extract or report from that tool.] 
Need
 
Priority
 
Concerns
 
Current Solution
 
Proposed Solutions
 
Broadcast messages
 
 
 
 
 
 
3.5 Alternatives and Competition 
[Identify alternatives the stakeholder perceives as available. These can include buying a competitor’s product, building a homegrown solution, or simply maintaining the status quo. List any known competitive choices that exist or may become available. Include the major strengths and weaknesses of each competitor as perceived by the stakeholder or end user.] 
4. Product Overview 
[This section provides a high level view of the product capabilities, interfaces to other applications, and systems configurations. This section usually consists of two subsections, as follows: 
· Product perspective 
· Assumptions and dependencies] 
4.1 Product Perspective 
[This subsection of the Vision document puts the product in perspective to other related products and the user’s environment. If the product is independent and totally self-contained, state it here. If the product is a component of a larger system, then this subsection relates how these systems interact and needs to identify the relevant interfaces between the systems. One easy way to display the major components of the larger system, interconnections, and external interfaces is with a block diagram.] 
4.2 Assumptions and Dependencies 
[List each factor that affects the features stated in the Vision document. List assumptions that, if changed, will alter the Vision document. For example, an assumption may state that a specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the Vision document will need to change.] 
5. Product Features 
[List and briefly describe the product features. Features are the high-level capabilities of the system that are necessary to deliver benefits to the users. Each feature is an externally desired service that typically requires a series of inputs to achieve the desired result. For example, a feature of a problem tracking system might be the ability to provide trending reports. As the use-case model takes shape, update the description to refer to the use cases. 
Because the Vision document is reviewed by a wide variety of involved personnel, the level of detail needs to be general enough for everyone to understand. However, enough detail must be available to provide the team with the information they need to create a use-case model. 
To effectively manage application complexity, we recommend for any new system, or an increment to an existing system, capabilities are abstracted to a high enough level so 25-99 features result. These features provide the fundamental basis for product definition, scope management, and project management. Each feature will be expanded in greater detail in the use-case model. 
Throughout this section, each feature will be externally perceivable by users, operators, or other external systems. These features should include a description of functionality and any relevant usability issues that must be addressed. The following guidelines apply: 
· Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how) they should be implemented. 
· If you are using the Rational RequisitePro toolkit, all need to be selected as requirements of type for easy reference and tracking. 
Define the priority of the different system features. Include, if useful, attributes such as stability, benefit, effort, and risk.] 
6. Other Product Requirements 
[At a high-level, list applicable standards, hardware, or platform requirements; performance requirements; and environmental requirements. 
Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the Feature Set. 
Note any design constraints, external constraints, or other dependencies. 
Define any specific documentation requirements, including user manuals, online help, installation, labeling, and packaging requirements. 
Define the priority of these other product requirements. Include, if useful, attributes such as stability, benefit, effort, and risk.] 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
<Nome do Projeto> 
Regras de Negócios 
Versão <1.0> 
[Observação: O template a seguir é fornecido para uso com o Rational Unified Process (RUP). O texto em azul exibido entre colchetes e em itálico (style=InfoBlue) foi incluído para orientar o autor e deve ser excluído antes da publicação do documento. Qualquer parágrafo inserido após esse estilo será definido automaticamente como normal (estilo=BodyText).] 
 
Histórico da Revisão 
Data
 
Versão
 
Descrição
 
Autor
 
<
dd/mmm/aa> 
<
x.x> 
<
detalhe
s>
 
<
nome> 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Índice Analítico 
1.
 
Introdução
 
 
 
1.1
Finalidade
 
 
 
1.2
Escop
o
 
 
1.3
Referên
cias
 
 
1.4
 
Visão Ge
ral
 
 
2.
 
Definições
 
2.
1
<
aBusinessRule
>
 
 
2.2
<
another
BusinessR
ule>
 
 
2.3
<
aGroup
ofBusiness
Rules>
 
 
2.3.1
<
aGroup
BusinessR
ule>
 
 
de um banco de dados vinculado para salvar suas informações, atualmente este recurso faz uso do MySQL para web. Além do banco de dados o software disponibilizará ao cliente um sistema de backup direto na nuvem fazendo com que a segurança dos dados caso ocorra algum problema na ferramenta se mantenha intacta e evite eventuais perdas de informações. 
 Nas áreas dos professores, o sistema disponibiliza recursos de avaliação pessoal de cada aluno, considerando suas atividades, seu desempenho, controle de faltas e avaliações. Um sistema de gerenciamento de matérias e trabalhos será destinado quando o professor dor realizar suas avaliações e projetos acadêmicos. O trabalho social realizado através das redes sociais utilizara os serviços do Facebook e do Instagram, ambos com a finalidade de publicações e marketing dos produtos que serão desenvolvidos. 
 Aqui foram exibidos os recursos disponíveis de forma básica e não tão complexa para o entendimento, porem junto do software disponibilizamos um manual de instruções onde explica cada função e demonstra um tutorial para utilização dos recursos disponíveis. Lembrando também que será realizado vários treinamentos para a liberação definitiva do projeto para ONG e também será