tags: - Engenharia de Software - Roteiro de entrevista fontes: - arquivo: requisitos-de-software-teorias-e-tecnicas-para-o-desenvolvimento-de-aplicacoes-de-qualidade.pdf autor: Thiago Leite e Carvalho editora: Casa do Código / Alura capitulos: "Cap. 4 completo (o que são requisitos de software, tipos de requisitos, principais artefatos de requisitos), 5 completo (as 5 fases da Engenharia de Requisitos, os 3 Ws, Product Discovery), 7 completo (Estudo de Viabilidade: OTCE, PIECES, análise de custo-benefício com Payback/NPV/ROI, técnicas de Design Thinking — Briefing/Imersão/Ideação), 8 completo (desafios da elicitação, Personas, Entrevistas e Questionários, Jornada do Usuário, Prototipação, Etnografia, Job to Be Done, Brainstorming, Lean Inception), 9 completo (Item de Backlog, especificação de CDU/HU/RN/CA/RNF, Gherkin, catálogo de RNFs), 10 completo (validação de requisitos: perspectivas conteúdo/estrutura, checklist de 14 pontos; priorização: princípios, critérios, MoSCoW, Timeboxing, Matriz Esforço x Valor, RICE), 11 completo (gerenciamento de requisitos: os quatro pilares — controle de versão, controle de mudanças, acompanhamento de status, rastreabilidade —, rastreabilidade horizontal x vertical, Matriz de Rastreabilidade em detalhe), 12 completo (IA na Engenharia de Requisitos: papel de auxiliar analítico por fase, panorama de categorias de ferramentas — sem reprodução dos prompts de exemplo do livro), Apêndice VII completo (Canvas MVP, Matriz CSD, Design Sprint, Crazy8s — técnicas reutilizáveis extraídas sem os exemplos aplicados do "Let's Fun")"

Requisitos¶

O que são requisitos de software¶

Definição: Requisito

No dicionário, uma condição ou exigência imprescindível a que se deve satisfazer para alcançar determinado fim. Trazido para o desenvolvimento de software: as descrições de como um software deve funcionar, assim como as definições de restrições sob as quais esse funcionamento deve operar. Descrever completamente um software exige sempre um conjunto de requisitos, não um documento único — diferentes tipos de requisito oferecem visões distintas para diferentes stakeholders.

Os tipos de requisitos¶

Existem dois eixos de classificação: requisito de usuário x requisito de software, e — dentro dos requisitos de software — funcional x não funcional.

Definição: Requisito de usuário (RU) x Requisito de software (RS)

RU são documentos que descrevem o software numa linguagem natural e de alto nível — textos e imagens que ajudam o solicitante a compreender o software como um todo (serviços, funcionalidades, integrações), sem necessariamente entrar em detalhe técnico. RS descrevem o comportamento esperado do software de maneira formal e detalhada — mesmo tipo de funcionalidade descrita, mas explicando minuciosamente como o software se comporta, para que a equipe de desenvolvimento saiba com precisão o que implementar.

Definição: Requisito Funcional (RF) x Requisito Não Funcional (RNF)

RF descrevem os serviços que o software deve fornecer — o que ele deve (ou não deve) fazer a partir de entradas/situações específicas, e os resultados esperados. RNF descrevem restrições sobre como essas funcionalidades devem operar — limitações de tempo, do processo de desenvolvimento, ou restrições externas ao software ou à empresa que o desenvolve. Um RNF, muitas vezes, se aplica ao software como um todo, não a uma funcionalidade específica.

flowchart TD
    RNF["Requisitos não<br/>funcionais"] --> RP["Requisitos<br/>de produto"]
    RNF --> RO["Requisitos<br/>organizacionais"]
    RNF --> RE["Requisitos<br/>externos"]
    RP --> Usabilidade
    RP --> Eficiencia["Eficiência"]
    RP --> Confiabilidade
    Eficiencia --> Performance
    Eficiencia --> Recursos
    Confiabilidade --> Seguranca["Segurança"]
    Confiabilidade --> Ambiente
    RO --> Regulatorio["Regulatório"]
    RO --> Operacional
    RO --> Desenvolvimento
    RE --> Etico["Ético"]
    Etico --> Legislativo
    Legislativo --> Contabil["Contábil"]
    Legislativo --> SegurancaProtecao["Segurança/Proteção"]

Requisitos de produto — restrições de uso e comportamento (o software é fácil de usar e acessível; é eficiente em tempo de resposta e consumo de recursos; é confiável — usa HTTPS/componentes de rede seguros; é seguro — dados sensíveis não "vazam").
Requisitos organizacionais — restrições de políticas e procedimentos da empresa solicitante e da equipe de desenvolvimento (a equipe usa uma linguagem específica; a empresa usa um provedor de nuvem específico; o time deseja usar Scrumban).
Requisitos externos — fatores não inerentes ao software e ao seu processo de desenvolvimento, mas que o afetam diretamente (seguir regras de um Conselho Regional; não violar regras contábeis, de segurança ou proteção de dados).

Os principais artefatos de requisitos¶

Definição: Artefato de requisito

Um documento (ou outro insumo — mesmo um e-mail, se registrado e adaptado às definições de RU/RS, conta) que representa um requisito específico, com função, visão e formato próprios. Nem todo artefato precisa ser usado em todo projeto — cabe a cada empresa/equipe escolher os que condizem com sua realidade.

Definição: Documento de Visão (DV)

Artefato do tipo requisito de usuário. Descreve ao solicitante o que é e o que for necessário para que quem solicita o software tenha uma visão completa (embora não detalhada) do que, de fato, é o software e do que está sendo solicitado — necessidades em alto nível e as funcionalidades para saná-las, as integrações que o software pode possuir, quem irá utilizá-lo. Ajuda o solicitante a validar se o que será (ou foi) desenvolvido atende às suas necessidades.

Definição: Roadmap

Pode ser entendido tanto como RU quanto como RS. Como RU, provê uma visão ampla das necessidades a serem atendidas ao longo de um período (geralmente 1 ano, mas configurável). Como RS, oferece uma visão de curto prazo (semanas), detalhando as funcionalidades que o software deverá ter durante um ciclo de desenvolvimento. Fortemente ligado à Gestão de Produtos Digitais, e atualizado constantemente conforme as necessidades mudam.

Definição: Glossário (artefato de requisito)

Pode ser RU ou RS. Provê o significado de termos, siglas, conceitos, entre outros, inerentes ao software em desenvolvimento — ajuda tanto o solicitante quanto a equipe a melhorar o entendimento do negócio ou da necessidade que o software está automatizando.

Definição: Caso de Uso (CDU) x História de Usuário (HU)

Ambos são, conceitualmente, do tipo requisito de software (mas, por serem também usados pelo solicitante, podem ser considerados requisito de usuário). Descrevem detalhadamente como uma funcionalidade deve se comportar e, consequentemente, ser codificada — usados pela equipe de desenvolvimento, em especial por quem codifica ou testa. CDU é o artefato mais antigo, surgido pouco depois da criação da Engenharia de Requisitos; escreve o comportamento numa linguagem mais formal, em tópicos ou passo a passo. HU é mais nova, criada junto das Metodologias Ágeis; tem a mesma função e não é nem melhor nem pior que o CDU — a diferença está só na forma de escrita. Qualquer um dos dois pode, inclusive, ser criado depois da codificação.

Definição: Regra de Negócio (RN)

Artefato do tipo requisito de software, sempre vinculado a pelo menos um CDU ou HU (por isso também pode ser tratado como requisito de usuário). Descreve, em texto livre, regras específicas que se aplicam aos tópicos ou passo a passo de um CDU/HU — validações de dados de entrada, cálculos matemáticos, descrições de como determinados dados devem ser salvos. É complementar ao CDU/HU: descrevê-las direto nos tópicos do artefato principal tornaria a leitura difícil, dada sua forma mais estruturada.

Definição: Critério de Aceitação (CA)

Artefato do tipo requisito de software, utilizado para validar se uma HU foi codificada de forma que a funcionalidade produza os resultados esperados — por se relacionar com HUs, também pode ser considerado requisito de usuário. Pode assumir duas formas: um texto livre para quem vai testar seguir o passo a passo de verificação, ou um artefato de BDD (Behavior Driven Development — técnica de teste com um padrão de escrita, como o Gherkin, para que o componente de testes consiga interpretar os dados de entrada e executar o teste automaticamente). Em ambos os casos, o CA é usado para testes manuais ou automatizados.

Definição: Requisito Não Funcional (RNF, como artefato)

Artefato do tipo requisito de software, também sempre relacionado a um CDU ou HU (e, por isso, também considerado requisito de usuário). Reúne todos os RNFs que se aplicam ao software, descrevendo-os com valores ou descrições detalhadas, para que seja possível identificar claramente as restrições de funcionamento.

Definição: Documento de Integração (DI)

Artefato do tipo requisito de software. Detalha como o software se relaciona com outros softwares — as formas de integração (API SOAP, API REST, ou mais baixo nível, como sockets), os parâmetros de entrada com tipos e valores permitidos, e os valores retornados com tipos e valores esperados. Usado tanto pela equipe que constrói o software consumidor quanto pela equipe que fornece o serviço, já que o detalhamento serve a quem quer que vá consumir o serviço descrito.

Definição: Matriz de Rastreabilidade (MR)

Artefato do tipo requisito de software, responsável por mapear os relacionamentos entre as necessidades dos solicitantes e os CDUs/HUs que as atendem — e também as relações entre CDUs e HUs entre si. Isso ajuda a identificar quais modificações em determinadas funcionalidades podem afetar outras, mitigando erros comportamentais após alterações (corretivas ou evolutivas). Estruturalmente, é uma tabela com linhas e colunas onde estão dispostas as necessidades, CDUs ou HUs relacionados entre si por meio dos cruzamentos desejados.

Definição: Nem todo artefato precisa ser usado — e mantê-los é trabalho contínuo

