Aula 5

Projeto Informacional
Prof. Fabrício Páris

Projeto de Produto – Engenharia Mecânica

Projeto Informacional
Projeto Informacional
• Após a definição do produto a ser desenvolvido, o próximo passo é o
estabelecimento das especificações de projeto do produto;
• Essa atividade tem o objetivo de propiciar o entendimento e a
descrição do problema na forma funcional, quantitativa e
qualitativamente, formalizando a tarefa de projeto;
• Os resultados desta atividade fornece a base sobre a qual serão
montados os critérios de avaliação para as tomadas de decisão
realizadas nas etapas posteriores do processo de projeto;
Projeto Informacional
Projeto Informacional
Projeto Informacional
Projeto Informacional
Projeto Informacional
Projeto Informacional
Projeto Informacional
Elicitação das necessidades dos usuários - métodos

• Entrevistas estruturadas com usuários: a gravação e a transcrição

destas entrevistas com os reais usuários fornecem uma informação
textual e mantém a essência da voz do consumidor enquanto
necessária. Geralmente estas entrevistas são estruturadas, baseadas e
preparadas com base em atributos típicos do produto objeto da
pesquisa;
Elicitação das necessidades dos usuários - métodos

• Que tipo de entrevista? As entrevistas individuais são mais eficientes

do que as entrevistas focadas em grupos. Há tendências potenciais e
aspectos de dinâmica de grupo que prejudicam a obtenção de dados
(inibição, p.ex.), em maior profundidade e detalhes, quando focado em
grupos de usuários;
• Quantas entrevistas devem ser feitas? Um número de 20 ou 30
entrevistas num grupo homogêneo de usuários pode garantir que 90%
ou mais das necessidades sejam identificadas. No entanto, o tópico e o
entrevistado também devem ser considerados; caso sejam mais
complexos, pode-se necessitar de mais entrevistas;
Elicitação das necessidades dos usuários - métodos

• Quem deve conduzir a entrevista? Membros da equipe de

desenvolvimento do projeto podem obter maior visão dos usuários ao ouvir
os mesmos discutirem seus problemas e preocupações. Ao menos a equipe
de projeto deve assistir ou ver os vídeos das entrevistas;
• O que o entrevistador deve falar? Um plano para os entrevistadores deve
ser organizado para garantir um bom fluxo e um entendimento dos tópicos
que serão de interesse. Os usuários, com frequência, apresentam soluções,
quando o objetivo da entrevista deve ser o levantamento de necessidades
que levaram a pensar nestas soluções. Por exemplo, usando “Por que?”
como a palavra chave da entrevista pode ser perguntado: Por que baixo
custo é um referencial importante neste projeto? Por que deve ser priorizada
a segurança independente do custo?
Elicitação das necessidades dos usuários - métodos
Elicitação das necessidades dos usuários - métodos
Elicitação das necessidades dos usuários - métodos
Elicitação das necessidades dos usuários - métodos

• Parcerias ou alianças no projeto: a participação de usuários na realização

do projeto também é uma forma de se conhecer as necessidades dos
usuários;
• Consultores e especialistas: profissionais em mercadologia são capacitados
na identificação das necessidades dos usuários e podem ser contratados ou
consultados. O método de Delphi é uma forma sistemática de buscar
informações desta natureza junto a especialistas sobre um produto ou
tecnologia objeto do desenvolvimento.
• Sessões de Brainstorming: este método solicita entradas que encorajam a
geração de ideias inovadoras que fujam do ordinário e mudem os conceitos
do tipo de produto em estudo.
Elicitação das necessidades dos usuários - métodos

• Experiências pessoais e da empresa: que trazem necessidades de sucessos

e de falhas de produtos passados, ou planilhas e modelos de referência
desenvolvidos para identificar necessidades ou atributos típicos do produto.
• Pesquisa em material publicado: revistas, jornais, leis, projetos de lei,
normas, patentes, incluindo o uso da Internet fornecem dados e diretrizes
de necessidades dos usuários;
• Análise de mercado e benchmarking da concorrência: esta análise
identifica os melhores na classe e ideias inovadoras;
• Prototipagem e realidade virtual: estas técnicas podem ser empregadas
para estudar respostas de usuários e, também, promover recomendações à
equipe de projeto.
Elicitação das necessidades dos usuários - métodos

