Skip to content

Celular Seguro: Análise de Documentos

Metodologia

A Técnica de Análise de Documentos para elicitação de requisitos do aplicativo Celular Seguro foi realizada a partir da seleção criteriosa de fontes oficiais e especializadas, abrangendo manuais do Gov.br, portarias do MJSP, legislações correlatas e reportagens confiáveis publicadas entre dezembro de 2023 e abril de 2025. Cada documento foi avaliado quanto à relevância para as funcionalidades do sistema e à confiabilidade do emissor, priorizando informações sobre bloqueio remoto de aparelhos, consulta de IMEI, cadastro de pessoas de confiança e emissão de alertas.

Durante o levantamento, procedeu‑se à leitura detalhada e à extração de trechos que descreviam requisitos funcionais — como “Bloquear aparelho remotamente” e “Consultar IMEI antes da venda” — e não‑funcionais — por exemplo, “Tempo de resposta máximo de 5 segundos”. Notas foram adicionadas sempre que surgiram ambiguidades, realizando‑se comparações cruzadas entre diferentes fontes para esclarecer termos vagos. Em seguida, os requisitos foram agrupados em categorias temáticas (registro de telefone, consulta de restrições, pessoas de confiança e emissão de alertas) e vinculados a uma tabela de rastreabilidade, garantindo a rastreabilidade entre cada requisito e sua origem documental.

Por fim, a equipe conduziu uma validação interna dos itens extraídos, revisando cada requisito com base nas fontes consultadas e assegurando que as descrições estivessem alinhadas ao escopo do Celular Seguro. Essa abordagem sistemática permitiu aproveitar o conhecimento prévio disponível, reduzir ambiguidades e estruturar os requisitos de forma confiável e coerente com as diretrizes da disciplina de Requisitos de Software da Universidade de Brasília.

Participantes da Sessão


Tabela 1: Participantes da sessão de análise de documentos – Celular Seguro
Colaboradores que apresentaram, analisaram e registraram os documentos para elicitação de requisitos.

Nome/ID Atuação
Arthur Carvalho Análise e apresentação dos documentos
Leonardo de Melo Criação das tabelas de requisitos

Gravação


Figura 1: Vídeo da apresentação e análise de documentos – “Análise de Documentos – Celular Seguro”
Gravação da sessão de apresentação e análise dos documentos conduzida por Leonardo de Melo e Arthur Carvalho via Microsoft Teams.

Autor do vídeo: Leonardo de Melo e Arthur Carvalho

Resumo dos documentos analisados

Documentação Oficial (Gov.br e MJSP)

  • Descrição do programa Celular Seguro, instituído pela Portaria MJSP 562/2023 e atualizado pela Portaria MJSP 837/2024.
  • Objetivo: combater roubo e furto de celulares via plataforma que permite ao cidadão bloquear aparelho, linha e contas bancárias.
  • Consulta prévia de IMEIs (Anatel e base própria) para evitar compra de dispositivos restritos.
  • FAQ detalha o fluxo de uso, as quatro funções principais (Registrar telefone, Pessoas de confiança, Celulares com restrição, Emitir alerta), as opções “Modo Recuperação” e “Bloqueio Total”, e alerta para registro de boletim de ocorrência após emitir alerta.

Fontes:

Descrição do Aplicativo (Google Play e App Store)

  • Modo Recuperação: bloqueia linha e serviços parceiros, mantendo o IMEI ativo para possível recuperação.
  • Bloqueio Total: inclui inutilização do IMEI, evitando uso imediato, mas dificultando localização posterior.
  • Versão 2.1 (abril/2025) adicionou emissão de múltiplos alertas para o mesmo número; consulta “Celulares com Restrição”; centralização de informações e nova identidade visual.

Fontes:

Fontes Jornalísticas (Agência Brasil, EBC, Poder360)

  • Programa superou 2 milhões de usuários e 50 mil alertas até maio/2024.
  • Descrevem o processo de bloqueio (login Gov.br, botão de emergência, geração de protocolo, notificação às operadoras e bancos).
  • A partir de abril/2025, notificações via WhatsApp para chips novos em aparelhos com alerta, orientando uso legal ou devolução do dispositivo.
  • Ampliação de parcerias com fintechs e bancos digitais (Neon, PicPay, Nubank etc.) para fortalecer bloqueios financeiros.

Fontes:

Apresentação estruturada dos requisitos elicitados

Com base na análise dos documentos acima, foram identificados diversos requisitos para o aplicativo Celular Seguro. Abaixo, os requisitos estão estruturados por categoria (Funcionais, Não-Funcionais, de Interface, de Produto, Riscos e Testes/Validações), conforme as legendas definidas. Cada requisito é apresentado com uma breve descrição e, quando pertinente, referências aos documentos que embasam sua elicitação.

Requisitos Funcionais (RF)

O sistema deve permitir que o usuário escolha livremente a opção que melhor atende à sua situação (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), mas deve alertá-lo claramente sobre as implicações de cada modo (ex.: modo recuperação facilita localizar o aparelho; bloqueio total previne qualquer uso do dispositivo) (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública).

