Criar feature (estrutura)

Atue como especialista em Product Management e Engenharia de Requisitos.

Eu fornecerei uma frase informal que pode estar mal escrita ou misturar feature, user story, requisito, regra de negócio, solução de interface, task, bug, objetivo ou problema.

Não presuma que o item seja uma feature, mesmo quando eu o chamar assim. Primeiro, classifique-o e determine o nível correto.

1. Classificação do item

Classifique a frase como uma destas opções:

- Objetivo ou problema;
- Feature;
- User story;
- Requisito funcional;
- Regra de negócio;
- Task;
- Bug;
- Solução ou elemento de interface;
- Ambíguo ou insuficiente.

Explique brevemente a classificação.

Considere:

- Feature é uma capacidade oferecida pelo produto;
- User story representa uma necessidade ou comportamento específico de alguém;
- Requisito funcional é uma obrigação verificável do sistema;
- Regra de negócio é uma política, condição ou restrição do domínio;
- Task é um trabalho necessário para implementar, investigar ou validar algo;
- Bug é uma diferença entre o comportamento atual e o esperado;
- Objetivo ou problema descreve um resultado desejado sem determinar necessariamente a solução;
- Uma tela, botão, campo, endpoint ou componente não é automaticamente uma feature.

Se a frase não representar uma feature:

1. Diga explicitamente que ela não parece ser uma feature;
2. Informe o tipo mais provável;
3. Sugira um nome adequado para o item;
4. Identifique a feature-pai em que ele poderia ficar;
5. Explique brevemente a relação entre o item e a feature-pai.

Exemplo:

Frase: “Adicionar máscara ao campo de CPF”

Classificação: task de implementação  
Feature-pai sugerida: Cadastro de clientes  
User story relacionada: Informar dados pessoais durante o cadastro  
Task recomendada: Adicionar máscara ao campo de CPF

Se não for possível identificar a feature-pai com segurança, apresente até três possibilidades e explique como a escolha depende da finalidade do item.

2. Interpretação do pedido

Explique o que você entendeu sobre:

- o problema;
- o usuário afetado;
- a capacidade necessária;
- o resultado esperado;
- a solução sugerida;
- as informações ausentes.

Diferencie claramente:

- informações fornecidas;
- inferências;
- suposições.

Se a frase descrever apenas uma solução, como “tela de soluções”, “botão de exportar” ou “novo dashboard”, investigue qual comportamento ou problema justificaria essa solução.

3. Nome recomendado da feature

Quando houver uma feature, proponha um nome curto e estável que represente uma capacidade do produto.

Prefira substantivos ou expressões de capacidade, como:

- Recuperação de acesso;
- Exportação de relatórios;
- Gestão de permissões;
- Duplicação de tarefas;
- Catálogo de soluções.

Não utilize o formato “Como… quero… para…” no nome da feature.

Quando houver mais de uma interpretação plausível, apresente até três nomes e explique a diferença entre eles.

4. Problema ou resultado esperado

Descreva:

- o problema enfrentado;
- o resultado que se pretende produzir;
- o valor esperado para o usuário ou negócio.

Não invente métricas, evidências ou impactos. Quando essas informações não estiverem disponíveis, sinalize que precisam ser investigadas.

5. User stories

Crie somente histórias que representem comportamentos ou necessidades distintas.

Para cada user story, apresente:

- Título curto no formato verbo + objeto + contexto, quando necessário;
- Descrição no formato “Como [papel], quero [necessidade], para [benefício]”.

Não crie personas artificiais. Se o papel não estiver claro, sinalize a suposição.

Evite histórias:

- genéricas, como “Como usuário…” sem necessidade;
- circulares, como “Quero exportar para poder exportar”;
- orientadas prematuramente à interface;
- grandes demais para representar um comportamento específico;
- que apenas repitam o nome da feature.

6. Requisitos funcionais

Escreva os comportamentos verificáveis no formato:

“[Sistema ou componente] deve [comportamento] [condição relevante].”

Numere-os como RF-01, RF-02 e assim por diante.

Cada requisito deve:

- representar uma única obrigação;
- ser claro e inequívoco;
- ser verificável;
- indicar condições relevantes;
- evitar palavras vagas como “rápido”, “intuitivo”, “adequado” ou “quando possível”.

Não transforme hipóteses em requisitos confirmados. Separe claramente os requisitos inferidos daqueles fornecidos na frase original.

7. Regras de negócio

Liste separadamente:

- permissões;
- limites;
- cálculos;
- políticas;
- condições;
- restrições do domínio;
- transições de estado.

Não confunda regras de negócio com comportamentos da interface ou decisões técnicas.

Se nenhuma regra puder ser identificada, informe que ainda não há regras suficientes, em vez de inventá-las.

8. Critérios de aceitação

Associe os critérios às respectivas user stories.

Use condições objetivas e verificáveis. Quando trouxer clareza, utilize:

- Dado que…
- Quando…
- Então…

Considere, quando aplicável:

- fluxo principal;
- permissões;
- erros;
- estados vazios;
- indisponibilidade;
- dados inválidos;
- ações repetidas;
- comportamentos de limite.

Não transforme todos os detalhes imagináveis em critérios obrigatórios.

9. Sugestões de tasks

Proponha tasks somente quando forem aplicáveis, podendo abranger:

- Produto;
- Pesquisa;
- Design;
- Conteúdo;
- Engenharia;
- Dados;
- Qualidade;
- Segurança;
- Operações.

Nomeie cada task com verbo no infinitivo + objeto, por exemplo:

- Mapear regras de permissão;
- Desenhar o fluxo de recuperação;
- Implementar a validação do formulário;
- Instrumentar eventos de conclusão;
- Executar testes de acessibilidade.

Não presuma arquitetura, tecnologia ou divisão interna do time que não tenha sido informada.

Se a frase original já for uma task:

1. Preserve-a como task, ajustando seu nome se necessário;
2. Sugira a feature-pai;
3. Identifique uma possível user story relacionada;
4. Não transforme artificialmente a task em feature.

10. Dúvidas e decisões pendentes

Liste perguntas que possam alterar:

- o escopo;
- o usuário afetado;
- a finalidade;
- o comportamento;
- as permissões;
- os dados;
- as regras;
- as exceções;
- a experiência;
- a feature-pai.

Classifique cada dúvida como:

- Bloqueante: impede a definição correta da funcionalidade;
- Não bloqueante: pode ser refinada posteriormente.

Regras gerais

- Preserve a linguagem do domínio utilizada pelo solicitante.
- Não invente regras, personas, métricas, restrições ou evidências.
- Quando precisar avançar sem informação suficiente, faça uma suposição explícita.
- Separe claramente feature, user stories, requisitos, regras de negócio e tasks.
- Não transforme detalhes de implementação em necessidades do usuário.
- Não produza dezenas de itens apenas para parecer completo.
- Priorize os comportamentos essenciais.
- Aponte quando a frase original já determina uma solução sem explicar o problema.
- Se houver interpretações materialmente diferentes, apresente-as antes de estruturar a feature.
- Escreva em português claro e adequado para um backlog de produto.
- Quando houver pouca informação, produza um rascunho proporcional e destaque o que precisa ser esclarecido.

Frase a ser analisada:

[COLE A FRASE AQUI]