Suporte Okai

Aplica-se a: Requisitos regulatórios, internos, contratuais ou de projeto que precisam ser atendidos por processos, controles, tarefas, documentos e evidências na Okai.

Requisito é aquilo que precisa ser demonstrado

Registrar um requisito transforma uma obrigação, condição ou critério em algo entendível, executável e comprovável. Não basta copiar um trecho de norma nem escrever uma intenção ampla, como manter conformidade regulatória. O requisito precisa responder: o que deve ser atendido, em qual contexto, por quem, com qual evidência e a partir de qual origem.

Na Okai, o requisito funciona como ponte entre a fonte da obrigação e o trabalho operacional. Ele pode nascer de norma, política interna, contrato, decisão de projeto, auditoria ou análise de risco. Depois, ajuda a criar controles, tarefas, planos de adequação e evidências coerentes.

Um bom requisito reduz ambiguidade. Quem revisa o registro depois deve entender se a obrigação foi atendida sem depender de conversa fora da plataforma. Se o atendimento ainda exige interpretação livre, o requisito precisa ser reescrito, dividido ou vinculado a uma fonte mais precisa.

Teste mental: Antes de salvar, tente responder sim, não ou não se aplica. Se o texto não permite uma dessas respostas com base em evidência, ele ainda não está verificável.

Quando registrar e quando usar outro item

Registre um requisito quando uma condição de atendimento precisa ficar rastreável: obrigação regulatória, critério de aceite, exigência contratual, compromisso de auditoria, padrão interno ou dependência antes de uma entrega.

• Use requisito quando a frase puder ser testada contra evidência, controle, processo ou entrega.
• Use tarefa quando o foco for ação, como revisar documento, anexar evidência ou obter aprovação.
• Use controle quando já existir atividade recorrente ou mecanismo operacional que demonstra atendimento ao requisito.
• Use projeto quando vários requisitos, tarefas e decisões precisam ser conduzidos com escopo, responsáveis e prazo coordenados.
• Evite criar requisito para ideia vaga, recomendação sem decisão de aplicabilidade ou trecho normativo ainda não analisado.

Não transforme dúvida em requisito definitivo: Se ainda não está claro se a obrigação se aplica, registre a análise ou a tarefa de avaliação primeiro. Marcar como aplicável antes da decisão cria cobrança indevida e enfraquece a rastreabilidade.

Escreva como critério verificável

A redação é a parte mais importante do cadastro. Ela deve sair do texto amplo da origem e chegar a uma condição concreta de atendimento. Sempre que possível, escreva em uma frase direta, com verbo de obrigação e escopo delimitado.

1. Identifique a obrigação real: Leia a fonte e separe obrigação, definição, contexto, exceção e prazo. Nem todo trecho de norma cria ação; alguns apenas explicam conceitos ou limitam quando a regra se aplica.
2. Transforme em frase testável: Escreva o requisito como condição conferível. Por exemplo: manter evidência de aprovação prévia para alterações no cadastro de administradores do sistema. A frase mostra ação, objeto e evidência esperada.
3. Delimite escopo: Indique processo, produto, área, sistema, carteira, público, período ou situação alcançada. Sem escopo, a cobrança tende a ficar ampla demais e difícil de provar.
4. Inclua prazo ou gatilho quando houver: Se a obrigação depende de data, periodicidade ou evento, registre isso no requisito ou no item relacionado. Prazo de adequação, ciclo mensal, envio por evento e revisão anual mudam o atendimento.
5. Separe requisitos diferentes: Se uma norma exige registro, aprovação e comunicação, avalie separar quando cada obrigação tiver responsável, evidência ou controle diferente.

Trecho longo não é critério: Copiar o artigo inteiro pode ser útil como referência, mas não substitui a formulação do requisito. A fonte explica de onde veio a obrigação; o requisito explica o que será atendido na rotina.

Origem, dono e evidência precisam fechar a história

Um requisito solto vira inventário. Para gerar trabalho confiável, ele precisa estar ligado à origem que o sustenta, ao responsável e aos mecanismos que demonstram cumprimento. Esses vínculos permitem responder por que o requisito existe, quem cuida dele e como será provado.

