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 da Funcionalidade

 

Versão 1.1

 

Analista de Sistema: 2º SGT PM MARCOS BACKES ROCHA

Porto Velho/RO, agosto de 2025.

Histórico das revisões

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:

 

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.

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