Dada a grande quantidade de artefatos possíveis, cada empresa/projeto deve empregar apenas os que condizem com sua realidade — usar todos, sem necessidade, tende a sobrecarregar o processo em vez de ajudar. Além disso, manter os requisitos de um software atualizados é uma tarefa tão complexa e trabalhosa quanto concebê-los pela primeira vez: modelos de banco de dados e a maioria dos diagramas de UML (ver Diagramas e UML) costumam ser criados durante a codificação; os demais artefatos podem ser desenvolvidos ainda na fase de requisitos, desde que adaptados às definições de RU/RS.

As cinco fases da Engenharia de Requisitos¶

Definição: Engenharia de Requisitos (ER)

A subárea da Engenharia de Software responsável por definir um processo para a obtenção, entendimento, escrita, validação e manutenção dos requisitos de um software — a etapa de Especificação do Processo de Software (ver Engenharia de Software), tratada com o mesmo rigor dado ao restante do desenvolvimento.

flowchart TD
    A["Necessidades<br/>(domínio do solicitante)"] --> B["Funcionalidades"]
    B --> C["Requisitos de software<br/>(domínio do software)"]

Uma única necessidade tende a se desdobrar em várias funcionalidades que, por sua vez, geram múltiplos requisitos que precisam ser documentados — sem um processo bem estruturado, fica fácil perder esse rastro e comprometer a qualidade do software.

Definição: Os 3 Ws da Engenharia de Requisitos

A ER oferece um processo para responder a três perguntas centrais. Why (por quê) — identifica a motivação para criar o software: já existe algo parecido? A solução proposta resolve o problema? A tecnologia atual permite construí-la? Também avalia conflitos de visão entre stakeholders. What (o quê) — refere-se às funcionalidades e serviços que o software deve oferecer para atender às necessidades, considerando desempenho, segurança e usabilidade; a partir dessa definição, os principais artefatos de requisitos são criados. Who (quem) — identifica quem utilizará o software (pessoas, outros softwares, hardwares), delimitando o que faz parte do escopo e o que só precisa ser integrado.

flowchart LR
    EV["Estudo de<br/>viabilidade"] --> ER["Elicitação e análise<br/>de requisitos"]
    ER --> ESP["Especificação<br/>de requisitos"]
    ESP --> VP["Validação/Priorização<br/>de requisitos"]
    EV -.-> RV["Relatório de<br/>viabilidade"]
    ER -.-> MS["Modelos<br/>de sistema"]
    ESP -.-> DR["Requisitos de usuário<br/>+ requisitos de sistema"]
    VP -.-> DOC["Documento<br/>de requisito"]
    DOC --> GR["Gerenciamento<br/>de requisitos"]

Não existe correspondência direta entre cada fase e cada um dos 3 Ws — na prática, eles se misturam ao longo das cinco fases.

Definição: 1. Estudo de viabilidade

Define se o software deve ou não ser construído, respondendo perguntas como: o software ajudará o solicitante a atingir seus objetivos corporativos? Pode ser concebido com as tecnologias disponíveis, dentro dos prazos e custos desejados? Poderá se integrar a outros softwares/hardwares existentes? Como a empresa se comportaria caso o software não fosse construído? É intimamente ligada ao modelo de negócio do solicitante, e vital para definir se a ER deve prosseguir ou não.

Definição: 2. Elicitação de Requisitos

Inicia o processo de entendimento de como o software deve ser: qual o domínio/ contexto onde ele está inserido, quem serão os usuários, quais entidades ele deverá processar, o que deve ser feito para sanar as necessidades, qual o desempenho esperado e quais restrições de funcionamento devem ser consideradas. Falhas na coleta e no entendimento das informações nesta fase resultam em interpretações equivocadas que levam a implementações incorretas e defeitos no uso do software — é a etapa em que mais surgem os erros relacionados a comportamentos inesperados detectados só posteriormente pelos usuários. Gera, ao final, os Modelos de Sistema, artefatos-ponte entre a Elicitação e a Especificação.

Definição: 3. Especificação de Requisitos

Cria os artefatos de requisitos necessários para descrever o software, a partir do entendimento já estabelecido na Elicitação — não são criados todos de uma vez, mas sob demanda ao longo do desenvolvimento (diferente da Elicitação, normalmente conduzida de forma concentrada). Independente da forma e do momento, o objetivo é sempre: descrever os comportamentos internos e as restrições do software, descrever as comunicações que ele realiza, e prover uma visão dele ao solicitante.

Definição: 4. Validação e Priorização de Requisitos

Tenta mitigar, antes da implementação, os problemas que a Elicitação e a Especificação — as duas fases que mais podem gerar problemas — deixaram passar, respondendo à pergunta "o software certo está sendo construído?". Necessário porque cada pessoa tem formas diferentes de pensar, entender e se expressar — não é falha da equipe nem do solicitante, é característica inerente à natureza humana. Em projetos com Metodologias Ágeis, essa fase tende a se resumir à especificação e validação do que já foi codificado, já que essas metodologias preconizam postergar a especificação para depois da codificação, evitando retrabalho.

Definição: 5. Gerenciamento de Requisitos

Realiza e organiza as mudanças nos requisitos, motivadas por dois fatores: o software está em constante evolução (o tempo de uso de um software é muito mais longo que o de concepção, e novas necessidades surgem por demanda do solicitante ou por fatores externos, como mudanças regulatórias); e o software pode se comportar de forma não esperada após a implantação (erros que só aparecem depois de uma etapa de validação, muitas vezes porque o próprio solicitante ainda não tinha um entendimento consolidado de suas necessidades). Exige um processo de rastreamento para identificar os pontos impactados pelas mudanças.

Product Discovery: a nova roupagem da Engenharia de Requisitos¶

Definição: Product Discovery (PD)

As primeiras versões da ER se apoiavam na premissa de que os requisitos eram estáveis e completamente compreendidos desde o início pelos stakeholders — ideia que se revelou equivocada com o surgimento das Metodologias Ágeis, que reconhecem o desenvolvimento de software como um processo intrinsecamente incerto. O Product Discovery surgiu como uma alternativa mais moderna, complemento essencial à entrega ágil (Delivery): um processo iterativo e colaborativo que tem como premissa identificar e validar rapidamente as necessidades reais dos usuários, bem como as soluções mais adequadas para atendê-las — estabelecendo um ciclo contínuo de descobrir antes de construir. Utiliza técnicas oriundas do UX (User Experience) e do DT (Design Thinking), como pesquisas, testes de usabilidade, prototipagem, jornadas de usuário e ideação.

Definição: Product Discovery x Engenharia de Requisitos

O PD não veio para substituir a ER, mas para complementá-la — os principais diferenciais estão na natureza iterativa e exploratória: enquanto a ER busca a completude e estabilidade dos requisitos, o PD aceita a incerteza e promove a experimentação, priorizando aprendizagem rápida e capacidade de adaptação em vez de uma lista exaustiva de funcionalidades logo de início. O PD também é mais multidisciplinar (designers, desenvolvedores, product managers, áreas do solicitante) e se concentra fortemente nas duas fases iniciais da ER: o estudo de viabilidade e a elicitação. A ER se alinha melhor a projetos com escopo mais controlado e baixa variabilidade; o PD se destaca em cenários dinâmicos, nos quais compreender o usuário e se adaptar rapidamente a mudanças é crucial para o sucesso do software.

Estudo de viabilidade¶

Nem sempre a convicção de que um software é necessário significa que sua concepção realmente trará ganhos — é preciso avaliar uma série de fatores antes de decidir construir (ou não). Essa avaliação se organiza em quatro óticas, conhecidas pelo acrônimo OTCE.

Definição: OTCE — as quatro óticas da viabilidade

Operacional — avalia o quão benéfico o software será para o solicitante: até que ponto ele se adequará às necessidades reais, e se os futuros usuários (incluindo os "altos escalões") apoiam sua concepção. Recorre à técnica PIECES (Performance, Informação, Economia, Controle, Eficiência, Serviço) para estruturar essa avaliação. Técnica — avalia se a tecnologia proposta é viável, se o solicitante já a possui (ou precisa adquiri-la) e se a equipe tem o conhecimento técnico necessário — tecnologias maduras oferecem melhor suporte; tecnologias incipientes, maior potencial de crescimento. Cronológica — avalia se o prazo para a concepção é desejável ou obrigatório; prazos obrigatórios (por exigência legal, por exemplo) exigem mais certeza de que a solução escolhida é a melhor opção. Econômica — avalia se o custo para conceber o software valerá a pena, por meio de uma análise de custo-benefício.

Definição: \"É preferível entregar um software funcionando com atraso do que um software com erros no prazo certo\"

Duas máximas resumem bem a tensão entre a viabilidade cronológica e as demais: não cumprir o cronograma é ruim, mas entregar um software inadequado é pior.

Análise de custo-benefício¶

Definição: Custos x Benefícios

Custos são os recursos despendidos para conceber o software — de desenvolvimento (pessoal, treinamento, equipamentos, só durante a construção) ou operacionais (energia, propaganda, suporte, durante toda a vida útil do software) — subdivididos ainda em fixos (previsíveis, ex.: salários) e variáveis (imprevisíveis, ex.: pico de infraestrutura). Benefícios são os ganhos — tangíveis (quantificáveis: redução de gastos, aumento de vendas) ou intangíveis (não quantificáveis com precisão: satisfação do cliente, confiança da equipe). Se os benefícios não puderem ser quantificados, a análise de custo-benefício fica comprometida, o que impacta diretamente a tomada de decisão.

Definição: Três técnicas de análise de custo-benefício (não excludentes entre si)

Payback Analysis (Análise do retorno financeiro) — calcula quando os benefícios superam os custos, usando o Valor Presente (VP) de cada ano projetado: VP = 1 / (1 + taxa de desconto)ⁿ, onde n é o número de anos.
NPV (Net Present Value, Valor Atual Líquido) — subtrai os custos atualizados dos benefícios também atualizados; resultado positivo indica que a concepção vale a pena. Mais útil que o Payback quando há mais de uma alternativa para comparar.
ROI (Return on Investment, Retorno sobre o investimento) — compara os benefícios obtidos com os gastos realizados: \(ROI = \dfrac{\text{Benefícios totais} - \text{Custos totais}}{\text{Custos totais}}\). Também usado para comparar alternativas entre si.

