tarefa final

Prévia do material em texto

14
UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS
UNIDADE ACADÊMICA DE GRADUAÇÃO
CURSO DE ANALISE E DESENVOLVIMENTO DE SISTEMAS
PAULINE ANGEL BECKER DA COSTA
TAREFA FINAL
Porto Alegre
2019
PAULINE ANGEL BECKER DA COSTA
TAREFA FINAL
Trabalho apresentado para a disciplina de Engenharia de Requisitos, pelo Curso de Analise de Desenvolvimento de Sistemas da Universidade do Vale do Rio dos Sinos – UNISINOS, ministrada pela professora Rosemary Francisco
Porto Alegre
2019
SUMÁRIO
31 INTRODUÇÃO
42 PrOto-Persona
52.1 OBJETIVOS
52.1.1 Objetivos de experiência
52.1.2. Objetivos finais
53 HISTORIAS
74 REQUISITOS
74.2.1 Funcionais
104.2.1 Não Funcionais
115 Validação de requisitos
136 Conclusão OU CONSIDERAÇÕES FINAIS
14REFERÊNCIAS
1 INTRODUÇÃO
A engenharia de requisitos de um problema é uma das tarefas mais difíceis no desenvolvimento de sistemas, o que pela razão principal do cliente não possuir o conhecimento técnico para definir de forma precisa as suas imprescindibilidades e funções que devem ser contempladas. Ainda que os mesmos, hipoteticamente, possuíssem tais entendimentos, os mesmos realizariam mudanças durante o andamento do projeto.
2 PrOto-Persona
Primeiramente, é importante que esclareçamos que neste cenário possuímos dois usuários distintos, sendo eles: o jovem em processo de escolha de carreira, e o os profissionais de áreas distintas que participam como mentores.
Porém, conforme especificado na solicitação, neste realizaremos a analise somente do jovem, que é nosso usuário principal do sistema.
Assim, a partir de análise do contexto disponibilizado, foi idealizado tal modelo de proto-persona:
	Características
	Bruna, impulsiva, confiante, impaciente, antenada.
	Comportamentos
	Usuário compulsivo de rede sociais; 
Não sabe administrar o próprio tempo; 
Joga videogames; 
Possui facilidade com o uso de tecnologias em geral.
Sem conhecimentos técnicos de nenhuma área;
Pensar em fazer nutrição;
Se preocupa de forma compulsiva com aparência;
	Infs. Demográficas
	17 anos; 
Segundo ano do ensino médio; 
Mora com os pais em Porto Alegre- RS;
Sem experiências profissionais;
	Necessidades e Objetivos
	Encontrar sua vocação/área;
Entender a realidade de cada área profissional.
2.1 OBJETIVOS
2.1.1 Objetivos de experiência
Podemos citar, baseados nas características comportamentais de nossa proto-persona, que os objetivos de experiência sejam:
- “Sentir-se inteligente”
- “Sentir-se bonita”
- “Ser vista”
2.1.2. Objetivos finais
De acordo com a contextualização recebida, os objetivos finais são:
-“Descobri minha vocação”
-“Me tornar boa em uma área”
-“Decidir a faculdade que vou cursar”
3 HISTORIAS
Seguem algumas histórias das principais funcionalidades necessárias ao uso do sistema.
3.1.1 Login
Como um usuário
Eu quero poder ter um login particular
De modo que minhas informações pessoais fiquem salvas
Porque não quero ter que informar estas informações continuamente
3.1.2 Web Conferencia 
Como um usuário
Eu quero poder realizar web conferencias com meu mentor/mentorado
De modo que a partir de um agendamento, possa entrar em web conferencia com meu mentor/mentorado, sendo possível ter mais de um mentorado por conferencia, mas não mais de um mentor.
3.1.3 Materiais de estudo
Como um usuário
Eu quero poder organizar os materiais a serem estudados
De modo que tais possam ser subdividos em matérias, módulos e tipos de atividades
Porque quero ter tais facilidade de organização na própria ferramenta
3.1.4 Avaliações
Como um usuário mentor
Eu quero poder criar atividades avaliativas
De modo que meus mentorados possam ter acesso a elas, por tempo, tentativas e duração estabelecidas por mim
Porque quero poder avaliar o desempenho e evolução dos meus mentorados.
3.1.5 Match
Como um usuário
Eu quero poder visualizar e demonstrar interesse nos mentores/mentorados disponíveis para mim
De modo que quando ambos os lados demonstrarem interesse, seja aberto um canal de comunicação entre ambos para iniciar a mentoria.
4 REQUISITOS
Como propriedades visando solucionar o problema do usuário, podemos especificar alguns dos requisitos, subdivido em funcionais e não funcionais, como:
4.2.1 Funcionais
Aqui descrevemos abaixo algumas das funções inerentes a este sistema:
- Criar uma conta de usuário (divido entre mentor e mentorado);
	RF001 - Criar uma conta de usuário
	 O sistema deve permitir a criação de uma conta de usuário, este podendo ser mentor ou mentorado, solicitando obrigatoriamente as seguintes informações:
-Nome Completo
-E-mail
-Data de nascimento
- Escolaridade
- Certificação profissional aos mentores
- Comprovante de matricula aos mentorados
- CPF
- Senha
Regras a serem respeitadas:
- Nome Completo, e-mail, senha, data de nascimento, escolaridade e cpf são dados obrigatórios;
- Todos os campos devem ser validados;
- Deve ser enviado um e-mail ao endereço informado, validando a conta;
- A certificação profissional aos mentores e comprovante de matricula aos mentorados, podem ser enviados após a criação da conta, porem os mesmos só terão acesso as funcionalidades do sistema após validação dos documentos;
Prioridade
Complexidade
Status
 Alta
Baixa
 Aprovado
- Exclusão de uma conta em uma tela de configuração de usuário
	RF002 - Excluir uma conta
	 O sistema deve permitir a exclusão de uma conta de usuário, este podendo ser mentor ou mentorado, solicitando obrigatoriamente a confirmação do usuário duas vezes informando que a conta será excluída permanentemente.
Regras a serem respeitadas:
- Conta deve ser excluída permanentemente;
- Deve ser enviado um e-mail ao endereço da conta informando que a mesma foi excluída;
Prioridade
Complexidade
Status
 Media
Baixa
 Aprovado
-Alterar e-mail vinculado a conta em tela de configurações de usuário
	RF003 - Alterar e-mail
	 O sistema deve permitir a alteração do e-mail vinculado a uma conta de usuário, este podendo ser mentor ou mentorado, solicitando obrigatoriamente as seguintes informações:
-Novo e-mail;
-Senha atual;
Regras a serem respeitadas:
- Novo e-mail e senha são obrigatórios;
- Todos os campos devem ser validados;
- Novo e-mail deve receber e-mail de validação;
Prioridade
Complexidade
Status
 Media
Media
 Aprovado
- Acessar materiais de estudo divididos em matérias, módulos e tipos;
	RF004 - Acessar materiais de estudo
	 O sistema deve permitir acessar os materiais de estudo divididos em matérias, módulos e tipos, na mesma tela, vinculado a uma conta de usuário, este podendo ser mentor ou mentorado, solicitando obrigatoriamente as seguintes informações:
-Matéria, módulos e atividades desejadas;
Regras a serem respeitadas:
- Arquivos devem poder ser visualizado em seu formato original em uma tela de visualização da atividade;
Prioridade
Complexidade
Status
 Alta
Alta
 Aprovado
- Realizar Login no sistema a partir de um e-mail e senha cadastrados na criação de conta;
	RF005 - Login
	 O sistema deve permitir o login em uma conta de usuário, este podendo ser mentor ou mentorado, solicitando obrigatoriamente as seguintes informações:
-E-mail
- Senha
Regras a serem respeitadas:
- Todos os campos são dados obrigatórios;
- Todos os campos devem ser validados;
Prioridade
Complexidade
Status
 Alta
Baixa
 Aprovado
4.2.1 Não Funcionais
	Capacidade
	O sistema deve manter salvos os materiais de estudo disponibilizados pelos mentores, divididos em matérias, módulos e tipos;
	Portabilidade
	A solução deve ser multiplataforma, visando sua a utilização em diversos equipamentos e sistemas. Sendo eles Android, IOS, browsers (Internet Explorer 7 ou superior, Mozilla Firefox 3.6 ou superior. Google Chrome 1.0 ou superior e Opera 1.0 ou superior)
	RF006 - Materiais de estudo
	 O sistema deve manter salvos os materiais de estudo disponibilizados pelos mentores, divididos em matérias, módulos e tipos;
