Axiomatic Design​: uma ferramenta para descrição completa dos

requisitos
Luciano Sales​1​; Sanderson Barbalho​2​; Shirley Moura​3

Resumo  –  ​O gerenciamento de requisitos é uma importante ferramenta para a concepção e

planejamento de um projeto, porém, a despeito da sua importância e de sua relativa maturidade,
observam-se erros frequentes nesse processo, devido, principalmente, a ênfase inapropriada, ou
mesmo exclusão, de um ou mais tipos de requisitos durante a fase de concepção de um projeto. ​O
Axiomatic Design (AD) é uma abordagem para o desenvolvimento de produtos que procura gerar a
melhor solução para um determinado problema proposto, tendo 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. ​Assim, o objetivo deste
artigo é o de identificar e descrever uma estrutura para a concepção de requisitos que leve em
consideração o AD, evitando os erros identificados nesse processo.
 
(Palavras-chave: Requisitos; Coletar Requisitos; Axiomatic Design)

Introdução

Erros em projetos podem ocorrer em todas as suas fases, porém, um dos mais prejudiciais está
relacionado com erros na elicitação de requisitos (SINGH, 2014; RAMINGWONG, 2012). Segundo
Kossman (2013), erros no gerenciamento de requisitos acarretam retrabalho, gerando custos maiores
que o planejado e atrasos nos projetos. Assim, tempo e foco investido no gerenciamento de requisitos
são fundamentais para o desenvolvimento de produtos com qualidade (RAMINGWONG, 2012;
SUDIN; AHMED-KRISTENSEN, 2011).

Segundo Singh (2012), a engenharia de requisitos possui um importante papel no desenvolvimento

de produtos, possuindo métodos e técnicas relativamente maduras. No entanto, a despeito da
importância do gerenciamento de requisitos e de sua relativa maturidade, observam-se erros
frequentes nesse processo, devido, principalmente, a ênfase inapropriada, ou mesmo exclusão, de
um ou mais tipos de requisitos durante a fase de concepção de um projeto (RAMINGWONG, 2012).
Segundo Mulla e Girase (2012), as atuais abordagens para elicitação de requisitos mostraram-se
insuficientes para registrar de forma correta, completa e consistente os requisitos, sendo um dos
grandes desafios para a engenharia de requisitos a melhoria nesse processo.

O Guia PMBOK (5ª edição), possui um processo, dentro do gerenciamento do escopo do projeto, que
trata de forma específica da coleta de requisitos: o processo Coletar Requisitos. Esse processo,
 Artigo Candidato Versão: <1.0>

procura fornecer uma base para a "definição e gerenciamento do escopo do projeto, INCLUINDO o
escopo do produto".

Na literatura, também, existem uma série de técnicas para a identificação, coleta de requisitos e
especificações técnicas, como o desdobramento da função qualidade (QFD) – citado no Guia

PMBOK ​(5ª edição)​ - ​e o ​axiomatic design​ (AD).

Neste artigo, o AD será́ analisado como alternativa de mitigação aos problemas relacionados com o
gerenciamento de requisitos em projetos, através da seguinte questão de pesquisa: Como o AD pode
alavancar o processo Coletar Requisitos? Assim, o objetivo deste artigo é o de identificar e descrever
uma estrutura para a concepção de requisitos que leve em consideração o AD, evitando os erros
identificados nesse processo. Para isso serão apresentados os conceitos relacionados ao processo
de coleta de requisitos e as suas principais falhas de acordo com a literatura, bem como serão
apresentados o AD e a sua possível contribuição para o desenvolvimento de um processo mais
robusto para o gerenciamento de projetos.

A importância dos requisitos no gerenciamento de projetos

