Para o PMBOK, requisito é uma condição ou capacidade cuja presença em um

produto, serviço ou resultado é exigida para satisfazer um contrato ou outra

condição formalmente imposta. Segundo Kossman (2013), um requisito é um
detalhamento de um aspecto específico de uma necessidade do cliente. Para
Singh e Vyas (2012), um requisito é uma condição ou capacidade necessária
para um usuário resolver um problema ou alcançar determinado objetivo.
Segundo esse mesmo autor, a maior causa do comprometimento dos
resultados dos projetos está associada a problemas com os requisitos, seja por
problemas na definição desses requisitos, por esquecimento no rastreamento
dos mesmos e pobreza nos processos relacionados a elicitação desses
requisitos.
No Guia PMBOK (5a edição), são apresentadas 11 (onze) ferramentas para o
processo Coletar Requisitos, são elas: entrevistas, grupos de discussão,
oficinas facilitadas, técnicas de criatividade em grupo, técnicas de tomada de
decisão em grupo, questionários e pesquisas, observações, protótipos,
benchmarking, diagramas de contexto e análise de documentos.
O que podemos observar é que tanto na documentação dos requisitos, quanto
na matriz de rastreabilidade, é necessário que as necessidades dos clientes
sejam claramente decompostas em requisitos, sejam eles de negócio, de
solução (funcionais e não funcionais), de projeto etc. Porém, as ferramentas
apresentadas pelo PMBOK (5a edição), não apresentam de forma clara um
processo de decomposição dessas necessidades em requisitos. Apenas na
ferramenta “oficinas facilitadas” é sugerida a possiblidade de utilização do QFD
para alcançar esse resultado e na ferramenta “diagramas de contexto”, onde
podemos visualizar, de forma vaga, o desenho de requisitos funcionais.
Bem turma, estou deixando em anexo, um artigo de minha autoria sobre a
ferramenta Axiomatic Design. Axiomatic Design (AD) é uma abordagem para
o desenvolvimento de projetos que procura gerar a melhor solução para um
determinado problema proposto (CARNEVALLI et al., 2010). Ele foi criado
e popularizado pelo professor Suh do Massachusetts Institute of Technology
(MIT), podendo ser aplicado em todas as atividades de concepção de um
produto (PARK, 2007). O AD tem avançado para criar uma base científica para
a concepção de um projeto, permitindo que os engenheiros e designers tomem
decisões de projetos corretas, aumentando a probabilidade de sucesso (SUH,
1998).
Segundo Suh (1998), o AD deve ser utilizado da seguinte forma:
“O primeiro passo no desenho de um sistema é determinar as necessidades
dos clientes (CN) ou atributos, no domínio do cliente, que o sistema deverá
satisfazer. Então, os requisitos funcionais e restrições do sistema, no domínio
funcional, são determinados para satisfazer às necessidades levantadas. O
próximo passo é mapear os requisitos funcionais dentro do domínio físico, ou
seja, escolher os parâmetros conceituais, tomando o cuidado para não gerar
conflitos com as restrições. Uma vez escolhidos esses parâmetros, passa-se
para a etapa do domínio do processo, onde as variáveis dos processos serão
identificadas, com o objetivo de desenvolver um novo processo de
fabricação ou usar algum processo existente”.
Segue o artigo completo para leitura e análise de dois exemplos incluídos no
artigo: AD_Artigo
Seguem alguns comentários sobre o uso do Axiomatic Design/Processo
Coletar Requisitos. VIDEO

https://www.youtube.com/watch?v=quy4SN18OEg

Segue, a tabela apresentada em vídeo que resumo os principais ponto do uso

do AD em diversas áreas de aplicação...
A fonte dessa tabela é o próprio criador do AD.
Domínio/Aplicação Domínio Cliente Domínio Funcional Domínio Físico Domínio Processo
Manufatura Atributos que Requisitos Variáveis físicas Variáveis que
o cliente funcionais – que podem podem
deseja funcionalidades satisfazer as desenvolver os
– do produto funcionalidades parâmetros
desejado físicos
Materiais Desempenho Propriedades Microestrutura Processo de
desejado do requeridas do material fabricação
material
Software Atributos Saídas Variáveis de Sub-rotinas,
desejados no específicas das entrada, Classes,
software partes dos algoritmos e módulos,
softwares codificação compiladores
Organizações Satisfação do Funções da Atividades, Pessoas e
cliente organização Programas outros
(transformações recursos que
necessárias) e podem
Escritórios suportar a
transformação
Sistemas Atributo Requisitos Máquinas, Recursos
desejado para funcionais do componentes,
todo o sistema sub-
sistema componentes
Negócio ROI Metas do Estrutura do Recursos
negócio Negócio humanos e
financeiros

Agora que vocês já conhecem os tipos de requisitos e a aplicação do Axiomatic

Design, vamos para a prática.
Antes, vou explicar o processo de detalhamento dos requisitos.
No Axiomatic Design, usamos uma decomposição hierárquica em modo zigue-
zague para definirmos (junto com o cliente) os requisitos do Projeto.
Funciona assim:
O Cliente define um Requisito Funcional (RF1). A equipe de projeto define a
solução técnica (RT1).
Uma vez definido RT1, continuamos a decomposição do RF1 com o cliente
(lembram do planejamento por ondas sucessivas?).
Se RF1 for decomposto em 3 Requisitos Funcionais (detalhamento de RF1),
RF11, RF12 e RF13, o próximo passo é definir RT11, RT12, RT13.

Vamos a um exemplo?
O cliente deseja uma Geladeira
...
Ele deseja preservar os alimentos comprados (necessidade do cliente).

Fonte: http://www.imagensanimadas.com/cat-geladeiras-e-refrigeradores-1481.htm
Como fazer isso?

Fonte: http://gifsdegatos.blogspot.com.br/2016/04/gato-com-duvida-gif.html
Inicialmente, o cliente sabe fornecer dois requisitos funcionais (comportamento
esperado):
RF1 = Uma área para conservar comida no longo prazo, como um
freezer (Desejável).
RF2 = Uma área para conservar comida no curto prazo (Mandatório).
Seguindo o método, vamos (equipe do projeto) definir os Requisitos Técnicos
RT1 e RT2, antes de decompor RF1 e RF2.
RT1 = Uma área de freezer.
RT2 = Uma área de refrigeração.
Assim, ao Definir RF1 e seu RT1, vamos (se for o caso) decompor RF1 (zigue-
zague).
RF1 = Uma área para conservar comida no longo prazo, como um freezer.
RF11 = Controle de temperatura do freezer operando entre -18 graus +/-5.
RF12 = Manter a temperatura uniforme em toda a área do freezer.
RF13 = Controle de humidade do freezer em 50%.
Agora podemos definir os Requisitos Técnicos RT11, RT12, RT13.
RT11 = Sistema de compressão com sensor para manter a temperatura
conforme definida pelo usuário.
RT12 = Sistema de circulação de ar que mantenha a mesma temperatura de
forma uniforme em todo o freezer.
RT13 = Sistema de condensação para manter a humidade.
O mesmo será feito para RF2 e RT2...
RF2 = Uma área para conservar comida no curto prazo.
RF21 = Controle de temperatura na área de refrigerador entre 2 e 5 graus.
RF22 = Manter a temperatura em toda área do refrigerador, com variação de no
máximo 1 grau.