Safebank - Bizotto/SafeBank GitHub Wiki

Especificação de Requisitos de Software

Projeto: SafeBank

Equipe:

Carlos Henrique Agostinho Berkenbrock e Nicolas Ian Bizotto

Disciplina: Engenharia de Software

Professor: Edinilson da Silva Vida 2022 – Faculdade Cesusc

1. INTRODUÇÃO

Esta seção tem por objetivo documentar o projeto referente ao Projeto de Conclusão do Curso de Análise e Desenvolvimento de Sistemas da Faculdade Cesusc. Nas próximas seções, serão apresentados os principais problemas que motivaram a realização deste projeto, a ferramenta de planejamento estratégico (Business Model Canvas), a visão geral da solução, e a descrição dos principais usuários da ferramenta.

1.1 Motivação

Esta seção descreve a situação atual do negócio a ser explorado pelo projeto e o impacto que a nova solução irá prover. O SafeBank, tem como sua principal motivação levar para a sociedade uma forma segura de planejar e salvar senhas, de maneira com que seja simples e de fácil entendimento para todas as idades, o principal problema pode ser o vazamento de informações por alguns tipos de vírus e malwares, havendo a possibilidade de uma invasão de nosso banco de dados.

O problema é...	Usuários com dificuldades de gerenciar suas senhas, problemas em lembrar suas senhas, hacking antiético.
Que afeta...	Todos os usuários que utilizam de diversas contas para login no seu dia á dia, dificultando o rápido a acesso a determinado site ou app.
O impacto disto é...	Numero elevado de pessoas que esquecem suas senhas, sofrem de hacking,
A solução seria...	Criar um aplicativo capaz de realizar o armazenamento de senhas, criação de tokens.

1.2 Business Model Canvas

Esta seção apresenta o Business Model Canvas, mais conhecido como Canvas, uma ferramenta de planejamento estratégico formatada em nove blocos, que permite desenvolver, discutir e visualizar o modelo de negócio relacionado ao projeto proposto. Neste sentido, são apresentadas algumas sugestões de operação e geração de valor do negócio ao mercado, e de mapeamento de possíveis fluxos e processos.

1.3 Visão Geral da Solução

Esta seção apresenta de maneira detalhada as principais ideias do projeto a ser desenvolvido, destacando as principais funcionalidades que caracterizam o sistema. Sumário Executivo: A proposta do SafeBank é desenvolver um aplicativo de gerenciamento de senhas e token. Sua principal função é que os usuários possam armazenar suas senhas e gerenciar de maneira rápida e segura. Todas suas informações serão guardadas de maneiras criptografas e sempre visando a segurança de seu dados.

2. DETALHAMENTO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Esta seção descreve as diversas fases, tarefas e atividades que compreendem o desenvolvimento do produto de software. Um processo é um conjunto estruturado de atividades necessárias para desenvolver um sistema de software.

2.1 Especificação de Requisitos de Software

Processo de desenvolvimento de Software: Scrum
Concepção inicial da ideia no Modelo Canvas

2.2 Projeto

Desenvolvimento do Termo de Abertura do Projeto
EAP
Projeto conceitual, MER
Identidade Visual: Definição da UI e padrões desejados para UX
Definição dos Frameworks: Mobile: React Native + TypeScript e MongoDB, Web: Html+CSS, TypeScript e MongoDB
Criação dos Diagramas de baixa e alta fidelidade.

2.3 Codificação das aplicações

Codificação do ambiente Mobile
Codificação do ambiente WEB
Codificação do ambiente Desktop

2.4 Lançamento da versão Alfa

2.5 Testagem

2.6 Lançamento da Versão Beta

2.7 Coleta de feedback e refinamento do protótipo

2.8 Lançamento da versão Final (1.0)

2.9 Implantação:

Manuais do sistema

3. ESTRUTURA ANALÍTICA DO PROJETO

Esta seção descreve a EAP (Estrutura Analítica do Projeto), uma subdivisão hierárquica do trabalho do projeto em partes menores, mais facilmente gerenciáveis. Nela, está organizado o que deve ser feito para produzir as entregas do projeto.

4. CRONOGRAMA INICIAL

Esta seção apresenta um cronograma inicial para o projeto, destacando quais serão os principais marcos do projeto, o que conterão e quando eles ocorrerão.

Etapas da EAP	Fases/Marcos do Projeto	Entregáveis	Data de Início Prevista	Data de Término Prevista
1.1	Ideia	Emaranhado de ideias sobre nosso projeto	01/06/2021	07/09/2021
	Canvas	criação Painel do Canvas	18/06/2022	23/06/2022
	criação de requisitos	Doc. Especificação de requisitos	18/06/2022	25/06/2022
	Desenvolvimento da EAP	Criado o fluxograma da EAP	18/06/2022	24/06/2022
	Desenvolvimento do MER	Fluxograma do MER	18/06/2022	25/06/2022
1.2	Modelagem da identidade Visual	Mapa da empatia, Personas, Protótipo de baixa fidelidade , Guia de estilo UI e protótipo de alta fidelidade	18/06/2022	25/06/2022
	Codificação Mobile	Tela de login, tela principal	18/06/2022	27/09/2022
	Codificação WEB	Site do projeto da API com: tela inicial, tela de produtos, tela de blog.	18/05/2022	30/07/2023
	Testagem	Versão beta	20/06/2022	30/08/2023