Para o PMBOK (5ª edição), 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 cenário atual, os produtos possuem características cada vez mais complexas e de natureza
multidisciplinar, pois precisam atender às necessidades de clientes cada vez mais interessados na
qualidade e no desempenho (GONÇALVES-COELHO et al, 2005). Assim, desenvolver um produto
complexo, que contém inúmeros sistemas e componentes é um grande desafio a ser implementado.
De nada adianta ter uma equipe multidisciplinar, se não houver uma complexa coordenação de todos
os requisitos identificados, compreensão das prioridades e gerenciamento de um grande número de

Confidencial ©MundoPM, 2015 Pagina 2 of 17

 Artigo Candidato Versão: <1.0>

tarefas que precisam permanecer alinhadas com o tempo e orçamento planejado, para alcançar as
necessidades e expectativas dos clientes (BHISE, 2013).

Não há como escapar: produtos precisam ser desenvolvidos para satisfazer certas necessidades das
pessoas. A qualidade de um produto depende de inúmeras atividades, sendo o processo de
concepção (​design​) uma das atividades mais importantes (GONÇALVES-COELHO et al, 2005).
Assim, o sucesso do projeto é diretamente influenciado pelo envolvimento ativo das partes
interessadas na descoberta e decomposição das suas necessidades em requisitos, e pelo cuidado
tomado na determinação e gerenciamento dos requisitos do produto, serviço ou resultado (PMBOK,
5ª edição). Para esse guia, “Coletar os Requisitos” é o processo de determinar, documentar e
gerenciar as necessidades e requisitos das partes interessadas, a fim de atender aos objetivos do
projeto.

O Tribunal de Contas da União, em seu Guia de Boas Práticas em Contratação de Soluções de

Tecnologia da Informação (2014), recomenda que, nas compras da administração pública, d​evem ser
considerados, pelo menos, os seguintes tipos de requisitos: Requisitos Internos Funcionais (são
aqueles ligados diretamente às funcionalidades esperadas pela área requisitante e necessárias aos
usuários finais, de maneira a atender à necessidade da contratação; Requisitos Internos Não
Funcionais ​(​são os não vinculados diretamente à necessidade da contratação, mas igualmente
importantes para sua satisfação); e os Requisitos Externos ​(​são os gerados fora da organização,
como as demandas legais, regulatórias e de padronização estabelecidas pelo Governo Federal).

Ou seja, quer nas empresas privadas ou na administração pública, a coleta e consequente definição
de requisitos devem sempre ocorrer. Sem requisitos claros, vinculados às necessidades dos clientes
e/ou do negócio, a execução de um projeto se torna onerosa para as organizações, pois os padrões
de qualidade não serão atingidos, resultando em retrabalho, custos adicionais em aditivações
contratuais e desmotivação das equipes e dos clientes.

Ferramentas para a coleta dos requisitos

No Guia PMBOK (5ª 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.

Confidencial ©MundoPM, 2015 Pagina 3 of 17

 Artigo Candidato Versão: <1.0>

Essas ferramentas devem ser utilizadas para produzir, como saída do processo, dois documentos:
a) Documentação dos requisitos: onde é descrito como os requisitos individuais atendem às
necessidades do negócio. Nesse documento, os requisitos não devem ser descritos de forma
ambígua, ou seja, devem ser mensuráveis e passíveis de testes. Também devem ser
rastreáveis, completos, consistentes e aceitáveis pelas partes interessadas.
b) Matriz de rastreabilidade dos requisitos: uma tabela que liga os requisitos de produto desde
as suas origens até as entregas que os satisfazem, conforme Figura 1.
Figura 1 – Matriz de rastreabilidade de requisitos

Fonte: ​PMBOK, 5ª edição

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 (5ª 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.

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

Confidencial ©MundoPM, 2015 Pagina 4 of 17

 Artigo Candidato Versão: <1.0>

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).

