From 7191c04f03a7c74e0bdabe6a1f30adc46dc47688 Mon Sep 17 00:00:00 2001 From: matheusdealcantara Date: Mon, 9 Dec 2024 23:27:20 -0300 Subject: [PATCH] =?UTF-8?q?Adicionar=20Doc.=20de=20Vis=C3=A3o=20no=20MKDoc?= =?UTF-8?q?s?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/documento-visao/documento-visao.md | 405 +++++++++++++++++++++++- mkdocs.yml | 1 - 2 files changed, 404 insertions(+), 2 deletions(-) diff --git a/docs/documento-visao/documento-visao.md b/docs/documento-visao/documento-visao.md index c1c714d..bf45c3e 100644 --- a/docs/documento-visao/documento-visao.md +++ b/docs/documento-visao/documento-visao.md @@ -1,3 +1,406 @@ | Versão | Data | Descrição da Alteração | Nome(s) Integrante(s) | | :----: | :--: | :--------------------: | :-------------------: | -| 1.0 | 25/02/2024 | Mudei isso e aquilo | Fulano de Tal | \ No newline at end of file +| 1.0 | 26/11/2024 | Redação inicial do documento de visão | Todos | +| 1.1 | 02/12/2024 | Finalização do backlog do produto e planejamento das sprints | Matheus de Alcântara, Vilmar, Gabriel Flores, Caio Sabino e João Victor Pires | + +Sagittarius – Sistema de Gestão para a empresa Frango Assado Pele Dourada + +## [VISÃO DO PRODUTO E DO PROJETO](https://1drv.ms/w/c/dc034d221001755e/ERKbbbL04F9LhrPs5txr-z0Bl07xoD9xL0_u6FwRZCJh2w?e=rvMSzA) + +Versão 1.0 + +Tabela - Integrantes do Grupo: + + +| Mat. | Nome | Função (responsabilidade) | +| :---: | -- | -- | +| 231026509 | Matheus de Alcântara da Silva Campos | Desenvolvedor Back-end e Banco de Dados | +| 231026590 | Vilmar José Fagundes dos Passos Júnior | Desenvolvedor Back-end e Banco de Dados | +| 222015159 | Lucas Guimarães Borges | Desenvolvedor Back-end | +| 222006150 | Micael Kauan Freitas Chagas | Desenvolvedor Front-end | +| 231026358 | Gabriel Flores Coelho | Banco de Dados | +| 221007635 | André Gustavo Rabelo do Nascimento | Desenvolvedor Front-end | +| 231026400 | João Victor Pires Sapiência Santos | Desenvolvedor Back-end | +| 231026302 | Caio Lucas Messias Sabino | Desenvolvedor Back-end | +| 221008196 | João Victor Sousa Soares e Silva | Desenvolvedor Front-end | +| 222022082 | Fábio Santos Araújo | Banco de Dados | + + +Visão de Produto e Projeto + +Histórico de Revisões + + +| Data | Versão | Descrição | Autor | +| -- | -- | -- | -- | +| 19/11/2024 | 1.0 | Criação da primeira versão do documento, com as informações do sobre o produto e nossas estratégias para desenvolve-lo | Equipe Sagittarius | + + +## VISÃO DO PRODUTO E PROJETO + +## 1 VISÃO GERAL DO PRODUTO + +### 1.1 Problema + +A gestão manual de operações em lojas de frangos assados, como vendas, encomendas, controle de estoque e fluxo de caixa, apresenta diversos desafios que comprometem a eficiência e a organização do negócio. Atualmente, essas atividades são realizadas de forma descentralizada, utilizando planilhas e cadernos de anotações que não atendem às necessidades específicas do setor. + +Esses problemas são agravados pela ausência de uma solução tecnológica específica para o segmento, que integre as operações diárias em uma única plataforma. Assim, surge a necessidade de um sistema interno que automatize tarefas críticas, centralize informações e forneça ferramentas para análise e gestão eficiente. + +A implementação dessa solução permitirá maior controle operacional, redução de erros e economia de tempo, contribuindo diretamente para o crescimento e sustentabilidade do negócio. + + +![](https://web-api.textin.com/ocr_image/external/7dad51ece9f91740.jpg) + +Figura 1 – Diagrama de Ishikawa + +### 1.2 Declaração de Posição do Produto + +#### 1.2.1 Produto Proposto + +O grupo propõe o desenvolvimento de um software interno com o objetivo de facilitar a administração e organização de uma loja de frangos assados. O software integrará funcionalidades como gestão de vendas, encomendas, controle de estoque, cadastro de clientes e contabilidade. + +#### 1.2.2 Características Diferenciais + +O software diferencia-se por oferecer uma solução completa e customizada para pequenas empresas do setor alimentício, especificamente lojas de frangos assados. Diferentemente de sistemas genéricos, o produto atenderá às necessidades específicas do negócio, proporcionando automação de tarefas administrativas, geração de relatórios e dashboards visuais, além de maior controle sobre as operações. + +#### 1.2.3 Usuários-Alvo + +O produto destina-se a proprietários e administradores de lojas de frangos assados. + +#### 1.2.4 Importância para os usuários + +• Os usuários atualmente enfrentam dificuldades na gestão manual de vendas,estoque e encomendas. + +• A implementação do sistema trará benefícios como economia de tempo, redução de erros operacionais, maior organização e acesso a informações rápidas e precisas. + +• Adicionalmente, o sistema contribuirá para um melhor controle financeiro, auxiliando no acompanhamento do fluxo de caixa e desempenho geral do negócio + +#### 1.2.5 Motivo para Adesão + +Os clientes devem adotar o sistema pelos seguintes motivos: + +• Automatização de tarefas essenciais, como atualização de estoque e geração de relatórios diários. + +• Aumento da eficiência operacional, possibilitando maior foco em estratégias de expansão e melhoria de produtos. + +• Interface intuitiva e acessível, projetada para pequenos empresários com baixo conhecimento técnico. + +Tabela 1 – Declaração de Posição do Produto + + +| Para: | Proprietários e administradores de lojas de frangos assados, que precisamde maior eficiência na gestão do negócio. | +| -- | -- | +| Necessidade: | Facilitar a administração e organização das operações diárias, eliminandoerros e atrasos provenientes da gestão manual. | +| O (Sistema de Gestão para a empresa Frango Assado Pele Dourada): | É uma aplicação web de gestão integrada para lojas de frangos assados. | +| Que: | Automatiza tarefas operacionais, melhora a organização e fornece relatórios e dashboards para análise do desempenho do negócio. | +| Ao contrário: | Processos manuais ou sistemas genéricos, que geram erros, atrasos e fal-ta de informações consolidadas e em tempo real. | +| Nosso produto: | Apresenta uma solução customizada, com interface intuitiva, automaçãode processos críticos e geração de insights visuais por meio de dashboards. | + + +### 1.3 Objetivos do Produto + +O projeto tem como objetivo principal desenvolver um software interno de gestão para facilitar a administração e organização da loja de frangos assados Pele Dourada. Com a integração de funcionalidades robustas, o sistema visa atender às necessidades específicas do negócio, proporcionando maior controle, eficiência e agilidade no dia a dia da operação. + +#### 1.3.1 Objetivos Principais + +## 2 Gestão de Vendas e Encomendas + +• Registrar as vendas no balcão para controlar a quantidade de produ tos vendidos. + +• Registrar as encomendas feitas pelos clientes, com opções de entre ga ou retirada no balcão. + +• Gerar relatórios diários com informações sobre as vendas realizadas e status das encomendas. + +## I. Controle de Estoque Diário + +• Registrar a quantidade de produtos disponíveis e atualizá-la automati-camente com base nas vendas e encomendas. + +• Permitir o cadastro de novos produtos e o controle contínuo do esto que. + +## II. Cadastro de Clientes + +• Facilitar o cadastro e a edição das informações dos clientes (nome, tele fone, endereço) para otimizar o gerenciamento das encomendas e o atendimento. + +## III. Controle de Caixa + +Registrar entradas e saídas de dinheiro, com a possibilidade de gerar um relatório detalhado de fluxo de caixa. + +• Permitir a visualização das vendas realizadas por cartão, facilitando a análise dos métodos de pagamento. + +## IV. Dashboard Geral + +• Fornecer um painel de controle visual com informações rápidas sobre o desempenho do negócio, incluindo vendas do mês, quantidade de fran gos vendidos, e status das encomendas. + +## V. Autenticação: + +Garantir a segurança do sistema com um processo de login para que apenas usuários autorizados possam acessar as funcionalidades e dados sensíveis. + +## 2.1.1 Objetivos Secundários + +## I. Link para Status da Encomenda + +• O sistema gera um link específico para cada encomenda, que pode ser compartilhado com o cliente. + +• O cliente pode acessar o link e visualizar o status da encomenda, como "Pendente", "Em Produção", "Pronto para Retirada", "Em Rota de En trega", etc. + +### 2.2 Tecnologias a Serem Utilizadas + +• Backend (Servidor) + +o Linguagem de Programação: Python + +o Framework: Django + +o Banco de Dados: PostgreSQL + +• Frontend (Interface de Usuário) + +o Linguagem de Programação: JavaScript + +o Framework/Biblioteca: React.js + +o Estilização: CSS + +• Ferramenta de Colaboração e Gerenciamento + +o Controle de Versão: Git (com repositório no GitHub) + +o Gerenciamento de Projetos: GitHub Projects + +o Comunicação: Teams, Discord + +## 3 VISÃO GERAL DO PROJETO + +### 3.1 Ciclo de vida do projeto de desenvolvimento de software + +Metodologia: A sua flexibilidade para lidar com mudanças nos requisitos, sua entrega de valor contínua ao cliente por meio de funcionalidades e otimização de tempo, decidimos adotar a metodologia ágil. Tendo em vista que, ela prio-riza as necessidades do cliente, visto que ele participa de todas as etapas do projeto, e promove o aprimoramento contínuo através de revisões regulares dos processos. + +- Processo: Será utilizada elementos do Scrum e XP. Visto que, combina a es trutura organizacional e a entrega iterativa do Scrum com as práticas técnicas rigorosas do XP, promovendo uma maior adaptabilidade a mudanças, entre gas rápidas e software de alta qualidade. + +Procedimentos: SCRUM Guide e XP Guide. + +Ferramentas: Será utilizado o GitHub para controle de submissões e mudan ças de código, o Discord para reuniões do grupo e gerenciamento do projeto,já que é possível criar canais de voz e texto para o controle de diferentes campos do projeto, além da confiabilidade com o sistema, o Figma para cria-ção de protótipos, design e interface do usuário. Para manter a comunicação com o cliente, foram utilizados o Microsoft Team e o WhatsApp. + +Métodos: Utilizamos os métodos do SCRUM/XP como por exemplo: Pair Programming, Code Review, Sprint, Sprint Planning, Sprint Review, Sprint Retrospective e Refinamento de Backlog de Produto. Será agendado encon tros semanais para manter a equipe organizada e em sintonia com o projeto para seguir o planejamento com êxito. + +3.2 Organização do Projeto + + +| Papel | Atribuições | Responsável | Participantes | +| -- | -- | -- | -- | +| Desenvolvedor Back-end | Desenvolver funcionalidades do produto, comunicação com front-end, comunicação com o banco de dados, re-alizar testes das funcionalidades | Matheus | Matheus, Vilmar,Lucas João Santos,Caio | +| Desenvolvedor Front-end | Programar visual do produto, comunicação com o back-end, desenvolvimento da API | Micael | Micael, André, JoãoSilva | +| Designer | Criar visual do produto, manter produto de fácil usabilidade | Micael | Micael, André, JoãoSilva | +| Cliente | Promover feedback das funcionalidades, feedback do visual do produto, controle de qualidade, manter projeto dentro do escopo | Matheus Rodrigues | Julia Rodrigues,Matheus Rodrigues | +| Dono do Produto | Atualizar a documentação do projeto, garantir as entre-gas das sprints | Matheus Rodrigues | Matheus Rodrigues | +| Desenvolvedor do Banco de Dados | Criar o banco de dados do produto, garantir a eficiência das buscas, criar perfis de acesso, comunicação com o back-end | Fabio | Matheus, Vilmar,Gabriel, Fábio | + + +### 3.3 Planejamento das Fases e/ou Iterações do Projeto + + +| Sprint | Produto (Entrega) | Data Início | Data Fim | Entregável(eis) | Responsá-veis | % conclusão | +| -- | -- | -- | -- | -- | -- | -- | +| Sprint 1 | Definição do Produto | 05/11/2024 | 12/11/2024 | Definição do escopo do pro-jeto. | Todos | 100% | +| Sprint 2 | Elaboração do protótipo e escolha das tecnologias. | 12/11/2024 | 19/11/2024 | Linguagens e frameworks. | Todos | 90% | +| Sprint 3 | Elaboração do documento de visão do projeto | 19/11/2024 | 26/11/2024 | Documento de Visão. | Todos | 100% | +| Sprint 4 | Criação do Schema do banco de dados. | 26/11/2024 | 03/12/2024 | Schema do Banco de dados. | Todos | 0% | +| Sprint 5 | Resumo diário das vendas, CRUD de encomendas e entregas | 05/12/2024 | 12/12/2024 | Página de encomendas e entregas. | Todos | 0% | +| Sprint 6 | CRUD de produtos | 12/12/2024 | 19/12/2024 | Página de produtos. | Todos | 0% | +| Sprint 7 | CRUD de clientes e fluxo de caixa | 02/01/2025 | 09/01/2025 | Página de gestão de clientes e de fluxo de caixa. | Todos | 0% | +| Sprint 8 | Dashboard e histó-rico de vendas no cartão | 16/01/2025 | 23/01/2025 | Dashboard inicial e página de histórico de vendas no cartão. | Todos | 0% | + + +3.4 Matriz de Comunicação + + +| Descrição | Área/ Envolvidos | Periodicidade | Produtos Gerados | +| -- | -- | -- | -- | +| • Acompanhamento das Atividades em Andamento • Acompanhamento dos Riscos, Compromissos, Ações Pendentes, Indicadores | • Equipe do Projeto | • Semanal | • Ata de reunião • Relatório de situação do projeto | +| • Acompanhamento das Atividades em Andamento • Acompanhamento dos Riscos, Compromissos, Ações Pendentes, Indicadores | | • Quinzenal | • Ata de reunião • Relatório de situação do projeto | +| - Comunicar situação do projeto | • Equipe • Prof./Monitor | • Semanal | • Ata de reunião, e • Relatório de situação do projeto | + + +3.5 Gerenciamento de Riscos + + +| Fase | Risco | Grau de Exposição | Mitigação | Plano de Contingência | +| -- | -- | -- | -- | -- | +| Levantamento de Requisitos | Requisitos mal definidos | Alto | Realizar reuniões claras e revisar os requisitos com o monitor e colegas. | Agendar reuniões adicionais para esclarecer e ajustar os requisitos. | +| Levantamento de Requisitos | Falta de participação dos stakeholders | Médio | Garantir o envolvimento do cliente e monitor em reuniões importantes. | | +| Design | Prototipação incompatível com o escopo | Médio | Validar o protótipo com os stakeholders antes de avançar para o desenvolvimento. | | +| | Design não intuitivo | Baixo | Realizar testes de usabilidade com a equipe e coletar feedbacks do cliente. | | +| Desenvolvimento | Bugs críticos | Alto | Realizar testes contínuos e usar ferramentas de debug. | Reservar tempo adicional no cronograma para resolver problemas críticos. | +| Desenvolvimento | Atrasos na entrega dos requisitos | Alto | Realizar reuniões regulares para garantir alinhamento entre equipe e stakeholders. | Repriorizar tarefas no backlog e ajustar cronograma conforme necessário. | +| Desenvolvimento | Falta de conhecimento técnico da equipe | Alto | Auxiliar com capacitação na tecnologia que utilizaremos e no uso do sistema para a equipe envolvida. | Realizar reuniões constantemente para auxiliar na resolução de problemas. | +| Desenvolvimento | Mudanças de escopo frequentes | Baixo | Definir escopo claro e solicitar aprovações formais em mudanças solicitadas. | | +| Desenvolvimento | Restrição de tempo para desenvolvimento | Alto | Estabelecer prioridades claras e realizar entregas principais antes de partir para funcionalidades adicionais. | Solicitar uma prorrogação da sprint ou reavaliar funcionalidades menos essenciais. | +| Desenvolvimento | Conflitos de código no versionamento | Médio | Estabelecer boas práticas de Git, como commits frequentes e branches bem | | +| | | | definidas. | | +| Documentação | Documentação incompleta ou desatualizada | Médio | Atualizar a documentação paralelamente ao desenvolvimento. | | +| Documentação | Dificuldade de entendimento | Alto | Usar linguagem clara e objetiva, com exemplos e ilustrações. | | +| Implementação | Erros na entrada de dados das vendas | Médio | Implementar validações no sistema para evitar erros, como campos obrigatórios e mensagens claras. | | +| Implementação | Problemas de compatibilidade com o servidor | Alto | Testar o sistema no ambiente de produção antes do lançamento oficial. | Ajustar configuraçõesdo servidor e realizar uma nova implementação. | +| Implementação | Desempenho abaixo do esperado | Alto | Monitorar o desempenho durante os testes e otimizar o código, se necessário. | Implementar soluções de otimização imediatas, como cache econsultas otimizadas no banco de dados. | + + +### 3.6 Critérios de Replanejamento + +• Mudanças significativas no escopo: Caso sejam identificadas alterações no escopo, como a necessidade de implementar funcionalidades adicionais (ex.: reserva de produtos por tempo limitado ou gerenciamento de prioridades para encomendas), o sistema deverá ser replanejado para ajustar os recursos e atender às novas especificações sem comprometer os objetivos iniciais. + +• Atrasos: Caso atrasos sejam detectados no desenvolvimento de funci-onalidades essenciais, serão realizadas revisões no cronograma para garantir entregas em tempo hábil, priorizando partes críticas do sistema, como o fluxo de vendas no balcão. + +• Mudança de funções entre os membros: Se houver necessidade de redistribuir tarefas entre os desenvolvedores, a equipe reforçará a documenta-ção detalhada, promoverá treinamento cruzado e manterá uma comunicação clara para garantir continuidade no progresso do sistema. + +• Novos requisitos para o projeto: Sempre que surgirem novos requisi-tos, como a necessidade de relatórios personalizados de vendas ou a opção de integração com aplicativos de entrega, será feita uma análise detalhada de impacto. O plano será ajustado para priorizar funcionalidades de maior valor agregado, garantindo que o sistema atenda às demandas dos usuários e do negócio. + +• Desentendimento entre os membros da equipe: Em caso de conflitos dentro da equipe, medidas serão tomadas para revisar as alocações de tarefas e facilitar a comunicação entre os membros, evitando impactos no desenvolvi-mento. Se necessário, será utilizada a Comunicação Não Violenta (CNV) para mediar e resolver divergências, promovendo um ambiente colaborativo e sau-dável para alcançar os objetivos do projeto. + +## 4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE + +Para o desenvolvimento do sistema de gestão da empresa Frango Assado Pele Dourada, a equipe adotou metodologias ágeis, combinando elementos do SCRUM e XP (Extreme Programming). Essa abordagem foi escolhida para garantir maior flexibilidade, colaboração contínua com o cliente e entregas incrementais de valor ao longo do projeto. + +O SCRUM é utilizado como framework principal para organização e gerenciamento do projeto. Ele promove a entrega incremental por meio de sprints, com foco na adaptação contínua e auto-organização da equipe. O XP complementa o SCRUM com práticas técnicas rigorosas que garantem a qualidade do software e a satisfação do cliente, como programação em pares, integração contínua e refatoração. + +Entre os métodos escolhidos serão utilizados as sprints, revisão de código em pares, reuniões semanais (checkpoints), retrospectivas e refinamento do Backlog do produto para manter a equipe organizada e sincronizada, ajudando na entrega contínua das tarefas do projeto. + +Cerimônias do SCRUM: + + +| Atividade | Método | Ferramenta | Entrega | +| -- | -- | -- | -- | +| Checkpoint | Reunião online | Teams | Registro do progresso, levantamento de erros, planejamentodo futuro. | +| Planning | Reunião online | Discord | Planejamento e decisão de tarefas da sprint | +| Refinamento | Reunião online | Discord | Histórias de usuáriomais detalhadas para auxiliar na criação das próximas sprints | +| Retrospectiva | Reunião online | Discord | Retrospectiva do progresso da sprint | +| Daily | Não serão realizadas por conta dos conflitos nos horários dos integrantes da equipe | | | + + +Práticas do XP utilizadas: + + +| Prática XP | Motivo | +| -- | -- | +| Programação em Dupla | Melhora a qualidade do código e promove o aprendizado entre os desenvolvedores, além de minimizar erros ao ter dois programadores colaborando. | +| Entregas Frequentes | Facilita a entrega contínua de valor aocliente, permitindo ajustes rápidos e uma abordagem mais responsiva às necessidades do cliente. | +| Integração Regular | Garante que novas funcionalidades sejam incorporadas sem introduzir falhas, mantendo a estabilidade do sistema durante o desenvolvimento. | +| Normas de Código | Assegura consistência e facilita a manutenção e compreensão do código entre diferentes membros da equipe. | +| Revisão de Código | Mantém o código limpo e eficiente, permitindo melhorias contínuas sem alterar sua funcionalidade essencial. | +| Testes de Funcionalidade | Essenciais para garantir que o software atende aos requisitos e mantém um altopadrão de qualidade. | +| Planejamento de Jogos | Não será utilizado devido às limitações de tempo disponíveis para interação com o cliente. | +| Cliente no Local | Não será implementado devido à indisponibilidade do cliente para participar presencialmente durante o desenvolvimento. | + + +## 5 DECLARAÇÃO DE ESCOPO DO PROJETO + +### 5.1 Backlog do produto + +Perfil: Administrador + +Cenário 1: Login + + +| REQUISITO | CATEGORIA | JUSTIFICATIVA | +| -- | -- | -- | +| O administrador deve poder acessar a sua conta por meio de nome de usuário e senha previamente fornecidos. | MUST | Garantir a confidencialidade e integridade do sistema aofornecer um mecanismo de autenticação. | +| O administrador deve poder redefinir a sua senha. | MUST | Garantir o acesso ao sistema em caso de esquecimento. | + + +Cenário 2: Gestão de vendas e encomendas + + +| REQUISITO | CATEGORIA | JUSTIFICATIVA | +| -- | -- | -- | +| O administrador deve poder registrar as vendas feitas em balcão, atribuindo uma quantidade e horário. | MUST | Permitir o controle da quantidade de produtos vendidos ao longo do dia. | +| O sistema deve atualizar automaticamente o estoque à medida que cada venda realizada for registrada. | MUST | Garantir a consistência e correspondência dos dados no sistema com o ambiente externo. | +| O administrador deve poder registrar as encomendas dos clientes, inserindo informações como o nome do cliente, horário e quantidade de produtos. | MUST | Garantir que não ocorramconfusões no processo de entrega das encomendas. | +| O administrador deve poder selecionar a opção “para entrega” ou “retirar no balcão” no ato de registro da encomenda. | MUST | Organizar as encomendas auxiliando na gestão. | +| O sistema deverá lançar um alerta na tela para as encomendas que estão atrasadas. | MUST | Informa o administrador para que possam tomar providências, como ligar para um cliente. | +| O sistema deverá fornecer um resumo do | MUST | Permitir que haja um monitoramento do | +| dia das vendas realizadas, havendo informações como quantidade do produto, total de vendas e informações gerais sobre encomendas. | | desempenho das vendasdo dia. | + + +Cenário 3: Controle de estoque diário + + +| REQUISITO | CATEGORIA | JUSTIFICATIVA | +| -- | -- | -- | +| O administrador deve poder cadastrar produtos no sistema. | MUST | Para que seja possível a adição de produtos no estoque. | +| O administrador deve poder registrar a quantidade de um determinado produto no estoque para o dia. | MUST | Permitir que o estoque esteja atualizado. | +| O administrador deve poder navegar entre os dias em que foram ou não registrados os produtos em estoque. | COULD | Permitir que o administrador possa ter um acesso ao histórico deestoques registrados anteriormente, no entanto, não é essencial. | + + +Cenário 4: Cadastro de clientes + + +| REQUISITO | CATEGORIA | JUSTIFICATIVA | +| -- | -- | -- | +| O administrador deve poder cadastrar um cliente, inserindo o seu nome, telefone e endereço. | MUST | Fornecer informações cruciais do cliente para o administrador para que asutilize quando necessário. | +| O administrador deve poder excluir ou alterar o cadastro de um cliente. | MUST | Garante maior controle doadministrador ao sistema. | + + +Cenário 5: Controle de caixa + + +| REQUISITO | CATEGORIA | JUSTIFICATIVA | +| -- | -- | -- | +| O administrador deve poder registrar entradas e saídas de dinheiro, detalhando o valor e data e fornecendo uma descrição. | MUST | Permitir que se monitoreo fluxo de caixa. | +| O sistema deve fornecer um saldo diário com todas as transações registradas. | MUST | Garante que haja uma visão geral das transações para avaliação do desempenho. | +| O sistema deve fornecer um relatório das vendas realizadas em cartão, detalhando a modalidade crédito ou débito. | MUST | Permitir que o administrador visualize odesempenho dos métodos de pagamento. | + + +Cenário 6: Dashboard geral + + +| REQUISITO | CATEGORIA | JUSTIFICATIVA | +| -- | -- | -- | +| O sistema deve exibir um dashboard com informações gerais (total de vendas no mês, quantidade de frangos vendidos, resumo de encomendas e vendas no balcão) da atividade mensal. | MUST | Contribuir para uma rápida análise do desempenho mensal da empresa. | +| O sistema deve fornecer gráficos e/ou informações visuais | MUST | Facilitar o entendimento eanálise. | + + +Forma de elicitação de requisitos: entrevistas. + +### 5.2 Perfis + +Tabela : Perfis de acesso + + +| # | Nome do perfil | Características do perfil | Permissões de acesso | +| -- | -- | -- | -- | +| <1> | Administrador | Responsável por gerenciar todo o sistema e realizar operações administrativas essenciais. | - Cadastro, edição e exclusão de produtos.- Visualização e edição de pedidos. - Acesso a relatórios completos. - Configuração do sistema. | + + +5.3 Cenários + +Tabela: Cenários funcionais + + +| Sistema: xxx – Cenários funcionais | Sistema: xxx – Cenários funcionais | Sistema: xxx – Cenários funcionais | +| -- | -- | -- | +| Numeração do cenário | Nome do cenário | Sprints | + + +5.4 Tabela de Backlog do produto + +Tabela: Backlog do produto + + +| Sistema: Frango Assado Pele Dourada – Backlog do produto | Sistema: Frango Assado Pele Dourada – Backlog do produto | Sistema: Frango Assado Pele Dourada – Backlog do produto | Sistema: Frango Assado Pele Dourada – Backlog do produto | Sistema: Frango Assado Pele Dourada – Backlog do produto | Sistema: Frango Assado Pele Dourada – Backlog do produto | | +| -- | -- | -- | -- | -- | -- | -- | +| Numeração (Cenário / requisito) | Sprint | Nome do requisito | Tipo de requisito (Funcional / não funcional) | Priorização do requisito Must, Should, Could | Descrição suscinta do requisito | User histories (U.S.) associadas Identifique as U.S. associadas ao requisito | +| 01 | Sprint 5 | | Funcional | Must | O administrador é capaz de controlar a quantidade de produtos vendidos ao longo do dia no balcão. | Como administrador, eu quero registrar as vendas no balcão. | +| 02 | Sprint 5 | | Funcional | Must | O administrador é capaz de organizar as entregas e retiradas. | Como administrador, eu quero registrar as encomendas dos clientes. | +| 03 | Sprint 5 | | Funcional | Must | O administrador é capaz de monitorar o desempenho do negócio. | Como administrador, eu quero visualizar um resumo diário das vendas. | +| 04 | Sprint 6 | | Funcional | Must | O administrador é capaz de manter o estoque atualizado. | Como administrador, eu quero registrar aquantidade de produtos disponíveis diariamente. | +| 05 | Sprint 6 | | Funcional | Must | O administrador é capaz de acompanhar o estoque de diferentes itens | Como administrador, eu quero cadastrar novos produtos no sistema. | +| 06 | Sprint 7 | | Funcional | Must | O administrador é capaz de facilitar o gerenciamento de encomendas e contatos. | Como administrador, eu quero cadastrar os dados dos clientes. | +| 07 | Sprint 7 | | Funcional | Must | O administrador é capaz de monitorar o fluxo de caixa. | Como administrador, eu quero registrar entradas e saídas de dinheiro. | +| 08 | Sprint 8 | | Funcional | Must | O administrador é capaz de visualizar as vendas realizadas por cartão para analisar o desempenho dos métodos de pagamento. | Como administrador, eu quero visualizar as vendas realizadas por cartão para analisar o desempenho dos métodos de pagamento. | +| 09 | Sprint8 | Não funcional | Must i | O administrador é capaz dvisualizar um dashboard cnformações gerais para tevisão rápida do desempenmensal. | e Como adminisom um dashboardr uma para ter uma vho desempenho | trador, eu quero visualizar com informações gerais isão rápida do mensal. | +| 10 | Sprint 5 | Funcional | Must | Será criado uma conta administradora para garansegurança dos dados | Como administir a login no sistemsegurança do | trador, eu quero realizar a para garantir a s dados. | +| 11 | Sprint 9 (opcional) | Funcional | Could | O administrador é capaz dum link de status de encopara compartilhar com o cl | e gerar Como adminismenda link com o statiente compartilhar cque ele acomppedido | trador, eu quero gerar umus da encomenda para om o cliente, permitindo anhe o andamento do | + + +## 6 REFERÊNCIAS BIBLIOGRÁFICAS + +1. H. Washizaki, eds., Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), Version 4.0, IEEE Computer Society, 2024; www.swebok.org. diff --git a/mkdocs.yml b/mkdocs.yml index 816d543..9ecaecc 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,7 +1,6 @@ site_name: Documentação nav: - - Instruções mkdocs: "index.md" - Documento de Visão: "documento-visao/documento-visao.md" - Documento de Requisitos: "documento-requisitos/documento-requisitos.md" - Documento de Arquitetura: "documento-arquitetura/documento-arquitetura.md"