Prioridade
Complexidade
Status
 Alta
Alta
 Aprovado
	RF007 - Multiplataforma
	 O sistema deve ser multiplataforma, visando suaa utilização em diversos equipamentos e sistemas. Sendo eles Android, IOS, browsers (Internet Explorer 7 ou superior, Mozilla Firefox 3.6 ou superior. Google Chrome 1.0 ou superior e Opera 1.0 ou superior)
Prioridade
Complexidade
Status
 Alta
Alta
 Aprovado
5 Validação de requisitos
Neste contexto foi optado pelo uso da matriz de interação, desta forma, será preenchido a cada requisito:
	Requisito
	Clareza
	Completeza
	Ambiguidade
	Consistência
	Combinação
	Redundância
	Grau de problemas
	RF001
	1
	0
	0
	0
	0
	0
	1
	RF002
	0
	2
	0
	0
	0
	0
	2
	RF003
	2
	1
	0
	0
	0
	0
	3
	RF004
	0
	2
	0
	0
	1
	0
	3
	RF005
	0
	0
	0
	0
	0
	0
	0
	RF006
	0
	1
	0
	0
	0
	0
	1
	RF007
	0
	0
	0
	0
	0
	0
	0
	Grau de incidência
	4
	4
	1
	0
	2
	0
	-
Os problemas de requisitos verificados durante a validação podem ser divididos nas seguintes categorias:
	Categorias
	Clareza
	Completeza
	Ambiguidade
	Consistência
	Combinação
	Redundância
Documentação dos problemas:
	#
	Requisito
	Categoria
	Descrição
	1
	RF002
	Completeza
	Falta indicação da tela onde deverá ser efetuada a operação.
	2
	RF003
	Clareza
	Não está claro o modelo do e-mail que será enviado e a tela onde será efetuado
	3
	RF004
	Completeza
	Não cita os formatos de arquivos que serão suportados.
6 Conclusão OU CONSIDERAÇÕES FINAIS
Após a realização desta análise e do projeto desta solução, verificou-se a utilidade da engenharia de requisitos para o apropriado desenvolvimento de uma aplicação, bem como qualquer sistema, além dos desejos do cliente. Sendo uma funcionalidade extremamente útil no desenvolvimento de softwares, devido ampara na projeção e construção de uma aplicação que solucione o problema, de forma eficiente, analisando o contexto, as prioridades, funções e comportamentos que impactaram no resultado.
Auxiliou também no entendimento do impacto do software no empreendimento do cliente, suas necessidades e a interação do usuário com as funcionalidades.
REFERÊNCIAS
https://www.caelum.com.br/apostila-ux-usabilidade-mobile-web/personas/
Personas, protopersonas e perfis extremos: O que é e quando usar , Heller 29/01/2018 (https://www.hellerdepaula.com.br/personas/)
ENGENHARIA DE REQUISITOS DE SOFTWARE VINÍCIUS COSTA DE SOUZA
http://www.rafaelfelipesantos.com.br/o-que-e-multiplataforma/
https://codificar.com.br/blog/requisitos-funcionais-nao-funcionais/
https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-funcionais/9525
https://www.analisederequisitos.com.br/requisitos-funcionais-e-requisitos-nao-funcionais-o-que-sao/
http://repositoriocanvas.unisinos.br/Eng_Requisitos/html_Eng_Requisitos_validacao/index.html
http://repositoriocanvas.unisinos.br/Eng_Requisitos/html_Eng_Requisitos_tec_elicitacao/index.html
COHN, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley Professional, 2004.
Pressman, R. Engenharia de Software: Uma abordagem Profissional. 7º edição. Editora Bookman.
Ken Schwaber e Jeff Sutherland. Scrum Guide. Disponível em http://www.scrum.org
Mike Cohns: Succeding with Agile. Disponível em http://www.mountaingoatsoftware.com/blog/