O AD é uma abordagem que inicia com uma declaração explícita do “o que nós queremos alcançar” e
termina com uma clara descrição do “como nós alcançaremos isso” (THOMPSON, 2013). Segundo
Suh (1998), o AD nada mais é que o mapeamento de um conjunto de variáveis, que se inicia com as
necessidades dos clientes, em outros domínios, de forma que se chegue a uma solução ótima da
concepção de um produto que atenda aquelas necessidades inicialmente levantadas. Do ponto de
vista do AD, a concepção de um produto necessita passar por quatro domínios distintos
(GONÇALVES-COELHO et al, 2005):

− Domínio do cliente, através da identificação das necessidades dos clientes ou do negócio (as
características que o cliente pretende encontrar em um objeto, seja ele um produto, um
processo, ou qualquer sistema tangível ou intangível);
− Domínio conceitual, através da identificação dos requisitos funcionais do objeto (um requisito
funcional descreve um comportamento que um dispositivo deve ter) e suas restrições
(representam os limites de uma solução aceitável);
− Domínio físico, através de parâmetros conceituais ou requisitos técnicos (o conjunto de
propriedades que descrevem fisicamente o objeto); e
− Domínio do processo, através de um esboço de como fazer o objeto concebido (ligado ao
processo de manufatura).

Esses domínios podem ser compreendidos através do processo representado pela Figura 2.

Figura 2 – O processo de concepção mapeado através dos quatro domínios do AD

Confidencial ©MundoPM, 2015 Pagina 5 of 17

 Artigo Candidato Versão: <1.0>

Fonte: Gonçalves-Coelho et al (2005)

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 varáveis dos processos serão
identificadas, com o objetivo de desenvolver um novo processo de fabricação ou usar
algum processo existente”.

Além do processo descrito acima, o AD possui dois importantes axiomas (PARK, 2007):

Axioma 1: Independência – Os requisitos funcionais precisam ser mantidos de forma independente,

ou seja, a concepção mais otimizada irá sempre manter a independência entre requisitos funcionais.
Além disso, uma concepção aceitável deve levar em consideração que um requisito técnico e um
requisito funcional devem estar relacionados de tal forma, que um ajuste em um requisito técnico para
satisfazer seus correspondente requisito funcional, não afetará outros requisitos funcionais. Ou seja, a
melhor solução ocorre quando há uma relação de 1:1 entre requisitos funcionais e técnicos.

Confidencial ©MundoPM, 2015 Pagina 6 of 17

 Artigo Candidato Versão: <1.0>

Axioma 2: Informação – Deve-se minimizar o conteúdo da informação da concepção (complexidade),

ou seja, a melhor definição de requisito deve possuir o mínimo de conteúdo possível. Assim, entre as
inúmeras soluções possíveis para descrever um requisito que atenda ao axioma 1, deve-se escolher
aquela que atenda o axioma 2.

É importante ressaltar que o desenho da solução requer um contínuo processo de construção entre e
dentro dos quatro domínios, ou seja, o conteúdo de cada domínio evolui de conceitos abstratos para
informações mais detalhadas, conforme mais informações são agregadas ao projeto ​(ALBANO E
SUH, 1994).

O AD possui inúmeras aplicações, também, na área de TI, incluindo na Engenharia de Software.

Segundo Suh (2001), a lógica permanece a mesma: O primeiro passo é determinar os atributos dos
clientes (no domínio clientes), depois os requisitos funcionais e restrições do software precisam ser
estabelecidos (domínio funcional), para satisfazer as necessidades dos clientes. O próximo passo é
desenhar esses requisitos funcionais dentro do domínio físico, através da identificação dos requisitos
técnicos (“como” o desenho irá satisfazer os requisitos funcionais – do ponto de vista lógico: seja por
uma função, por uma classe etc.). Ao final, o processo de implementação precisa ser definido, no
domínio dos processos.

Axiomatic Design e a coleta de requisitos em projetos: exemplo e estudo de

caso