Técnicas de Design Thinking aplicadas à viabilidade¶

Para reunir informações de várias óticas ao mesmo tempo, sem depender de um único levantamento superficial, três técnicas de Design Thinking (DT) ajudam a estruturar o estudo de viabilidade — cada uma alinhada a óticas específicas do OTCE.

Técnica	Ponto-chave	Contribuição para o Estudo de Viabilidade	Óticas
Briefing	O que queremos resolver e por quê?	Define limites econômicos e operacionais iniciais	Operacional, Econômica
Imersão	O que é verdade sobre o problema e o contexto?	Valida hipóteses com dados reais e identifica claramente o que o software deve ser	Técnica, Operacional
Ideação	Como podemos resolver isso da melhor forma possível?	Gera soluções realistas e prioriza as que melhor equilibram custo, risco e impacto	Técnica, Econômica, Cronológica

Definição: Briefing

Objetiva obter um entendimento inicial, alinhando expectativas e definindo o "problema" a ser resolvido — o propósito do software, o contexto de uso/concepção e as expectativas relativas a ele. Requer a participação de todos os stakeholders, respondendo: o que estamos tentando resolver? Quem será impactado? Quais as metas de sucesso e restrições conhecidas? Quais premissas estamos assumindo sobre mercado e tecnologia?

Definição: Imersão

Promove um aprofundamento da visão geral obtida no briefing, focando tanto na perspectiva dos usuários do futuro software quanto no negócio que ele visa otimizar ou automatizar — a meta é validar ou refutar as definições obtidas no briefing, transformando insights iniciais em dados concretos, para que o estudo se apoie em fatos, não em suposições.

Definição: Ideação

Materializa tudo o que foi identificado como viável e vantajoso na imersão — gera várias alternativas de solução (arquiteturas, tecnologias, funcionalidades), avaliando impactos de custo, benefício, prazo e negócio para cada uma. Produz, como principais resultados, esboços de arquitetura, protótipos de baixa fidelidade e cronogramas.

Definição: Um estudo de viabilidade deve ser rápido

Apesar de envolver diversas atividades e stakeholders de áreas diferentes, o estudo de viabilidade deve ser rápido — via de regra, não deve ultrapassar uma semana (cinco dias úteis). Em startups, isso é ainda mais crítico: a volatilidade de ideias e desafios é muito grande, e um estudo demorado corre o risco de já estar desatualizado quando terminar.

Definição: Artefatos gerados pelo Estudo de Viabilidade

Ao final dessa fase, os principais artefatos que podem ser gerados são o Relatório de Viabilidade (reunindo os achados de cada ótica avaliada), o Documento de Visão, o Roadmap e um Glossário inicial.

Elicitação de Requisitos¶

Definição: As três fontes principais de insumos

Para reunir os dados e conhecimentos essenciais à concepção de um software, a equipe de desenvolvimento recorre a três fontes: Stakeholders (todas as pessoas envolvidas — solicitantes e equipe de desenvolvimento —, cada uma questionada de forma adequada ao seu papel), Documentos (dados e informações já existentes sobre o processo a automatizar, incluindo leis e regulamentações do nicho de negócio) e Software legado (se já existir um sistema em uso ou sendo migrado, ele e sua documentação revelam o que já funciona e o que motivou a criação do novo software).

Definição: Desafios comuns da elicitação

Stakeholders muitas vezes têm uma visão turva do que o software deve ser, ou usam termos técnicos da própria área que dificultam a comunicação; diferentes stakeholders podem ter demandas conflitantes entre si; documentos preexistentes podem estar desatualizados; e o próprio processo de concepção é dinâmico — prioridades mudam e novas demandas surgem durante a construção. Superar todos esses desafios por completo é praticamente impossível; o objetivo realista é minimizá-los a ponto de não comprometerem o projeto como um todo.

Personas¶

Definição: Persona

Técnica criada por Alan Cooper (livro About Face, década de 1980), popularizada mais recentemente pelo uso amplo do UX: um personagem fictício que representa um grupo de usuários reais, usado para identificar padrões de comportamentos e necessidades. Embora fictícia, uma persona não deve ser inventada — precisa representar, de fato, pessoas que vão interagir ou ser impactadas pelo software, direta ou indiretamente.

O processo de identificação costuma ser lúdico e participativo, usando um template de quatro quadrantes: Nome e desenho, Perfil (idade, profissão, características), Comportamento (hábitos pessoais e profissionais) e Necessidades (o que a persona espera do software).

Definição: Principais vantagens de usar Personas

Solidifica o reconhecimento sobre os usuários e como interagem com o software; facilita a identificação de perfis específicos (incluindo questões de acessibilidade); cria empatia com os stakeholders durante a elicitação; ajuda a entender o valor que a solução agregará ao usuário; evita gasto de recursos (financeiros e temporais) com demandas irreais; e facilita a definição do perfil para realização de outras pesquisas.

Entrevistas e Questionários¶

Definição: Entrevista x Questionário

Ambas podem ser pré-definidas (fechadas/formais/estruturadas — um roteiro fixo de perguntas) ou abertas (informais/não estruturadas — sem roteiro fixo, deixando a conversa fluir livremente). Entrevistas tendem a ser mais longas (a interação natural costuma ser mais prolixa) e geram mais engajamento e proximidade entre equipe e solicitante — mas são obrigatoriamente síncronas (presenciais ou remotas), mais difíceis de agendar. Questionários são mais ágeis e assíncronos, aplicáveis rapidamente a mais pessoas, mas a interação mais sucinta pode prejudicar a profundidade e a qualidade das informações obtidas.

Definição: Cuidados ao aplicar qualquer uma das duas técnicas

Escolher stakeholders que representem uma amostra relevante (porém não excessiva) de pessoas afetadas direta ou indiretamente pelo software — essa diversidade é fundamental para captar diferentes visões e necessidades complementares; e produzir um documento que mapeie e organize as informações obtidas, para que sirvam como insumo real ao software solicitado. Nenhuma das duas técnicas deveria ser escolhida de forma exclusiva e rígida — usar entrevistas pré-definidas quando já há conhecimento prévio do que se deseja mapear (para refiná-lo) e questionários quantitativos para priorizar necessidades já mapeadas é uma combinação comum.

Jornada do Usuário (JU)¶

Definição: Jornada do Usuário (User Journey)

Processo no qual são analisados os comportamentos de uma persona ao realizar uma atividade para atingir um objetivo, contando essa trajetória de maneira detalhada — passos, emoções, expectativas, frustrações e pensamentos, projetando toda a interação da persona com o possível software. Nem sempre é necessário mapear a jornada completa; pode-se focar apenas num recorte específico que faça sentido para o contexto em avaliação. Ajuda a criar empatia com os futuros usuários, permitindo que a equipe de desenvolvimento entenda o software sob a ótica de quem o utilizará.

Definição: Mapa da Jornada do Usuário (MJU)

A representação gráfica da JU — relaciona, lado a lado, necessidades, atividades e emoções em contraste com anseios, contatos, interações e resultados, ao longo dos passos da jornada. Permite visualizar o que a persona deseja fazer e como ela age para atingir seus objetivos, mapeando emoções ao longo do caminho para detectar pontos-chave que devem ser resolvidos pelo software.

Definição: Vantagens e desvantagens da JU/MJU

Vantagens: foco no usuário (persona), não nas funcionalidades — busca entender como o software é usado, não só o quê ele faz; alinhamento entre equipes (UX, Devs, Marketing, solicitante), de forma lúdica e instigante; ajuda a visualizar a experiência completa da persona. Desvantagens: demora para mapear jornadas complexas, com muitos comportamentos e funcionalidades envolvidas; pode ser subjetiva, dependendo de como o mapeamento é realizado e das suposições feitas pela equipe.

Prototipação¶

Definição: Protótipo

A técnica mais visual entre as apresentadas — uma representação gráfica que corresponde a uma versão inicial e resumida de como o software deve ser. Muito utilizada quando as necessidades ou requisitos estão pouco claros e a descrição textual não consegue transmitir adequadamente os anseios dos solicitantes — permite validar e testar particularidades dos requisitos antes da construção efetiva do software.

Definição: Protótipo Descartável (throwaway) x Reutilizável (evolutionary)

Descartável visa sanar rapidamente entendimentos ainda incipientes ou obscuros — nível de fidelidade baixo ou médio, já que a intenção não é reaproveitar o trabalho, só esclarecer dúvidas. Reutilizável visa aprimorar/refinar conhecimentos já dominados — nível de fidelidade alto, pois a intenção principal é reaproveitar o trabalho, usando ferramentas/componentes que geram código de front-end compatível com várias plataformas (web e mobile).

Definição: Os três níveis de fidelidade

Baixa fidelidade (geralmente feita à mão) — ajuda a identificar o que deve estar disponível nas telas e onde as informações devem estar, definindo o fluxo sem navegação real. Média fidelidade (feita com ferramentas) — ajuda a identificar quais componentes serão usados e as relações entre informações, já com navegação real. Alta fidelidade (feita com ferramentas) — ajuda a identificar o acabamento visual, a experiência de usabilidade e questões de acessibilidade.

Ferramentas comuns por nível: baixa (papel e caneta, quadro branco, Marvel); média (Figma/FigJam, Miro, Pencil, PowerPoint); alta (Adobe XD, Figma, Sketch).

flowchart LR
    Criar --> Testar --> Aprender --> Revisar --> Criar

Definição: O ciclo de prototipação

Independentemente da fidelidade ou do tipo de protótipo, um ciclo deve ser realizado para que ele traga os benefícios esperados: Criar o protótipo para realizar a atividade desejada (obter ou validar informações); Testar em conjunto com usuários/solicitantes; Aprender com o resultado do teste; e Revisar o protótipo com base no aprendizado — reiniciando o ciclo quantas vezes forem necessárias.

Definição: Vantagens, desvantagens e limitações da prototipação

