Specifications and acceptance criteria C1

Nível: C1

Objetivo

Escrever specifications e acceptance criteria C1 com edge cases, error states, accessibility, analytics, privacy e operational requirements. O foco é especificação que sobrevive à ambiguidade e o que pode ser medido em produção.

Explicação

Specifications e acceptance criteria em C1 não são 'lista de requisitos'; são contratos que sobrevivem à ambiguidade. Seis eixos:

1. Edge cases

Comportamento em limites. C1 cita: 'what happens when the cart is empty? when the user has 0 items? when the input is null?'. Edge cases em C1 são listados explicitamente, não 'deixados para o developer descobrir'.

2. Error states

Comportamento quando algo dá errado. C1 cita: 'what is the user-facing message? what is the log? what is the metric?'. Error states em C1 cobrem o happy path E o failure path.

3. Accessibility

A11y não é opcional. C1 cita: 'WCAG 2.1 AA compliance: keyboard navigation, screen reader, color contrast 4.5:1'. Accessibility em C1 é acceptance criterion, não 'nice to have'.

4. Analytics

O que precisa ser medido. C1 cita: 'events: checkout_started, checkout_completed, checkout_failed; properties: cart_value, payment_method'. Analytics em C1 define o que o produto vai medir.

5. Privacy

O que não pode ser coletado. C1 cita: 'PII fields are hashed; logs do not include user_email; GDPR right-to-erasure is supported'. Privacy em C1 é acceptance criterion, não 'compliance afterthought'.

6. Operational requirements

Como o time opera o sistema. C1 cita: 'the alert fires at error rate > 1% for 5 minutes; the on-call rotation is Berlin/São Paulo; the runbook is in the wiki'. Operational em C1 é parte do spec, não 'depois a gente opera'.

Exemplos

Erros comuns

• Spec sem edge cases: 'o sistema faz X' é genérico; 'o sistema faz X com carrinho vazio, com 0 itens, com entrada nula' é spec.
• Error states vagos: 'mostra erro' é genérico; 'mostra mensagem Y, loga erro Z, dispara alerta A' é spec.
• A11y afterthought: 'vamos fazer a11y depois' é tarde; C1 inclui WCAG desde o spec.
• Analytics sem definição: 'vamos medir conversão' é genérico; 'event checkout_completed com cart_value e payment_method' é spec.
• Privacy como afterthought: 'vamos cuidar de GDPR depois' é multa esperando; C1 inclui privacy no spec.
• Ops como afterthought: 'o time opera' é genérico; 'alert em error rate > 1% por 5 min' é spec.

Prática guiada

Reescreva cada spec abaixo no padrão C1.

1. Edge cases: liste o que acontece em cada limite (vazio, null, 0, max).
2. Error states: cite mensagem, log, métrica.
3. A11y: cite WCAG 2.1 AA com critérios mensuráveis.
4. Analytics: cite evento e propriedades.
5. Privacy: cite regras de PII, logs, GDPR.
6. Ops: cite alerta, on-call, runbook.

Resumo

Spec C1 tem seis eixos: edge cases (limites), error states (mensagem + log + métrica), accessibility (WCAG 2.1 AA), analytics (eventos + propriedades), privacy (PII + GDPR), operational (alert + on-call + runbook). Spec sem esses eixos é genérico; com eles, é contrato que sobrevive à ambiguidade.

História: Specifications and acceptance criteria C1

Nível: C1

História em inglês

Writing the spec for the new checkout feature

On Thursday, I had to write the spec for the new checkout feature. I opened with edge cases: what happens when the cart is empty? when the user has 0 items? when the input is null? I added error states: for each failure, what is the user-facing message, the log, and the metric? I included a11y: WCAG 2.1 AA compliance, with keyboard navigation, screen reader, and color contrast 4.5:1. I added analytics: events checkout_started, checkout_completed, checkout_failed; properties cart_value and payment_method. I closed with operational requirements: alert at error rate > 1% for 5 minutes; on-call rotation split between Berlin and São Paulo.

Tradução linha por linha

Notas de vocabulário

• what happens when the cart is empty, 0 items, input is null = Edge cases: limites explícitos.
• user-facing message, log, metric = Error states: comportamento completo.
• WCAG 2.1 AA: keyboard, screen reader, contrast 4.5:1 = A11y: standard mensurável.
• events checkout_started, checkout_completed; properties cart_value, payment_method = Analytics: evento + propriedades.
• alert at error rate > 1% for 5 minutes; on-call rotation = Ops: alerta + on-call.

Perguntas de compreensão

1. O que diferencia spec C1 de 'lista de requisitos'?
2. Por que a11y é acceptance criterion em C1?
3. Por que privacy no spec?

Prática com a história

1. Escreva três edge cases C1 para o checkout.
2. Escreva um acceptance criterion C1 para a11y.
3. Escreva um error state C1 completo para falha de pagamento.