Engenharia de Requisitos e Análise de Sistemas para soluções do DETRAN

Conceitos essenciais de Engenharia de Requisitos no contexto do DETRAN

Engenharia de Requisitos é o conjunto de práticas para descobrir, analisar, documentar, validar e gerenciar necessidades de usuários e regras institucionais, transformando-as em especificações claras para desenvolvimento e manutenção de sistemas. Em soluções do DETRAN, requisitos costumam envolver serviços ao cidadão, conformidade legal, rastreabilidade, auditoria, integrações com bases governamentais e regras de negócio rígidas (prazos, impedimentos, validações).

Uma boa análise de sistemas, nesse contexto, busca reduzir ambiguidades e garantir que o software reflita o processo real: quem pode fazer o quê, em quais condições, com quais evidências, e como o sistema se comporta em exceções (indisponibilidade de integração, falta de documentos, impedimentos administrativos).

Técnicas de levantamento (elicitação) e quando usar

Entrevistas

Indicadas para aprofundar regras, exceções e decisões. Funcionam bem com perfis como atendentes, supervisores, gestores, auditoria, jurídico e TI de integração.

Passo a passo prático

• Defina objetivo e escopo da entrevista (ex.: “agendamento para atendimento presencial de CNH”).
• Liste hipóteses e dúvidas (ex.: “há prioridade para PCD?”, “há bloqueios por débitos?”).
• Prepare roteiro com perguntas abertas e fechadas.
• Conduza registrando exemplos reais (casos recentes) e exceções.
• Valide o entendimento ao final (resumo do que foi dito, pendências e documentos citados).
• Converta achados em requisitos e regras rastreáveis (com fonte e data).

Perguntas úteis

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Quais são os passos do atendimento do início ao fim?
• O que impede o cidadão de prosseguir?
• Quais prazos existem e como são contados?
• Quais dados precisam ser conferidos e em quais bases?
• Que evidências precisam ficar registradas para auditoria?

Workshops (reuniões colaborativas)

Indicados para alinhar múltiplas áreas e resolver conflitos rapidamente (atendimento, fiscalização, jurídico, TI, ouvidoria). Úteis para mapear jornada e priorizar backlog.

Passo a passo prático

• Convide representantes com poder de decisão e conhecimento operacional.
• Defina artefatos de saída (ex.: lista de casos de uso, regras de negócio, matriz de integrações).
• Use um quadro com colunas: “Etapa”, “Dados”, “Regras”, “Exceções”, “Integrações”, “Evidências”.
• Feche com decisões, responsáveis e itens pendentes (com prazo).

Análise documental

Essencial em serviços públicos: portarias, resoluções, manuais internos, termos de cooperação, contratos de integração, relatórios de auditoria, chamados recorrentes e logs. Ajuda a descobrir regras “invisíveis” que não aparecem em entrevistas.

Passo a passo prático

• Liste documentos relevantes e versão vigente.
• Extraia regras e obrigações (quem, o quê, quando, evidência).
• Marque pontos de ambiguidade (termos vagos como “preferencialmente”, “quando necessário”).
• Converta em requisitos testáveis e registre rastreabilidade (documento, seção, data).

Documentação: casos de uso, histórias de usuário e critérios de aceitação

Casos de uso (visão orientada a interação)

Casos de uso descrevem como um ator interage com o sistema para atingir um objetivo. São úteis quando há fluxos com exceções e integrações.

Estrutura recomendada

• Nome e objetivo
• Atores
• Pré-condições
• Gatilho
• Fluxo principal
• Fluxos alternativos
• Exceções (falhas e impedimentos)
• Pós-condições
• Regras de negócio associadas
• Integrações e dados trocados
• Requisitos não funcionais relevantes (auditoria, desempenho, segurança)