Vantagens: ajuda a responder se os usuários estão recebendo o que precisam, se o software será fácil de usar e se é viável de ser desenvolvido; alinha as equipes num entendimento comum; evita falhas de entendimento; diminui o gap entre a documentação e a equipe de desenvolvimento. Desvantagens: protótipos não relevantes podem acarretar perda de tempo e recursos; a construção pode atrasar outras atividades; o usuário pode se sentir insatisfeito após interagir com muitos protótipos, ou achar que o software final já está pronto. Limitação: por natureza, um protótipo não consegue abranger todos os aspectos do sistema — algumas funcionalidades deixarão de ser representadas, e não é possível avaliar requisitos não funcionais (desempenho, confiabilidade, tempo de resposta) por meio dele.

Etnografia¶

Definição: Etnografia

Técnica originária da Antropologia, usada para compreender comportamentos e práticas de indivíduos dentro de um grupo social por meio de observação direta e imersiva do modus operandi desse grupo — membros da equipe de desenvolvimento observam, durante alguns dias, como as pessoas atuam na execução de processos internos, mapeando comportamentos e identificando necessidades a automatizar. É especialmente útil para identificar requisitos que os solicitantes/usuários têm dificuldade de expressar sobre sua própria rotina — incluindo atividades inesperadas ou fora de contexto para solucionar situações atípicas, que dificilmente seriam detectadas por outras técnicas.

Definição: Observação Passiva x Ativa

Na observação passiva, o membro da equipe apenas observa atentamente tudo o que acontece, registrando anotações, fotos e vídeos. Na observação ativa, o membro se torna parte do grupo observado, vivenciando mais profundamente as necessidades do grupo.

Definição: Roteiro da etnografia

Planejamento (definir o que observar — tarefas, ambientes, usuários — e o problema a investigar) → Imersão no ambiente (passiva ou ativa) → Anotações (documentar fluxos de trabalho, interações, "gambiarras", com fotos/gravações se permitido) → Análise e interpretação (identificar padrões, limitações, anseios e tentar descobrir requisitos não explicitados) → Validação (compartilhar as conclusões para checar se fazem sentido e revelar novos requisitos/melhorias). Desvantagens: para obter conhecimentos sólidos, a observação pode durar longos períodos, sujeitos a interferências externas; e, por ser muito imersiva, pode inadvertidamente focar no "que é o problema" e não em "como solucioná-lo" — aumentando custos e prazos se mal conduzida.

Job to Be Done (JTBD)¶

Definição: Job to Be Done (JTBD)

Técnica criada por Clayton Christensen que foca em compreender o que realmente motiva uma pessoa a "contratar" um produto ou serviço para resolver um problema ou atingir um objetivo — o Job — em vez de focar apenas no resultado final em si. Resumida na frase clássica: "As pessoas não querem uma furadeira, elas querem um furo na parede." Não surgiu especificamente para software, mas pode ser aplicado trocando a pergunta "o que se deseja que o software tenha?" por "o que se deseja otimizar, automatizar ou resolver com o software?".

Definição: Os seis pontos do JTBD