Assim, o AD pode ser utilizado como ferramenta que torna o processo de coleta de requisitos mais
simples e ao mesmo tempo completo, permitindo a identificação plena do que se deseja implementar.
Serão apresentados dois exemplos: o primeiro um exemplo conceitual, para melhor compreensão da
ferramenta, o segundo, um caso implementado na definição de requisitos do projeto para
implementação da rede de telecomunicações de longa distância do Exército.

Imaginem que um projeto deve ser desenvolvido para a construção de carteiras escolares para
adolescentes de escolas públicas. O gerente do projeto precisa coletar os requisitos desse projeto e
definir todos os requisitos em uma documentação de requisitos, como recomenda o Guia PMBOK.

As técnicas de entrevistas, grupos de discussão etc., ajudarão na identificação das principais

necessidades do cliente, bem como no mapeamento dessas necessidades em requisitos funcionais,
como descrito no processo do AD.

Confidencial ©MundoPM, 2015 Pagina 7 of 17

 Artigo Candidato Versão: <1.0>

Necessidade do Cliente 1: Carteiras para alunos do ensino médio.

Requisito Funcional 1: A carteira deverá ser utilizada por, pelo menos, 3 anos.

Requisito Funcional 2: O aluno precisa ter um espaço para acomodar os livros que não estão sendo
usados.

Requisito Funcional 3: A carteira deverá proporcionar conforto ao aluno (Restrição: a carteira deverá
ser acolchoada).

Requisito Funcional 4: A carteira deverá permitir o uso de notebook pelo aluno.

Requisito Funcional 5: Deve atender a alunos destros ou canhotos.

Após a definição dos requisitos funcionais (ou seja, o comportamento que o produto deve ter), serão
definidos requisitos técnicos (preferencialmente, atendendo ao Axioma 1 e 2).

Tabela 1: Mapeamento Requisitos Funcionais em Requisitos Técnicos

Requisito Funcional Requisito Técnico

Requisito Funcional 1: A carteira deverá ser Requisito Técnico 1: A carteira será produzida
utilizada por, pelo menos, 3 anos. com estrutura em metal, reforçada nos pontos de
contato direto dos alunos, para suportar um peso
máximo de 100 quilos.

Requisito Funcional 2: O aluno precisa ter um Requisito Técnico 2: Imediatamente abaixo do

espaço para acomodar os livros que não estão assento do aluno será inserida uma grade de
sendo usados. aço,

Requisito Funcional 3: A carteira deverá Requisito Técnico 3: Nos pontos localizados nas
proporcionar conforto ao aluno (Restrição: a costas e no assento, a estrutura de ferro deverá
carteira deverá ser acolchoada). ter um estofamento a ser produzido com o
polímero X.

Requisito Funcional 4: A carteira deverá permitir Requisito Técnico 4: Na carteira, para

o uso de notebook pelo aluno e apoio para os escrituração e leitura, deverá ser construída um
livros. braço de apoio. Esse braço deve possuir uma
barra de metal no lado inferior (próximo ao aluno)
que permita o encaixe de um notebook.

Confidencial ©MundoPM, 2015 Pagina 8 of 17

 Artigo Candidato Versão: <1.0>

Requisito Funcional 5: Deve atender a alunos Requisito Técnico 5: A estrutura da cadeira deve
destros ou canhotos. comportar uma modularização tal que ajustes no
processo de manufatura permitam facilmente o
setup entre cadeiras para destro e canhoto.

Com a definição dos requisitos funcionais e técnicos, surge a necessidade de definição dos
processos que irão permitir a implementação ou fabricação de cada um desses requisitos:

Tabela 2: Mapeamento Requisitos Funcionais e Requisitos Técnicos em Processos de

Fabricação

Processo de Fabricação ou
Requisito Funcional Requisito Técnico
Implementação

RF1: A carteira deverá ser
utilizada por, pelo menos, 3
anos.
RT 1: A carteira será produzida
com estrutura em metal,
reforçada nos pontos de contato
direto dos alunos, para suportar
um peso máximo de 100 quilos.
PF1: A estrutura de metal será
desenhada e produzida na fábrica
X.

