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 Funciona
Versão 2.0
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?