• (Brasil) INPI:
https://gru.inpi.gov.br/pePI/servlet/LoginController?action=login
• (América Latina) LATPAT:
https://lp.espacenet.com/
• (União Europeia) ESPACENET:
https://worldwide.espacenet.com/
• (World Intellectual Property Organization) WIPO:
https://patentscope.wipo.int/search/en/search.jsf
Elicitação das necessidades dos usuários - métodos

• Google Patents:
https://patents.google.com/
Transformação das necessidades em requisitos
de usuários
• As necessidades dos usuários são transformadas ou traduzidas para os
requisitos de usuários usando-se uma linguagem mais compacta e
apropriada ao entendimento geral da equipe de desenvolvimento;
• Na tabela a seguir tem-se uma amostra de atributos típicos de sistemas
técnicos que podem ser utilizados como um dicionário de tradução das
necessidades de usuários para os requisitos de usuários.
Conversão dos requisitos de usuários em
requisitos de projeto
• A conversão de requisitos de usuário em requisitos de projeto significa
estabelecer características de engenharia do produto. Estas
características expressam, conforme REICH (1996), a “voz da
engenharia”.
• São, em essência, os atributos do produto que podem ser manipulados
(modificados, retirados, incluídos, ampliados, diminuídos, etc.) para
satisfazer os requisitos dos usuários.
Conversão dos requisitos de usuários em
requisitos de projeto
• A palavra tradução é empregada para designar uma forma de
interpretação de cada requisito de usuário e expressar o resultado,
numa linguagem técnica orientada ao objeto de estudo, os chamados
requisitos de projeto, que devem ser na medida do possível parâmetros
mensuráveis;
• A tradução dos requisitos de usuários em requisitos de projeto não é de
um-a-um, pois um requisito de usuário pode ser expresso por vários
parâmetros, dimensões ou requisitos de projeto.
Conversão dos requisitos de usuários em
requisitos de projeto
• As características de engenharia ou requisitos de projeto, quando
adequadamente formulados, terão papel relevante para a solução dos
problemas e satisfação dos usuários.
• Na realidade, estas características da engenharia podem ser entendidas
como os próprios problemas de projeto a serem resolvidos. São
elas que vão orientar a equipe de projeto na busca de soluções
alternativas e na avaliação das mesmas.
• Elas têm o propósito de estabelecer os parâmetros, grandezas, funções,
restrições, entre outros atributos do produto, os quais "mapeiam" os
problemas técnicos de um dado contexto.
Casa da Qualidade
Introdução
• A Casa da Qualidade permite priorizar os Requisitos de Projeto, o que
viabiliza a realização das Especificações de Projeto;
Casa da Qualidade
Casa da Qualidade
Casa da Qualidade
Priorização dos requisitos de projeto
• Se um requisito de projeto (característica de engenharia) não afeta
nenhum requisito de usuário, ou seja, todas as células da coluna têm
valor nulo, então, este requisito de projeto pode não ter significado,
pode ser um parâmetro desnecessário.

• Se for o caso de um produto sendo reprojetado ou um caso de

engenharia reversa e se todas células numa coluna estiverem vazias, a
equipe de elicitação das necessidades pode ter esquecido de questionar
certo tipo de usuário.
 Requisitos do
Projeto

Usuários

Estética
Robustez
Silencioso

Mobilidade
Cinemática

Soma Total
Requisitos dos

Estabilidade
Confiabilidade
Mantenabilidade
Ruído do atrito do vento

5
1
5
0
0
0
0
5

16
com a pá (dB)
Ruído e vibração do

5
1
5
0
0
1
1
5

18
rolamento-eixo (Hz)
Tempo de manutenção

5
3
1
5
0
3
5
0

22
(h)
Número de componentes

3
1
1
5
1
5
5
0

21
(Nº)
Casa da Qualidade

3
0
0
0
5
5
5
3

21
Tempo de uso (anos)

Resistência a fadiga (nº

3
0
0
0
5
5
5
0

18
de ciclos)
Taxa de falha
5
0
1
0
5
5
5
0

21

(falhas/ano)
Resistência mecânica
3
1
0
0
5
5
3
0

17

(MPa)
Peso do equipamento
3
1
5
5
3
0
3
0

20

(N)
Velocidade de ínicio de
3
0
5
3
3
0
0
3

17

operação (m/s)
Torque de ínicio de
3
0
5
3
3
0
0
3

17

operação (Nm)
Forma agradável
9
0
5
0
0
0
0
3
1

(subjetivo)
5
3
3
0
0
3
5
1