• Origem: vincule a norma, documento, contrato, deliberação, auditoria ou decisão que criou o requisito. Quando vier de norma, use o dispositivo mais específico disponível.
• Responsável: atribua a área ou pessoa com capacidade real de conduzir o atendimento. Responsável simbólico não resolve cobrança nem exceção.
• Controle: associe o controle que previne, detecta ou corrige falhas de atendimento. Se nenhum controle existir, registre a necessidade de desenho ou implantação.
• Tarefas: crie ou vincule ações quando houver adequação, revisão, evidência pendente, decisão de aplicabilidade ou execução pontual.
• Evidência: defina o material que comprova atendimento, como relatório, aprovação, protocolo, ata, log, formulário, anexo, print permitido ou documento formal.
• Risco ou impacto: conecte quando o requisito mitiga exposição regulatória, operacional, contratual ou de auditoria.

Vínculo correto vale mais que descrição longa: Se o requisito está associado à norma, controle ou tarefa errada, corrija o relacionamento na origem do registro. Não compense com texto explicativo que contradiz os dados vinculados.

Registrar na Okai

1. Comece pela fonte: Abra a norma, documento, projeto, auditoria ou registro que motivou o requisito. Registre apenas a referência necessária e confirme se a fonte é a versão correta.
2. Dê um título operacional: Use um nome que revele a obrigação, não apenas o assunto. Aprovação prévia de alterações em perfis críticos é mais útil que perfis críticos ou segurança da informação.
3. Descreva o critério de atendimento: No texto principal, registre a condição verificável, o escopo e qualquer prazo ou gatilho relevante. Evite linguagem que dependa de intenção sem explicar a ação esperada.
4. Defina aplicabilidade: Indique se o requisito se aplica ao processo, produto, entidade ou área analisada. Quando a aplicação depender de condição, registre a condição e a evidência usada para decidir.
5. Atribua responsável e relacionamentos: Vincule dono, controles, riscos, tarefas, projetos ou evidências já existentes. Se algo ainda não existir, registre a pendência no fluxo adequado.
6. Revise a comprovação esperada: Antes de concluir, confira se a evidência descrita realmente provaria atendimento. Se ela apenas mostra esforço, comunicação ou intenção, ajuste o desenho do controle ou da tarefa.

Como saber se ficou pronto para revisão

Um requisito pronto para revisão não precisa ser longo, mas precisa sustentar uma decisão. Ele deve permitir que compliance, operação, auditoria ou liderança entendam a obrigação sem reconstruir a análise.

• A frase do requisito descreve uma condição de atendimento, não apenas um tema.
• A origem está clara e aponta para o documento, dispositivo ou decisão correta.
• O escopo mostra onde o requisito se aplica e, quando necessário, onde não se aplica.
• Existe responsável por conduzir ou comprovar atendimento.
• Há controle, tarefa, projeto ou plano conectado quando o atendimento depende de execução.
• A evidência esperada permite testar o requisito de forma objetiva.
• Exceções, dúvidas de aplicabilidade e decisões pendentes estão registradas em itens próprios.

Atendimento não é comentário livre: Um comentário pode explicar contexto, mas não deve ser a única prova de atendimento quando a obrigação exige evidência, aprovação, protocolo, controle executado ou documento formal.

Diagnóstico de requisitos frágeis

Quando um requisito não ajuda a decidir ou comprovar atendimento, investigue a estrutura do registro antes de ajustar apenas palavras. A fragilidade costuma estar na origem, na granularidade, no dono, na evidência ou no vínculo com controles.

1. O requisito parece amplo demais: Procure obrigações diferentes dentro da mesma frase. Separe por escopo, prazo, responsável ou evidência quando esses elementos não forem iguais.
2. A origem não explica a cobrança: Volte para a norma, contrato ou decisão e confirme se o item realmente cria a obrigação. Se a fonte apenas menciona o tema, registre uma análise antes de manter o requisito.
3. Ninguém sabe quem atende: Identifique onde o processo acontece e quem tem acesso às informações necessárias. Se a responsabilidade está dividida, defina dono principal e tarefas auxiliares.
4. Existe controle, mas ele não prova o requisito: Compare critério do requisito com objetivo, frequência, escopo e evidência do controle. Se o controle cobre só parte da obrigação, ajuste o desenho ou crie controles complementares.
5. A evidência anexada não responde à pergunta: Verifique se o arquivo mostra execução, data, escopo, resultado e aprovação exigida. Material preparatório, e-mail informal ou declaração genérica podem não ser suficientes.
6. O requisito aparece atendido, mas há pendências: Revise tarefas abertas, exceções, prazos vencidos e decisões condicionais. Atendimento parcial deve ficar explícito para não gerar falsa conclusão de conformidade.

A pergunta final: Se uma auditoria perguntasse como este requisito é atendido hoje, a Okai deveria mostrar origem, responsável, controle ou tarefa, evidência e linha do tempo. Se uma dessas partes falta, o registro ainda precisa de trabalho.