Requisitos Não-Funcionais (RNF)

  • Disponibilidade e Confiabilidade: O sistema Celular Seguro deve ser altamente disponível, dado seu propósito de atender situações de emergência. Ele deve funcionar 24 horas por dia, 7 dias por semana, garantindo que os usuários possam emitir alertas ou consultar informações a qualquer momento, de qualquer lugar do país. Considerando que é um serviço nacional já adotado por milhões de pessoas (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro), a infraestrutura deve ser escalável e redundante para suportar picos de acessos (por exemplo, muitos bloqueios podem ser acionados em eventos como o Carnaval, quando há aumento de furtos (Celular Seguro — Ministério da Justiça e Segurança Pública)). A confiabilidade estende-se também à entrega dos alertas aos parceiros: o sistema deve assegurar a entrega consistente das notificações de bloqueio às operadoras e bancos, mesmo que partes do sistema falhem (mecanismos de fila ou re-tentativa devem estar presentes).

  • Desempenho e Tempo de resposta: O tempo entre o usuário emitir um alerta e a execução dos bloqueios associados deve ser o mais curto possível. Idealmente, o Celular Seguro deve repassar a informação do alerta aos parceiros em tempo real ou poucos segundos após a confirmação do usuário. Os parceiros, por sua vez, comprometeram-se com prazos de atendimento rápidos – muitas instituições financeiras concluem o bloqueio em até 10 minutos após a comunicação (Lista de Parceiros — Ministério da Justiça e Segurança Pública), e operadoras realizam bloqueios de IMEI em até 1 dia útil (geralmente bem antes) (Lista de Parceiros — Ministério da Justiça e Segurança Pública). Assim, do ponto de vista do usuário, espera-se que em alguns minutos após o alerta ele já tenha sua linha e apps bancários inacessíveis ao criminoso. O aplicativo também deve ser leve e responsivo: telas de consulta (como verificação de IMEI) devem retornar resultados rapidamente, e a interface deve reagir aos comandos do usuário sem atrasos perceptíveis, mesmo em dispositivos modestos ou conexões móveis.

  • Segurança da Informação: Como o aplicativo lida com dados sensíveis (CPF do usuário, IMEI do aparelho, status de roubo/furto, e acesso a contas bancárias), a segurança deve ser um aspecto fundamental. Alguns sub-requisitos de segurança incluem:

  • Autenticação Segura: O uso do login Gov.br garante um nível de segurança federada; o Celular Seguro não gerencia senhas próprias, mas deve confiar no token seguro fornecido pelo Gov.br após autenticação bem-sucedida (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). A sessão do usuário deve expirar após um período de inatividade, exigindo novo login, para prevenir acesso indevido em caso de aparelho desbloqueado.
  • Proteção de Dados Pessoais: O sistema deve estar em conformidade com a LGPD (Lei Geral de Proteção de Dados). De acordo com a declaração na loja Google Play, o app não compartilha dados pessoais com terceiros e não coleta dados além do necessário (Celular Seguro BR - Apps on Google Play). Isso indica que o Celular Seguro opera principalmente como um gateway de comunicação (recebendo do usuário o evento de alerta e repassando aos parceiros), sem armazenar grandes quantidades de dados pessoais localmente. Ainda assim, toda transmissão de dados (como CPF, IMEI, protocolo) deve ser feita de forma criptografada (HTTPS/SSL), assegurando confidencialidade e integridade.
  • Controle de Acesso e Autorização: Somente usuários autenticados podem executar ações (cadastrar telefones, emitir alertas). Uma pessoa de confiança só pode emitir alerta para um determinado aparelho se tiver sido previamente autorizada pelo dono daquele aparelho no sistema (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Além disso, cada instituição parceira só recebe as informações necessárias para sua parte do bloqueio – ex.: bancos recebem CPF/identificador do cliente e talvez um código do protocolo, mas não necessariamente detalhes do aparelho; operadoras recebem IMEI e número de telefone, mas não dados financeiros.

  • Logs e Auditoria: Todas as operações críticas (cadastro de dispositivo, emissão de alerta, consulta de IMEI) devem ser registradas em log seguro, para fins de auditoria pelo MJSP. Isso ajuda a detectar usos indevidos ou fraudes e fornece evidências caso necessário investigar algum problema (por exemplo, se alguém alega que um alerta foi emitido indevidamente, o log pode mostrar se foi pela própria conta ou por pessoa de confiança, data e hora, etc.).

  • Usabilidade e Experiência do Usuário: O Celular Seguro deve ser simples e intuitivo de usar, dado que será utilizado por um público amplo e muitas vezes em momentos de estresse (pós-roubo). A nova identidade visual implementada na versão 2.0 buscou melhorar a experiência (Celular Seguro BR – Apps no Google Play), devendo usar ícones e textos claros. Por exemplo, o app coloca na tela inicial as quatro ações principais em destaque (registrar telefone, pessoas de confiança, celulares com restrição, emitir alerta) (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), facilitando a navegação. Mensagens de feedback devem ser fornecidas para o usuário entender o que ocorreu: após emitir um alerta, além de mostrar o protocolo, o app poderia exibir "Alerta registrado com sucesso e enviado às operadoras e bancos" para que o usuário tenha confiança de que a ação foi efetuada. Erros também devem ser tratados de forma amigável – e.g., se o usuário tentar cadastrar um telefone inválido, mostrar qual o problema. O design deve seguir as diretrizes de acessibilidade: fonte legível, suporte a leitores de tela, contraste adequado, etc., alinhado com os princípios do Design System do Gov.br.

  • Compatibilidade e Portabilidade: O aplicativo móvel deve ser compatível com as principais versões de Android e iOS utilizadas no Brasil, de modo a atingir o maior número de cidadãos. Além disso, a versão web deve funcionar nos navegadores mais comuns (Chrome, Firefox, Safari, Edge) e em diversos tamanhos de tela, incluindo dispositivos móveis, para garantir acesso universal. O usuário deve conseguir iniciar um processo em uma plataforma e concluir em outra sem problemas (por exemplo, se começou cadastrando o telefone pelo site mas na hora do roubo só tem um outro celular com o app disponível, deve conseguir logar e já encontrar seus dados sincronizados). Isso implica manter os dados do usuário centralizados no servidor e não em um único dispositivo.

  • Gratuidade do Serviço: É um requisito de produto que o Celular Seguro seja oferecido gratuitamente ao cidadão (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎), sem cobrança de quaisquer taxas pelo uso do aplicativo ou site. Embora implícito por ser um serviço público, vale ressaltar que isso impacta a não funcionalidade de suporte e escala – o sistema deve suportar muitos usuários sem modelo de cobrança e, portanto, deve ser mantido com recursos públicos, o que exige eficiência de custos em sua operação.

  • Conformidade Legal e Regulatória: Além da LGPD já mencionada, o sistema deve observar normas setoriais. Por exemplo, deve respeitar as regras da Anatel para bloqueio de IMEIs roubados (integração ao CEMI) e garantir que os bloqueios realizados via app tenham o mesmo efeito de um bloqueio solicitado via operadora. Também deve estar alinhado às regulações bancárias no tocante ao bloqueio de contas. As portarias MJSP nº 562/2023 e 837/2024 estabelecem oficialmente o programa Celular Seguro e suas diretrizes (Conheça o Celular Seguro — Ministério da Justiça e Segurança Pública) (Conheça o Celular Seguro — Ministério da Justiça e Segurança Pública), portanto o sistema deve cumprir o que essas portarias determinam (como oferecer as opções de bloqueio independente, e receber notificações de novas linhas em IMEIs restritos). Em termos de acessibilidade digital, deve atender ao eMAG (Modelo de Acessibilidade de Governo Eletrônico) em sua interface web, garantindo inclusão de pessoas com deficiência.

  • Escalabilidade e Manutenibilidade: Dado o crescimento rápido do número de usuários (milhões em poucos meses (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro)), a arquitetura do sistema deve ser escalável horizontalmente, suportando aumento de carga sem degradação. Além disso, como novas instituições parceiras estão sendo adicionadas continuamente (ex.: bancos digitais integrados em 2024/2025 (Celular Seguro — Ministério da Justiça e Segurança Pública)), o sistema deve ter uma arquitetura modular que facilite a inclusão de novos parceiros e atualização de procedimentos sem necessidade de reescrever grandes partes. Deve ser fácil para a equipe de manutenção do MJSP atualizar a lista de parceiros ou alterar textos informativos (como FAQ) conforme o programa evolui.

Requisitos de Interface (RI)

  • Layout da Tela Inicial: Ao efetuar login, o usuário deve ser apresentado à tela principal do aplicativo contendo as quatro funcionalidades de destaque: Registrar Telefone, Pessoas de Confiança, Celulares com Restrição e Emitir Alerta, conforme descrito na documentação (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Cada funcionalidade deve ser representada por um ícone e rótulo descritivo. Essa tela inicial serve como hub de navegação e deve ser de fácil compreensão, indicando claramente ao usuário onde realizar cada ação desejada.

  • Fluxo de Onboarding: Nas primeiras utilizações, o app deve guiar o usuário pelo fluxo de configuração inicial. Isso inclui:

  • Tela de Login Gov.br: botão evidente “Entrar com Gov.br” que redireciona para a página de autenticação Gov.br (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎).
  • Tela de Termos de Uso: exibição do texto dos termos e política de privacidade, com opção de aceitar. Apenas após tocar em “Concordo” o usuário avança (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎).
  • Tela de Cadastro de Pessoas de Confiança (opcional): ao entrar pela primeira vez, o app pode perguntar se o usuário deseja cadastrar uma pessoa de confiança, explicando a funcionalidade. Se o usuário optar por cadastrar, abrir o formulário correspondente; caso contrário, essa etapa pode ser pulada, mas com a opção sempre disponível posteriormente.

  • Tela de Cadastro de Telefone: orientar o usuário a registrar pelo menos um dispositivo. Deve haver um botão ou indicação “Cadastrar Telefone” na área “Meus telefones” quando esta estiver vazia (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). O formulário de cadastro de telefone deve solicitar informações mínimas, como o número de telefone (com DDD). Poderá também solicitar o IMEI do aparelho, embora não seja estritamente necessário para o bloqueio (as operadoras conseguem obtê-lo). Importante: caso o usuário tente cadastrar um número que não esteja em seu CPF, o app deve exibir um aviso lembrando que apenas linhas sob sua titularidade funcionarão para bloqueio (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública).

  • Emissão de Alerta – UI: A interface para emitir um alerta de emergência deve ser simples e rápida de usar, pois pode ser utilizada em momentos críticos. Recomenda-se que haja um botão destacado, possivelmente vermelho ou laranja, rotulado como “Alerta” ou “Emergência” na tela principal para acesso imediato (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Ao tocar nesse botão, o app deve:

  • Exibir a lista de aparelhos cadastrados (se o usuário tiver mais de um) e pedir que selecione o dispositivo afetado (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Se o usuário tiver apenas um telefone cadastrado, esse passo pode ser automático.
  • Em seguida, exibir as duas opções de bloqueio (Modo Recuperação vs Bloqueio Total) com uma breve descrição de cada uma (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), para que o usuário escolha. Essa tela deve ressaltar, por exemplo: “Modo Recuperação – bloqueia só a linha e bancos, permite rastrear o aparelho depois” e “Bloqueio Total – bloqueia aparelho, linha e bancos imediatamente” para reforçar o entendimento.
  • Após a seleção, pedir uma confirmação final do usuário, algo como: “Confirmar emissão de alerta para o aparelho XYZ no modo [Selecionado]?”. Essa confirmação é importante para evitar acionamentos acidentais.

  • Ao confirmar, o app deve processar o envio e então mostrar uma tela de resultado informando “Alerta emitido com sucesso” e exibindo em destaque o número de protocolo gerado (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Instruções como “Anote este protocolo para futuras consultas” devem estar presentes nessa tela, possivelmente com opção de copiar o código ou compartilhá-lo (por exemplo, enviar por e-mail).

  • Design da função de Consulta (Celulares com Restrição): A interface de consulta de IMEI deve ser acessível por um menu ou botão “Celulares com Restrição” na tela principal (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Ao entrar nessa função, o usuário deve ver um campo de input para digitar o IMEI (com validação para exatamente 15 dígitos) e um botão “Consultar”. Após submeter, o resultado deve indicar claramente se o IMEI está livre ou possui restrição. Por exemplo:

  • Se não há registro: mostrar um sinal verde ou mensagem “Este IMEI não possui restrições conhecidas nas bases consultadas.”
  • Se há restrição: destacar em vermelho “ATENÇÃO: Este celular está bloqueado/impedido por roubo ou furto! (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública)”. Poderia inclusive detalhar a data do bloqueio se disponível.
  • Caso o IMEI consultado pertença a um aparelho que teve alerta em modo recuperação (e portanto não aparece na base Anatel ainda), o sistema deve retornar algo como “Não constam restrições na base Anatel, mas aparelhos com alerta de Modo Recuperação podem não ser listados. Use com cautela.” – conforme nota da própria documentação (Celular Seguro BR – Apps no Google Play).

  • A interface deve explicar como obter o IMEI (dica: “Digite *#06# no telefone para descobrir o IMEI” (Celular Seguro passa a emitir alerta de bloqueio por roubo )) e lembrar que aparelhos dual-SIM têm dois IMEIs, devendo verificar ambos (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública).

  • Listagem de Operadoras e Parceiros: Ao cadastrar um telefone ou emitir um alerta, o app deve apresentar ao usuário a seleção da operadora de telefonia correspondente àquele número. Somente operadoras oficialmente integradas ao programa devem aparecer na lista (Claro, Vivo, TIM, Oi/Algar, Sercomtel, etc., e uma opção “Outras”). A FAQ do serviço menciona que apenas operadoras listadas no app realizam o bloqueio de linha/IMEI automaticamente (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Assim, na UI de cadastro de telefone, pode haver um menu suspenso “Operadora” – se o usuário escolher uma não suportada (ou “Outras”), o app deve alertar: “Operadora não integrada – em caso de roubo, você deverá contactá-la manualmente para bloquear a linha” (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Similarmente, poderia haver uma lista de instituições financeiras parceiras visível, talvez nos Termos de Uso ou em uma seção informativa, para que o usuário saiba quais bancos serão alcançados pelo bloqueio (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública).

  • Feedback e Orientações Pós-bloqueio: A interface deve fornecer orientação ao usuário após a emissão do alerta. Como explicitado nos documentos, o app não substitui o boletim de ocorrência policial (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Portanto, após um alerta, além do protocolo, o app poderia exibir mensagem: “Importante: registre um Boletim de Ocorrência na Polícia Civil o mais rápido possível, informando o número de protocolo do Celular Seguro (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública).” Poderia incluir um botão ou link para “Delegacia Virtual” do estado do usuário (talvez detectando pelo DDD do telefone cadastrado) para facilitar esse registro. Esse tipo de orientação de pós-evento melhora a eficácia do processo como um todo e está alinhado às recomendações do MJSP.

  • Elementos de acessibilidade e UX: O aplicativo deve seguir as recomendações de design acessível: permitir aumento de fonte (ou respeitar as preferências de fonte do sistema operacional), cores com bom contraste, labels em todos os botões (evitar depender apenas de ícones), suporte a navegação por leitores de tela para pessoas com deficiência visual. Por exemplo, o botão de emergência deve ter uma label textual “Emitir Alerta de Emergência” que seja lida pelo leitor de tela, e não apenas uma cor chamativa. Além disso, o idioma principal é o português, mas poderia haver suporte à língua inglesa ou espanhola para usuários estrangeiros residentes, embora como regra somente números nacionais possam ser cadastrados (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). A interface web deve ter equivalentes dessas considerações, garantindo que mesmo via navegador seja fácil realizar todas as operações.

Requisitos de Produto (RPR)

  • Integração com plataforma Gov.br: O Celular Seguro deve integrar-se à infraestrutura de Login Único Gov.br para autenticação dos usuários (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Isso envolve utilizar os protocolos OIDC/OAuth do Gov.br, redirecionando o usuário para login no site governamental e recebendo os tokens de autorização. Essa integração garante segurança e aproveita a base existente de cidadãos já cadastrados (CPF verificado, níveis de confiabilidade bronze/prata/ouro, etc.). O produto deve atender às condições de uso da API do Gov.br e às políticas de governo digital vigentes.

  • Integração com sistemas de telecomunicações (Anatel/ABR Telecom): Um requisito essencial de produto é a conexão com o Cadastro de Estações Móveis Impedidas (CEMI), mantido pela ABR Telecom em nome da Anatel. O Celular Seguro deve enviar os comandos de bloqueio de IMEI e linha através desse sistema de forma automatizada (Lista de Parceiros — Ministério da Justiça e Segurança Pública). Para isso, deve seguir o manual operacional do CEMI e suas interfaces. A ABR Telecom faz a validação sistêmica dos pedidos e os repassa às operadoras participantes (Claro, TIM, Vivo, etc.) (Lista de Parceiros — Ministério da Justiça e Segurança Pública), portanto o produto Celular Seguro deve estar homologado junto a Anatel/ABR Telecom para emitir bloqueios em nome dos usuários. Além disso, conforme Portaria 837/2024, as operadoras devem notificar o MJSP quando um novo chip for ativado em aparelho com restrição (Conheça o Celular Seguro — Ministério da Justiça e Segurança Pública). Logo, o sistema Celular Seguro precisa receber essas notificações e processá-las – integrando possivelmente com um serviço de mensagens (WhatsApp) para contatar o usuário do novo chip, conforme descrito no requisito funcional de notificação. Em suma, a arquitetura do produto envolve um módulo central (MJSP) comunicando-se de um lado com a rede das teles (via ABR Telecom/CEMI) e de outro com os servidores das instituições financeiras.

  • Integração com instituições financeiras (Febraban e bancos): Do lado financeiro, o produto deve aderir ao acordo com a Febraban e implementar conectores com os bancos parceiros. Cada instituição possui seu procedimento de bloqueio (como vimos, alguns requerem reconhecimento facial do cliente para desbloqueio depois (Lista de Parceiros — Ministério da Justiça e Segurança Pública), outros bloqueiam cartões, etc.), mas para o Celular Seguro importa que haja uma forma padrão de notificar todas sobre um CPF que deve ser bloqueado. Provavelmente isso ocorre via um hub central na própria Febraban ou webservices de cada banco. Requisito é que o produto Celular Seguro envie a todos os parceiros financeiros os dados necessários no instante do alerta, e eventualmente registre quais responderam. Deve também ser possível adicionar novos parceiros facilmente: por exemplo, se um novo banco digital aderir, incluir suas credenciais de API e começar a enviar alertas para ele. A Lista de Parceiros mantida pelo MJSP e divulgada publicamente deve estar sempre atualizada no sistema (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), o que implica um processo de gestão de configurações parceiro no produto.

  • Escopo de usuários (nacional, cidadãos brasileiros): O produto é destinado a todos os cidadãos brasileiros com telefone celular (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Portanto, ele deve rejeitar cadastros de números internacionais e operar apenas com números de telefone do plano nacional de numeração (+55) (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Essa restrição deve ser clara e implementada tanto na UI quanto nas APIs (por exemplo, não permitir código de país diferente de +55 ao cadastrar telefone). Adicionalmente, o público-alvo abrange usuários de todos os estados; o produto deve considerar eventuais diferenças regionais no encaminhamento a delegacias (mas isso é mais processual). O importante é que qualquer pessoa com CPF e conta Gov.br possa utilizar o serviço, o que confere ao produto um alcance nacional.

  • Confiabilidade e Escalabilidade (Infraestrutura de Governo): Sendo parte da plataforma Gov.br de serviços digitais, o Celular Seguro deve se adequar aos padrões de infraestrutura de governo. Pode estar hospedado em datacenters governamentais ou em nuvem contratada, mas em ambos os casos deve atender requisitos de redundância e recuperação de desastres (DR). Ou seja, um requisito de produto é ter pelo menos um site secundário ou backup para garantir continuidade do serviço mesmo em caso de falha grave em um datacenter. A escalabilidade do produto deve ter sido planejada desde seu desenvolvimento – o fato de atingir milhões de usuários em poucos meses (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro) mostra que a arquitetura já nasceu para grande porte. Entretanto, manter a capacidade de expansão é requisito contínuo (por ex., se o uso crescer para dezenas de milhões, ou se decidirem incluir bloqueio de outros dispositivos no futuro, o design deve comportar extensão).

  • Manutenção Evolutiva (atualizações): O produto Celular Seguro deverá receber atualizações conforme necessário, seja para corrigir problemas ou adicionar melhorias. Isso requer processos de versionamento e deploy claros. A evidência disso é a versão 2.1 lançada em 2025 com novas funções (Celular Seguro BR – Apps no Google Play) (Celular Seguro BR – Apps no Google Play). Requisito de produto é que tais atualizações sejam entregues sem interromper o serviço (talvez usando estratégias de atualização contínua para a plataforma central e incentivando usuários a atualizarem o app nas lojas). Além disso, todas as partes interessadas (operadoras, bancos) devem ser notificadas quando houver mudanças que as afetem, garantindo alinhamento operacional.

  • Documentação e Transparência: O programa Celular Seguro, por ser governamental e envolvendo muitas partes, deve ser acompanhado de documentação adequada. Isso inclui: manuais de integração para parceiros, documentação pública (FAQs, tutoriais – já existentes (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública) (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎)), e política de privacidade publicada (o link de Política de Privacidade é fornecido na loja (Celular Seguro BR – Apps no Google Play)). A transparência é requisito: os cidadãos devem ter acesso à informação de quais dados o app utiliza e com quem os compartilha (conforme LGPD), bem como estatísticas agregadas do programa (por ex., o MJSP divulgou números de bloqueios realizados (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro) e pode continuar fazendo boletins).

  • Aceitação pelos Usuários e Parceiros: Embora não seja um requisito técnico, um requisito de alto nível do produto é que ele seja amigável o suficiente para que a população adote seu uso em massa e que as empresas parceiras cumpram seus papéis. Isso significa que o projeto do Celular Seguro deve levar em conta as expectativas dos usuários (facilidade, rapidez) e as capacidades dos parceiros (não solicitar a eles algo inexequível). A existência de campanhas informativas – por exemplo, perfis do governo divulgando “Baixe o app Celular Seguro” – e a adesão de novos bancos demonstram esse alinhamento como parte do sucesso do produto.

Riscos (RR)

  • RR1 – Emissão indevida de alertas (falsos positivos): Existe o risco de um usuário acionar o bloqueio sem que de fato tenha ocorrido um roubo ou perda (por engano ou abuso). Impacto: O aparelho e contas seriam bloqueados desnecessariamente, causando transtorno ao próprio usuário. Mitigação: O design do app procura minimizar isso exigindo confirmação clara do alerta e explicando que a ação é irreversível (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Além disso, somente o titular (ou alguém autorizado) pode emitir alerta para aquele dispositivo, reduzindo possibilidades de terceiros mal-intencionados causarem bloqueios indevidos. Caso aconteça um falso alerta, o usuário terá que seguir o procedimento de desbloqueio padrão (ir à operadora e bancos com documentos) (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), o que é inconveniente – esse risco residual é assumido como trade-off para garantir segurança (melhor bloquear por engano do que não bloquear em caso real).

  • RR2 – Irreversibilidade do bloqueio: Uma vez acionado o alerta no Celular Seguro, não há como desfazer o bloqueio via aplicativo (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Isso, embora seja uma decisão deliberada de segurança, configura um risco ao usuário caso ele recupere o celular logo após o alerta. Ele enfrentará dificuldade para reativar o aparelho e acessos, tendo que lidar individualmente com cada entidade (operadora, bancos) para desbloquear (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Mitigação: O app e sua documentação enfatizam que o alerta deve ser usado somente em caso de certeza de roubo/furto/perda (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro). O risco de arrependimento não pode ser totalmente removido, mas o usuário é alertado previamente. Como melhoria futura, o MJSP ou parceiros poderiam estudar janelas curtas de reversão (ex.: 5 minutos para cancelar se acionado por engano), mas atualmente isso não existe.

  • RR3 – Bloqueio ineficaz por dados desatualizados: Se o usuário não mantiver seu cadastro correto – por exemplo, se ele trocar de número de telefone e não atualizar no app – poderá ocorrer de um alerta não surtir efeito. O risco similar ocorre se cadastrar um telefone que não esteja em seu nome (CPF diferente) ou cuja operadora não é suportada. Nesses casos, as operadoras não realizarão o bloqueio solicitado (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública) e/ou o app informará apenas os bancos. Mitigação: O sistema comunica claramente que a linha deve estar no CPF do titular para funcionar (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), evitando expectativas equivocadas. Além disso, no cadastro ele pode restringir o formato de número para prevenir inserção errada. Para operadora não suportada, o app avisa que o usuário terá que contatá-la manualmente (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Resta um risco de alguns usuários não perceberem esses detalhes e acharem que bloquearam tudo quando não – caberá à comunicação do programa reforçar essas instruções (por isso a FAQ destaca essas questões).

  • RR4 – Uso mal-intencionado por “pessoa de confiança”: Ao cadastrar uma pessoa de confiança, o usuário está concedendo a ela poder de bloquear seu aparelho remotamente. Isso traz um risco de abuso, caso a pessoa de confiança aja de má-fé ou por engano. Impacto: Alguém próximo poderia acionar indevidamente o bloqueio de um celular alheio. Mitigação: O sistema limita que apenas pessoas explicitamente autorizadas pelo usuário tenham essa capacidade (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). A responsabilidade recai sobre o usuário na escolha do contato – tanto que o app recomenda “escolha com sabedoria” (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Para minimizar conflitos, o usuário pode remover ou trocar a pessoa de confiança a qualquer momento. As ações realizadas por um contato são auditadas e podem ser identificadas via protocolo, servindo de registro caso haja disputa.

  • RR5 – Atraso na efetivação dos bloqueios: Há risco de demora entre emitir o alerta e o bloqueio acontecer de fato nas pontas (especialmente o bloqueio de IMEI pela operadora, que pode levar algumas horas). Nesse meio tempo, o criminoso poderia usar o aparelho para acessar dados ou fazer transações. Mitigação: Muitas instituições implementam bloqueios quase imediatos (vários bancos em <10 minutos (Lista de Parceiros — Ministério da Justiça e Segurança Pública), operadoras às vezes em minutos para a linha). Além disso, a simples emissão do alerta limpa credenciais armazenadas em apps (porque o login Gov.br pode invalidar tokens?) – não documentado, mas possivelmente os apps integrados de bancos detectam o status de comprometido e se auto-deslogam. O risco de uso indevido pós-roubo é reduzido principalmente pelo bloqueio rápido de contas bancárias (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), que é onde está o maior prejuízo potencial (fraudes financeiras). O bloqueio de IMEI, mesmo que leve algumas horas, impede revenda fácil do aparelho. Portanto, o impacto da latência é mitigado parcialmente. O sistema também prioriza notificações WhatsApp no modo recuperação para desestimular o uso do aparelho pelo receptador, mesmo antes do bloqueio formal (Celular Seguro passa a emitir alerta de bloqueio por roubo).

  • RR6 – Subnotificação (usuários que não usam o app): Um risco ao objetivo do programa é que muitos cidadãos não conheçam ou não utilizem o Celular Seguro, recorrendo apenas aos métodos tradicionais (bloquear chip via operadora, etc.). Isso enfraquece a eficácia centralizada e a possibilidade de recuperar aparelhos. Mitigação: Não é um risco técnico do sistema em si, mas o MJSP deve continuar promovendo o app. A facilidade de uso e resultados demonstrados (50 mil aparelhos bloqueados em poucos meses (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro)) ajudam a convencer mais usuários a adotá-lo. Trata-se de um risco de adesão que é tratado fora do escopo do software, com campanhas de divulgação.

  • RR7 – Mercado de celulares roubados se adaptar: Com a implementação do Celular Seguro, existe o risco de criminosos mudarem de tática para contornar o sistema. Por exemplo, sabendo do modo recuperação, podem evitar inserir novos chips em aparelhos roubados, usando-os apenas via Wi-Fi para não serem rastreados. Ou podem desativar o aparelho imediatamente para retirar peças. Mitigação: Esses riscos fogem um pouco ao controle direto do software, mas influenciam seu sucesso. O MJSP, atento a isso, tem ampliado o escopo do programa (por exemplo, incluindo notificações via WhatsApp justamente para casos de uso via Wi-Fi não adiantaria, mas se o ladrão não usar mais o aparelho com rede celular, ao menos impede sua utilização como telefone). O programa pode evoluir para compartilhar dados com fabricantes (ex.: Apple/Google) para inutilizar aparelhos via contas associadas, mas isso seria futuro. Em suma, reconhece-se que nenhuma medida elimina 100% o crime, porém o Celular Seguro eleva o risco para o criminoso e reduz o valor de revenda do celular, o que já é sucesso parcial. Monitorar indicadores de roubo antes/depois do app é importante para avaliar e ajustar estratégias.

  • RR8 – Dependência de terceiros: O sucesso do bloqueio e recuperação depende das ações dos parceiros (operadoras, bancos, polícia). Se alguma operadora parceira falhar em bloquear uma linha, ou um banco não efetuar o bloqueio de conta, o usuário pode sofrer prejuízo. Mitigação: Os parceiros formalizaram compromissos de atuação via acordos de adesão (Conheça o Celular Seguro — Ministério da Justiça e Segurança Pública). O MJSP monitora a atuação (possivelmente registrando tempos de resposta de cada notificação). A transparência da lista de parceiros e suas ações (como na página pública que lista os procedimentos de cada banco e seus prazos (Lista de Parceiros — Ministério da Justiça e Segurança Pública) (Lista de Parceiros — Ministério da Justiça e Segurança Pública)) também gera accountability. Ainda assim, permanece um risco operacional. Do ponto de vista do software, é importante ter redundâncias: se uma notificação a um parceiro falhar (ex.: serviço indisponível), o sistema deve re-tentar ou escalar. Além disso, o protocolo fornecido ao usuário permite que ele mesmo cobre a instituição, caso necessário, diminuindo o risco de ficar sem solução – o cidadão pode, munido do protocolo, exigir o bloqueio diretamente junto à operadora/banco se identificar atraso.

Testes e Validações (RT)

  • RT1 – Validação de cadastro apenas para números nacionais: Testar que o sistema não permite cadastrar telefones com código de país diferente de +55 (Brasil). Nas regras de negócio está explícito que números internacionais não podem ser cadastrados no Celular Seguro (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Caso um usuário tente inserir um número estrangeiro, o sistema deve rejeitar com mensagem de erro apropriada. Esse requisito deve ser validado com casos de teste fornecendo, por exemplo, um número dos EUA (+1) e verificando se o app impede o prosseguimento.

  • RT2 – Verificação de titularidade (CPF) da linha: Embora o aplicativo não possa diretamente consultar a base de dados das operadoras (devido a limitações de privacidade), é importante validar o comportamento do sistema quando a regra de titularidade não é atendida. Ou seja, se um usuário cadastrar um telefone que não está em seu CPF e emite um alerta, nenhum bloqueio de operadora ocorrerá (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública). Para testar isso, pode-se criar um cenário simulado: usuário A cadastra um número que na base da operadora pertence a usuário B e emite um alerta – o teste deve confirmar que o status no lado operadora permanece ativo (nenhum bloqueio) enquanto o lado bancos efetuou bloqueios (pois os bancos validam pelo CPF que acionou). Esse é um caso de validação cruzada: as operadoras validam o CPF antes de bloquear (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública), garantindo que um usuário não consiga bloquear linhas de terceiros. O teste garante que essa salvaguarda funciona, mesmo que resulte em um “bloqueio parcial” (apenas bancos) quando a titularidade não bate. Além disso, a interface deve avisar o usuário nesse caso (conforme RNF/RR acima), e isso também pode ser verificado em teste de usabilidade.

  • RT3 – Emissão de protocolo e consistência de dados: Ao emitir um alerta, deve-se testar que um número de protocolo único é gerado e apresentado ao usuário (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎). Esse protocolo deve ser persistido no backend e associar corretamente todos os detalhes da ocorrência (CPF do usuário, IMEI/número do aparelho, data/hora, opção de bloqueio escolhida, etc.). Testes unitários podem validar o formato do protocolo (por exemplo, se segue um padrão específico) e testes de integração podem assegurar que, dado um protocolo, as instituições parceiras conseguem consultá-lo para validação. Por exemplo, um parceiro bancário pode guardar o protocolo nos logs de bloqueio; a Polícia Civil pode referenciá-lo no BO. Deve-se garantir que dois alertas diferentes nunca gerem o mesmo número de protocolo (unicidade global).

  • RT4 – Teste de fluxo completo de bloqueio: Realizar testes integrados simulando o fluxo ponta-a-ponta: um usuário emite alerta (via interface), o sistema envia comandos a uma operadora e a dois bancos fictícios de teste, e em seguida verifica-se: (a) a linha telefônica de teste foi marcada como bloqueada, (b) o IMEI de teste entrou na lista de impedidos, (c) as contas bancárias de teste foram congeladas. Cada parceiro deve responder conforme esperado. Esses testes podem ser feitos em ambiente de homologação com stubs das operadoras/bancos que respondam instantaneamente, permitindo confirmar que o Celular Seguro envia as notificações corretamente e lida com as respostas. Critérios de sucesso: bloqueios efetuados dentro dos tempos previstos (ex.: validar que bloqueio bancário ocorreu em <30 min conforme SLA (Lista de Parceiros — Ministério da Justiça e Segurança Pública)). Também deve-se testar o caso de operadora não suportada: quando o parceiro de telefonia não está integrado, o sistema deve ainda assim enviar a notificação aos bancos e não deve tentar efetuar bloqueio de IMEI por conta própria (espera-se que não, conforme arquitetura – esse caso pode ser validado verificando que nenhum comando de IMEI foi emitido se operadora marcada como “outra”).

  • RT5 – Teste da função de consulta de IMEI: Deve-se testar a busca por IMEI em diversos cenários: IMEI inexistente na base (esperar resposta “sem restrição”), IMEI presente por bloqueio total (esperar “com restrição”), IMEI de modo recuperação (atualmente deve retornar “sem restrição” porque ainda não integrado (Celular Seguro BR – Apps no Google Play), possivelmente com aviso). Usando um conjunto de IMEIs de teste cadastrados no ambiente de homologação da Anatel (CEMI), garantir que o app/aplicação web consegue consultar a API da Anatel e exibir corretamente o resultado ao usuário. Além disso, verificar que a máscara de entrada do IMEI no formulário não permite menos ou mais que 15 dígitos (validação de fronteira) e que a mensagem de erro caso o input seja inválido é clara.

  • RT6 – Teste de notificações WhatsApp (modo recuperação): Em um ambiente controlado, marcar um aparelho de teste em modo recuperação, inserir um novo chip de teste e verificar que o sistema envia a mensagem de WhatsApp para o novo número (Celular Seguro passa a emitir alerta de bloqueio por roubo ). Como esse componente envolve um serviço externo (WhatsApp Business API do MJSP), é importante testar: formato da mensagem, se o número do remetente confere com os oficiais divulgados ((61) 2025-3000 ou 3003) (Celular Seguro passa a emitir alerta de bloqueio por roubo ), e se a mensagem só é enviada uma vez por evento. Simular casos de múltiplas trocas de chip para um mesmo IMEI em curto intervalo e conferir se o sistema notifica todas ou aplica alguma regra (ex.: pode evitar spam). Esse teste valida a integração e também a eficácia: podemos até envolver voluntários para verificar a compreensão da mensagem recebida, se as instruções estão claras (testes de aceitação do usuário final para esse componente).

  • RT7 – Segurança e Penetration Test: Realizar testes de penetração no aplicativo e APIs para identificar vulnerabilidades. Por exemplo, testar se é possível interceptar e modificar um alerta em trânsito (deveria ser impossível devido a HTTPS), ou se alguma API não autenticada responde dados sensíveis. Testar também cenários de abuso: múltiplas tentativas de login (o Gov.br provavelmente cuida disso), spam na consulta de IMEI (talvez implementar captcha se necessário?). Esses testes garantem que o aplicativo segue os requisitos de segurança especificados. Resultados esperados: nenhum dado pessoal vazando, não é possível usuário não autorizado acionar alertas ou acessar dados de outro.

  • RT8 – Teste de usabilidade e acessibilidade: Conduzir avaliações com usuários para verificar se conseguem compreender e usar o app conforme previsto. Esse teste verifica indiretamente vários requisitos de interface e usabilidade. Por exemplo: usuários comuns devem ser capazes de cadastrar o telefone e uma pessoa de confiança sem precisar de instruções externas; em situação hipotética de roubo, devem conseguir emitir o alerta rapidamente. Também testar com usuários usando leitores de tela para ver se todos os elementos possuem rótulos adequados. Pontos a observar: entendimento das diferenças entre os modos de bloqueio (se o texto apresentado é suficiente ou se gera dúvidas), facilidade para encontrar o número de protocolo depois, etc. Ajustes na interface podem ser feitos com base nesses testes, mas o objetivo aqui é validar que os requisitos de UX (experiência do usuário) foram atendidos, resultando num produto simples, direto e eficiente no momento em que mais se precisa.

Os itens acima cobrem não apenas o que deve ser testado no sistema, mas também quais validações de negócio o próprio sistema efetua (ex.: validação de CPF, validação de formato de IMEI, confirmação de ações irreversíveis). Garantir por meio de testes rigorosos que todos os critérios de aceitação dos requisitos estão sendo cumpridos é essencial para a qualidade do Celular Seguro, dada sua natureza crítica.

Requisitos Funcionais (RF)


Tabela 1: Requisitos Funcionais do Celular Seguro
Apresenta os requisitos funcionais (ADD01–ADD12) elicitados na sessão.

ID Requisito Elicitado Categoria
ADD01 O sistema deve permitir autenticação do usuário via conta Gov.br, utilizando CPF e senha, como pré‑requisito de acesso. RF
ADD02 O aplicativo deve exibir os Termos de Uso e Privacidade na primeira vez que for aberto e requerer que o usuário os aceite para prosseguir. RF
ADD03 O usuário poderá cadastrar múltiplos telefones celulares em sua conta no Celular Seguro, vinculando cada número de telefone ao seu CPF. RF
ADD04 O aplicativo deve permitir o cadastro de “pessoas de confiança”, autorizando contatos escolhidos a emitir alertas em nome do usuário em caso de emergência. RF
ADD05 O sistema deve fornecer uma função de emissão de alerta de bloqueio em caso de roubo, furto ou perda do aparelho, acionada por um botão de emergência de forma rápida. RF
ADD06 Ao emitir um alerta, o usuário deverá selecionar o tipo de bloqueio desejado: Modo Recuperação (bloqueia linha e contas, mantendo o IMEI ativo) ou Bloqueio Total. RF
ADD07 Após o disparo do alerta, o sistema deve gerar um número de protocolo único e apresentá‑lo ao usuário, para referência junto às autoridades e parceiros. RF
ADD08 O alerta emitido pelo Celular Seguro deverá ser enviado automaticamente às operadoras de telefonia e instituições financeiras parceiras para os bloqueios necessários. RF
ADD09 O aplicativo deve oferecer a funcionalidade de consultar se um aparelho possui restrição, permitindo verificar pelo IMEI se um celular é bloqueado antes de comprá‑lo. RF
ADD10 O Celular Seguro deve estar disponível tanto como aplicativo móvel (Android/iOS) quanto via versão web, oferecendo as mesmas funcionalidades em ambas plataformas. RF
ADD11 O sistema deve possibilitar a emissão de mais de um alerta para a mesma linha telefônica, permitindo novos alertas após ocorrências distintas. RF
ADD12 Em modo Recuperação, o sistema deve receber notificações de quando um novo chip for inserido no aparelho e enviar alerta ao usuário. RF

Requisitos Não‑Funcionais (RNF)


Tabela 2: Requisitos Não Funcionais do Celular Seguro
Apresenta os requisitos não funcionais (ADD13–ADD19) elicitados na sessão.

ID Requisito Elicitado Categoria
ADD13 O serviço Celular Seguro deve estar disponível para todos os cidadãos brasileiros, 24×7, sem interrupções planejadas. RNF
ADD14 O tempo de resposta para comunicação de um alerta aos parceiros deve ser mínimo – idealmente instantâneo – e os bloqueios devem ocorrer em minutos. RNF
ADD15 O aplicativo e a plataforma devem seguir requisitos de segurança da informação: conexão criptografada, proteção de dados conforme LGPD e não compartilhamento indevido. RNF
ADD16 A usabilidade deve ser priorizada: interface intuitiva, botões claros, textos explicativos e fluxo reduzido, considerando o estado emocional do usuário. RNF
ADD17 O Celular Seguro deve ser compatível com as principais versões de sistemas móveis e navegadores, e aderir a padrões de acessibilidade. RNF
ADD18 O serviço deverá ser oferecido gratuitamente, sem cobrança pelo download ou uso do aplicativo. RNF
ADD19 O sistema deve cumprir a legislação e normas vigentes, incluindo portarias, resoluções da Anatel e diretrizes da Febraban. RNF

Requisitos de Interface (RI)


Tabela 3: Requisitos de Interface do Celular Seguro
Apresenta os requisitos de interface (ADD20–ADD27) elicitados na sessão.

ID Requisito Elicitado Categoria
ADD20 A tela inicial deve apresentar as quatro funções principais (Registrar Telefone, Pessoas de Confiança, Celulares com Restrição, Emitir Alerta) com ícones claros. RI
ADD21 O onboarding deve guiar o usuário pelo login Gov.br, aceite de termos, cadastro de pessoa de confiança e registro de telefone. RI
ADD22 A interface de emissão de alerta deve listar aparelhos, permitir selecionar bloqueio e exigir confirmação final. RI
ADD23 Após confirmar o alerta, exibir tela de sucesso com número de protocolo e instruções para guardá‑lo. RI
ADD24 A consulta de IMEI deve ter campo de 15 dígitos e botão de busca, exibindo resultado claro e alertando sobre limitações. RI
ADD25 Nas telas de cadastro e alerta, listar operadoras suportadas e indicar bloqueio manual se a operadora não estiver na lista. RI
ADD26 Apresentar mensagens de erro adequadas para dados inválidos ou ações sem pré‑requisitos. RI
ADD27 Seguir padrões de design acessível: rótulos textuais, suporte a aumento de fonte e contraste adequado. RI

Requisitos de Produto/Integração (RPR)


Tabela 4: Requisitos de Produto/Integração do Celular Seguro
Apresenta os requisitos de produto e integração (ADD28–ADD38) elicitados na sessão.

ID Requisito Elicitado Categoria
ADD28 O sistema deve integrar‑se ao Login Único Gov.br via OAuth2/OIDC, respeitando políticas de sessão e segurança. RPR
ADD29 Conectar‑se ao sistema CEMI da Anatel/ABR Telecom para efetivar bloqueios de IMEI e linha, processando respostas em prazo. RPR
ADD30 Receber notificações de novos chips em IMEIs bloqueados e acionar procedimentos necessários. RPR
ADD31 Integrar‑se com instituições financeiras via canal padronizado, enviando CPF e informações do alerta. RPR
ADD32 Restringir cadastro a números do Brasil (+55) com validação na interface e documentação. RPR
ADD33 Suportar milhões de usuários simultâneos, com arquitetura escalável e tolerância a picos de acesso. RPR
ADD34 Manter disponibilidade mínima de 99% de uptime e plano de contingência para indisponibilidades. RPR
ADD35 Irreversibilidade do alerta: não permitir desfazer bloqueio via app. RPR
ADD36 Realizar protótipos e testes de usabilidade antes de novas versões. RPR
ADD37 Não realizar desbloqueio pelo app após recuperação do aparelho; processo externo. RPR
ADD38 Impedir cadastro do mesmo número em mais de um CPF simultaneamente. RPR

Riscos (RR)


Tabela 5: Riscos do Celular Seguro
Apresenta os riscos (ADD39–ADD43) elicitados na sessão.

ID Requisito Elicitado Categoria
ADD39 Risco de uso indevido: apenas usuários ou contatos de confiança podem acionar bloqueio; tentativas de terceiros falham. RR
ADD40 Alertar que bloqueio não pode ser revertido via app, evitando acionamentos acidentais. RR
ADD41 Orientar registro de Boletim de Ocorrência após emitir alerta. RR
ADD42 Caso parceiros não executem bloqueio, usuário deve usar protocolo para acompanhamento. RR
ADD43 Aconselhar escolha criteriosa de pessoa de confiança; logs mitigam risco de abuso. RR

Testes / Validações (RT)


Tabela 6: Testes / Validações do Celular Seguro
Apresenta os testes e validações (ADD44–ADD50) elicitados na sessão.

ID Requisito Elicitado Categoria
ADD44 Validação de formato de entrada: telefone com DDD válido e IMEI de 15 dígitos, com erros adequados. RT
ADD45 Teste de integração completo em ambiente de homologação, simulando fluxo real. RT
ADD46 Testar regularmente envio de notificações via WhatsApp para garantir números ativos e corretos. RT
ADD47 Impedir alerta sem telefone registrado ou sem login. RT
ADD48 Auditorias periódicas em logs e protocolos para evitar bloqueios duplicados. RT
ADD49 Teste de carga e desempenho simulando milhares de alertas simultâneos. RT
ADD50 Testes de segurança independentes (penetration test) para mitigar vulnerabilidades. RT

Bibliografia

Ministério da Justiça e Segurança Pública – Portal do Programa Celular Seguro (MJSP): Conheça o Celular Seguro. Disponível em: https://www.gov.br/mj/pt-br/acesso-a-informacao/acoes-e-programas/celular-seguro/conheca-o-celular-seguro (Conheça o Celular Seguro — Ministério da Justiça e Segurança Pública) (Conheça o Celular Seguro — Ministério da Justiça e Segurança Pública).

Ministério da Justiça e Segurança Pública – Portal do Programa Celular Seguro (MJSP): Dúvidas Frequentes. Disponível em: https://www.gov.br/mj/pt-br/acesso-a-informacao/acoes-e-programas/celular-seguro/duvidas-frequentes (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública) (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública).

Portal Gov.br – Serviço: Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro. Disponível em: https://www.gov.br/pt-br/servicos/comunicar-roubo-furto-de-aparelho-pelo-aplicativo-celular-seguro (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎) (Comunicar roubo/furto de aparelho pelo aplicativo Celular Seguro‎).

Portal Gov.br – Aplicativo Celular Seguro BR (Galeria de Aplicativos). Disponível em: https://www.gov.br/pt-br/apps/celular-seguro-br (Celular Seguro BR).

Google Play Store – Celular Seguro BR (descrição do aplicativo, versão 2.1, atualizado em 26/04/2025). Disponível em: https://play.google.com/store/apps/details?id=com.celularlegal (Celular Seguro BR – Apps no Google Play) (Celular Seguro BR – Apps no Google Play).

Agência Brasil/EBC – “Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro. Número de usuários cadastrados supera 2 milhões”. Publicado em 23/05/2024, por Agência Brasil (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro) (Celular Seguro ultrapassa 50 mil bloqueios de aparelhos desde dezembro).

Poder360 – “Celular Seguro começa a emitir alerta de bloqueio por roubo”. Publicado em 08/04/2025, por Poder360 (com informações da Agência Brasil) (Celular Seguro passa a emitir alerta de bloqueio por roubo ) (Celular Seguro passa a emitir alerta de bloqueio por roubo ).

Agência Brasil/EBC – “Celular Seguro começa a emitir alerta de bloqueio de aparelhos”. Publicado em 07/04/2025. (Conteúdo referenciado indiretamente via Poder360 e redes sociais da EBC) (Celular Seguro passa a emitir alerta de bloqueio por roubo ) (Celular Seguro passa a emitir alerta de bloqueio por roubo ).

CartaCapital – “Celular Seguro oferece Bloqueio Total e Modo Recuperação; entenda a diferença”. Publicado em 2024 (referência ao esclarecimento das modalidades de bloqueio) (Dúvidas Frequentes — Ministério da Justiça e Segurança Pública).

Repositório UNAD (Colômbia) – “Técnicas para elicitar requisitos – Análisis de documentación”. Disponível em: https://repository.unad.edu.co/reproductor-ova/10596_35614/tcnicas_para_elicitar.html (Técnicas para elicitar | Ingeniería de Requisitos ) – (Referência conceitual sobre a técnica de análise de documentos em engenharia de requisitos).

Histórico de Versões

Versão Data de produção Descrição da Alteração Autor(es) Revisor(es) Data de Revisão
1.0 01/05/2025 Criação da documentação e desenvolvimento do projeto Arthur Carvalho, Leonardo de Melo Leonardo de Melo 01/05/2025
1.1 04/05/2025 Adição do vídeo no documento Leonardo de Melo Arthur Carvalho 04/05/2025