UC-AG-01: Agendar atendimento presencial (cidadão) Objetivo: reservar data/hora para atendimento em unidade do DETRAN Atores: Cidadão (primário), Sistema de Impedimentos (externo), Sistema de Pagamentos (externo) Pré-condições: cidadão autenticado; unidade selecionada Gatilho: cidadão escolhe serviço e solicita agenda Fluxo principal: 1) Sistema lista serviços disponíveis na unidade 2) Cidadão seleciona serviço e informa dados solicitados 3) Sistema valida impedimentos e pendências 4) Sistema apresenta datas/horários disponíveis 5) Cidadão seleciona data/hora 6) Sistema confirma e gera protocolo Fluxos alternativos: A1) Cidadão escolhe atendimento prioritário e informa condição; sistema solicita comprovação Exceções: E1) Integração de impedimentos indisponível: sistema bloqueia confirmação e orienta tentativa posterior, registrando ocorrência E2) Cidadão com impedimento: sistema impede agendamento e informa motivo genérico ao cidadão, detalhando no log interno Pós-condições: agendamento registrado; protocolo emitido; trilha de auditoria gravada

Histórias de usuário (visão orientada a valor)

Histórias de usuário são úteis para backlog e entregas incrementais. A história descreve valor e contexto, e os critérios de aceitação tornam o requisito verificável.

Modelo

• Como [perfil], quero [necessidade], para [benefício].
• Critérios de aceitação (testáveis).
• Regras de negócio e exceções associadas.

US-AG-03: Como cidadão, quero reagendar meu atendimento, para escolher um novo horário quando eu não puder comparecer. Critérios de aceitação: 1) Dado que existe um agendamento futuro, quando eu solicitar reagendamento, então o sistema deve apresentar horários disponíveis para o mesmo serviço e unidade. 2) Quando eu confirmar o novo horário, então o sistema deve cancelar o agendamento anterior e registrar o novo com o mesmo identificador de cidadão e um novo protocolo. 3) Se o reagendamento ocorrer a menos de 24 horas do horário original, então o sistema deve bloquear a ação e orientar o cancelamento (regra configurável). 4) O sistema deve registrar trilha de auditoria contendo: usuário, data/hora, IP/dispositivo (quando disponível), agendamento anterior e novo.

Critérios de aceitação: como escrever bem

Critérios de aceitação devem ser específicos, mensuráveis e verificáveis. Evite termos como “rápido”, “intuitivo”, “adequado”. Prefira condições e resultados observáveis.

• Use formato Dado/Quando/Então para reduzir ambiguidades.
• Inclua validações, mensagens, registros de auditoria e comportamento em falhas de integração.
• Inclua exemplos de dados (máscaras, formatos, limites).

Como estruturar uma especificação de requisitos (modelo prático)

Uma especificação bem estruturada facilita desenvolvimento, testes, auditoria e manutenção. A seguir, um modelo aplicável a módulos típicos do DETRAN.

1) Escopo

• Objetivo do módulo (o que resolve).
• O que está dentro e fora (ex.: “não inclui pagamento online nesta fase”).
• Perfis/atores envolvidos.
• Unidades atendidas (todas as CIRETRANs? apenas piloto?).

2) Regras de negócio

Regras de negócio são condições obrigatórias do domínio. Devem ser numeradas (RB-001, RB-002) e rastreáveis a fontes (norma, procedimento, decisão do gestor).

• Regra
• Justificativa/fonte
• Exceções permitidas (se houver) e quem autoriza
• Impacto no sistema (validação, bloqueio, registro)

3) Exceções e tratamentos

Liste cenários de falha e como o sistema deve reagir: indisponibilidade de serviço externo, dados divergentes, tentativa de fraude, duplicidade, concorrência (duas pessoas tentando a mesma vaga).

4) Integrações

Para cada integração, descreva contrato e comportamento esperado.

• Sistema externo e finalidade
• Dados enviados/recebidos (campos, formatos)
• Regras de timeout e retentativa
• Fallback (o que fazer se falhar)
• Logs e correlação (ID de transação)

5) Relatórios e consultas

Relatórios são requisitos frequentes em órgãos públicos. Especifique:

• Nome do relatório e público-alvo
• Filtros (período, unidade, serviço, status)
• Campos exibidos
• Ordenação e paginação
• Exportação (PDF/CSV) quando aplicável
• Regras de acesso (perfil, sigilo)

6) Requisitos não funcionais (RNF) essenciais