1.4	Homologação	Checagem completa dos requisitos	20/06/2022	25/09/2023
1.3	Divulgação e venda	Campanha de Marketing, captação de usuários e clientes, parcerias de divulgação, venda.	20/06/2022	!!!
1.4	Lançamento do APP	lançamento da versão 1.0 (final)	25/09/2022	30/01/2024
	Implantação	Processo de treinamento dos compradores e suportadores da API	25/10/2022	!!!

5. ESPECIFICAÇÃO DE REQUISITOS

Esta seção descreve, de forma organizada os itens que caracterizam a finalidade de uso do sistema como, por exemplo, os atores, os requisitos funcionais (RFs), os requisitos não funcionais (RNFs), as regras de negócio (RNs), as mensagens do sistema (MSGs), os requisitos adiados e o diagrama de casos de uso. O objetivo do documento é fornecer aos desenvolvedores as informações necessárias para o projeto e implementação, assim como para a realização dos testes e homologação da aplicação. A prioridade de cada RF e RNF pode ser classificada como “essencial”, “importante” e “desejável”, de acordo com a descrição abaixo: Essencial: Um RF ou RNF essencial, se não for atendido, impede que a aplicação entre em funcionamento. RFs ou RNFs essenciais são imprescindíveis, isto é, têm de ser implementados impreterivelmente. Importante: Se um RF ou RNF importante não for atendido, a aplicação pode até entrar em funcionamento, mas de forma não satisfatória. RFs ou RNFs importantes deveriam ser implementados, mas, se não forem, não impedirão a implantação e utilização da aplicação. Desejável: Um RF ou RNF desejável, por fim, é aquele cuja ausência de implementação não compromete a operacionalização da aplicação, isto é, a aplicação pode funcionar de forma satisfatória mesmo sem sua implementação. Esses RFs ou RNFs podem ser deixados para versões posteriores da solução, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.

5.1 ATORES

Esta seção apresenta cada ator que desempenha um papel particular de usuário da aplicação.

Ator	Descrição
Usuário	Pessoas que possuem dificuldade no gerenciamento de suas senhas. O aplicativo leva ao usuário todo o gerenciamento da senhas dos aplicativos cadastrado, levando ao usuário segurança, acesso rápido e prático.

5.2 REQUISITOS FUNCIONAIS

Esta seção apresenta as necessidades, características ou funcionalidades esperadas nos processos que são atendidos pelo software proposto.

[RF1] O sistema deve permitir o cadastro de novos usuários;
Prioridade:		Essencial		Importante		Desejável
Ator(es):	Usuário	x

[RF2] O sistema deve exibir os termos e condições de uso para o uso do APP ;
Prioridade:		Essencial		Importante		Desejável
Ator(es):	Usuário	x

[RF3] O sistema deve enviar um token nas mensagens de texto para confirmação de cadastro;
Prioridade:		Essencial		Importante		Desejável
Ator(es):	Usuário			x

[RF4] O sistema deve permitir A geração de senhas novas e a aleatoriedade da mesma;
Prioridade:		Essencial		Importante		Desejável
Ator(es):	Usuário	x

[RF5] O sistema deve permitir a importação de senhas já criadas pelo usuário;
Prioridade:		Essencial		Importante		Desejável
Ator(es):	Usuário	x

[RF6] O sistema deve permitir a gestão e a alteração de senhas criadas dentro do app ;
Prioridade:		Essencial		Importante		Desejável
Ator(es):	Usuário			x

[RF7] O sistema deve não permitir a alteração da senha mestra ;
Prioridade:		Essencial		Importante		Desejável
Ator(es):	Usuário	x

5.3 REQUISITOS NÃO FUNCIONAIS

Nesta seção, estão especificados os requisitos não funcionais ou atributos de qualidade que não estão diretamente relacionados à funcionalidade de um sistema.

[RNF01] O sistema deve permitir a autenticação dos usúarios;
Prioridade:		Essencial		Importante		Desejável

[RNF02] O sistema deve enviar uma mensagem com a confirmação que foi cadastrado uma nova senha de um app;
Prioridade:		Essencial		Importante		Desejável

[RNF03] O sistema deve esconder a senha do app até que seja selecionado pelo usúario;
Prioridade:		Essencial		Importante		Desejável

6.4 REGRAS DE NEGÓCIO

Esta seção apresenta as regras de negócio, que são declarações que definem ou restringem algum aspecto do negócio e que podem ser implementadas por um sistema computacional.

[RN1] O Usuário deve efetuar o cadastro previamente no APP;
Prioridade:		Essencial		Importante		Desejável
Casos associados:				x

[RN2] O sistema deve enviar um código de validação para o email do usuário;
Prioridade:		Essencial		Importante		Desejável
Casos de uso associados:	RF3- O sistema deve enviar um token nas mensagens de texto para confirmação de cadastro;

[RN3] sistema só completará o cadastro se o campo do código de validação for o mesmo código enviado ao email do Usuário;
Prioridade:		Essencial		Importante		Desejável
Casos de uso associados:

[RN4] O sistema só será liberado caso o Usuário aceite os Termos e condições de uso;
Prioridade:		Essencial		Importante		Desejável
Casos de uso associados:	[RF2] O sistema deve exibir os termos e condições de uso para o uso do APP;

6. DIAGRAMA DE CASO DE USO

Essa seção apresenta todos os requisitos funcionais da aplicação, especificados como casos de uso.

7 REFERÊNCIAS

Material de apoio das aulas