RF 2: O aluno precisa ter RT 2: Imediatamente abaixo do PF2: No desenho da estrutura

um espaço para acomodar assento do aluno será inserida deverá ser incluída essa grade de
os livros que não estão uma grade de metal. metal, fabricada também na
sendo usados. fábrica X.

RF 3: A carteira deverá RT 3: Nos pontos localizados nas PF 3: O estofamento deverá ser

proporcionar conforto ao
aluno (Restrição 1: a
carteira deverá ser
acolchoada).
costas e no assento, a estrutura
de ferro deverá ter um
estofamento a ser produzido com
o polímero X.
levado em consideração no
desenho da estrutura, porém, o
mesmo será produzido na fábrica
Y. Após cada lote da estrutura de
metal ser produzido, serão
transportados para a Fábrica Y
para estofamento.

RF 4: A carteira deverá RT 4: Na carteira, para PF 4: O braço de apoio de

permitir o uso de notebook escrituração e leitura, deverá ser madeira, com as dimensões M e

Confidencial ©MundoPM, 2015 Pagina 9 of 17

 Artigo Candidato Versão: <1.0>

pelo aluno e apoio para os
livros.
construída um braço de apoio de
madeira com as seguintes
dimensões: M e N. Esse braço
deve possuir uma barra de metal
no lado inferior (próximo ao
aluno) que permita o encaixe de
um notebook.
N será fabricado na Fábrica Y. O
metal para encaixe do notebook
será produzido na Fábrica X,
devendo ser transportado para a
Fábrica Y, uma vez que a
montagem final ocorrerá nessa
fábrica.

RF 5: Deve atender a RT 5: A estrutura da cadeira PF 5: 10% da estrutura metálica

alunos destros ou canhotos.
deve comportar uma das carteiras devem ser
modularização tal que ajustes no fabricadas com o braço de apoio
processo de manufatura para atender os alunos canhotos.
permitam facilmente o setup
entre cadeiras para destro e
canhoto.

Assim, teremos identificados todos os requisitos necessários para confeccionar a documentação dos
requisitos, e, ao mesmo tempo, teremos uma rastreabilidade dos requisitos desde a necessidade do
negócio até as suas entregas.

No segundo exemplo, o AD foi utilizado na prática para a elaboração de um Termo de Referência

(TR)para a contratação da rede de telecomunicações de longa distância do Exército (EBNet), pelo
Centro Integrado de Telemática do Exército (CITEx), o provedor de serviços de TI do Exército, e suas
12 (doze) unidades operacionais, espalhadas pelo território brasileiro, os Centros de Telemática (CT).

Cabe ressaltar que, é obrigatório na Administração Pública que os requisitos funcionais (ou mesmo os
técnicos), para justificar a sua inclusão em um termo de referência, estejam mapeados em uma
necessidade clara do negócio. Assim, a matriz utilizada atende (e auxilia nesse atendimento), a uma
exigência legal dos processos de contratação da Administração Pública.

Nesse caso, resumido, já que o TR completo possuía mais de 100 páginas, as principais
necessidades do negócio, eram a “melhoria da qualidade dos links da EBNet” e uma “maior
disponibilidade da EBNet”. Todas as necessidades foram identificadas através de entrevistas e
grupos de discussão com integrantes do negócio e clientes (Organizações Militares), realizadas pela

Confidencial ©MundoPM, 2015 Pagina 10 of 17

 Artigo Candidato Versão: <1.0>

equipe do projeto. Os requisitos funcionais foram identificados através de grupos de discussão com
integrantes da alta administração do CITEx e a equipe do projeto.

Os requisitos técnicos e processos de fabricação foram identificados e definidos através de

entrevistas às principais empresas interessadas na implantação do projeto, conforme processos de
aquisição do Guia PMBOK.