20

Fixação das pás (N)

Fixação da sitema no
5
3
1
3
0
3
5
3

23

local de geração (N)

Priorização dos requisitos de projeto
• A simples soma dos valores dos relacionamentos em uma coluna
do campo IV dá uma ordenação da importância dos requisitos de
projeto para atender às necessidades dos usuários.

• Se for efetuada o somatório, em cada coluna, do produto do valor do

relacionamento pelo peso de importância porcentual do requisito do
usuário, tem-se uma ordenação de prioridade dos requisitos de
projeto em função da importância atribuída pelo usuário às suas
necessidades e da taxa de melhoramento pretendida pela empresa.
Planejamento da qualidade desejada
• Trata-se da atribuição de valores de importância aos requisitos de
usuário, bem como a valoração de produtos concorrentes;
• Assim, se esta tarefa for subestimada e seus resultados duvidosos,
estes serão “transferidos” para as demais informações de
desenvolvimento do produto e poderão conduzir a soluções
inadequadas.
• Para a definição da importância do requisito de usuário pode ser
atribuído um valor numérico baseado numa dada escala;
• Esse valor indica como o requisito deverá ser “visto” pela equipe
durante a solução do problema;
Planejamento da qualidade desejada
• Recomenda-se que sejam estabelecidos valores relativos para cada
requisito através do julgamento da própria equipe de desenvolvimento;

• AKAO (1990), apresenta um método alternativo para calcular o valor

dos requisitos dos usuários, chamados pelo autor de peso da qualidade
demandada.
Planejamento da qualidade desejada
Casa da Qualidade
Conversão dos requisitos de projeto em
especificações de projeto
• Para cada requisito de projeto deve-se prever grandezas mensuráveis e
meios ou métodos de verificar se a solução a ser desenvolvida
atenderá este requisito de projeto;
• Outros dados necessários para completar a redação de cada
especificação de projeto são os possíveis efeitos negativos ou riscos
decorrentes, na busca de soluções para implementar a respectiva
especificação;
• Assim, as especificações de projeto com a classificação, em ordem
decrescente, obtida conforme descrito no item anterior, juntamente
com o modo de verificação e os possíveis riscos, podem ser
apresentados numa tabela.
Conversão dos requisitos de projeto em
especificações de projeto
Redação das especificações de projeto
• Na redação da especificação deve-se verificar se existe uma
necessidade para a mesma e questioná-la. O que poderia acontecer se
a especificação não fosse incluída e atendida? Se a resposta não
trouxer qualquer consequência, provavelmente, a especificação
não será necessária;

• Uma declaração da especificação deve incluir uma forma de

verificação e um critério de aceitação da mesma. A especificação
deve ser alcançável tecnicamente e ser compatível com o
orçamento, programação e outras restrições.
Redação das especificações de projeto
• Se a especificação é necessária, verificável e viável então a redação
deve expressar um único pensamento, ser concisa e simples.
• Uma especificação não deve apresentar dúvidas na interpretação e não
ser ambígua.
• Em geral frases simples e curtas são suficientes para a apresentação de
boas especificações.
Qualidade das especificações de projeto
• Descrição de “o que” e não de “como”: A especificação não deve
apresentar soluções preconcebidas para o produto a ser desenvolvido.
Para chegar-se a este resultado, é preciso questionar porque a
especificação é necessária e então derivar os reais requisitos;
• Atomicidade: a especificação deve ser suficientemente fracionada ou
detalhada. Isto é, deve haver um único propósito, uma ideia por
especificação. Cada especificação deve ser alocada a uma única
entidade física;
Qualidade das especificações de projeto
• Detalhamento: o maior ou menor detalhamento de uma especificação
depende da audiência ou dos fornecedores. Para comunicações
internas ou com fornecedores com procedimentos bem definidos, a
linguagem pode ser de alto nível, mas quando se trata de fornecedores
sem estas capacidades, as especificações devem ser desdobradas num
fino detalhamento;
• Viabilidade: é necessário que cada especificação seja passível de
implementação dentro das capacidades e limitações do sistema em
desenvolvimento e de seu meio ambiente.
Qualidade das especificações de projeto
• Quantificável: deve-se, na medida do possível, atribuir valores
quantitativos às especificações de projeto. Deve-se especificar um
atributo de um sistema a ser projetado. Sem uma quantificação pode
ocorrer a elevação de custo devido a um superdimensionamento ou, o
valor necessário não é atingido.