• Segurança e privacidade: autenticação, autorização por perfil, mascaramento de dados sensíveis.
• Auditoria: trilha completa de ações e alterações (quem, quando, o quê, antes/depois).
• Desempenho: tempos máximos para listar agenda e confirmar reserva.
• Disponibilidade: janelas de manutenção e comportamento em degradação.
• Usabilidade: mensagens claras, acessibilidade quando aplicável.

Priorização: como decidir o que vem primeiro

Priorização é necessária porque nem tudo cabe no mesmo ciclo. Em serviços do DETRAN, priorize considerando risco institucional, impacto no cidadão, obrigações legais e dependências de integração.

Métodos práticos

• MoSCoW: Must (obrigatório), Should (importante), Could (desejável), Won’t (fora do ciclo).
• Valor x Esforço: matriz para identificar “ganhos rápidos” e itens de alto impacto.
• Risco/Conformidade: itens ligados a auditoria, LGPD, prazos legais e impedimentos tendem a subir.

Exemplo: “Bloquear agendamento para cidadão com impedimento” tende a ser Must; “Escolha de tema visual” tende a ser Could.

Gerenciamento de mudanças: controle sem travar o projeto

Mudanças são comuns por atualização normativa, ajustes operacionais e descobertas durante testes. O objetivo é controlar impacto e manter rastreabilidade.

Passo a passo prático

• Registre a solicitação de mudança (o que mudou, por quê, fonte, urgência).
• Classifique (correção, melhoria, adequação legal, risco).
• Analise impacto: regras afetadas, telas, integrações, relatórios, testes, dados.
• Atualize artefatos: requisitos, casos de uso/histórias, critérios de aceitação, glossário.
• Repriorize com stakeholders e aprove formalmente (quando necessário).
• Garanta rastreabilidade: requisito ↔ mudança ↔ teste ↔ entrega.

Exemplos de regras de negócio comuns em serviços públicos (aplicáveis ao DETRAN)

Prazos e contagem

• RB-101: Cancelamento sem penalidade permitido até X horas antes do horário agendado (X configurável por unidade/serviço).
• RB-102: Reagendamento permitido no máximo Y vezes por protocolo dentro de Z dias.
• RB-103: Vagas liberadas por lote em horários definidos (ex.: diariamente às 08:00), com registro de auditoria da abertura.

Validações cadastrais e documentais

• RB-201: Para agendar serviço que exige identificação, CPF deve estar válido e associado ao cidadão autenticado.
• RB-202: Para serviços específicos, exigir documento complementar (ex.: comprovante) e validar formato/tamanho do arquivo (quando houver upload).

Impedimentos e bloqueios

• RB-301: Se houver impedimento ativo (administrativo/judicial), bloquear agendamento e registrar motivo detalhado apenas em log interno.
• RB-302: Se houver débito vinculado ao serviço, exigir quitação confirmada antes de permitir confirmação do agendamento.

Auditoria e rastreabilidade

• RB-401: Toda criação, alteração e cancelamento de agendamento deve registrar: usuário, data/hora, canal (web/app/atendente), unidade, serviço, IP (quando aplicável), valores anteriores e novos.
• RB-402: Alterações feitas por atendente devem exigir justificativa selecionada de lista controlada.

Modelagem de domínio e glossário: reduzindo ambiguidades

Modelagem de domínio (visão prática)

Modelagem de domínio descreve entidades e relações do negócio, ajudando a evitar interpretações diferentes para os mesmos termos. Em um módulo de agendamento/atendimento, entidades comuns incluem: Cidadão, Serviço, Unidade, Agenda, Slot (vaga), Agendamento, Protocolo, Atendimento, Documento, Impedimento, Pagamento, Prioridade.

Exemplo de relações

• Uma Unidade oferece muitos Serviços.
• Um Serviço possui regras de elegibilidade e pode exigir Documentos.
• Uma Agenda contém muitos Slots por data/hora.
• Um Agendamento reserva um Slot e gera um Protocolo.
• Um Atendimento é a execução do serviço e referencia um Agendamento (quando aplicável).

Glossário (exemplo inicial)

• Agendamento: reserva de data/hora para atendimento, vinculada a um serviço, unidade e cidadão.
• Atendimento: registro da execução do serviço (comparecimento), com status e evidências.
• Slot (vaga): unidade mínima de disponibilidade (data/hora) para um serviço/unidade.
• Protocolo: identificador único emitido ao confirmar um agendamento.
• Impedimento: condição que bloqueia ou restringe o serviço (administrativo/judicial/técnico), consultada internamente.
• Canal: origem da solicitação (portal, app, presencial, call center).