Tabela 3: Extrato da Matriz de Rastreabilidade dos Requisitos do Projeto EBNet

Necessidade do Requisitos Requisitos Técnicos Processo de

Cliente ou do Funcionais fabricação ou
Negócio Implementação
O tráfego corporativo Implantação de duas Deverá ser implantada
deve ser separado do redes: rede principal duas redes, com
tráfego de internet corporativa e rede de roteadores diferentes
internet para cada tipo de
tráfego, sendo os
endereços definidos
pela Contratante.
A separação do tráfego Os dois tipos de Haverá a aquisição de
não deverá aumentar a tráfego devem ser um roteador para
complexidade da rede integrados nas integrar as duas redes
nas Organizações Organizações nas Organizações
Militares Militares, através de Militares, devendo
um roteador de esse roteador suportar
integração que deverá esse tipo de integração
ser conectado (porta da rede
diretamente na LAN da corporativa, porta da
Melhoria da qualidade
Organização rede de internet, porta
dos links: internet e
da rede LAN e porta
corporativo
reserva)
A separação do tráfego Será utilizado o O roteador de
não deverá representar protocolo de integração a ser
um aumento da roteamento PfR adquirido deverá
complexidade para (Performance Routing), suportar o protocolo
gerenciar a EBNet pois é um protocolo PfR (o pessoal técnico
que permite a deverá ser treinado
integração do tráfego nesse protocolo)
sem aumentar a
complexidade da
gerência
O tráfego de dados Implantação de uma Todos os roteadores a
corporativo deve rede IP Multisserviços serem usados na rede
priorizar dados de para o tráfego corporativa devem
videoconferência corporativo 3 (três) permitir a
classes de serviço

Confidencial ©MundoPM, 2015 Pagina 11 of 17

 Artigo Candidato Versão: <1.0>

distintas: aplicações de implementação de

videoconferência QoS
corporativa (prioridade
1), voz corporativa
(VoIP – prioridade 2) e
dados (prioridade 3)
O tráfego de internet A rede de Internet, Serão admitidos
deve seguir os padrões deve operar no roteadores com
de mercado sistema de ​Best Effort características técnicas
mais básicas, desde
que sigam os
requisitos técnicos
definidos
Os dados corporativos Para o tráfego de Os roteadores da rede
das Organizações dados corporativos, a corporativa devem ser
Militares devem rede a ser implantada configurados para
trafegar da forma mais deverá possuir permitir a arquitetura
eficiente até chegarem topologia ​full mesh full mesh
no seu destino
Os links de internet Os CTA/CT são os
das Organizações pontos de
Militares devem ser concentração regionais
providos pelo seu que deverão
Centro de Telemática concentrar o tráfego
de apoio das OM a eles
(Restrição determinada vinculadas, de acordo
pelo Projeto Provedor com uma topologia
de Internet) hub-and-spoke
Os links de internet Em caso de
Os roteadores da rede
EBNet com maior devem possuir indisponibilidade na
internet devem ser
disponibilidade que a redundância prestação do serviço
configurados para
solução atual pelo Centro de
permitir a arquitetura
Telemática, a
hub-and-spoke e todas
CONTRATADA deverá
as demais
fornecer acesso dos
configurações que
pontos de presença
permitam as
das Organizações
redundâncias
Militares da região de
apontadas
abrangência do
referido Centro de
Telemática ao sítio
central (CITEx), de
forma automática e
transparente para o
usuário
O sítio central A contingência do
(redundância do CITEx, em caso de
sistema) deverá, indisponibilidade deste

Confidencial ©MundoPM, 2015 Pagina 12 of 17

 Artigo Candidato Versão: <1.0>

também, possuir um Centro, será́ o 7°

ponto de redundância Centro de Telemática
Por serem os pontos Os acessos aos PP do
mais importantes da sítio central, do sítio
EBNet, os Centros de redundante e dos sítios
Telemática necessitam localizados nos
ter uma disponibilidade CTA/CT deverão
maior que as demais possuir caminhos
Organizações Militares físicos distintos e
independentes

