PRIORIZAÇÃO DE REQUISITOS

# Priorização de Requisitos do Projeto Kronos (Método MoSCoW) 

 

 Este documento utiliza o método MoSCoW para classificar os requisitos funcionais do projeto Kronos, com o objetivo de definir o escopo do Produto Mínimo Viável (MVP) e planear as fases seguintes do desenvolvimento. 

 

 ## 1. Must-Have (Tem que ter) 

 

 Estes requisitos são **essenciais e inegociáveis** para a primeira versão do produto. Sem eles, o sistema não funciona ou não entrega o seu valor principal. O foco aqui é construir o fluxo completo da **História de Utilizador 1 (HU1)**. 

 

 | ID | Requisito | Justificação | 

 | :--- | :--- | :--- | 

 | **RF01** | Upload de Mídia | Ponto de partida de toda a operação. Sem upload, nada acontece. | 

 | **RF02** | Extração de Áudio | Lógica central para processar vídeos, que é o caso de uso principal. | 

 | **RF03** | Iniciar Transcrição | Ação fundamental do utilizador para começar o processo. | 

 | **RF04** | Integração com a API de Transcrição | O coração técnico do projeto; sem a API externa, não há transcrição. | 

 | **RF05** | Armazenamento da Transcrição | É crucial persistir o resultado para que o utilizador possa vê-lo. | 

 | **RF06** | Prevenção de Duplicidade | Requisito de negócio chave para otimizar custos e evitar reprocessamento. | 

 | **RF07** | Exibição do Resultado | O utilizador precisa de ver o produto final do seu pedido. | 

 | **RF10** | Tratamento de Erros | Garante uma experiência minimamente funcional, informando o utilizador sobre falhas básicas (ex: formato inválido). | 

 

 ## 2. Should-Have (Deveria ter) 

 

 Estes requisitos são muito importantes, mas não são vitais para a primeira versão. Devem ser implementados logo após o MVP para enriquecer a experiência do utilizador. Correspondem, em grande parte, à **História de Utilizador 2 (HU2)**. 

 

 | ID | Requisito | Justificação | 

 | :--- | :--- | :--- | 

 | **RF09** | Listagem de Transcrições | Adiciona um grande valor, permitindo que os utilizadores revejam trabalhos anteriores, mas o sistema funciona sem isso inicialmente. | 

 | **RF08** | Feedback de Processamento | Melhora significativamente a usabilidade, mas um simples "a carregar..." é suficiente para o MVP. Um feedback mais detalhado pode vir depois. | 

 

 ## 3. Could-Have (Poderia ter) 

 

 Estes requisitos são desejáveis, mas menos importantes. Podem ser vistos como melhorias que seriam implementadas se houvesse tempo e recursos disponíveis, após a entrega dos "Must" e "Should". 

 

 | ID | Requisito (Sugestão) | Justificação | 

 | :--- | :--- | :--- | 

 | **CH01** | Editar Transcrição | Permitir que o utilizador corrija pequenos erros no texto gerado pela IA. | 

 | **CH02** | Exportar para .txt ou .docx | Adicionar a funcionalidade de exportar o texto para diferentes formatos de ficheiro. | 

 | **CH03** | Suporte a mais formatos de multimédia | Expandir a compatibilidade para além dos formatos mais comuns. | 

 | **CH04** | Notificação de Conclusão | Enviar uma notificação no navegador quando uma transcrição longa for concluída. | 

 

 ## 4. Won't-Have (Não terá - por agora) 

 

 Funcionalidades que foram consideradas, mas que estão explicitamente fora do escopo do projeto inicial para evitar o "scope creep" (aumento descontrolado do escopo). 

 

 | ID | Requisito (Excluído) | Justificação | 

 | :--- | :--- | :--- | 

 | **WH01** | Contas de Utilizador e Autenticação | Aumenta muito a complexidade. A versão inicial será de uso público e anónimo. | 

 | **WH02** | Transcrição em Tempo Real (Live) | Requer uma arquitetura completamente diferente (websockets, streaming) e está fora do objetivo inicial. | 

 | **WH03** | Funcionalidades Colaborativas | Partilhar e editar transcrições em equipa está fora do escopo. | 

 | **WH04** | Suporte a Múltiplos Idiomas | O foco inicial será apenas num idioma (ex: português ou inglês) para simplificar a integração com a API. | 

 

 ### Conclusão do Planeamento 

 

 O plano de desenvolvimento deve focar-se em entregar todos os requisitos **Must-Have** primeiro para construir um MVP robusto. Em seguida, o foco deve passar para os itens **Should-Have** para completar as funcionalidades mais pedidas.