Atividade prática 1: escrever requisitos completos para um módulo de agendamento/atendimento

Enunciado

Você deve especificar um módulo que permita ao cidadão agendar atendimento presencial para um serviço (ex.: “Emissão de CNH”, “Transferência de veículo”), com validações de impedimentos, regras de cancelamento e registro de auditoria. O módulo deve atender também ao perfil de atendente e gestor (relatórios).

Checklist do que sua especificação deve conter

• Escopo (inclui/exclui) e perfis.
• Lista de requisitos funcionais numerados (RF-001...).
• Regras de negócio numeradas (RB-001...).
• Exceções e tratamentos (falhas de integração, concorrência de vaga).
• Integrações (impedimentos, pagamentos, cadastro).
• Relatórios (pelo menos 2) e regras de acesso.
• RNFs: auditoria, segurança, desempenho.
• Glossário mínimo (10 termos).

Modelo de requisitos (preencha e adapte)

Escopo: [descreva objetivo, limites, unidades e canais] Perfis: Cidadão, Atendente, Gestor RF-001: O sistema deve permitir que o cidadão selecione unidade e serviço para agendamento. RF-002: O sistema deve listar datas/horários disponíveis por unidade/serviço. RF-003: O sistema deve validar impedimentos antes de confirmar o agendamento. RF-004: O sistema deve permitir cancelamento de agendamento conforme RB-101. RF-005: O sistema deve permitir reagendamento conforme RB-102. RF-006: O sistema deve emitir protocolo e comprovante do agendamento. RF-007: O atendente deve consultar agendamentos por CPF, protocolo e período. RF-008: O gestor deve visualizar relatório de taxa de comparecimento por unidade/serviço. RB-101: Cancelamento permitido até X horas antes. RB-102: Reagendamento limitado a Y vezes em Z dias. RB-103: Bloquear confirmação se integração de impedimentos estiver indisponível. Integrações: INT-01 Impedimentos (consulta por CPF), INT-02 Pagamentos (status de quitação) Relatórios: RPT-01 Agenda diária por unidade; RPT-02 No-show (faltas) por período RNF-01 Auditoria completa de ações; RNF-02 Autorização por perfil; RNF-03 Listagem de horários em até 2s em 95% das requisições

Atividade prática 2: revisão de inconsistências, ambiguidades e lacunas

Objetivo

Revisar uma especificação para encontrar problemas que geram retrabalho, falhas em produção e divergências entre áreas.

Roteiro de revisão (use como checklist)

• Ambiguidade: termos vagos (“rápido”, “adequado”, “preferencial”). Substitua por métricas e condições.
• Inconsistência: RB diz “permitido até 24h”, mas critério de aceitação diz “até 12h”.
• Lacuna: não define o que acontece se duas pessoas tentarem a mesma vaga simultaneamente.
• Exceções: falta comportamento para integração fora do ar, timeout, dados divergentes.
• Segurança: não define perfis e permissões (quem pode cancelar de terceiros? atendente pode reagendar sem justificativa?).
• Auditoria: não define quais eventos devem ser logados e com quais campos.
• Dados: formatos, obrigatoriedade, validação (CPF, telefone, e-mail), máscaras e limites.
• Relatórios: filtros, campos, periodicidade, exportação e controle de acesso.

Exercício de detecção (texto com problemas para você corrigir)

RF-X: O sistema deve permitir que o cidadão cancele o agendamento em tempo hábil. RF-Y: O sistema deve validar impedimentos, quando possível. Critério: O cancelamento deve ser fácil e rápido. Regra: Reagendamento permitido até a data do atendimento.

Tarefas

• Reescreva RF-X e RF-Y com condições objetivas e testáveis.
• Crie RBs numeradas para cancelamento e reagendamento com prazos configuráveis.
• Defina comportamento quando a validação de impedimentos não estiver disponível.
• Escreva critérios de aceitação em Dado/Quando/Então para pelo menos 2 cenários (cancelamento e falha de integração).