Logicamente, para as empresas licitantes, quanto mais claros forem os requisitos, menores serão os
riscos e, consequentemente, menores serão os custos ocultos. Além disso, com o entendimento do
projeto, mais concorrentes tendem a participar do processo de contratação: quanto mais
concorrência, menores os custos.

Essa matriz permite um mapeamento claro do que efetivamente se deseja construir com um projeto,
agregando informações para a documentação dos requisitos e para a matriz de rastreabilidade dos
requisitos, tornando a definição do escopo mais fácil para ser desenvolvida. O resultado do projeto
EBNet 2015 levou a uma economia de mais de 50% na contratação da nova rede (comparando-se ao
contrato anterior), aumentando a disponibilidade e dobrando a velocidade dos links para as
Organizações Militares: um grande sucesso para a organização.

Conclusão

Neste artigo, o AD foi analisado como alternativa de mitigação aos problemas relacionados com o
gerenciamento de requisitos. Assim, o objetivo deste artigo foi identificar e descrever uma estrutura
para a concepção de requisitos que leve em consideração o AD, evitando os erros identificados nesse
processo. A questão de pesquisa “Como o AD pode alavancar o processo Coletar Requisitos?” foi
respondida através da aplicação prática do conhecimento teórico desenvolvido e, também, da
proposta de incorporação do seu uso no processo Coletar Requisitos do PMBOK.

O processo Coletar Requisitos utilizado no Guia PMBOK é bem recente, sendo incorporado a esse
Guia apenas na sua quarta edição, o que, permite especular que ainda passa por um processo de
melhoria contínua e maturidade. O AD pode vir a contribuir com o PMBOK como uma ferramenta

Confidencial ©MundoPM, 2015 Pagina 13 of 17

 Artigo Candidato Versão: <1.0>

robusta para coleta e elicitação dos requisitos, agregando valor para as atuais ferramentas descritas
no Guia ​PMBOK (5ª edição).

Para o gerenciamento de projeto, o AD alavanca o processo de coleta de requisitos, contribuindo para

a qualidade dos produtos e serviços a serem desenvolvidos, permitindo a rastreabilidade clara de
tudo o que está sendo desenvolvido, alavancando o gerenciamento do escopo do projeto e,
finalmente, contribuindo de forma decisiva nos resultados perseguidos pelas organizações.

Bibliografia
ALBANO, Leonard D., SUH, Nam P. Axiomatic design and concurrent engineering. Computer-Aided
Design, (26) 7, 1994.

BHISE, Vivek D. Design Complex Products with Systems Engineering Processes and Techniques.
CRC Press. 2013.

CARNEVALLI, José Antonio, et al. Axiomatic design application for minimising the difficulties of QFD
usage. Production Economics 125 (2010) 1-12.

GONÇALVES-COELHO, Antonio M., ​et al. Improving the use of QDF with Axiomatic Design.
Concurrent Engineering: Research and Applications. Vol. 13, N. 3, 2005.

KOSSMANN, Mario. Requirements Management: how to ensure you achieve what you need from
your projects. England: Gower, 2013.

MULLA, Nilofar. GIRASE, Sheetal. A new approach to requirement elicitation based on stakeholder
recommendation and collaborative filtering. International Journal of Software Engineering &
Applications (IJSEA). Vol.3, N. 3, 2012.

PARK, Gyung-Jin. Analytic Methods for Design Pratice. Springer. 2007.

PMI (Project Management Institute). The PMBOK Guide (5ª edição). Project Management Institute,
2013.

RAMINGWONG, Lachana. A review of requirements engineering processes, problems and models.

International Journal of Engineering Science and Technology. Vol. 4, N. 6, 2012.

SINGH, M. P., VYAS, Rajnish. ANALYSIS OF REQUIREMENT ENGINEERING PROBLEMS AND

