AD - Axiomatic Design

Prévia do material em texto

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 o cliente deseja
	Requisitos funcionais – funcionalidades – do produto desejado
	Variáveis físicas que podem satisfazer as funcionalidades
	Variáveis que podem desenvolver os parâmetros físicos
	Materiais
	Desempenho desejado do material
	Propriedades requeridas
	Microestrutura do material
	Processo de fabricação
	Software
	Atributos desejados no software
	Saídas específicas das partes dos softwares
	Variáveis de entrada, algoritmos e codificação
	Sub-rotinas, Classes, módulos, compiladores
	Organizações
	Satisfação do cliente
	Funções da organização
	Atividades, Programas (transformações necessárias) e Escritórios
	Pessoas e outros recursos que podem suportar a transformação
	Sistemas
	Atributo desejado para todo o sistema
	Requisitos funcionais do sistema
	Máquinas, componentes, sub-componentes
	Recursos
	Negócio
	ROI
	Metas do negócio
	Estrutura do Negócio
	Recursos 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.