---
breaks: false
tags: LMR
title: '2022-09-12 Doc de Visão'
---
# Documento de visão

# 1. Contexto
Com o surgimento da pandemia da covid-19, o trabalho remoto tornou-se bastante comum em diferentes setores do mercado de trabalho.

Após a melhoria da situação pandêmica, alguns trabalhos permaneceram nessa modalidade.

Dessa forma, problemas comuns a esses trabalhadores começaram a ter mais destaque, seja na mídia ou entre conversas entre pares.

Dificuldades como:
- Trabalhar muito, por vezes ultrapassando o expediente;
- chegar a exaustão de maneira recorrente;
- não conseguir conciliar bem as demais atividades.

Assim, deseja-se uma solução de software que melhore a rotina de quem trabalha home office.

# 2. Equipe
Por enquanto, a equipe é o grupo-cliente:
- HOSANA IASMIN CASTRO DOS SANTOS
- IGOR ALVES DOS SANTOS
- ISAAC LOPES DE MEDEIROS

# 3. Stakeholders
A princípio, seria:
- cliente:
- a equipe
- público de usuários:
- potencialmente, trabalhadores remotos
- equipe de desenvolvimento:
- grupo de desenvolvedores
- outras funções profissionais não serão tratadas nesse contexto (gestores de produto, QA, Infraestrutura, Designers, Suporte à Operação do Software, etc)

- concorrentes:
- apps de bem-estar,
- apps de controle de horário,
- apps de produtividade
- a professora
- mediadora do aprendizado

# 4. Perfis de usuários
- Usuários de exemplo / testes (dados fictícios)
- Administrador de sistema
- Usuários de Suporte
- Usuários finais (público alvo)

# 5. Oportunidades e Objetivos
Diferenciais:
- Feedback ao final do dia ou no início do dia seguinte sobre:
- horários sugeridos
- qualidade/rendimento das atividades
- bem estar
- Testar capacidade cognitiva antes de estudos

Objetivos:
- Auxiliar no controle da jornada de trabalho (controle de horário)
- Sugerir dicas para melhor aproveitar o restante do dia (produtividade)
- Proporcionar satisfação ao terminar o dia (bem-estar / qualidade de vida)

# 6. Regras de Negócio
**RN01**:
- **Nome**: Acesso ao Sistema
- **Descrição**: Para utilizar a sincronização do sistema, o usuário deverá efetuar o login.

**RN02**:
- **Nome**: Preenchimento obrigatório
- **Descrição**: Deverá obrigatoriamente preencher os campos usuário e senha.

**RN03**:
- **Nome**: Validação
- **Descrição**: Os dados informados nos campos usuário e senha deverão ser validados junto ao cadastro de usuários no banco de dados.

**RN04**:
- **Nome**: Diretivas de Senha
- **Descrição**: A senha deverá seguir requisitos de complexidade:
- No mínimo 8 caracteres;
- Deve conter no mínimo uma letra maiúscula;
- Deve conter letras e numeros.

**RN05**:
- **Nome**: Validação
- **Descrição**: Os dados informados nos campos usuário e senha deverão ser validados junto ao cadastro de usuários no banco de dados.

**RN06**:
- **Nome**: Validação de horário
- **Descrição**: Não é permitido adicionar uma atividade na lista de atividades com um horário no passado.

**RN07**:
- **Nome**: Conflito de horários
- **Descrição**: Não é permitido cadastrar mais de uma atividade no mesmo horário.

**RN08**:
- **Nome**: Feedback sobre satisfação
- **Descrição**: Ao final do dia o usuario deve responder um feedback sobre satisfação (NPS) geral.

**RN09**:
- **Nome**: Aprendizado supervisionado
- **Descrição**: A acurácia para que o sistema possa sugerir algum horario deve ser maior que 75%.

# 7. Requisitos Funcionais
## a) Gerais

**RF1**:
- **Nome**: Apresentar o sistema
- **Descrição**: o sistema deve conter uma tela inicial que contenha dicas de funcionamento.

