Glossário de engenharia de requisitos

Definições curtas e canônicas dos termos usados em levantamento de requisitos e documentação de software. Cada termo tem endereço próprio — o link leva direto à definição.

Processo

Engenharia de requisitos: Engenharia de requisitos é a disciplina que levanta, analisa, especifica, valida e gerencia o que um sistema precisa fazer, antes e durante a construção.Abrange cinco atividades encadeadas: elicitação, análise, especificação, validação e gestão de mudanças.
Elicitação: Elicitação é a atividade de descobrir junto aos interessados o que o sistema precisa fazer, antes de qualquer redação formal.Não é só "perguntar o que você quer": grande parte do que importa é tácito, e por isso se usam entrevista, observação, prototipagem e análise de documentos.
Análise de requisitos: Análise de requisitos é a atividade de transformar necessidades brutas em requisitos organizados, sem conflito e priorizados.
Especificação: Especificação é o registro formal dos requisitos num documento estruturado que serve de referência para construção, teste e contrato.
Gestão de mudanças: Gestão de mudanças de requisitos é o processo de avaliar, aprovar e registrar alterações no que foi acordado, medindo o impacto antes de aceitar.É o que separa escopo que evolui de escopo que escapa.
Stakeholder: Stakeholder é qualquer pessoa ou grupo afetado pelo sistema ou capaz de influenciar suas decisões.Inclui quem nunca usará o sistema mas responde por ele — jurídico, compliance, segurança.
Escopo: Escopo é o conjunto do que o sistema vai entregar, e — igualmente importante — a declaração explícita do que não vai.
Baseline: Baseline é a versão dos requisitos formalmente aprovada, a partir da qual toda alteração passa a exigir controle de mudança.

Tipos de requisito

Requisito: Requisito é uma declaração verificável do que o sistema deve fazer ou de qual qualidade deve ter.Se não há como demonstrar que foi atendido, não é requisito — é intenção.
Requisito funcional: Requisito funcional descreve um comportamento que o sistema deve executar: uma entrada, um processamento e uma saída.Exemplo: "o sistema deve emitir nota fiscal ao confirmar o pagamento".
Requisito não funcional: Requisito não funcional descreve uma qualidade que o sistema deve ter — desempenho, segurança, disponibilidade, usabilidade — em vez de um comportamento.Precisa de número para ser verificável: "rápido" não é requisito; "resposta em até 400 ms no percentil 95" é.
Necessidade: Necessidade é o problema de negócio na linguagem de quem o vive, antes de virar requisito.É o insumo da análise: uma necessidade costuma gerar vários requisitos.
Regra de negócio: Regra de negócio é uma restrição que existe na operação independentemente de haver software, e que o sistema precisa respeitar.
Restrição: Restrição é uma limitação imposta à solução — tecnologia obrigatória, prazo, orçamento, norma — que reduz o espaço de escolhas do projeto.

Artefatos

SRS: SRS (Software Requirements Specification) é o documento que reúne todos os requisitos de um sistema, sua estrutura e seu contexto.A estrutura de referência está na ISO/IEC 29148, que substituiu a antiga IEEE 830.
PRD: PRD (Product Requirements Document) é o documento que descreve o problema, o público e os resultados esperados de um produto, orientando o time sobre o porquê antes do como.Difere do SRS pelo público e pela profundidade: o PRD fala com produto e negócio; o SRS, com engenharia.
Matriz de rastreabilidade: Matriz de rastreabilidade é a tabela que liga cada requisito à sua origem e aos artefatos que o realizam e o testam.Serve para responder duas perguntas caras: o que quebra se este requisito mudar, e por que este código existe.
ICD: ICD (Interface Control Document) é o documento que especifica como dois sistemas trocam dados: formato, protocolo, autenticação e erros.
Documento de arquitetura: Documento de arquitetura é o registro das decisões estruturais do sistema e das razões por trás delas.O que o torna útil meses depois não é o diagrama, e sim o porquê de cada escolha.
User story: User story é uma descrição curta de uma necessidade sob a perspectiva de quem a tem, no formato "como <papel>, quero <ação>, para <benefício>".É um convite à conversa, não uma especificação — o detalhe mora nos critérios de aceite.
Critério de aceite: Critério de aceite é a condição objetiva que precisa ser verdadeira para uma story ser considerada pronta.
Caso de uso: Caso de uso é a descrição de uma interação completa entre um ator e o sistema para alcançar um objetivo, incluindo os fluxos alternativos e de exceção.

Qualidade e verificação

Validação: Validação responde se estamos construindo o sistema certo — se os requisitos resolvem o problema real.
Verificação: Verificação responde se estamos construindo o sistema corretamente — se o que foi feito corresponde ao que foi especificado.A confusão entre os dois é o erro de vocabulário mais comum da área.
Rastreabilidade: Rastreabilidade é a capacidade de seguir um requisito da sua origem até o código e o teste que o comprovam, e no sentido inverso.
Ambiguidade: Ambiguidade é a propriedade de um requisito que admite mais de uma interpretação razoável.É o defeito mais caro da especificação, porque só aparece quando o software já foi construído da forma errada.
INVEST: INVEST é o acrônimo dos seis atributos de uma boa user story: Independente, Negociável, Valiosa, Estimável, Pequena e Testável.
Gherkin: Gherkin é a linguagem estruturada que escreve critérios de aceite no formato Dado / Quando / Então, legível por pessoas e executável por ferramentas de teste.

Normas e referências

ISO/IEC/IEEE 29148: ISO/IEC/IEEE 29148 é a norma internacional que define os processos e o conteúdo esperado da documentação de requisitos de sistemas e software.Substituiu a IEEE 830, ainda muito citada em material antigo.
BABOK: BABOK (Business Analysis Body of Knowledge) é o corpo de conhecimento de análise de negócios publicado pelo IIBA, referência para técnicas de elicitação e análise.

Da necessidade ao documento pronto

O Espaço IA entrevista, transforma necessidade em requisito verificável e gera o SRS, a matriz de rastreabilidade e o documento de arquitetura.

Começar gratuitamente →