# [MODELO] RFC: Request for Comments — Projeto de Portfólio **Engenharia de Software – Católica SC** --- # Identificação - **Título do Projeto:** Nome claro e específico do sistema. - **Linha de Projeto (Direction):** Web Apps / Mobile / Jogos Digitais / IA / IoT — uma das [cinco linhas oficiais](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook/blob/main/directions/portfolio-directions-GERAL.md) - **Autor:** Nome completo - **Data da Proposta:** DD/MM/AAAA - **Versão:** 1.0 --- # 1. Visão do Produto e Impacto (O Problema) O objetivo desta seção é responder uma pergunta fundamental: **Este projeto resolve um problema real ou é apenas um exercício técnico?** --- ## 1.1 Contexto e Problema Descreva claramente o problema que motivou o projeto. Explique: - Quem sofre com esse problema - Em que contexto ele ocorre - Como esse problema é resolvido atualmente - Quais são as limitações das soluções atuais Sempre que possível apresente: - exemplos reais - prints de processos atuais - descrições de fluxos existentes --- ## 1.2 Origem da Demanda e Evidências É necessário demonstrar que existe **interesse real pela solução**. Apresente pelo menos **uma evidência concreta**. ### Demanda Externa Projeto solicitado por: - empresa - ONG - órgão público - grupo de usuários Inclua: - nome da organização - contexto da demanda - descrição do problema relatado --- ### Pesquisa com Usuários Pode incluir: - entrevistas - questionários - observação de processos Inclua: - número de pessoas entrevistadas - principais dores identificadas - padrões observados Adicione **tabelas, gráficos ou prints**. --- ### Evidência de Interesse Podem ser incluídos: - cartas de intenção - feedback de usuários - comentários de comunidades - resultados de formulários --- ## 1.3 Análise de Soluções Existentes (Benchmark) Investigue **3 a 5 soluções existentes** que tentam resolver o mesmo problema. Para cada solução apresente: - nome do produto - link - público-alvo - funcionalidades principais - limitações Inclua **prints da interface ou diagramas simplificados**. --- ### Comparação | Solução | Pontos Fortes | Limitações | |---|---|---| --- ### Diferencial do Projeto Explique claramente: - por que criar algo novo - qual lacuna não foi resolvida pelas soluções existentes - qual nicho específico será atendido --- ## 1.4 Público-Alvo Defina quem usará o sistema. Exemplos: - estudantes - contadores - equipes de suporte - jogadores Descreva: - perfil do usuário - contexto de uso - nível de conhecimento técnico esperado --- ## 1.5 Objetivos do Projeto ### Objetivo Geral Qual transformação o projeto pretende gerar. --- ### Objetivos Específicos Liste **3 a 5 objetivos técnicos ou de produto**. Exemplo: - automatizar um processo manual - permitir análise de dados - criar um sistema de recomendação --- ## 1.6 Métricas de Sucesso (KPIs) Como saberemos que o projeto foi bem sucedido? Exemplos: - latência inferior a 200ms - acurácia da IA superior a 85% - suporte a 100 usuários simultâneos - redução do tempo de um processo em 30% --- # 2. Engenharia de Requisitos Esta seção define **o que o sistema fará**. Evite descrições vagas. --- ## 2.1 Personas Crie **1 a 3 personas principais**. Inclua: - nome fictício - contexto - objetivos - principais dificuldades Adicionar **imagens ou ilustrações** pode ajudar na compreensão. --- ## 2.2 Casos de Uso Principais Liste os principais fluxos do sistema. Exemplo: - criar conta - registrar dados - consultar informações - gerar relatórios Sempre que possível inclua **diagramas de caso de uso**. --- ## 2.3 Requisitos Funcionais (RF) Use a estrutura: > O sistema deve permitir que **[ator] realize [ação]**. Exemplo: RF01 — O sistema deve permitir que o usuário crie uma conta. RF02 — O sistema deve permitir que o usuário registre informações. RF03 — O sistema deve permitir que o usuário visualize dados registrados. --- ## 2.4 Requisitos Não Funcionais (RNF) Inclua requisitos relacionados a: - desempenho - segurança - disponibilidade - escalabilidade - usabilidade Exemplo: RNF01 — O sistema deve suportar 100 usuários simultâneos. RNF02 — O tempo de resposta deve ser inferior a 300ms. RNF03 — O sistema deve utilizar autenticação segura. --- ## 2.5 Regras de Negócio Exemplos: - apenas usuários autenticados podem acessar determinados recursos - determinadas operações exigem validação adicional --- ## 2.6 Fora do Escopo Liste explicitamente **o que o sistema não fará**. Isso ajuda a evitar crescimento descontrolado do projeto. --- # 3. Fluxos e Comportamento do Sistema Esta seção demonstra **como o sistema funciona**. Use diagramas sempre que possível. --- ## 3.1 Fluxo Principal do Usuário Apresente o fluxo principal do sistema. Utilize: - fluxogramas - diagramas de atividades - diagramas de sequência Inclua **imagens dos diagramas**. --- ## 3.2 Fluxos Alternativos Descreva cenários como: - erros - cancelamentos - exceções --- # 4. Mockups e Experiência do Usuário (UX) Esta seção apresenta **a visualização inicial do produto antes da implementação**. Mockups ajudam a validar: - fluxo de navegação - organização da interface - interações do usuário - clareza da experiência Ferramentas sugeridas: - Figma - Excalidraw - Balsamiq - Whimsical - protótipos desenhados à mão --- ## 4.1 Fluxo de Navegação Apresente um diagrama mostrando como o usuário navega entre telas. Exemplo: Login → Dashboard → Cadastro → Relatório Inclua **imagem do fluxo de navegação**. --- ## 4.2 Wireframes ou Mockups das Telas Apresente os principais mockups do sistema. Inclua pelo menos: - tela inicial - fluxo principal - tela de entrada de dados - tela de resultado ou visualização Para cada tela inclua: - imagem - breve descrição da funcionalidade - ações principais do usuário Sempre que possível: - inclua **links para protótipo navegável** - inclua **prints das telas** --- ## 4.3 Fluxo de Interação do Usuário Demonstre passo a passo um fluxo importante. Exemplo: 1. usuário acessa o sistema 2. cria conta 3. registra dados 4. visualiza resultados Inclua **sequência de telas ou fluxo visual**. --- ## 4.4 Feedback Inicial de Usuários (Opcional) Se possível, inclua: - comentários de usuários - sugestões de melhoria - validação inicial do mockup --- # 5. Arquitetura do Sistema Esta seção demonstra **como o sistema será construído**. --- ## 5.1 Diagrama C4 Apresente três níveis. ## 1. Nível 1: Diagrama de Contexto É a **visão macro** do sistema. O foco aqui não é a tecnologia, mas sim como o software se encaixa no ecossistema e no mundo real. * **Objetivo:** Mostrar o sistema como uma "caixa preta" e suas interações básicas com o ambiente externo. * **O que incluir:** * **Atores:** Diferentes perfis de usuários (Ex: Cliente, Administrador, Operador). * **Sistemas Externos:** Softwares legados, serviços de terceiros ou provedores de identidade. * **Fluxo de Valor:** Como a informação entra, circula e sai do sistema principal. --- ## 2. Nível 2: Diagrama de Containers Neste estágio, damos o primeiro **"zoom"**. Decompomos o sistema em suas unidades de execução independentes (containers). * **Objetivo:** Apresentar a arquitetura de alto nível e as decisões tecnológicas fundamentais. * **O que incluir:** * **Aplicações Web/Mobile:** Interfaces de usuário (Ex: SPA em React, App Android/iOS). * **Serviços de Backend:** Unidades lógicas de processamento (Ex: API Gateway, Microserviços em Node.js ou Go). * **Armazenamento:** Persistência de dados (Ex: PostgreSQL, MongoDB, Redis). * **Protocolos:** Como os containers se comunicam (Ex: JSON/HTTPS, gRPC, RabbitMQ). --- ## 3. Nível 3: Diagrama de Componentes O foco agora é o que acontece **dentro de um único container** (como uma API específica ou um serviço de backend). * **Objetivo:** Identificar as responsabilidades internas, padrões de código e a organização lógica. * **O que incluir:** * **Estrutura Interna:** Organização das camadas (Ex: Controladores, Serviços, Repositórios e Clientes de API). * **Lógica de Negócio:** Componentes que encapsulam as regras específicas do domínio. * **Interações:** Como os componentes internos se orquestram para processar e responder a uma requisição. --- ## 5.2 Modelo de Dados Apresente: - DER (diagrama entidade relacionamento) - esquema relacional - modelo de documentos (NoSQL) Inclua **diagramas do modelo de dados**. --- ## 5.3 Principais Componentes Descreva os principais módulos do sistema. Exemplo: - API - sistema de autenticação - módulo de processamento - camada de persistência --- ## 5.4 Stack Tecnológica Liste as tecnologias utilizadas. Para cada tecnologia explique **por que ela foi escolhida**. Exemplo: Node.js Escolhido pela capacidade de lidar com alto volume de requisições I/O. --- # 6. Segurança e Privacidade Inclua preocupações básicas de segurança. Exemplos: - proteção contra OWASP Top 10 - autenticação e autorização - criptografia de dados sensíveis --- ## 6.1 Privacidade e LGPD Explique: - quais dados serão coletados - como serão armazenados - como o usuário poderá solicitar remoção de dados --- # 7. Planejamento do Projeto Defina os principais marcos de desenvolvimento. Use **datas absolutas** no formato `DD/MM/AAAA (dia da semana)`, ancoradas no calendário do semestre — não em "semana X". | Marco | Descrição | Prazo | |---|---|---| | M1 | Setup do ambiente e prova de conceito | DD/MM/AAAA (dia da semana) | | M2 | MVP funcional | DD/MM/AAAA (dia da semana) | | M3 | Testes e melhorias | DD/MM/AAAA (dia da semana) | > Os marcos precisam caber no prazo de entrega da Disciplina de Portfólio — **30/11/2026 (segunda-feira)**. É o que o avaliador verifica no ponto 8 das [diretrizes de avaliação](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook/blob/main/documentation/diretrizes-avaliacao-professores.md). --- # 8. Referências Inclua: - artigos - documentação técnica - ferramentas utilizadas - repositórios --- # 9. Apêndices Podem incluir: - mockups adicionais - resultados de pesquisa - entrevistas com usuários - diagramas complementares - links para protótipos ou repositórios Sempre que possível inclua **imagens, protótipos ou referências visuais**. --- # 10. Parecer do Comitê de Avaliação (A ser preenchido pelos três professores avaliadores) Cada avaliador atribui **uma nota única de 0 a 10, em intervalos de 0,5**, e assina. | Faixa | Situação | |---|---| | **7,0 a 10** | ✅ Aprovada | | **6,0 a 6,5** | ⚠️ Aprovada **com correções obrigatórias** — sem elas a proposta cai abaixo de 6,0 e reprova | | **Abaixo de 6,0** | ❌ Reprovada — exige reapresentação | Escala completa e critérios em [Recomendações para Avaliação das Propostas de Portfólio](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook/blob/main/documentation/diretrizes-avaliacao-professores.md). --- ## Avaliador 1 | Campo | Preenchimento | |---|---| | **Nome** | | | **Nota** (0 a 10, passo 0,5) | | | **Situação** | [ ] Aprovada [ ] Aprovada com correções [ ] Reprovada | | **Data** | DD/MM/AAAA | | **Assinatura** | | **Correções obrigatórias** (preencher se a situação exigir): 1. 2. 3. **Comentários e recomendações:** --- ## Avaliador 2 | Campo | Preenchimento | |---|---| | **Nome** | | | **Nota** (0 a 10, passo 0,5) | | | **Situação** | [ ] Aprovada [ ] Aprovada com correções [ ] Reprovada | | **Data** | DD/MM/AAAA | | **Assinatura** | | **Correções obrigatórias** (preencher se a situação exigir): 1. 2. 3. **Comentários e recomendações:** --- ## Avaliador 3 | Campo | Preenchimento | |---|---| | **Nome** | | | **Nota** (0 a 10, passo 0,5) | | | **Situação** | [ ] Aprovada [ ] Aprovada com correções [ ] Reprovada | | **Data** | DD/MM/AAAA | | **Assinatura** | | **Correções obrigatórias** (preencher se a situação exigir): 1. 2. 3. **Comentários e recomendações:** --- ## Consolidação | Avaliador | Nota | Situação | |---|---|---| | Avaliador 1 | | | | Avaliador 2 | | | | Avaliador 3 | | | | **Média final** | | | **Correções obrigatórias consolidadas** — o aluno deve endereçar todas antes da versão final entregue ao professor da disciplina: 1. 2. 3. **Data da validação das correções:** DD/MM/AAAA **Professor da disciplina:** __________________________