Objetivo principal (core functional job-to-be-done) — o Job em si, o que se deseja alcançar. Resultados desejados (the desired outcomes tied to the core functional job-to-be-done) — os ganhos obtidos quando o Job é realizado com sucesso. Tarefas relacionadas (related jobs) — tarefas auxiliares que surgem durante o processo de concretização do Job. Fatores emocionais e sociais (emotional and social jobs) — emoções que ocorrem durante o processo ou que devem ser solucionadas para o Job ser atingido. Tarefas da cadeia de consumo (consumption chain jobs) — tarefas realizadas desde a descoberta da necessidade até seu atingimento e posterior cancelamento/desistência. Resultados financeiros desejados (the buyer's financial desired outcomes) — os ganhos financeiros esperados com o atingimento do Job.

Definição: Job Story (JS)

Uma frase que busca identificar as motivações que levam alguém a solicitar um software (ou produto), usada para chegar aos seis pontos do JTBD. Segue a estrutura: "Quando [situação], eu gosto de [motivo] de tal forma que [benefício]" — situação, motivo e benefício já direcionam a definição dos demais pontos.

Definição: Vantagens e desvantagens do JTBD

Vantagens: maior foco na real necessidade, identificando o motivo por trás da demanda (o "trabalho" que o solicitante realmente deseja realizar); evita viés de solução, focando no progresso desejado em vez de funcionalidades prematuras; pode complementar bem outras técnicas (entrevistas, personas, jornadas). Desvantagens: requer maturidade dos stakeholders, já que nem todos estão familiarizados com a técnica; exige eventos profundos e bem conduzidos, com habilidade para captar motivações e contextos; consome mais tempo e esforço que técnicas mais diretas (questionários, entrevistas).

Definição: JTBD x Jornada do Usuário — não são a mesma coisa

Ambas têm versões descritivas parecidas (a Job Story e a Journey), mas focam em coisas diferentes: JTBD evidencia as necessidades subjacentes — o "trabalho" que o usuário deseja realizar, numa perspectiva mais estratégica; JU concentra-se nas etapas e interações — o caminho da experiência que o usuário faz, numa perspectiva mais operacional/tática. É comum utilizar o JTBD previamente para compreender o contexto e, em seguida, aplicar a JU para projetar ou refinar a experiência.

Brainstorming¶

Definição: Brainstorming

Técnica criada em 1948 por Alex Osborn (publicitário americano, autor de Your Creative Power), não criada especificamente para a Elicitação de Requisitos, mas muito usada nela. Defende que ideias criativas, inovadoras e viáveis surgem mais facilmente em momentos livres de críticas, permitindo que a participação efetiva de todos os envolvidos culmine no alcance de um objetivo comum.

Definição: As quatro regras de Osborn

Foco na quantidade (Go for quantity) — gerar o maior número possível de ideias; quanto maior a quantidade, maior a chance de soluções de qualidade surgirem. Sem críticas (Withhold criticism) — nenhuma crítica, avaliação ou julgamento durante a geração de ideias, para que todos se sintam livres para se expressar. Incentivo a ideias "malucas" (Encourage wild ideas) — ideias incomuns ou aparentemente sem sentido são bem-vindas, servindo de gatilho para ideias mais práticas. Combinar e melhorar ideias (Combine and improve ideas) — os participantes são encorajados a construir sobre as ideias dos outros, combinando-as ou expandindo-as.

Definição: Três tipos de brainstorming

Silent storming (silencioso) — cada participante escreve ideias em post-its separadamente, expõe uma a uma, e ideias semelhantes de outros participantes são agrupadas junto — reduz o viés de quem fala primeiro ou mais alto. Group storming (colaborativo) — participantes falam as ideias em voz alta ao redor de um quadro, com um facilitador fixando e agrupando por afinidade. Reverse storming (reverso) — cada ideia é passada para a pessoa à esquerda, que a descarta (registrando o motivo) ou a mantém, criando um novo post-it; o ciclo continua até as ideias retornarem aos criadores originais.

Definição: Roteiro de um evento de brainstorming

Planejamento (definir objetivo, facilitador, até 10 participantes para manter a dinâmica produtiva, compartilhar contexto antecipadamente, preparar o ambiente físico) → Execução, dividida em geração de ideias (sem julgamentos, tempo limitado — ex.: 20-30 minutos — estimulando quantidade e diversidade) e consolidação (triagem de duplicadas/irrelevantes, discussão com os autores, seleção das mais viáveis por consenso). Como o brainstorming naturalmente produz muitas ideias, a consolidação costuma usar uma votação: Multi-votação (cada participante distribui um número limitado de votos entre as ideias, mantendo só as que atingem um mínimo) ou Grupo nominal/Zen voting (votação anônima que reduz vieses — cada participante recebe votos "vermelhos", para ideias de baixa prioridade/praticidade, e "verdes", para ideias muito prioritárias/práticas).

Definição: Vantagens e desvantagens do Brainstorming

Vantagens: estímulo à criatividade; engajamento coletivo que dissemina conhecimento; geração de muitas ideias, ideal para o levantamento inicial de requisitos; baixo custo (só um facilitador e poucos participantes); rapidez (sessões de 30 minutos a 2 horas). Desvantagens: alto volume de ideias superficiais ou irrelevantes; domínio de participantes mais extrovertidos, podendo intimidar os mais tímidos; falta de foco sem moderação eficiente; dificuldade de consolidação com muitas ideias; risco de conformismo (ideias semelhantes surgindo por influência do grupo).

Lean Inception¶

Definição: Lean Inception

Técnica mais difundida atualmente para a elicitação, criada por Paulo Caroli — uma mistura do Lean Startup (Eric Ries) com o Lean UX (Jeff Gothelf e Josh Seiden), totalmente voltada à concepção de softwares. Integra e executa várias das técnicas já apresentadas neste capítulo num único evento estruturado e enxuto, com o objetivo principal de definir o MVP de maneira rápida, eficaz e colaborativa — mitigando falhas recorrentes e inerentes ao processo de elicitação.

Definição: Objetivos de uma Inception

Entender o que deve ser feito (por quê, como e para quem o software deve ser concebido); definir a visão do software (o que ele é e não é); estabelecer objetivos de negócio (que problema resolve); alinhar expectativas técnicas e funcionais entre equipe e solicitantes; criar um plano de ação mínimo e incremental; e identificar métricas de sucesso que meçam se o software está, de fato, valendo a pena.

Definição: Cronograma de uma Lean Inception (proposta de Caroli)

Um evento de cinco dias, com atividades pela manhã e à tarde: Dia 1 — Kick off e visão do produto / É-Não é e Faz-Não faz (escopo e limites); Dia 2 — Identificação de Personas / Brainstorming de funcionalidades; Dia 3 — Revisão técnica de UX e de negócio / Criação de Jornadas de Usuário; Dia 4 — Identificação de funcionalidades nas jornadas / Priorização de funcionalidades; Dia 5 — Canvas MVP / Encerramento. Requer um ambiente físico próprio (sala ampla, paredes livres para post-its, mesa grande que estimule interação entre todos os participantes).

Definição: O que se espera ao final de uma Inception

Todos os stakeholders com visão clara e compartilhada do software; um backlog inicial priorizado para o 1º MVP (e, preferencialmente, outro backlog para os próximos MVPs); Personas e Jornadas de Usuário definidas; riscos identificados; estimativas de esforços iniciais; e um plano de releases (MVPs) ou Roadmap inicial. Uma Inception é geralmente realizada no início da concepção, mas também pode ser repetida a cada nova demanda de evolução do software já entregue.

Outras técnicas auxiliares de viabilidade e elicitação¶

Canvas MVP¶

Definição: Canvas MVP

Quadro visual usado numa Inception (tipicamente no encerramento, ver cronograma acima) para ajudar os stakeholders a estruturar e validar as ideias de um MVP de forma rápida e econômica, evitando que o time gaste tempo, dinheiro e energia desenvolvendo funcionalidades que talvez não gerem valor real. Organizado em sete blocos: Proposta do MVP (a intenção principal — qual mudança, impacto ou aprendizado o time pretende alcançar), Personas segmentadas (o recorte específico de público a ser priorizado nessa primeira entrega, sem tentar agradar a todos de uma vez), Jornadas (o que o público-alvo realiza e que o MVP pretende avaliar), Funcionalidades (a lista mínima necessária para validar a proposta, sem excesso), Resultados esperados (o que se deseja descobrir com o experimento — não necessariamente sucesso, mas aprendizado), Métricas para validar as propostas de negócio (critérios objetivos de medição) e Custo e cronograma (estimados só depois de definidos os demais blocos).

flowchart TD
    subgraph CanvasMVP["Canvas MVP"]
        PS["Personas<br/>segmentadas"] --- PM["Proposta do MVP"] --- RE["Resultado<br/>esperado"]
        J["Jornadas"] --- FUNC["Funcionalidades"] --- MET["Métricas para validar<br/>propostas de negócio"]
        CC["Custo e cronograma"]
    end

Definição: Os dois ciclos conceituais do Canvas MVP

Além dos sete blocos, o Canvas MVP se apoia em dois ciclos: o loop do Lean Startup (construir → medir → aprender — as Funcionalidades representam a construção, as Métricas a medição, e o Resultado esperado o aprendizado buscado) e o ciclo de design centrado no usuário (usuário → jornada → ação), que garante que o MVP seja pensado como uma intervenção real na experiência do usuário, não apenas um exercício técnico.

Matriz CSD¶

Definição: Matriz CSD

Técnica usada para esclarecer dúvidas antes de iniciar novas demandas, reunindo rapidamente, num único documento, o máximo de informações relevantes sobre o contexto (entregas passadas, atividades em andamento e planos futuros). Organiza as informações que os stakeholders levantam em três colunas: Certezas (informações consensuais entre todos), Suposições (informações que ainda carecem de confirmação) e Dúvidas (informações incertas, desconhecidas ou obscuras, que precisam de um processo de entendimento). É simples de aplicar (post- its físicos ou digitais) e, sendo atualizada continuamente, funciona como indicador estratégico do nível de entendimento e maturidade do projeto — muitas dúvidas e suposições indicam maior risco; muitas certezas indicam maior maturidade.

flowchart LR
    C["Certezas"]
    S["Suposições"]
    D["Dúvidas"]

Design Sprint¶

Definição: Design Sprint

Técnica criada pelo Google para resolver problemas complexos e testar ideias de forma rápida, estruturada e colaborativa, condensando em cinco dias o que geralmente levaria meses de trabalho — permitindo explorar soluções, criar protótipos e validar hipóteses com usuários reais antes de investir tempo e recursos no desenvolvimento em si. Apoia-se em cinco princípios: colaboração multidisciplinar, foco intenso (evitando perda de alinhamento), tomada de decisão eficiente (usando técnicas de ideação do Design Thinking para evitar debates improdutivos), prototipação rápida (esboços simples e ágeis) e validação com usuários reais ao final do processo.

Definição: Os cinco dias de um Design Sprint

Dia 1 (Map) — mapear profundamente o problema e o objetivo, definindo o modus operandi do Sprint junto aos stakeholders.
Dia 2 (Sketch) — esboçar várias ideias de solução a partir do que foi entendido no Dia 1, com a técnica Crazy8s se destacando entre as usadas.
Dia 3 (Decide) — escolher, entre a grande quantidade de ideias geradas, as mais alinhadas aos objetivos e entendimentos do Dia 1, criando um storyboard de 10 a 15 etapas para orientar a prototipação.
Dia 4 (Prototype) — prototipar as ideias escolhidas com fidelidade média ou alta (ferramentas como Figma, Keynote, Miro), definindo também um roteiro de testes.
Dia 5 (Test) — validar os protótipos com usuários reais selecionados, anotando o que funcionou, o que precisa de ajustes e o que não valida a proposta.

Ao final dos cinco dias, o Design Sprint entrega: hipóteses validadas ou invalidadas (reduzindo o risco de investir tempo e recursos num software ineficaz), redução significativa de riscos antes do desenvolvimento (usabilidade fraca, proposta de valor fraca, fluxo problemático), um mapa claro do problema e das oportunidades, e decisões embasadas em evidências reais — não em opinião, autoridade ou hierarquia.

Crazy8s¶

Definição: Crazy8s

Técnica de ideação rápida (usada tipicamente no Dia 2 de um Design Sprint) para estimular a criatividade na concepção de um software ou funcionalidade: em apenas 8 minutos, cada stakeholder deve gerar 8 ideias diferentes, dobrando uma folha de papel 3 vezes ao meio (gerando 8 retângulos) e esboçando uma ideia em cada um, sem permitir julgamento durante a criação. Ao término do tempo, cada pessoa apresenta e defende suas ideias (3 minutos cada); depois, todas as ideias são expostas para votação, elegendo-se 1 ideia principal e 2 secundárias para trabalhar de forma mais minuciosa. Por focar em volume e velocidade, em vez de refinamento, o Crazy8s ajuda a visualizar caminhos diversos, mantendo o foco na compreensão do problema e na geração de soluções — e não em polir uma única ideia prematuramente.

Especificação de Requisitos¶

Definição: De onde nascem as especificações — o Item de Backlog

Hoje, toda especificação de CDU, HU, RN, CA e RNF tem origem no Item de Backlog (IB) — antes das metodologias ágeis, não havia um conceito de requisitos bem definido, e cada necessidade era tratada de forma mais vaga. Um bom IB deve ser escrito seguindo cinco critérios: Clareza (compreensível para todos os stakeholders), Valor (relacionado a uma necessidade real do solicitante), Estimável (avaliável em esforço/complexidade e tempo), Priorizável (comparável com outros IBs em importância) e Pequeno (sucinto o bastante para caber num post-it, podendo depois ser expandido em CDU, HU, RN, CA ou RNF).

Definição: Por que criar CDUs, HUs, RNs, CAs e RNFs

Esses cinco artefatos são considerados os mais importantes porque: descrevem como o software se comporta (não só o que faz, mas como faz); servem como meio de comunicação entre quem solicita e quem desenvolve/mantém o software, reduzindo o gap semântico entre os dois mundos; e funcionam como meio de retenção de conhecimento — sem eles, cada troca de pessoas na equipe exigiria um longo período de retreinamento.

Especificando Caso de Uso (CDU)¶

Definição: Caso de Uso (CDU)

Criado por Ivar Jacobson em 1986 (enquanto trabalhava na Ericsson), é um documento que descreve como um ator (usuário) interage com um software para alcançar um objetivo específico. Jacobson propôs que um CDU tenha, no mínimo, as seguintes seções: Nome do Caso de Uso, Ator(es) Principal(is) (quem interage diretamente — primários ou secundários, como outros softwares), Objetivo/ Propósito, Pré-condições, Fluxo Principal (sequência de passos ideais), Fluxos Alternativos/Exceções (erros, falhas ou caminhos alternativos, garantindo cobertura completa), Pós-condições/Resultado Esperado, e opcionalmente Regras de Negócio relacionadas. Essas seções não estão "escritas em pedra" — cada empresa/projeto pode usá-las, omiti-las ou adicionar novas, desde que o CDU continue completo e eficiente.

CASO DE USO: Redefinir Senha
Ator Principal: Usuário - Primário
Pré-condições: O usuário já deve ter acesso ao software.

Fluxo Principal
P1. O usuário acessa "Esqueci minha senha" na tela de login;
P2. O software solicita um e-mail cadastrado;
P3. O software envia um link de redefinição (RN02);
P4. O usuário acessa o link e cadastra uma nova senha (RN03);
P5. O software salva a nova senha e confirma o sucesso.

Fluxos Alternativos
A1. E-mail não cadastrado (RN01) — o software exibe mensagem de erro
    e o caso de uso é encerrado.

Pós-condição: A senha do usuário foi atualizada com sucesso.

Definição: Boas práticas na criação de CDU

Identificar corretamente e claramente quem interage com o software (os atores); descrever o fluxo principal, os alternativos e os de exceções; evitar excesso de detalhes técnicos, focando no comportamento (não em como implementar); manter o escopo bem definido, sem misturar vários objetivos num só CDU; incluir pré-condições e pós-condições, preferencialmente; e validar os fluxos com usuários/solicitantes e testadores, para garantir cobertura de cenários reais.

Especificando História de Usuário (HU)¶

Definição: Origem da HU

Duas pessoas são geralmente associadas à criação da História de Usuário, entre 1996 e 1999: Kent Beck (considerado o pai do XP — Extreme Programming) e Ron Jeffries — mas a HU como a conhecemos hoje é resultado principalmente dos trabalhos de refinamento de Jeffries. Difundiu-se amplamente com o Manifesto Ágil (início dos anos 2000) e foi incorporada ao Scrum, o que contribuiu para sua ampla adoção.

Definição: Estrutura de uma HU

Jeffries definiu a estrutura em 3 itens: Como [persona] descreve quem interagirá com o software; quero [ação] descreve a ação que deve ser automatizada; para [benefício] descreve o benefício/objetivo alcançado com a automatização. A meta da HU não é documentar detalhadamente a necessidade, mas capturar sua intenção e valor de negócio — os detalhes são explorados depois, em conversas entre a equipe e os stakeholders, nas quais a HU é expandida com Cenários e Critérios de Aceitação. Algumas abordagens usam "Sendo" ou "Quando" no lugar de "Como", com resultados equivalentes.

Definição: INVEST (Bill Wake) e 3C (Ron Jeffries) — guias para boas HUs

INVEST: Independent (independente de outras HUs, evitando interferências e atrasos), Negotiable (negociável — não é uma definição fixa e indiscutível, mas um convite à colaboração), Valuable (valiosa — agrega valor ao software e ao negócio), Estimable (estimável em esforço/complexidade/tempo), Small (pequena o suficiente para caber numa sprint) e Testable (testável, com CAs que permitam validar sua implementação).

3C: Card (Cartão — escrita com poucas palavras, como um post-it), Conversation (Conversa — a expansão do Card via conversas entre stakeholders, esclarecendo dúvidas e emergindo detalhes técnicos) e Confirmation (Confirmação — a HU deve poder ser confirmada e validada quanto à sua eficácia, com o auxílio dos CAs).

HISTÓRIA DE USUÁRIO: Redefinir Senha
Como usuário cadastrado,
quero redefinir minha senha caso a esqueça,
para recuperar meu acesso ao sistema com segurança.

Cenário 1: Usuário redefine a senha com sucesso
Dado que o usuário solicitou a redefinição de senha
Quando ele informar um e-mail válido cadastrado
E acessar o link recebido e cadastrar uma nova senha válida
Então o software deve salvar a nova senha
E confirmar a alteração com uma mensagem de sucesso.

Definição: Gherkin — o formato Dado/Quando/Então

Gherkin é a linguagem usada para escrever Cenários e Critérios de Aceitação de forma estruturada, seguindo o formato Given/When/Then (traduzido como Dado/Quando/Então): Dado descreve o contexto/pré-condição antes da ação ocorrer; Quando descreve a ação realizada; Então descreve o resultado esperado após a ação (podendo ser encadeado com E, para condições ou resultados adicionais). É a base da técnica de BDD (Behavior Driven Development), permitindo que ferramentas de teste interpretem o cenário escrito em linguagem natural e o executem automaticamente como um teste (ver Mock Objects para outras técnicas de teste automatizado).

Definição: Boas práticas na criação de HU

Focar no valor de negócio, não em como implementar; criar histórias pequenas e independentes; definir critérios de aceitação objetivos e testáveis; e validar os fluxos com usuários e testadores para garantir cobertura de cenários reais.

Definição: CDU x HU — diferenças estruturais, mesmo objetivo

Ao contrário do CDU, a HU deve seguir à risca sua estrutura curta — não seguir as premissas INVEST e 3C tende a torná-la confusa (por depender de outras HUs) ou extensa (por não seguir sua estrutura básica), dificultando compreensão, estimativa e validação, o que compromete o planejamento da sprint e a entrega de valor. Ainda assim, os dois artefatos têm semelhanças: os fluxos de um CDU correspondem aos cenários de uma HU; ambos usam RNs; ambos se submetem a RNFs; e ambos servem para guiar testes — só que a HU também conta com CAs como item a mais.

Especificando Regra de Negócio (RN)¶

Definição: Regra de Negócio (RN)

Um conjunto de restrições operacionais ou organizacionais que precisam ser seguidas pelo software, independentemente de um CDU ou HU específico. Restrições operacionais são políticas, leis etc.; restrições organizacionais são regras de acesso, diretrizes internas da empresa etc. RNs garantem a conformidade das funcionalidades (CDUs e HUs) com normas legais e políticas internas.

Definição: Boas práticas na criação de RN

Ser reutilizável (aplicável a mais de um CDU/HU); ser obrigatória (o software sempre deve cumpri-la, sem discricionariedade de quem solicita/usa); descrever o que deve ser cumprido, não como implementar; ser clara, simples e sem ambiguidades, de forma a ser facilmente codificada e validada; ser testável/ verificável; ser acessível aos stakeholders (via backlog, wiki); ser única e reutilizável; ser validada com stakeholders antes de codificada; estar relacionada ao negócio (referenciando a fonte/origem, quando aplicável — leis, regulamentos, compliance); ser estável, não mudando a cada uso; e ser escrita em linguagem próxima ao negócio, sem textos técnicos.

Especificando Critérios de Aceitação (CA)¶

Definição: Critério de Aceitação (CA)

Uma condição objetiva que define quando uma HU pode ser considerada pronta (codificada e validada) e assim aceita pelo PO ou solicitante — funciona como um checklist de validação. CAs pertencem exclusivamente às HUs, tendo surgido junto com as Metodologias Ágeis.

Definição: Boas práticas na criação de CA

Ser específico da HU, nunca genérico, alinhado aos cenários definidos; usar linguagem objetiva; ser claro, simples e sem ambiguidades; ser testável, de modo que QA/Testers consigam automatizá-lo ou validá-lo; usar o formato Dado/Quando/ Então (Gherkin), deixando claro contexto, ação e resultado esperado; cobrir cenários positivos e negativos da HU; ser focado e essencial, evitando quantidade inadequada ou inflada de critérios; e ser validado com stakeholders antes de codificado.

Especificando Requisitos Não Funcionais (RNF)¶

Definição: Requisito Não Funcional (RNF)

Descreve regras comportamentais sobre como o software deve operar, definindo atributos de qualidade e restrições operacionais — não trata das funcionalidades em si, mas de aspectos como desempenho, segurança, usabilidade, confiabilidade e portabilidade. São os requisitos mais difíceis de definir e especificar, por serem subjetivos e abstratos — mas também os que mais podem degradar a qualidade do software e causar desconforto a usuários se malfeitos.

Definição: Características que tornam um RNF difícil de especificar

Transversais (impactam o software como um todo, não uma funcionalidade específica); Mensuráveis (idealmente definem métricas ou critérios objetivos); Restritivos (limitam opções de arquitetura, tecnologia ou implementação); Qualitativos (materializam atributos de qualidade); Difíceis de testar (quando não são claros e objetivos, tornam-se quase impossíveis de testar).

Definição: Boas práticas na especificação de RNF

Ser específico e mensurável (evitar "rápido", usar "responder em até 2 segundos para 95% das requisições"); usar padrões de qualidade reconhecidos (a norma ISO/IEC 25010 define claramente atributos de qualidade de software amplamente reconhecidos); documentar separadamente dos requisitos funcionais, para garantir rastreabilidade sem que fiquem "escondidos"; priorizar RNFs críticos, já que cada tipo tem prioridades diferentes a depender do software; validar com o stakeholder correto para cada tipo; considerar o impacto na arquitetura ao definir RNFs; incluir critérios de aceitação claros ("disponível 99,9% do tempo, exceto em janelas de manutenção programadas", em vez de "disponível quase sempre"); e ligar RNFs aos requisitos funcionais e HUs/CDUs relacionados.

Definição: Catálogo dos principais tipos de RNF

Desempenho (Performance) — limites de tempo, capacidade de processamento e velocidade de resposta (ex.: responder em até 2s para 95% das requisições; suportar 10.000 usuários simultâneos).
Confiabilidade (Reliability) — estabilidade e consistência em diferentes condições de uso (ex.: taxa de falha ≤ 0,1% ao mês; recuperação automática em até 60s após queda de servidor).
Disponibilidade (Availability) — percentual de tempo em que o software está acessível e funcionando (ex.: disponibilidade de 99,9% por mês — SLA; janela de manutenção não pode ultrapassar 2h/semana).
Segurança (Security) — proteção contra acessos não autorizados, ataques e vazamentos de dados (ex.: TLS/HTTPS em todas as comunicações; senhas com bcrypt + salting; MFA para administradores).
Usabilidade (Usability) — regras de facilidade de uso, acessibilidade e experiência do usuário (ex.: conformidade com WCAG 2.1 nível AA; fluxo de compra em no máximo 5 passos).
Portabilidade (Portability) — capacidade de rodar em diferentes plataformas e ambientes (ex.: compatível com Windows/Linux/macOS; app mobile em Android e iOS).
Escalabilidade (Scalability) — capacidade de crescer em carga, usuários ou volume de dados sem comprometer o desempenho (ex.: suportar 100% de aumento de tráfego em promoções; adicionar servidores sem downtime).
Regulatórios/Legais — conformidade com leis e normas do domínio (ex.: LGPD; PCI DSS para transações financeiras).

Definição: RNFs têm stakeholders e prioridades diferentes por contexto

Cada tipo de RNF se relaciona com stakeholders diferentes (ex.: Desempenho interessa a usuários finais e arquitetos; Regulatórios/Legais interessa a compliance e auditores) e tem relevância variável conforme o tipo de software (um e-commerce prioriza Desempenho e Disponibilidade no checkout; um banco prioriza Confiabilidade e Segurança quase ao extremo; uma rede social tolera mais volatilidade em Disponibilidade, mas exige Escalabilidade altíssima). Identificar essas relações e prioridades ajuda a direcionar esforços de especificação e validação.

Definição: Especificação pode (e deve) vir depois da codificação, em metodologias ágeis

Embora a etapa de Especificação venha antes da de Desenvolvimento na Engenharia de Requisitos clássica, com o advento das Metodologias Ágeis recomenda-se que CDUs, HUs e RNs sejam criados apenas após a codificação e validação, junto aos respectivos stakeholders — essa abordagem evita retrabalhos e garante que os artefatos finais reflitam com maior fidelidade as codificações reais.

Validação e Priorização de Requisitos¶

Validando requisitos¶

Definição: Validação de requisitos

Atividade que responde à pergunta "o software certo está sendo construído?" — verificar se o que foi documentado (necessidades, CDUs, HUs, RNs, RNFs) realmente reflete o que os stakeholders precisam, e se está bem estruturado o suficiente para guiar o desenvolvimento. A validação olha para dois ângulos complementares:

Conteúdo — o requisito documentado está completo e correto? Reflete de fato a necessidade levantada?
Estrutura — o requisito está bem organizado, claro e segue os padrões definidos pelo time (ex.: template de CDU, formato INVEST de HU)?

Algumas boas práticas tornam a validação mais eficaz:

Envolvimento dos stakeholders adequados — quem valida deve ter conhecimento suficiente do negócio ou da técnica para identificar problemas reais.
Separação entre autor e validador — quem escreveu o requisito tende a validar com menos rigor o próprio texto; uma segunda pessoa aumenta as chances de pegar falhas.
Adequação ao tipo de artefato — um artefato textual (CDU, HU) se valida por leitura crítica; um artefato visual (protótipo, diagrama) se valida melhor por interação/simulação.
Validação contínua — não é um evento único no fim da especificação, mas uma prática recorrente ao longo de todo o processo.

Definição: Inspeções e Prototipagem (técnicas de validação)

Inspeções são reuniões formais e multidisciplinares de revisão, em que stakeholders de diferentes áreas leem e questionam os requisitos documentados em busca de falhas, ambiguidades ou lacunas. Prototipagem (ver Prototipação) usa modelos parciais ou simulados do software para verificar, na prática, se o entendimento documentado corresponde à expectativa real do stakeholder — útil sobretudo para validar requisitos de interface e fluxo.

Definição: Checklist de validação de requisitos (14 pontos)

Uma lista de verificações recorrentes ao revisar qualquer requisito documentado:

Informações prematuras — o requisito documenta decisões de implementação que ainda não deveriam estar definidas nessa etapa?
Mistura de necessidades e funcionalidades — o texto confunde "o que o stakeholder precisa" com "como o software vai fazer isso"?
Artefato desnecessário — esse requisito realmente precisa existir, ou é redundante com outro já documentado?
Obrigatoriedade indevida — algo descrito como obrigatório é, na verdade, opcional (ou vice-versa)?
Conformidade com o negócio — o requisito está alinhado com as regras e objetivos reais do negócio?
Ambiguidade — o texto permite mais de uma interpretação?
Realismo — o requisito é tecnicamente e financeiramente viável de implementar?
Testabilidade — é possível escrever um teste (ou critério de aceitação) que comprove se o requisito foi atendido?
Priorização — o requisito tem uma prioridade definida, ou está solto sem indicação de importância?
Omissão — falta alguma informação essencial para implementar corretamente?
Contradição — o requisito entra em conflito com outro já documentado?
Inadequação — o requisito está na categoria/artefato errado (ex.: uma regra de negócio descrita como se fosse um caso de uso)?
Mensurabilidade — para RNFs em especial: os critérios são mensuráveis (ex.: "responder em até 2s"), ou vagos (ex.: "responder rápido")?
Excesso de especificação, formatação e rastreabilidade — o requisito tem detalhe demais para a etapa atual? Segue o padrão de formatação do time? Está rastreável a uma necessidade de origem (ver Matriz de Rastreabilidade)?

Priorizando requisitos¶

Definição: Priorização de requisitos

Atividade que responde à pergunta "por onde começar?" — analisar, avaliar e ordenar requisitos (itens de backlog, funcionalidades, demandas) segundo critérios objetivos e estratégicos, para guiar a ordem de desenvolvimento.

Definição: Cinco princípios da priorização

Envolver todos os stakeholders relevantes — a priorização não deve ser decidida isoladamente por uma única pessoa ou área.
Ser relativa/comparativa — prioridade só faz sentido quando um item é comparado a outro, não em termos absolutos.
Ser consistente e contextual — comparar itens de natureza semelhante (ex.: não faz sentido comparar diretamente um CRUD simples com um processamento em lote complexo).
Ser gradual, com escalas coerentes — usar níveis (ex.: Alto/Médio/Baixo, ou escalas numéricas) de forma consistente entre todos os itens avaliados.
Evitar requisitos interdependentes quando possível — dependências entre itens dificultam a priorização isolada de cada um.

Definição: Cinco critérios de avaliação para priorização

Custo de implementação
Risco
Volatilidade (chance de o requisito mudar no curto prazo)
Importância (valor de negócio ou para o usuário)
Tempo de codificação

MoSCoW¶

Definição: MoSCoW

Técnica de priorização qualitativa que classifica cada requisito em uma de quatro categorias:

Must have — obrigatório; sem ele, o software não tem valor ou não pode ser entregue (ex.: "o sistema de gerenciamento de requisitos precisa permitir criar e editar um requisito").
Should have — importante, mas não bloqueia o lançamento (ex.: "deve permitir anexar arquivos a um requisito").
Could have — desejável, com impacto menor se não for feito (ex.: "poderia sugerir tags automaticamente com base no texto do requisito").
Won't have — combinado que não será feito nesse momento (ex.: "não vai suportar exportação para PDF nesta versão") — deixar isso explícito evita expectativa equivocada dos stakeholders.

Timeboxing¶

Definição: Timeboxing

Técnica de priorização baseada em tempo fixo: define-se um intervalo (box) de tempo — tipicamente uma sprint, no Scrum — e prioriza-se apenas o que cabe dentro dele, em vez de tentar prever quanto tempo cada item vai levar. Benefícios: mantém foco e disciplina, evita perfeccionismo (o time entrega o que é possível dentro do prazo, não o "ideal"), aumenta a previsibilidade e ajuda no cumprimento de prazos.

Matriz Esforço x Valor¶

Definição: Matriz Esforço x Valor

Técnica visual que posiciona cada requisito num quadrante 2x2, cruzando esforço de implementação com valor gerado:

Alto valor + Baixo esforço → prioridade imediata.
Alto valor + Alto esforço → prioridade secundária (vale a pena, mas exige planejamento).
Baixo valor + Baixo esforço → prioridade condicional (fazer se sobrar capacidade).
Baixo valor + Alto esforço → evitar ou reavaliar.

quadrantChart
    title Matriz Esforço x Valor
    x-axis "Baixo Esforço" --> "Alto Esforço"
    y-axis "Baixo Valor" --> "Alto Valor"
    quadrant-1 "Prioridade secundária"
    quadrant-2 "Prioridade imediata"
    quadrant-3 "Prioridade condicional"
    quadrant-4 "Evitar ou reavaliar"

RICE¶

Definição: RICE

Técnica de priorização quantitativa que calcula uma pontuação a partir da fórmula:

\[RICE = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}\]

