Política de Tecnologia para Criação e Documentação de Histórias de Usuário¶

Esta política visa padronizar o processo de criação de Histórias de Usuário (HUs), garantindo consistência, clareza e alinhamento com os requisitos do projeto e as necessidades dos usuários.

As HUs deverão ser cadastradas como Issues na ferramenta de gestão e as atividades de registro, priorização e refinamento deverão seguir o processo de desenvolvimento ágil descrito no PPA.

Nomenclatura da História de Usuário (HU)¶

A nomenclatura da HU deverá seguir as diretrizes estabelecidas na Política de Nomenclatura de Artefatos.

Estrutura da Descrição da História de Usuário¶

Como [persona]¶

Descrever o perfil, grupo ou sistema envolvido. A persona é uma representação do usuário final, cliente ou outro sistema consumidor.

Quero [ação]¶

Indicar a ação que a persona deseja realizar ou o objetivo buscado. Deve ser clara e concisa.

Para [resultado/benefício]¶

Descrever o benefício ou valor gerado pela ação. Explica por que a funcionalidade é importante.

APF - Padrão para Contagem Estimada (SFP)¶

Padroniza a documentação de impactos técnicos e funcionais, garantindo rastreabilidade e comunicação eficiente.

Tipo de Impacto¶

Quando usar: Sempre que houver alteração no sistema.
Como usar:
Impacto Funcional: Quando há visibilidade direta ao usuário.
Impacto Não Funcional: Melhorias internas, sem interface com o usuário final (ex: segurança, desempenho).

Backend – APIs e Serviços¶

Quando usar: Para criação, alteração ou remoção de endpoints (REST/Webservices).
Como usar: Descrever no formato: **VERBO** - nome-do-serviço/caminho/do/endpoint.

Referência: Swagger de Desenvolvimento

Frontend / Mobile – Telas, Relatórios e Arquivos¶

Quando usar: Para alterações visuais ou funcionais nas interfaces.
Como usar: Informar ambiente (**WEB** ou **MOBILE**), tipo (**TELA**, **RELATORIO**, **ARQUIVO**) e o caminho da funcionalidade.

Banco de Dados – Entidades (MER)¶

Quando usar: Em alterações em tabelas, views ou entidades.
Como usar: Indicar origem (**WEB** ou **MOBILE**) e seguir o padrão schema.entidade (ex: sgf.TB_USUARIO).

Importante¶

O preenchimento correto é obrigatório para validação técnica.
Demandas incompletas serão devolvidas para correção.
A responsabilidade da validação é do time de desenvolvimento e arquitetura.

Regras de Negócio¶

Regras que definem como o sistema deve operar em determinadas condições para atender aos objetivos do negócio.

Como registrar:¶

RN-000: Código identificador da regra.
Nome: Breve e objetivo.
Descrição Detalhada: Explicação completa baseada em alinhamento com o cliente.

Exemplo:¶

RN-001 - Controle de campos obrigatórios para informações de conta

Os campos Banco, Agência e Conta Corrente são obrigatórios em todas as transações financeiras. A aplicação deve verificar se esses campos estão preenchidos ao salvar os dados. Ao tentar salvar os dados sem preencher algum dos campos obrigatórios, a aplicação deve exibir mensagens de erro específicas para cada campo faltante.

Critérios de Aceitação¶

Os critérios de aceitação são os parâmetros ou condições que devem ser cumpridos para que a funcionalidade implementada seja considerada completa e atenda aos requisitos estabelecidos pelas regras de negócio específicas.

Os critérios deverão ser detalhados para cada História de Usuário, conforme a definição de pronto, para garantir que a implementação atenda aos requisitos do usuário e do sistema.

Exemplos:¶

Critério de aceite 1¶

Detalhar critério de aceitação vinculado à história em elaboração. Caso tenha campos, poderá estruturar da seguinte forma:

Campo 1;
Campo 2;
Campo 3;
Campo 4;
Campo 5;

Critério de aceite 2¶

Detalhar critério de aceitação vinculado à história em elaboração. Caso tenha tabela, poderá estruturar da seguinte forma:

Campo	Tipo
Campo 1	Numérico
Campo 2	Alfanumérico

Critério de aceite 3¶

Detalhar critério de aceitação vinculado à história em elaboração. Caso tenha imagem, poderá estruturar da seguinte forma:

[Inserir imagem]

Critério de aceite 4¶

Detalhar critério de aceitação vinculado à história em elaboração. Caso tenha lista, poderá estruturar da seguinte forma:

Primeira entrada;
Segunda entrada;
Terceira entrada;

Critério de aceite 5¶

Detalhar critério de aceitação vinculado à história em elaboração. Caso tenha link, poderá estruturar da seguinte forma:

[Inserir link]

Tipos de Testes¶

Devem ser especificados os testes aplicáveis à HU:

Observação: Esta seção pode estar na própria HU ou na tarefa de teste vinculada.

Protótipos¶

Anexar imagens dos protótipos relacionados aos critérios de aceitação.
Quando não aplicável, indicar N/A.

Referências¶

Incluir links ou documentos relevantes como issues relacionadas, wikis, documentos funcionais/técnicos.
Quando não aplicável, indicar N/A.