Bate-papo Inicial...

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.

Assistam a aula!
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/Apli Domínio Domínio Domínio Domínio

cação Cliente Funcional Físico Processo
Manufatura Atributos Requisitos Variáveis Variáveis
que o funcionais físicas que que
cliente – podem podem
deseja funcionalid satisfazer desenvolv
ades – do as er os
produto funcionalid parâmetro
desejado ades s físicos

Materiais Desempe Propriedad Microestrut Processo

nho es ura do de
desejado requeridas material fabricação
do
material
 Software Atributos Saídas Variáveis Sub-
desejado específicas de entrada, rotinas,
s no das partes algoritmos Classes,
software dos e módulos,
softwares codificação compilado
res

Organizações Satisfaçã Funções da Atividades, Pessoas e

o do organizaçã Programas outros
cliente o (transforma recursos
ções que
necessárias podem
)e suportar a
Escritórios transform
ação

Sistemas Atributo Requisitos Máquinas, Recursos

desejado funcionais component
para do sistema es, sub-
todo o component
sistema es

Negócio ROI Metas do Estrutura Recursos

negócio do Negócio humanos
e
financeiro
s

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.

E o processo segue.

Vejam a figura abaixo:

Continua...
5:

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.