Reach (Alcance) — quantas pessoas/usuários o requisito afeta num período (ex.: número de usuários impactados por mês).
Impact (Impacto) — o quanto o requisito afeta positivamente cada usuário alcançado, numa escala: Impacto muito pequeno = 0,25; Baixo impacto = 0,5; Médio impacto = 1; Alto impacto = 2; Massivo = 3.
Confidence (Confiança) — o quão confiante o time está nas estimativas de Reach e Impact, numa escala de porcentagem: Alta confiança (80–100%) = 1,0; Média confiança (60–79%) = 0,8; Baixa confiança (40–59%) = 0,5; Muito baixa confiança (menor que 40%) = 0,1 — ajuda a evitar "chutes" que distorçam a priorização.
Effort (Esforço) — todo o esforço necessário para implementar a demanda, não só a codificação (também análise, elicitação, testes, protótipos, DevOps etc.). É o elemento mais complexo de mensurar (Effort não é código, Effort é entrega) e é o divisor da fórmula: quanto maior o esforço, menor a prioridade resultante, e vice-versa.

Definição: Formas de mensurar Effort

Para que o Effort seja comparável entre demandas, deve sempre usar a mesma unidade. Formas comuns: pontos de história (Scrum, ex.: 3, 5, 8, 13), dias/semanas de trabalho (ex.: 2 dias, 1 semana), pessoa-mês/pessoa-semana, estimativa bucket simples (Baixo/Médio/Alto), e T-shirt sizes (XS = 0,5, S = 1, M = 2, L = 4, XL = 6) — a mais utilizada, por ser uma escala padronizada que evita exageros, não exigir precisão impossível, ser rápida, confiável, comparável, sucinta e pragmática (o objetivo do RICE é priorização relativa, não cálculo exato).

