AXIOMATIC DESIGN

Prévia do material em texto

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 
derequisitos 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íniofuncional), 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 
utilizada por, pelo menos, 3 anos. 
Requisito Técnico 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. 
Requisito Funcional 2: O aluno precisa ter um 
espaço para acomodar os livros que não estão 
sendo usados. 
Requisito Técnico 2: Imediatamente abaixo do 
assento do aluno será inserida uma grade de 
aço, 
Requisito Funcional 3: A carteira deverá 
proporcionar conforto ao aluno (Restrição: a 
carteira deverá ser acolchoada). 
Requisito Técnico 3: Nos pontos localizados nas 
costas e no assento, a estrutura de ferro deverá 
ter um estofamento a ser produzido com o 
polímero X. 
Requisito Funcional 4: A carteira deverá permitir 
o uso de notebook pelo aluno e apoio para os 
livros. 
Requisito Técnico 4: Na carteira, para 
escrituração e leitura, deverá ser construída um 
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 
destros ou canhotos. 
Requisito Técnico 5: A estrutura da cadeira deve 
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 
Requisito Funcional Requisito Técnico 
Processo de Fabricação ou 
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 
um espaço para acomodar 
os livros que não estão 
sendo usados. 
RT 2: Imediatamente abaixo do 
assento do aluno será inserida 
uma grade de metal. 
PF2: No desenho da estrutura 
deverá ser incluída essa grade de 
metal, fabricada também na 
fábrica X. 
RF 3: A carteira deverá 
proporcionar conforto ao 
aluno (Restrição 1: a 
carteira deverá ser 
acolchoada). 
RT 3: Nos pontos localizados nas 
costas e no assento, a estrutura 
de ferro deverá ter um 
estofamento a ser produzido com 
o polímero X. 
PF 3: O estofamento deverá ser 
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á 
permitir o uso de notebook 
RT 4: Na carteira, para 
escrituração e leitura, deverá ser 
PF 4: O braço de apoio de 
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 
alunos destros ou canhotos. 
RT 5: A estrutura da cadeira 
deve comportar uma 
modularização tal que ajustes no 
processo de manufatura 
permitam facilmente o setup 
entre cadeiras para destro e 
canhoto. 
PF 5: 10% da estrutura metálica 
das carteiras devem ser 
fabricadas com o braço de apoio 
para atender os alunos canhotos. 
 
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çãoda 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 
Cliente ou do 
Negócio 
Requisitos 
Funcionais 
Requisitos Técnicos Processo de 
fabricação ou 
Implementação 
Melhoria da qualidade 
dos links: internet e 
corporativo 
O tráfego corporativo 
deve ser separado do 
tráfego de internet 
Implantação de duas 
redes: rede principal 
corporativa e rede de 
internet 
Deverá ser implantada 
duas redes, com 
roteadores diferentes 
para cada tipo de 
tráfego, sendo os 
endereços definidos 
pela Contratante. 
A separação do tráfego 
não deverá aumentar a 
complexidade da rede 
nas Organizações 
Militares 
Os dois tipos de 
tráfego devem ser 
integrados nas 
Organizações 
Militares, através de 
um roteador de 
integração que deverá 
ser conectado 
diretamente na LAN da 
Organização 
Haverá a aquisição de 
um roteador para 
integrar as duas redes 
nas Organizações 
Militares, devendo 
esse roteador suportar 
esse tipo de integração 
(porta da rede 
corporativa, porta da 
rede de internet, porta 
da rede LAN e porta 
reserva) 
A separação do tráfego 
não deverá representar 
um aumento da 
complexidade para 
gerenciar a EBNet 
Será utilizado o 
protocolo de 
roteamento PfR 
(Performance Routing), 
pois é um protocolo 
que permite a 
integração do tráfego 
sem aumentar a 
complexidade da 
gerência 
O roteador de 
integração a ser 
adquirido deverá 
suportar o protocolo 
PfR (o pessoal técnico 
deverá ser treinado 
nesse protocolo) 
O tráfego de dados 
corporativo deve 
priorizar dados de 
videoconferência 
Implantação de uma 
rede IP Multisserviços 
para o tráfego 
corporativo 3 (três) 
classes de serviço 
Todos os roteadores a 
serem usados na rede 
corporativa devem 
permitir a 
 
Confidencial ©MundoPM, 2015 Pagina 11 of 17 
 
 
Artigo Candidato Versão: <1.0> 
 
 
distintas: aplicações de 
videoconferência 
corporativa (prioridade 
1), voz corporativa 
(VoIP – prioridade 2) e 
dados (prioridade 3) 
implementação de 
QoS 
O tráfego de internet 
deve seguir os padrões 
de mercado 
A rede de Internet, 
deve operar no 
sistema de ​Best Effort 
 
Serão admitidos 
roteadores com 
características técnicas 
mais básicas, desde 
que sigam os 
requisitos técnicos 
definidos 
EBNet com maior 
disponibilidade que a 
solução atual 
Os dados corporativos 
das Organizações 
Militares devem 
trafegar da forma mais 
eficiente até chegarem 
no seu destino 
Para o tráfego de 
dados corporativos, a 
rede a ser implantada 
deverá possuir 
topologia ​full mesh 
Os roteadores da rede 
corporativa devem ser 
configurados para 
permitir a arquitetura 
full mesh 
Os links de internet 
das Organizações 
Militares devem ser 
providos pelo seu 
Centro de Telemática 
de apoio 
(Restrição determinada 
pelo Projeto Provedor 
de Internet) 
Os CTA/CT são os 
pontos de 
concentração regionais 
que deverão 
concentrar o tráfego 
das OM a eles 
vinculadas, de acordo 
com uma topologia 
hub-and-spoke 
Os roteadores da rede 
internet devem ser 
configurados para 
permitir a arquitetura 
hub-and-spoke e todas 
as demais 
configurações que 
permitam as 
redundâncias 
apontadas 
Os links de internet 
devem possuir 
redundância 
Em caso de 
indisponibilidade na 
prestação do serviço 
pelo Centro de 
Telemática, a 
CONTRATADA deverá 
fornecer acesso dos 
pontos de presença 
das Organizações 
Militares da região de 
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 
(redundância do 
sistema) deverá, 
A contingência do 
CITEx, em caso de 
indisponibilidade deste 
 
Confidencial ©MundoPM, 2015 Pagina 12 of 17 
 
 
Artigo Candidato Versão: <1.0> 
 
 
também, possuir um 
ponto de redundância 
Centro, será́ o 7° 
Centro de Telemática 
Por serem os pontos 
mais importantes da 
EBNet, os Centros de 
Telemática necessitam 
ter uma disponibilidade 
maior que as demais 
Organizações Militares 
Os acessos aos PP do 
sítio central, do sítio 
redundante e dos sítios 
localizados nos 
CTA/CT deverão 
possuir caminhos 
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 queestá 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