Ganhos:
- Capacidade de distinguir requisitos funcionais e não funcionais e escrever expressões de requisitos claras e mensuráveis com o apoio da inteligência artificial
- Capacidade de usar inteligência artificial com prompts estruturados para extrair história do usuário, critérios de aceitação e limite de escopo das notas da entrevista
- Adquirir o hábito de verificar os requisitos gerados pela IA em busca de ambiguidade, contradição e regras ausentes e confirmá-los com as partes interessadas
A análise de requisitos é a tarefa de definir de forma completa, clara e verificável o que um sistema deve fazer. É uma das etapas onde o especialista em MIS produz mais valor; porque um erro aqui cresce exponencialmente no final do projeto. Existem dois tipos básicos de análise de requisitos. O requisito funcional descreve o trabalho que o sistema deve realizar: “O sistema deve enviar um e-mail ao cliente quando confirmar o pedido”. Os requisitos não funcionais descrevem como o sistema deve ser: qualidades como desempenho, segurança, usabilidade e acessibilidade. “A tela do relatório deve abrir em menos de 2 segundos com carga média” é um requisito não funcional.
Um bom requisito tem três características: é claro (tem uma única interpretação), é mensurável (tem um limite testável) e é rastreável (é claro de onde ele vem). “O sistema deve ser rápido” não atende a nada disso; “rápido” é subjetivo, não pode ser medido, não pode ser testado. Nesta fase, a IA é uma ajuda poderosa na elaboração de requisitos e na detecção de formulações ambíguas; mas apenas a parte interessada decide qual regra de negócio é real.
História do usuário e critérios de aceitação
Um formato comum na escrita de requisitos modernos é a história do usuário: "Como [função], para [propósito], eu quero [recurso]." Exemplo: “Como representante comercial, quero o cálculo do desconto na tela do celular para poder fazer orçamentos rápidos em campo”. A história é curta e voltada para os negócios; Não impõe uma solução técnica.
Toda história deve ter critérios de aceitação: condições testáveis que devem ser atendidas para que a história seja considerada “ok”. Um padrão frequentemente utilizado é o padrão "Dado/Quando/Então": "Dado: o cliente está no segmento VIP. Quando: pedidos acima de 10.000 TL. Então: o sistema aplica um desconto de 5%." Esse padrão elimina a ambigüidade porque conecta claramente a condição e o resultado esperado.
Dica: Ao escrever uma história de usuário para a inteligência artificial, certifique-se de dizer "gerar pelo menos 2 critérios de aceitação no formato Dado/Quando/Então para cada história". Quando o modelo é forçado a produzir benchmarks, lacunas ocultas nos requisitos tornam-se visíveis.
Passo a passo: extração de requisitos assistida por IA
Etapa 1 — Colete informações brutas. Registros de chamadas, e-mails, capturas de tela existentes, listas de reclamações. Quanto mais informações reais, menos fabricação.
Passo 2 — Extraia o primeiro conjunto de histórias. Forneça informações brutas à inteligência artificial e faça com que ela produza rascunhos de histórias de usuários. Esta etapa não é uma lista completa, mas um primeiro passo.
Passo 3 — Adicione critérios de aceitação. Gere critérios Dado/Quando/Então para cada história. Uma história para a qual não é possível produzir critérios significa, na verdade, que não está suficientemente definida.
Passo 4 — Procurando contradições e lacunas. Pergunte à IA “há alguma contradição, duplicação ou situação indefinida entre esses requisitos?” Pergunte e verifique. Filtre o resultado como humano.
Passo 5 — Priorize e confirme. Priorize histórias com as partes interessadas com base no valor comercial e na urgência. A decisão prioritária pertence à unidade de negócios, não à IA.
Não se esqueça dos requisitos não funcionais
A maioria dos projetos tem dificuldades em campo porque esquecem os não funcionais na hora de escrever os requisitos funcionais. Um relatório pode funcionar “corretamente”, mas se demorar 45 segundos para ser aberto, ninguém o utilizará. A tabela a seguir mostra tipos de requisitos não funcionais comumente esquecidos e exemplos de escrita mensuráveis.
Gênero
má expressão
expressão mensurável
Desempenho
"Deve ser rápido"
"Resposta da consulta < 2 segundos com carga média"
acessibilidade
"Todos deveriam poder usá-lo"
"Compatível com WCAG 2.1 AA; navegação completa pelo teclado"
Segurança
"Deve ser seguro"
"Os dados pessoais são criptografados em repouso; o acesso é baseado em funções"
disponibilidade
"Deve ser fácil"
"Novo usuário conclui o pedido em 3 etapas sem treinamento"
Disponibilidade/continuidade
"Não deveria travar"
"Tempo de atividade mensal ≥ 99,5%"
Três minicasos: em números
Caso 1 — O preço de uma necessidade incomensurável. A tela, que foi desenvolvida em um banco com a exigência de que “a tela do relatório abra rapidamente”, abriu em 22 segundos sob carga de campo. O desenvolvedor pensou que estava fornecendo a palavra "rápido" em seu ambiente (2 segundos). Se o requisito tivesse sido escrito como "<3 segundos no horário de pico, taxa de transferência real", o problema teria sido detectado nos testes. A remodelação custou 3 semanas e um custo adicional mensurável.
Caso 2 — Lacuna capturada pelos critérios de aceitação. Ao escrever os critérios de aceitação para a história “o sistema aplica desconto” em um projeto de comércio eletrônico, a parte interessada percebeu que o que aconteceria se o desconto entrasse em conflito com o cupom e o desconto VIP não fosse discutido. Uma única pergunta Dado/Quando/Então evitou o erro de desconto duplo antes da entrada em operação; Este erro causou graves perdas de receitas em projetos semelhantes.
Caso 3 – Regra feita por IA. Em um projeto de RH, a AI adicionou a frase “o pedido de licença é aprovado automaticamente dentro de 24 horas” ao rascunho de requisitos. Nenhuma aprovação automática foi discutida na reunião; O modelo criou uma regra que parecia “razoável”. Ao lado de cada requisito, o especialista escreve “fonte: qual entrevista/documento?” Ao adicionar a coluna, ele removeu 4 frases sem fonte.
Alerta Fraco/Prompt Forte
Alerta fraco:
Escreva histórias de usuários para este projeto.
Alerta poderoso:
Sua função: Você é um analista de negócios MIS. Extraia histórias de usuários da nota de entrevista abaixo. Regras: - Formato: “Como [função], para [propósito], eu quero [recurso].” - Escreva PELO MENOS 2 critérios de aceitação para cada história no formato Dado/Quando/Então. - Adicione uma coluna “Fonte” ao lado de cada história: de qual frase ela veio? adequação.- Escreva requisitos não funcionais mensuráveis (desempenho, segurança, acessibilidade) em uma seção separada. Nota da entrevista:[texto]
O prompt poderoso reforça o formato da história, os critérios de aceitação, a rastreabilidade da fonte e os requisitos não funcionais, tudo de uma vez; Isso torna mais fácil controlar a saída.
Quatro modelos copiáveis
1) Esclarecimento de requisitos:
Revise o requisito abaixo. Marque cada afirmação que seja vaga, incomensurável ou aberta a mais de uma interpretação e escreva uma pergunta esclarecedora para cada uma. Não invente a resposta. Requisito: [texto]
2) Varredura de contradição:
Na lista de requisitos abaixo, encontre itens que se contradizem, sejam repetitivos ou deixem lacunas lógicas. Relate cada descoberta com números de item e uma justificativa de uma frase. Lista: [texto]
3) Gerando critérios de aceitação:
Escreva pelo menos 4 critérios de aceitação para a seguinte história de usuário no formato Dado/Quando/Então, incluindo casos de limite e exceção. Liste também quaisquer pontos que ainda não estejam claros. História: [texto]
4) Esboço do escopo:
Elabore os itens "Dentro do escopo" e "Fora do escopo" como uma tabela de duas colunas de acordo com os seguintes requisitos. Etiqueta [CONFIRMAÇÃO NECESSÁRIA] para qualquer item sobre o qual você não tem certeza. Requisitos: [texto]
Erros comuns
- Pensar que a solução é uma necessidade. "Adicionar um menu suspenso" é uma solução, não um requisito. O requisito diz que “o usuário deve poder selecionar o país na lista definida”; A equipe de TI projeta a solução.
- Ignorando os não funcionais. Simplesmente anotar “o que fazer” e esquecer “como ser” (velocidade, segurança, acessibilidade) é a brecha mais comum e mais cara.
- Usando adjetivos incomensuráveis. Palavras como “rápido, fácil, seguro e fácil de usar” são inválidas sem limite.
- Não percebendo a regra que a IA inventou. O modelo pode adicionar regras “razoáveis”, mas não realmente faladas; Peça recursos para cada necessidade.
- Deixando a priorização para a IA. O que fazer primeiro é uma decisão de valor comercial; A unidade de negócios dá isso.
Cuidado: A frase mais perigosa na análise de requisitos é “todo mundo já sabe disso”. Suposições tácitas não fazem parte da documentação, nunca fazem parte do código e emergem em campo. Pergunte à IA “o que é assumido, mas não está escrito neste requisito?” torna visíveis essas suposições ocultas.
Resumindo
A análise de requisitos define o que o sistema deve fazer de forma clara, mensurável e rastreável. Os requisitos funcionais descrevem o trabalho, os requisitos não funcionais descrevem as qualidades e estes últimos são frequentemente esquecidos. A história do usuário e os critérios de aceitação Dado/Quando/Então são ferramentas poderosas que eliminam a incerteza. A inteligência artificial acelera significativamente a produção de storyboards, critérios de aceitação, detecção de conflitos e esclarecimento de dúvidas; Porém, a correção da regra de negócio, o escopo e a decisão prioritária e a origem de cada frase são de responsabilidade do ser humano. Não finalize nenhum requisito que não tenha fontes e seja imensurável.
Tarefa de aplicativo
Escreva uma solicitação comercial de um parágrafo para um “sistema de agendamento on-line” imaginário (por exemplo, “Os clientes devem poder marcar compromissos on-line, a equipe deve poder ver os calendários”). (1) Crie pelo menos 5 histórias de usuários e 2 critérios de aceitação para cada uma com uma forte solicitação desta solicitação. (2) Encontre pelo menos 2 lacunas ocultas nos critérios produzidos pelo modelo (por exemplo, nomeação dupla ao mesmo tempo, regra de cancelamento). (3) Incluir pelo menos 3 requisitos não funcionais de forma mensurável. (4) Identifique pelo menos 3 itens como “Fora do Escopo”. (5) Marque uma regra que o modelo possa ter inventado e escreva como você a confirmaria.
lista de verificação
- [] Escrevi requisitos funcionais e não funcionais separadamente.
- [ ] Cada requisito é claro, mensurável e testável.
- [ ] Cada história tem critérios de aceitação Dado/Quando/Então.
- [ ] Posso rastrear a origem (conversa/documento) de cada requisito.
- [ ] Marquei as possíveis regras que a IA havia inventado e deixei para confirmação.
- [ ] Fiz a priorização junto com a unidade de negócio.