PROPOSED SOLUTIONS. International Journal of Advanced Research in Computer Science and
Electronics Engineering (IJARCSEE) Vol. 1, N. 7, 2012.

Confidencial ©MundoPM, 2015 Pagina 14 of 17

 Artigo Candidato Versão: <1.0>

SINGH, Rajinder. Comprehensive Study of Impact of Requirement Engineering Processes on Rework.

International Journal of Computer Trends and Technology (IJCTT). Vol. 9, N. 5, 2014.

SUDIN, Mohd Nizam; AHMED-KRISTENSEN, Saeema. Change in requirements during the design
process. INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN. 2011.

SUH, Nam Pyo. Axiomatic Design: advances and applications. Oxford: Oxford University Press, 2001.

SUH, Nam Pyo. Axiomatic design theory for systems. Research in Engineering Design. Vol. 10. 1998.

THOMPSOM, Mary Kathryn. Improving the requirements process in Axiomatic Design Theory. ​CIRP
Annals - Manufacturing Technology 62 (2013) 115–118.

Tribunal de Contas da União. Guia de Boas Práticas em Contratação de Soluções de Tecnologia da

Informação (2014).

Sobre o Autores​:

Luciano Sales, lucianofrc@gmail.com

Luciano Sales, é o gerente do Programa Amazônia Conectada no Centro Integrado de
Telemática do Exército e professor da Fundação Getúlio Vargas (FGV); doutorando em sistemas
mecatrônicos pela Universidade de Brasília, mestre em Gestão do Conhecimento e da Tecnologia da
Informação pela Universidade Católica de Brasília (UCB); é pós-graduado (MBA) em Gestão Estratégica
pela Fundação Getúlio Vargas (FGV); Engenheiro de Computação pelo Instituto Militar de Engenharia
(IME); Bacharel em Ciências Militares pela Academia Militar das Agulhas Negras (AMAN); certificado
Program Management Professional (PgMP) e Project Management Professional (PMP) pelo Project
Management Institute (PMI); MSP Foundation e Practitioner, PRINCE2 Foundation e Practitioner, ITIL
V2 Service Manager e ITIL V3 EXPERT, pelo Office of Government Commerce (OGC); foi Diretor de
Certificação do Capítulo PMI-AM.

Possui graduação em Engenharia Elétrica pela Universidade Federal do Rio Grande do Norte (1993), mestrado
em Engenharia Mecânica pela Universidade Federal do Rio Grande do Norte (1997) e doutorado em Engenharia
Mecânica pela Universidade de São Paulo (2006), ambos, mestrado e doutorado, desenvolvidos na área de
Engenharia de Produção. É pós-doutor em Engenharia de Produção pela Universidade Federal de São Carlos
(UFSCar). É profissional em gestão de projetos com certificado PMP (Project Management Professional), pelo
Project Management Institute (PMI). Atualmente é professor adjunto do Departamento de Engenharia de
Produção da Universidade de Brasília (UnB). Atuou entre janeiro de 2003 e janeiro de 2008 como engenheiro de
desenvolvimento sênior e gerente de projetos, e entre janeiro de 2008 e agosto de 2012 como Gerente do
Escritório de Projetos da OPTO ELETRÔNICA S.A. Tem experiência nas áreas de Engenharia Eletrônica,
Processos de Fabricação e de Gerência da Produção, com ênfase em Desenvolvimento de Produto. Tem atuado
em projetos de mapeamento de processos de planejamento e controle da produção em organizações militares e
em projetos vinculados à defesa cibernética no âmbito do Governo Brasileiro.

Confidencial ©MundoPM, 2015 Pagina 15 of 17

 Artigo Candidato Versão: <1.0>

Confidencial ©MundoPM, 2015 Pagina 16 of 17

 Artigo Candidato Versão: <1.0>

Confidencial ©MundoPM, 2015 Pagina 17 of 17