Resumo comparativo das técnicas de priorização:

Técnica	Considera esforço?	Considera impacto/valor?	Considera dados?	Complexidade
MoSCoW	Sim	Parcial	Não	Fácil
Timeboxing	Não (tempo, não esforço)	Não	Não	Fácil
Matriz Esforço x Valor	Sim	Sim	Parcial	Médio
RICE	Sim	Sim	Sim	Mais complexo

Conclusão: validação e priorização são atividades contínuas¶

A validação é um dos pilares da qualidade de software: bem conduzida, reduz retrabalho e aumenta a confiabilidade do software final. Deve ser encarada como uma atividade contínua de aprendizado e refinamento, garantindo que o software não apenas funcione corretamente, mas represente os desejos de quem o solicitou. Já a priorização é fundamental para guiar o caminho do desenvolvimento, definindo os primeiros passos e preparando o terreno para os próximos — permite definir prazos, mitigar incertezas e obter maior alinhamento com as expectativas dos solicitantes.

Mesmo bem aplicadas, ambas têm limitações: a validação de um requisito garante apenas que o que foi entendido foi corretamente documentado e codificado, mas não garante que o entendimento original estava correto (não detecta uma falha de elicitação); já a priorização não consegue prever mudanças de rumo que venham a ocorrer durante o processo. Ainda assim, essas atividades devem ser executadas sempre — nem tudo vai estar errado, nem tudo vai sempre mudar, e são elas que trazem as certezas possíveis dentro da subjetividade inerente ao desenvolvimento de software.

Gerenciamento de Requisitos¶

Definição: Por que gerenciar requisitos

Mudanças nos requisitos de um software são inevitáveis — nenhum entendimento inicial é perfeito, e o próprio negócio muda com o tempo. Um software que nunca sofre alterações é, na prática, um forte indício de que ele não está sendo usado. As mudanças costumam vir de quatro fontes: falha de entendimento (a elicitação não captou corretamente a necessidade), falha de especificação (o entendimento era correto, mas o artefato — CDU, HU — foi escrito de forma incompleta ou ambígua), falha de codificação (o artefato estava correto, mas a implementação não seguiu fielmente o que foi especificado) e mudanças externas (novas leis, regulações ou necessidades de negócio que não existiam antes).

Definição: Sinais de que é preciso voltar à prancheta

