Documento de requisitos Documento de requisitos   SECRETARIA DE SEGURANÇA, DEFESA E CIDADANIA POLÍCIA MILITAR DO ESTADO DE RONDÔNIA DIRETORIA DE INFORMÁTICA DEPARTAMENTO DE DESENVOLVIMENTO         Especificação dos Requisitos do Software e Análise do Projeto do Sistema de Gestão Administrativa.   Versão 1.1   Analista de Sistema: 2º SGT PM MARCOS BACKES ROCHA Porto Velho/RO, agosto de 2025. Histórico das revisões Data Versão Descrição Autor/Responsável 02/08/2025 1.0 Documento inicial 2º SGT PM MARCOS BACKES ROCHA Nota da versão: Foram realizadas três reuniões participativas com o efetivo do Departamento de ... 03/08/2025 1.1 Conformidade com a legislação 2º SGT PM MARCOS BACKES ROCHA Nota da versão: Foram realizadas consultas jurídicas com o... Tabela 1.1. Histórico de revisões Introdução Propósito do Documento Obrigatórias Qual é o objetivo principal deste documento? Quais problemas ou necessidades ele busca atender? Qual a importância deste documento para o projeto? Recomendadas Este documento será usado para quais fases do ciclo de vida do sistema? Há restrições ou premissas que impactam o propósito do documento? Escopo do Sistema ou Produto Obrigatórias Qual o nome do sistema ou produto? Quais funções principais ele irá desempenhar? Quais metas e objetivos pretende alcançar? Recomendadas Quais benefícios ele trará para a organização ou para os usuários? Existe algo explicitamente fora do escopo? Há limitações orçamentárias ou de prazo que afetam o escopo? Público-Alvo e Uso do Documento Obrigatórias Quem são os principais stakeholders deste documento (desenvolvedores, testadores, gerentes, usuários finais)? Como cada grupo utilizará este documento? Recomendadas Há informações específicas para determinados públicos (ex.: segurança para equipe de TI)? Há grupos que precisam de versões simplificadas ou customizadas do documento? Referências Obrigatórias Quais normas, regulamentos, leis, políticas internas ou manuais serviram como base para este projeto? Recomendadas Existe documentação prévia ou projetos anteriores relacionados? Há requisitos derivados de contratos ou acordos? Há bibliografia técnica utilizada como referência? Definições, Acrônimos e Abreviações Obrigatórias Quais termos técnicos ou específicos precisam ser explicados para todos os leitores? Recomendadas Existem siglas ou abreviações usadas no documento? Algum termo é usado com significado diferente do habitual? Descrição Geral Contexto / Perspectiva do Produto Obrigatórias Este sistema substitui algum já existente ou é totalmente novo? Quais sistemas ou processos ele deve integrar ou se comunicar? Recomendadas Há limitações tecnológicas, regulatórias ou de integração? Existe um diagrama ou mapa de contexto para representar essas relações? Quais são os principais atores externos envolvidos? Funções Gerais do Produto Obrigatórias Quais são as principais funcionalidades que o sistema deve oferecer? Recomendadas Há funcionalidades obrigatórias e opcionais? Existe alguma ordem lógica ou prioridade entre essas funções? Há funções previstas para versões futuras? Características dos Usuários Obrigatórias Quem são os usuários finais do sistema? Qual o nível de conhecimento técnico deles? Recomendadas Qual o volume estimado de usuários simultâneos? Há necessidades de acessibilidade? Existem restrições de idioma ou localização geográfica? Requisitos Os requisitos são divididos neste planejamento em funcionais e não funcionais. Requisitos não funcionais são identificados pelo prefixo “RNF” e são os relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade. Já os requisitos funcionais são identificados pelo prefixo “RF” e definem uma função do sistema de software ou seu componente. Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas. A numeração inicia com o identificador RNF01 para os não funcionais e RF01 para os funcionais, sendo incrementados à medida que forem surgindo novos requisitos. O identificador do requisito é utilizado para referenciá-lo em qualquer local do documento ou anexos. Para estabelecer a prioridade dos requisitos, foram adotadas as denominações: essencial , importante e desejável . Abaixo temos a descrição de significado de cada uma dessas denominações:   Essencial É o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente. Importante É o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim. Desejável É o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada. Tabela 1.2. Prioridade dos Requisitos Requisitos Funcionais Obrigatórias Quais ações o sistema deve executar para atender às necessidades do negócio? Quais entradas e saídas são esperadas? Recomendadas Como o sistema deve responder a cada ação do usuário? Existem cálculos, regras ou fluxos obrigatórios? Existem integrações automáticas com outros sistemas? Requisitos Não-Funcionais Obrigatórias Quais requisitos de desempenho (tempo de resposta, capacidade) são esperados? Quais requisitos de segurança (autenticação, criptografia, auditoria) são obrigatórios? Recomendadas Existem requisitos de disponibilidade e continuidade (SLA)? Há exigências de compatibilidade com plataformas ou dispositivos? Quais requisitos de usabilidade devem ser atendidos? Há requisitos de escalabilidade ou manutenibilidade? Matriz de Rastreabilidade de Requisitos Funcionais e Não-Funcionais Obrigatórias Cada requisito pode ser rastreado até qual objetivo de negócio? Recomendadas Qual entrega ou componente do sistema satisfaz esse requisito? Existe um teste ou critério que confirme que ele foi atendido? A descrição detalhada dos requisitos está especificada no arquivo Matriz de Rastreabilidade de Requisitos. xlsx . Casos de Uso Os casos de uso descrevem, de forma estruturada, as interações entre atores (usuários ou sistemas externos) e o sistema, detalhando os passos necessários para atingir um objetivo específico. Cada caso de uso deve estar claramente identificado, descrito e rastreável aos requisitos funcionais e, quando aplicável, aos requisitos não funcionais correspondentes, garantindo assim a rastreabilidade e o alinhamento com as necessidades do projeto. A identificação dos casos de uso é feita por meio de um identificador único no formato “[CDU]”, cuja numeração inicia em [CDU01] e é incrementada sequencialmente à medida que novos casos de uso são definidos. Esse identificador é utilizado como referência em qualquer parte do documento, anexos ou outros artefatos do projeto, permitindo fácil associação e consulta cruzada. Com base nos Requisitos Funcionais (RF) e Requisitos Não Funcionais (RNF) previamente descritos, foi possível consolidar e registrar os seguintes casos de uso. Ref. CDU Nome do CDU Ref. RF/RNF Anexo / Apêndice CDU01 Designação do efetivo para os grupos considerados RN02, RF02, RF09, RF10, RF11, RF12 Anexo 01         Tabela 1.3. Casos de Uso Identificados. Obrigatórias Qual é o código identificador do caso de uso (ex.: CDU01)? Qual é o nome/título do caso de uso? Qual o objetivo principal deste caso de uso? Quem são os atores envolvidos (primários e secundários)? Quais são as pré-condições (situações que devem estar atendidas antes do início do caso)? Quais são as pós-condições (resultados esperados ao final da execução do caso)? Qual é o fluxo principal de eventos (passo a passo)? Quais são os requisitos funcionais relacionados a este caso de uso? Recomendadas Existem fluxos alternativos ou exceções relevantes? Há regras de negócio específicas aplicáveis a este caso? Este caso de uso gera ou consome dados sensíveis (LGPD)? Qual a frequência com que o caso de uso será executado? Existem restrições tecnológicas associadas? Qual é o nível de prioridade deste caso de uso no projeto? Há protótipos, diagramas ou telas associadas que devem ser anexadas? Este caso de uso depende de outro caso para ser iniciado? Diagrama de Sequência Diagrama de Fluxo (BPMN) Critérios de Validação e Aceitação Obrigatórias Como será verificado que cada requisito foi corretamente implementado? Quais critérios devem ser cumpridos para que um requisito seja aceito? Recomendadas Quem será responsável pela validação e aceitação? Há etapas intermediárias de aceite parcial? Gerenciamento de Mudanças e Baselines Obrigatórias Como serão registradas solicitações de mudança de requisitos? Quem poderá aprovar ou rejeitar alterações? Recomendadas Como será mantida a rastreabilidade após mudanças? Quantas versões ou baselines serão criadas durante o projeto? Qual o prazo máximo para avaliar solicitações de mudança? Anexo/Apêndice Glossário, Regras de Negócio, Diagramas e Outros Artefatos complementares Obrigatórias Há regras de negócio específicas que o sistema deve seguir? Recomendadas Quais diagramas (caso de uso, BPMN, arquitetura) devem ser anexados? Há exemplos, protótipos ou mockups que auxiliem a compreensão dos requisitos? Há documentos de treinamento ou manuais previstos para acompanhar o sistema? Apêndice 1: Matriz de Requisitos Matriz de Riscos