## b) CRUD

**RF2**:
- **Nome**: Criar usuário (**C**RUD)
- **Descrição**: o sistema deve permitir criação de usuário, usando email e senha.

**RF3**:
- **Nome**: Acessar o sistema (C**R**UD)
- **Descrição**: o sistema deve permitir que os usuários consigam acessar a área privativa (logada).

**RF4**:
- **Nome**: Atualizar dados pessoais (CR**U**D)
- **Descrição**: o sistema deve permitir que os usuários consigam atualizar seus dados pessoais.

**RF5**:
- **Nome**: Deletar usuário (CRU**D**)
- **Descrição**: o sistema deve permitir que os usuários consigam apagar seu usuário no software.

## c) Controle de horário

**RF6**:
- **Nome**: Criar uma lista de atividades do dia com acompanhamento de quando forem realizadas
- **Descrição**: o sistema deve permitir que os usuários consigam criar listas de atividades com horários e indicação se já foram realizadas.

**RF7**:
- **Nome**: Criar lembrete para as atividades que tiverem horário
- **Descrição**: o sistema deve alertar o usuário instantes antes do horário marcado em uma atividade.

## d) Bem-estar / qualidade de vida
**RF8**:
- **Nome**: Coletar feedback sobre satisfação (NPS) geral com o dia de atividades
- **Descrição**: o sistema deve questionar ao usuário, após o fim da agenda do dia, como ele está satisfeito.

**RF9**:
- **Nome**: Coletar feedback sobre satisfação (NPS) com cada atividade do dia
- **Descrição**: o sistema deve questionar ao usuário após o fim da agenda do dia, de maneira opcional - caso o usuário queira detalhar, como ficou satisfeito com cada atividade e horário.

## e) Aprendizado

**RF10**:
- **Nome**: Interpretar os horários indicados em atividades realizadas.
- **Descrição**: o sistema deve interpretar se as atividades que tinham horários foram realmente realizadas dentro daquele horário e acumular, de maneira não supervisionada, o aprendizado sobre essas constatações.

**RF11**:
- **Nome**: Interpretar a satisfação com os dias de atividades.
- **Descrição**: o sistema deve interpretar o nível satisfação do usuário com um conjunto de atividades realizadas em um dia e acumular, de maneira não supervisionada, o aprendizado sobre essas constatações.

**RF12**:
- **Nome**: Interpretar a satisfação com atividades específicas.
- **Descrição**: o sistema deve interpretar o nível satisfação do usuário com as atividades específicas que eles quis responder e acumular, de maneira não supervisionada, o aprendizado sobre essas constatações.

## f) Produtividade

**RF13**:
- **Nome**: Sugerir melhores horários
- **Descrição**: durante o cadastro de novas atividades, caso o usuário não informe horário, o sistema deve sugerir um melhor momento para realizá-las (usando como parâmetro o histórico), sem interferir o expediente de trabalho.

**RF14**:
- **Nome**: Alertar horários ruins
- **Descrição**: durante o cadastro de novas atividades, caso o usuário informe horário, o sistema deve indicar que historicamente aquele horário não lhe satisfez.

**RF15**:
- **Nome**: Testar capacidade cognitiva.
- **Descrição**: quando alguma atividade de aprendizado for ser realizada pelo usuário, o sistema deve avaliar a capacidade / disposição da pessoa para aprender.

**RF16**:
- **Nome**: Sugerir momentos de descanso.
- **Descrição**: quando o teste de capacidade cognitiva indicar indisposição ou se o histórico de satisfação indicar insatisfação com aquela atividade (ou dias com aquela atividade), o sistema deve perceber quando uma atividade não valerá a pena ser feita e, portanto, deve sugerir descanso ao usuário.

## g) Dados
**RF17**:
- **Nome**: Sincronizar dados
- **Descrição**: o lado cliente do sistema deve comunicar-se (envio e recebimento) em tempo real com seu lado servidor, de maneira a poder ter sempre os dados atualizados que inseriu em um dispositivo logado nos demais em que também estiver.