Mudanças pontuais são normais e devem ser incorporadas ao processo — mas quando um mesmo requisito sofre alterações recorrentes, isso costuma indicar que a necessidade subjacente não foi bem compreendida, e não que o requisito só precisa de mais um ajuste. Dois sinais de alerta: alto número de solicitações de mudança para a mesma funcionalidade, e grande quantidade de informações sendo adicionadas, excluídas ou modificadas nela. Nesses casos, vale refazer a Análise & Projeto da funcionalidade do zero, em vez de seguir "remendando" o artefato existente.

Os quatro pilares da gerência de requisitos¶

Definição: Controle de Versão (requisitos)

Garante que as diferentes versões de cada requisito se mantenham organizadas e rastreáveis — cada requisito recebe uma identificação única (ex.: US001-V1.2), o que facilita localizar seu histórico de mudanças. Também é aplicável a conjuntos de requisitos entregues juntos em um mesmo lote/release/MVP, ajudando a rastrear quais requisitos foram entregues em qual versão do software.

Definição: Controle de Mudanças (requisitos)

Garante que toda alteração proposta seja avaliada, aprovada e registrada antes de ser implementada — evitando impactos negativos não previstos no cronograma, custos e qualidade. Envolve: propor a mudança (qualquer stakeholder pode sugerir alterações), analisar impactos (efeitos técnicos, de negócio, custo e cronograma), tomar a decisão (aceitar, adiar ou rejeitar), atualizar os requisitos e artefatos afetados mantendo a consistência entre eles, atualizar planos (cronograma, orçamento, escopo) e medir a volatilidade dos requisitos (frequência de alterações ao longo do tempo — alta volatilidade indica instabilidade no entendimento das necessidades).

Definição: Acompanhamento do Estado dos Requisitos

Possibilita monitorar o progresso das modificações nos requisitos e nos códigos, desde a definição até a implementação e verificação. Envolve definir os estados possíveis de um requisito ao longo do processo (ex.: proposto, aprovado, em desenvolvimento, implementado, verificado), registrar o estado atual de cada um, e acompanhar a distribuição de estados entre todos os requisitos — dando uma visão geral do andamento (quantos estão em teste, quantos finalizados etc.), útil para controle gerencial e relatórios de progresso.

Definição: Rastreabilidade dos Requisitos

Garante que cada requisito possa ser vinculado a outros requisitos, a componentes do software, a casos de teste, código ou documentação — permitindo identificar dependências entre requisitos (ex.: um requisito de autenticação depende de outro de cadastro de usuário) e relacionar os requisitos aos elementos do software que os implementam (módulos, funcionalidades), facilitando a análise de impacto de mudanças. É o pilar detalhado a seguir.

Pilar	Objetivo principal	Benefício
Controle de versão	Controlar histórico e versões dos requisitos	Evita perda de informações e inconsistências
Controle de mudanças	Gerenciar solicitações e impactos de alterações	Mantém estabilidade e previsibilidade
Acompanhamento de status	Monitorar progresso e estado dos requisitos	Facilita gestão e comunicação do avanço
Rastreabilidade	Ligar requisitos entre si e ao restante do software	Garante cobertura e facilita análise de impacto

Responder às perguntas certas é o que torna esse processo eficaz: a mudança é realmente válida, ou só uma falha de entendimento? Deve ser feita neste software, ou também em outros? É evolutiva ou corretiva? Em que momento deve ser efetivada? Quem é o responsável por realizá-la? Diversos stakeholders contribuem com essas respostas — Product Owners e Scrum Masters (explicam e detalham a mudança), analistas de requisitos e desenvolvedores (detectam impactos, origem e natureza), testadores e QAs (identificam se a mudança foi bem-sucedida), representantes do solicitante (avaliam o impacto em usuários e mercado) e suporte técnico/help desk (avaliam usabilidade e qualidade do feedback antes e depois da mudança).

Rastreabilidade horizontal e vertical¶

A Matriz de Rastreabilidade relaciona requisitos entre si e ao restante do software — mas essa relação pode acontecer em duas direções distintas.

Definição: Rastreabilidade horizontal x vertical

A rastreabilidade horizontal conecta artefatos do mesmo nível de abstração entre si (ex.: um CDU que depende de duas Regras de Negócio, ou um RNF que impacta vários Casos de Uso) — garante coerência e consistência entre requisitos, identificando dependências, conflitos, duplicidades ou lacunas entre eles. A rastreabilidade vertical conecta artefatos de diferentes níveis de abstração, desde a necessidade de negócio original até o código e os testes que a implementam (ex.: Necessidade → Funcionalidade → CDU/HU → Classe → Caso de Teste) — garante que tudo o que foi solicitado tenha sido efetivamente desenvolvido e testado, e que nada tenha sido implementado sem uma necessidade de origem.

flowchart LR
    CDU_A["CDU A / HU A"] <--> CDU_B["CDU B / HU B"]
    CDU_B <--> CDU_C["CDU C / HU C"]
    CDU_A <--> CDU_C
    RNA["RN A"] --> CDU_A
    RNB["RN B"] --> CDU_B
    RNFA["RNF A"] --> CDU_C

flowchart TD
    NEC["Necessidade de negócio"] --> FUN1["Funcionalidade"]
    FUN1 --> CDU1["CDU / HU"]
    CDU1 --> CLASSE["Código<br/>(classe/método)"]
    CLASSE --> TESTE["Caso de teste"]

A Matriz de Rastreabilidade — já apresentada como artefato — é a ferramenta concreta que materializa essas duas direções: uma tabela cujas linhas e colunas cruzam os itens que se relacionam, marcando com um "X" cada cruzamento existente. Quanto mais granular a matriz (indo até a classe e o teste que implementam cada necessidade), mais poderosa ela é para análise de impacto — mas também mais trabalhosa de manter, especialmente em projetos grandes. Por isso, o ideal costuma ser uma matriz resumida, mapeando só até o nível de necessidade → funcionalidade → CDU/HU, sem descer a cada classe e teste.

Definição: Manter a Matriz de Rastreabilidade é um desafio real

Manter uma MR atualizada é uma tarefa desafiadora: exige grande compromisso de todos os stakeholders, e nem todos têm capacidade ou interesse em sustentar esse esforço. Isso é um desafio real da Engenharia de Requisitos, mas não é motivo para abandonar o artefato — o ideal é que ela seja criada e mantida com o nível de granularidade que o time consiga sustentar de fato, em vez de idealizada e depois abandonada.

Conclusão: gerenciar requisitos é uma atividade contínua¶

O tempo de vida útil de um software costuma ser muito maior que seu tempo de desenvolvimento — por isso, gerenciar as mudanças que ocorrem nele, sejam corretivas ou evolutivas, é fundamental para mantê-lo funcionando e entregando valor ao longo de toda sua existência. Como toda etapa da Engenharia de Requisitos, o gerenciamento também enfrenta desafios: desenvolver software é uma atividade abstrata e mentalmente desgastante, e manter documentação rastreada é, com frequência, mais cansativo e estressante do que o próprio desenvolvimento — o que leva muitos times a deixarem a rastreabilidade se perder ao longo do tempo. Evitar essa perda é o maior desafio prático da gerência de requisitos.

A Engenharia de Requisitos na era da IA¶

Definição: IA como auxiliar, não substituta, da Engenharia de Requisitos

A integração da Inteligência Artificial (IA) na Engenharia de Requisitos não substitui a equipe de desenvolvimento — ela amplifica suas capacidades. Ferramentas de IA auxiliam em tarefas repetitivas e de baixo valor agregado (obter dados a partir de documentos extensos, manter manualmente a rastreabilidade entre artefatos), liberando a equipe para focar no que é estratégico: a negociação, a criatividade na definição do software e a construção de um entendimento profundo e compartilhado com os stakeholders. O papel da IA em cada fase da ER é, sobretudo, o de um auxiliar analítico: identificar padrões e inconsistências em grandes volumes de dados de forma muito mais rápida do que uma análise manual conseguiria.

A tabela a seguir resume como a IA pode apoiar cada fase da ER, com exemplos de categorias de ferramentas atualmente disponíveis no mercado:

Fase da ER	Como a IA ajuda	Exemplos de ferramentas
Estudo de Viabilidade	Análise preditiva de custos/prazos/riscos a partir de dados históricos; cruzamento de informações de mercado	IBM Watson Discovery (análise de documentos não estruturados); ChatGPT, Claude e Gemini (análise geral e geração de pareceres)
Elicitação	Transcrição e resumo automático de reuniões/entrevistas; identificação de padrões, temas recorrentes e jobs to be done em textos não estruturados	Otter.ai e Fireflies.ai (transcrição de reuniões); Dovetail (análise qualitativa de pesquisas); ELICA (inferência de requisitos implícitos em documentos)
Especificação	Reescrita de requisitos ambíguos em formato claro, mensurável e testável; verificação de consistência terminológica; geração de checklists a partir de texto livre	Visure Requirements e ReqSuite RM (avaliação automática de qualidade de requisitos); Notion AI e ClickUp AI (estruturação de HUs a partir de descrições soltas)
Validação e Priorização	Verificação automática de testabilidade e alinhamento a objetivos de negócio; análise de valor/esforço/risco para sugerir ordem de prioridade	Jira + Atlassian Intelligence; aqua AI; Tara AI
Gerenciamento	Manutenção automática da rastreabilidade entre requisitos, código e testes; detecção de quebras de rastreabilidade após mudanças; notificação de impacto	ClickUp AI; ReqBrain

Definição: O futuro da ER é orquestrar a IA, não ser substituído por ela

O uso de IA contribui para a melhoria da qualidade dos requisitos — reduzindo ambiguidades, inconsistências e lacunas — e para a confiabilidade dos artefatos produzidos, graças à sua capacidade de analisar grandes volumes de dados qualitativos e quantitativos. A tendência é que a profissão de quem trabalha com requisitos evolua para demandar a habilidade de orquestrar essas ferramentas — saber fazer as perguntas certas a elas e validar criticamente suas sugestões, em vez de aceitá-las sem questionamento. Quem dominar essa colaboração entre IA e expertise técnica estará mais bem posicionado para construir software de qualidade, alinhado aos desejos reais de quem o solicitou.