# 8. Requisitos Não-Funcionais

## a) Produto
Requisitos que especificam o comportamento do produto.Ex. portabilidade; tempo na execução; confiabilidade, mobilidade, etc.

**RNF1**:
- **Nome**: Usabilidade - Uso após tutorial
- **Descrição**: o sistema deve ter 1o uso liberado apenas quando o usuário terminar de ver aprensentação do sistema.

**RNF2**:
- **Nome**: Eficiência - O sistema deve ser "rápido"
- **Descrição**: o sistema deve proporcionar uma experiência flúida de uso pelo usuário, sem deixá-lo esperando por muito tempo entre as funcionalidades.

**RNF3**:
- **Nome**: Confiabilidade - Infraestrutura configurada para otimizar disponibilidade.
- **Descrição**: o sistema deve ter infraestrutura automatizada configurada através de código (IaC), de maneira a aumentar sua disponibilidade durante momentos de picos de acesso.

**RNF4**:
- **Nome**: Portabilidade - Execução em diferentes plataformas
- **Descrição**: o sistema deve ser disponibilizado em versões mobile, smartwatch e assistente de voz.

**RNF5**:
- **Nome**: Interface - Design system baseado na ideia de qualidade de vida
- **Descrição**: o sistema deve ter interface que represente sensação de qualidade de vida.

## b) Organizacional
**RNF6**:
- **Nome**: Entrega - Resumos semanais
- **Descrição**: o sistema deve enviar resumos semanais sobre a qualidade das atividades realizadas na semana.

## c) Social

**RNF7**:
- **Nome**: Internacionalização - Diferentes idiomas naturais
- **Descrição**: o sistema deve estar disponível inicialmente em Português e Ingles.

**RNF8**:
- **Nome**: Acessibilidade - Conformidade com critérios recomendados para sistemas inclusivos.
- **Descrição**: o sistema deve cumprir normativos internacionais sobre acessibilidade de sistemas, conforme a plataforma do dispositivo.

**RNF9**:
- **Nome**: Legal - Leis de proteção de dados pessoais
- **Descrição**: o sistema deve cumprir legislações sobre respeito à proteção de dados pessoais por parte dos sistemas, disponíveis em diferentes países / regiões.

# 9. Versões desejadas
Uma versão inicial do sistema pode conter apenas:
- RF2
- RF3
- RF4
- RF5
- RF6
- RF8
- RF9
- RF15

# 10. Riscos e Limitações
## a) Riscos
O desenvolvimento do sistema pode ficar comprometido se:
- os clientes ou desenvolvedores não continuarem com a sua criação
- as pessoas envolvidas não tiverem disponibilidade de tempo
- o projeto não tiver orçamento para tornar possível seu desenvolvimento

## b) Limitação

O uso do sistema pode ser limitado a:
- o poder aquisitivo do público-alvo (diferentes dispositivos)
- o idioma dos usuários (se não for disponibilizado no que são fluentes)
- capacidade sensorial dos usuários (necessitando que o sistema seja acessível às suas condições).

# 11. Glossário
- **Acurácia**: Proximidade entre o valor obtido experimentalmente e o valor verdadeiro na medição de uma grandeza física.

- **Aprendizado supervisionado**: A aprendizagem supervisionada é um ramo do aprendizado de máquina, um método de análise de dados que usa algoritmos que aprendem iterativamente a partir dos dados para permitir que os computadores encontrem informações ocultas sem serem explicitamente programados para onde procurar.

- **Infraestrutura como Código / Infrastructure as Code (IaC)**: consiste na utilização de uma linguagem de codificação descritiva de alto nível (em geral arquivos de configuração padronizados, como json e yaml) que tem como objetivo automatizar o provisionamento da infraestrutura de TI.

- **CRUD**: Acrônimo para Create, Read, Update, Delete. São maneiras de se operar em informações armazenadas em sistemas.