Tese M - Análise de Stakeholders Mapas Cognitivos 64016

ii
Dados Internacionais de Catalogação-na-Publicação (CIP)

Divisão de Informação e Documentação
López Villafranca, Brenda Carolina
Processo de Análise de Stakeholders Utilizando Mapas Cognitivos / Brenda Carolina López Villafranca.
São José dos Campos, 2012.
196f.
Tese de Mestrado – Engenharia Aeronáutica e Mecânica na Área de Produção – Instituto Tecnológico de

Aeronáutica, 2012. Orientador: Dr. Geilson Loureiro.
1. Análise de Stakeholders 2. Mapas Cognitivos 3. Engenharia de Requisitos. I. Instituto Tecnológico de

Aeronáutica. Engenharia Aeronáutica e Mecânica. Área de Produção. II Título.
REFERÊNCIA BIBLIOGRÁFICA
LÓPEZ VILLAFRANCA, Brenda Carolina. Processo de Análise de Stakeholders

Utilizando Mapas Cognitivos. 2012. 196f. Tese de Mestrado em Produção – Instituto
Tecnológico de Aeronáutica, São José dos Campos.
CESSÃO DE DIREITOS
NOME DO AUTOR: Brenda Carolina López Villafranca

TÍTULO DO TRABALHO: Processo de Análise de Stakeholders Utilizando Mapas Cognitivos
TIPO DO TRABALHO/ANO: Tese de Mestrado / 2012
É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta

tese e para emprestar ou vender cópias somente para propósitos acadêmicos e científicos. O
autor reserva outros direitos de publicação e nenhuma parte desta tese pode ser reproduzida
sem a sua autorização (do autor).
Brenda Carolina López Villafranca

Rua João Teixeira Netto No. 102 Apto. 701
Parque Residencial Aquarius, São José dos Campos, SP
iii
PROCESSO DE ANÁLISE DE STAKEHOLDERS

UTILIZANDO MAPAS COGNTIVOS
Composição da Banca Examinadora:
Profa. Dra. Ligia Maria Soto Urbina Presidente – ITA
Prof. Dr. Geilson Loureiro Orientador – ITA
Prof. Dr. Luís Gonzaga Trabasso ITA
Dr. Paulo Tadeu de Mello Lourenção Embraer
ITA
iv
Dedico este trabajo a la Brenda de ayer que aceptó el desafío

y enfrentó este proceso complejo en su contexto.
A Christian, mi compañero de vida que siempre creyó

y me incentivó con su ejemplo de determinación
y a los pedacitos de mi corazón,
que son la principal motivación de este esfuerzo.
A mis padres que siempre se entregaron junto conmigo

en mis logros y me dieron todas las armas necesarias
para llegar a donde estoy, siempre siendo modelos de perseverancia.
A mis hermanos, que aunque estando lejos,

siempre acompañaron mis luchas.
v
Agradecimentos
Agradeço ao Brasil e ao Instituto Tecnológico de Aeronáutica, porque ainda sendo
estrangeira, me privilegiaram com educação de excelência, à Profa. Ligia, que sempre foi luz
nos dias difíceis, ao Prof. Cabral por me abrir as portas desta instituição, ao meu orientador o
Prof. Geilson Loureiro por seu olhar crítico sempre visando a qualidade do trabalho e à banca
examinadora: Profa. Ligia, Prof. Gonzaga e ao Dr. Lourenção pelas contribuições que
ajudaram a melhorar esta tese. Agradeço também ao LIT/INPE por permitir e fornecer o
ambiente ideal para a pesquisa e experimentação, a Susan Teves, Denio Lemos, Marcio
Bueno e Durval Zandonadi pela disposição para participar da pesquisa, aos meus
companheiros do LSIS Karina Zanta, Renato Calado e Carlos Lino, porque eles também
foram grandes contribuidores para o desenvolvimento e conclusão deste trabalho com seus
conhecimentos, conselhos e pela força brindada, a Raquel Dias pelo apoio e orientação
brindados no inicio deste trabalho. Agradeço especialmente aos meus compadres Dinho e
Paula por seu apoio e suporte incondicional durante dias de trabalho. Agradeço a Deus, que
me colocou aqui e agora, e por todo o aprendizado que deixou este processo de descobertas,
que foi muito mais do que um grau acadêmico.

vi
Resumo
Objetivo do trabalho é propor um processo para a Análise de Stakeholders utilizando
mapas cognitivos a fim de auxiliar no processo da elicitação de necessidades raiz. O processo
proposto aborda desde o estudo do contexto até a identificação das necessidades e
informações relevantes para serem transformadas em requisitos e a estruturação do problema
a partir do ponto de vista do stakeholder. A motivação do trabalho vem da dificuldade no
entendimento das necessidades dos stakeholders no desenvolvimento de sistemas, sejam eles
produto, processo ou serviço. O processo proposto se fundamenta nos conceitos da
Engenharia de Sistemas e da Cognição e seus Mapas Cognitivos. O trabalho aporta três
principais contribuições, a primeira é a elicitação exaustiva com o stakeholder até chegar à
necessidade raiz, utilizando o processo cognitivo por meio dos repetidos questionamento até
chegar à raiz do assunto. A segunda contribuição é na captura gráfica do rationale das
necessidades mais relevantes. A terceira contribuição é a de ajudar ao stakeholder a entender
sua própria necessidade e/ou problema, também com a ajuda do processo cognitivo utilizado
na criação dos mapas. De esta maneira obtendo como resultado informações relevantes
elicitadas junto com seu rationale e o entendimento do problema. O processo proposto foi
aplicado num estudo piloto dentro do Laboratório de Integração e Testes (LIT) do Instituto
Nacional de Pesquisas Espaciais (INPE). O Processo de Análise de Stakeholders Utilizando
Mapas Cognitivos pode ser considerado como uma opção válida na hora de decidir a
estratégia da Análise de Stakeholders; ele facilita a aproximação com o stakeholder e fornece
uma ferramenta iterativa e interativa que incita à reflexão tanto para o stakeholder expressar
suas necessidades quanto para que o engenheiro de sistemas possa gerar questionamentos e
ambos construírem conclusões do problema e seu contexto dando partida à concepção da
solução.
vii
Abstract
The objective of this work is to propose a stakeholder analysis process using cognitive
mapping, aiming to support the process to elicit root needs. The proposed process encompass
the context study up to the identification of the relevant needs and its rationale, which would
be transformed into requirements, besides the problem structuring from the stakeholder’s
point of view. The motivation comes from the difficulty in understanding the stakeholder’s
needs during the system development process, where the system can be considered as product,
process or service. The proposed process has its foundations on the Systems Engineering
concepts and cognition and its Cognitive Mapping concepts. This work has three main
contributions, the first is the exhaustive elicitation with the stakeholder until getting the root
need, making use of the cognitive process, thru repeated questioning until getting to the root
of the issue. The second contribution is the graphic capture of the relevant needs rationale.
The third contribution is to help the stakeholder to understand its own needs and/or problem,
also aided with the cognitive process used during the mapping. Obtaining as results, the
elicited relevant information and its rationale and the comprehension of the problem. The
proposed process was applied in a pilot study at the Laboratory of Integration and Testing
(LIT) of the Brazilian Institute for Space Research (INPE). The Stakeholder Analysis Process
Using Cognitive Mapping can be considered as an option at the time to formulate the strategy
for the Stakeholder Analysis. It enables the approach to be used with the stakeholder and
provides an interactive and iterative tool that incite reflection for the stakeholder to express
his needs and to the systems engineer to create questions, thus, both of them construct the
conclusions of the problem and its context, giving space for the solution conception.
viii
Lista de Siglas e Acrônimos
CBERS China-Brazil Earth Resources Satellite
ConOps Concept of Operations
EGSE Electronic Ground Support Equipment
GSE Ground Support Equipment
IDEF0 Integration Definition for Function Modeling
IEEE Institute of Electrical and Electronics Engineers
INCOSE International Council on Systems Engineering
INPE Instituto Nacional de Pesquisas Espaciais
IRA Infra-Red Array
LIT Laboratório de Integração e Testes
LSIS Laboratório de Engenharia Simultânea de Sistemas
MGSE Mechanical Ground Support Equipment
MoE’s Measure of Effectiveness
NASA National Aeronautics and Space Administration
SODA Strategic Options Development and Analysis
TBT Teste de Balanço Térmico

ix
Sumário
1 INTRODUÇÃO ...........................................................................................................................12
1.1 CONTEXTO E ESCOPO DA TESE .......................................................................................................... 12
1.2 PROBLEMA ................................................................................................................................... 13
1.3 MOTIVAÇÃO ................................................................................................................................. 15
1.4 OBJETIVOS.................................................................................................................................... 18
1.4.1 Objetivo Geral.................................................................................................................. 18
1.4.2 Objetivos Específicos ....................................................................................................... 18
1.5 METODOLOGIA ............................................................................................................................. 18
1.6 ESTRUTURA DA TESE....................................................................................................................... 20
2 ENGENHARIA DE SISTEMAS ......................................................................................................22
2.1 PROCESSO DE ENGENHARIA DE SISTEMAS ........................................................................................... 24
3 ENGENHARIA DE REQUISITOS ..................................................................................................27
3.1 REQUISITOS .................................................................................................................................. 27
3.2 RATIONALE DOS REQUISITOS ............................................................................................................ 28
3.3 PROCESSO DE ENGENHARIA DE REQUISITOS ........................................................................................ 29
4 ANÁLISE DE STAKEHOLDERS .....................................................................................................32
4.1 DEFINIÇÃO DE STAKEHOLDERS .......................................................................................................... 32
4.2 A ANÁLISE DAS NECESSIDADES DOS STAKEHOLDERS .............................................................................. 33
4.3 TRANSIÇÃO DAS NECESSIDADES DOS STAKEHOLDERS .............................................................................. 35
4.4 TÉCNICAS DE ELICITAÇÃO DE NECESSIDADES ........................................................................................ 37
5 COGNIÇÃO ...............................................................................................................................40
5.1 REPRESENTAÇÕES MENTAIS ............................................................................................................. 41
5.1.1 Representações oral e escrita .......................................................................................... 42

x
5.1.2 Representações visuais .................................................................................................... 43
5.2 MAPAS COGNITIVOS....................................................................................................................... 45
5.2.1 Mapas Conceituais .......................................................................................................... 46
5.2.2 Mapas Causais................................................................................................................. 46
6 TÉCNICAS DE ELICITAÇÃO DE NECESSIDADES UTILIZANDO MAPAS COGNITIVOS......................50
6.1 MAPAS COGNITIVOS DE MANEIRA GERAL ........................................................................................... 50
6.2 LADDERING................................................................................................................................... 51
6.3 SODA: DESENVOLVIMENTO E ANÁLISE DE OPÇÕES ESTRATÉGICAS .......................................................... 55
7 PROCESSO DE ANÁLISE DE STAKEHOLDERS UTILIZANDO MAPAS COGNITIVOS ........................58
7.1 ESCOPO E OBJETIVOS DO PROCESSO .................................................................................................. 58
7.1.1 Escopo ............................................................................................................................. 58
7.1.2 Objetivos.......................................................................................................................... 60
7.2 INTERPRETAÇÃO DA MODELAGEM DO PROCESSO .................................................................................. 61
7.3 PROCESSO DE ALTO NÍVEL ............................................................................................................... 62
7.4 SUBPROCESSO 1.0 ANÁLISE DO CONTEXTO ......................................................................................... 64
7.5 SUBPROCESSO 2.0 ELABORAÇÃO DA ESTRATÉGIA DE INTERVENÇÃO ......................................................... 70
7.6 SUBPROCESSO 3.0 ELICITAÇÃO DAS INFORMAÇÕES DOS STAKEHOLDERS COM MAPAS COGNITIVOS ............... 74
7.7 SUBPROCESSO 4.0 ANÁLISE DOS MAPAS COGNITIVOS .......................................................................... 82
7.8 SUBPROCESSO 5.0 IDENTIFICAÇÃO DE NECESSIDADES E ANÁLISE DO PROBLEMA ........................................ 92
7.9 DESENVOLVIMENTO DO PROCESSO .................................................................................................... 98
7.10 RAÍZES E CONTRIBUIÇÕES DO PROCESSO PROPOSTO ........................................................................ 99
8 EXEMPLO DE APLICAÇÃO DO PROCESSO ................................................................................109
8.1 CONTEXTO.................................................................................................................................. 109
8.2 A SHUNT BOX ............................................................................................................................. 109
8.3 APLICAÇÃO DO PROCESSO DE ANÁLISE DE STAKEHOLDERS .................................................................... 110
8.4 LIÇÕES APRENDIDAS DURANTE A APLICAÇÃO ...................................................................................... 149
9 DISCUSSÃO ............................................................................................................................151
xi
9.1 CUMPRIMENTO DOS OBJETIVOS DO PROCESSO DESENVOLVIDO .............................................................. 152
9.1.1 Objetivo 1: Auxiliar na elicitação de informações de stakeholders. .............................. 152
9.1.2 Objetivo 2: Auxiliar na estruturação das informações extraídas .................................. 152
9.1.3 Objetivo 3: Capturar o rationale.................................................................................... 153
9.1.4 Objetivo 4: Auxiliar no nivelamento de entendimento .................................................. 153
9.2 A UTILIZAÇÃO DOS MAPAS COGNITIVOS PARA A ANÁLISE DE STAKEHOLDERS ........................................... 153
9.3 COMPARAÇÃO COM ABORDAGENS SIMILARES DE ELICITAÇÃO DE NECESSIDADES........................................ 156
9.3.1 Mapas Cognitivos de maneira geral .............................................................................. 156
9.3.2 Laddering ....................................................................................................................... 157
9.3.3 SODA.............................................................................................................................. 157
9.4 VANTAGENS DO PROCESSO ............................................................................................................ 159
9.5 DESVANTAGENS DO PROCESSO ....................................................................................................... 161
10 CONCLUSÃO ...........................................................................................................................164
10.1 OBJETIVOS ESPECÍFICOS ........................................................................................................... 164
10.2 OBJETIVO GERAL ..................................................................................................................... 165
10.3 TRABALHOS FUTUROS .............................................................................................................. 167
REFERÊNCIAS ...................................................................................................................................169
APÊNDICE A: FLUXOS DO DIAGRAMA DE CONTEXTO IDEF0 DO PROCESSO PROPOSTO ...................173
APÊNDICE B: FLUXOGRAMA DO PROCESSO DE ANÁLISE DE STAKEHOLDERS UTILIZANDO MAPAS
COGNITIVOS. ................................................................................................................................................179
APÊNDICE C: TIPOS DE APLICAÇÃO DO PROCESSO DE ANÁLISE DE STAKEHOLDERS UTILIZANDO
MAPAS COGNITIVOS .....................................................................................................................................180
APÊNDICE D: EVOLUÇÃO DA FIGURA DE APOIO PARA A ANÁLISE DE STAKEHOLDERS DO ESTUDO
PILOTO SHUNT BOX. .....................................................................................................................................182
APÊNDICE E: DETALHAMENTO DO ESTUDO DO PROBLEMA ............................................................185
ANEXO A: CORRESPONDÊNCIA COM O PESQUISADOR PHD. JAMES BRYANT ..................................192

12
1 Introdução
1.1 Contexto e Escopo da Tese
O ciclo de vida de um sistema à luz da Engenharia de Sistemas contempla, segundo o
INCOSE sete fases: Pesquisa Exploratória, Concepção, Desenvolvimento, Produção,
Utilização, Suporte e Descarte (INCOSE, 2011). A fase de concepção se inicia com a Análise
de Stakeholders, a qual faz parte do Processo de Engenharia de Requisitos, é o elo entre a fase
de Concepção e a de Desenvolvimento.
A Figura 1 contextualiza o Processo da Análise de Stakeholders dentro da Engenharia
de Sistemas.
Figura 1 Escopo e contexto do Processo de Análise de Stakeholders
O escopo do processo de Análise de Stakeholders se delimita de maneira transversal
ao longo dos diferentes níveis de abstração da concepção, desde a definição da missão até o
13
nível em que o envolvimento do stakeholders para elicitação de informações seja necessário.
Este nível pode variar dependendo da complexidade do sistema em análise.
O INCOSE (2011, p. 55) define stakeholder da sequinte maneira:
O Stakeholder é qualquer entidade (individual ou organização) com um

interesse legítimo no sistema... usuários, operadores, organizações que tomam
decisões, partes do acordo, órgãos reguladores, agências desenvolvedoras,
organizações de suporte e a sociedade em geral”.
A Análise de Stakeholders tem como objetivo entender o problema e as necessidades
dos mesmos. Esta tese propõe um processo que suporte e auxilie esta análise.
Portanto, o escopo do processo proposto nesta tese é o escopo da Análise de
Stakeholders dentro do contexto da Engenharia de Requisitos em seus diferentes níveis de
abstração.
1.2 Problema
Um dos principais desafios referentes ao desenvolvimento de novos produtos é o
entendimento das necessidades do cliente, pois o objetivo do desenvolvimento é satisfazer
essas necessidades. Se estas não são entendidas corretamente pelos engenheiros de sistemas,
pelos projetistas e até pelos próprios stakeholders, será inviável chegar numa solução
adequada.
É difícil para os próprios stakeholders explicitar e entender suas necessidades. É nesse
ponto que entra a tarefa do engenheiro de sistemas, a de entender e ajudar a entender o
stakeholder quais são suas necessidades. O engenheiro de sistemas busca a visão do todo. Ele
está estudando o problema e seu contexto e pode auxiliar ao stakeholder no entendimento do
problema.
14
No ano 2010, este trabalho se iniciou com uma pesquisa para conhecer as principais
dificuldades ou problemas na Engenharia de Requisitos no cluster aeroespacial de São José
dos Campos, SP. Na pesquisa de campo documentada no artigo “Mapeamento Cognitivo
como uma técnica para apoio à Engenharia de Requisitos” (Dias, López & Belderrain, 2012)
foram identificados alguns dos problemas enfrentados no trabalho do dia a dia dos
profissionais da área. Na pesquisa, consultaram-se três engenheiros de sistemas, dois
engenheiros de sistemas voltados à área aeronáutica e um terceiro voltado à área de foguetes.
Os resultados desta pesquisa, com relação à Análise de Stakeholders estão
representados no Quadro 1. Na coluna do lado esquerdo, listam-se os problemas identificados
e na coluna do lado direito, como o processo proposto de Análise de Stakeholders ajudará a
minimizá-los.
Quadro 1 - Problemas abordados pelo Processo de Análise de Stakeholders Utilizando Mapas Cognitivos.
Problemáticas da Engenharia de Requisitos / Suporte que se espera que o processo proposto
Análise de Stakeholders: forneça:
Elicitação de requisitos deficiente Amplo escopo de informações extraídas como:
informações para requisitos de stakeholders e para
requisitos de sistema, como: necessidades essenciais,
restrições, medidas de efetividade (métricas), desejos,
alternativas de solução, suposições, entre outras.
Requisitos subjetivos Identificação da raiz das necessidades subjetivas dos
stakeholders.
Dificuldade dos stakeholders em identificar e Dados extraídos de maneira estruturada em clusters,
entender suas necessidades para a melhor análise do problema.
Dificuldade dos desenvolvedores em Linha de raciocínio até um dado relevante
entenderem as necessidades dos stakeholders Justificativa de um dado relevante; e
Visualização gráfica das informações extraídas.
Rastreabilidade deficiente dos requisitos e seu Linha de raciocínio até um dado relevante;
rationale. Visualização gráfica da cognição das informações
extraídas.
Fonte: Adaptado de Dias, López & Belderrain, 2012

15
1.3 Motivação
A Análise de Stakeholders se refere ao entendimento do pensamento das pessoas
envolvidas com o sistema, sua percepção e seu relacionamento com este. Partindo da premissa
de que o objetivo da Análise de Stakeholders é o entendimento de suas expectativas, e que a
maneira de perceber, estruturar e resolver um problema é única para cada um deles. Ainda que
o stakeholder seja uma organização, esta é representada por pessoas que refletem a sua cultura
e seus valores.
Essa individualidade se deve ao fato de que a maneira como as pessoas percebem e
resolvem os problemas depende de suas vivências passadas, experiências e valores, além das
lições aprendidas em problemas similares e no ambiente ou contexto onde o problema se
apresenta.
Levando em consideração que a Engenharia de Sistemas geralmente acontece num
ambiente de engenharia e desenvolvimento de alta tecnologia e, apesar de que sempre se
enfatiza seu caráter multidisciplinar, poucas vezes é levado em consideração o fator humano
sob o ponto de vista cognitivo. Isto é, o entendimento da maneira como o stakeholder
expressa suas necessidades e desejos, a maneira de reconhecer e identificar seus problemas;
de expressá-los, estruturá-los e resolvê-los. Nos últimos anos, está sendo abordado o tema da
Engenharia Cognitiva, mas voltado para engenharia de software em sistemas safety-critical
como proposto por Leveson (2009).
O fator humano é de grande importância para o sucesso da concepção de um sistema
na fase inicial devido a que as necessidades nascem do stakeholder, um ser humano com
necessidades que serão satisfeitas pelo sistema. O claro entendimento do stakeholder no início
da concepção do sistema é fundamental para poder dar a solução adequada.

16
A Engenharia de Requisitos é composta por várias tarefas, uma delas a elicitação de
informações, comumente conhecida como elicitação de requisitos. A maioria dos requisitos
resultam das informações extraídas dos stakeholders.
Neste processo de Análise de Stakeholders não somente se elicitam necessidades.
Durante os contatos e conversas com os stakeholders, se elicitam desejos, sentimentos,
necessidades, restrições, frustrações, sonhos, ou ainda, informações confusas e contraditórias
e/ou de difícil expressão. É um processo rico em informações e entrelinhas que requerem mais
do que habilidades de engenharia para poder captar, capturar e interpretar.
É importante entender a real necessidade dos stakeholders, necessidades de fundo ou
necessidades raiz e entender se realmente a necessidade pode ser resolvida com um sistema
complexo, se realmente quem é responsável por dar uma solução, é capaz de propô-la,
concebê-la e implementá-la. Podem existir casos em que a solução esteja na melhoria de um
processo e não no desenvolvimento de um novo sistema tangível e/ou complexo.
É importante que o engenheiro de sistemas tenha habilidades de elicitação, de
questionar para levar ao stakeholder até sua necessidade raiz, ou real necessidade. Elicitação
não é simplesmente perguntar e aceitar a primeira resposta do stakeholder, elicitação é ajudar
o stakeholder a transmitir informações que ele não tinha pensado nem refletido, ajudar na
estruturação dessas ideias para definir claramente o problema, o escopo do problema e suas
restrições. Lembrando que essas informações podem ser ambíguas e sem estrutura.
Valorizando o entendimento profundo e detalhado dos stakeholders a partir de sua
percepção do problema, nasce a motivação para propor um processo para a Análise de
Stakeholders que tem o objetivo de capturar de maneira exaustiva as informações que o
stakeholder pode transmitir por meio de um processo de elicitação utilizando mapas
cognitivos.
17
A motivação desta pesquisa iniciou-se com o trabalho realizado em Dias, R; Lopez &
Belderrain (2012); a partir dos problemas enfrentados na Engenharia de Requisitos quanto na
customização da ferramenta de mapas cognitivos utilizada por Ensslin, Montibeller &
Noronha (2002); para assim evoluir num processo de Análise de Stakeholders.
Esse processo proposto de Análise de Stakeholder Utilizando Mapas Cognitivos
integra as necessidades de um processo para elicitação de informações dos stakeholders com a
ferramenta de Mapas Cognitivos em sua utilização de estruturação de problemas proposta por
Ensslin, Montibeller & Noronha (2001), com uma série de adaptações para este propósito.
Parte-se de duas premissas para propor o Processo de Análise de Stakeholders
Utilizando Mapas Cognitivos. A primeira premissa é que alguns dos desafios da Engenharia
de Requisitos é o claro entendimento do problema e das necessidades dos stakeholders, e o
como lidar com requisitos subjetivos. A segunda premissa é que a Ferramenta de Mapas
Cognitivos é utilizada para lidar com dados subjetivos na estruturação de problemas. Assume-
se que utilizar a ferramenta de estruturação de problemas com dados subjetivos pode atender
as necessidades da Análise de stakeholders na Engenharia de Requisitos.
Existem poucas técnicas exclusivas na Engenharia de Sistemas, voltadas para o
desenvolvimento de produto, na elicitação de requisitos de stakeholders. Utilizam-se
ferramentas genéricas e não muito específicas como entrevistas estruturadas e não
estruturadas, documentos existentes, técnicas de focus groups, work shops, entre outras, para
o entendimento das necessidades dos stakeholders de um produto ou serviço. O processo
proposto é um método específico, detalhado e com uma aplicação sistêmica para elicitar
qualquer tipo de informações dos stakeholders de maneira detalhada, exaustiva e estruturada;
sejam elas necessidades, MoE’s, Restrições, pressupostos, etc.

18
1.4 Objetivos
1.4.1 Objetivo Geral
O objetivo desta tese é propor um processo de Análise de Stakeholders utilizando
uma ferramenta de mapas cognitivos customizada, para que auxilie na fase de Análise de
Stakeholders dentro da Engenharia de Sistemas.
1.4.2 Objetivos Específicos
1. Analisar os problemas existentes durante a Análise de Stakeholders: entender
quais são as dificuldades que um engenheiro de sistemas enfrenta na hora de
elicitar informações dos stakeholders.
2. Desenvolver e detalhar um processo de Análise de Stakeholders: Com base nas
dificuldades identificadas no processo de Análise de Stakeholders na literatura
e em campo, e com estudo da ferramenta de Mapas Cognitivos, propor e
detalhar um processo que atenda às necessidades da Análise de Stakeholders.
3. Aplicar o processo desenvolvido num exemplo prático que permita
experimentar as dificuldades da Análise de Stakeholders e os benefícios e
dificuldades que o processo pode trazer à Análise.
4. Avaliar e discutir os resultados da aplicação: Avaliar desde o ponto de vista do
Engenheiro de Sistemas a utilidade do processo e avaliar a posição do
stakeholder em quanto ao processo, se sua participação ajuda no
esclarecimento do problema em estudo.
5. Comparar o processo com abordagens similares na literatura.
1.5 Metodologia
A metodologia científica utilizada durante a pesquisa foi conforme proposto por Da
Silva e Menezes (2005). O resumo da metodologia apresenta-se no Quadro 2.

19
Quadro 2 - Metodologia Científica de acordo com Da Silva & Menezes (2005).

Ponto de Vista Tipo de Pesquisa
Natureza da pesquisa Aplicada
Básica
Abordagem da pesquisa Qualitativa
Quantitativa
Objetivos da pesquisa Explicativa
Exploratória
Descritiva
Procedimentos técnicos da pesquisa Bibliográfica
Documentário
Experimental
Estudo de caso
Levantamento
Expost-facto
Ação
Participativa
Natureza da Pesquisa
A natureza da pesquisa é aplicada, porque tem como objetivo gerar conhecimento
para ser aplicada e contribuir na solução do problema em estudo.
Abordagem do problema
A maneira de abordar o problema é qualitativa, pois não utiliza métodos estatísticos
ou numéricos para a coleta e análise dos dados, o processo se fundamenta na observação e na
análise do comportamento humano na resolução de problemas.
Objetivos da Pesquisa
O objetivo da pesquisa é exploratória, porque visa entender o problema através da
pesquisa bibliográfica e analisa exemplos de problemas similares e contem exemplos de
aplicação da proposta.
Procedimentos técnicos
20
São aplicados dois procedimentos técnicos para o desenvolvimento da proposta de
tese, a pesquisa bibliográfica e a pesquisa ação.
Pesquisa bibliográfica, porque o processo proposto esta fundamentado em
abordagens que existem na literatura e na teoria da Engenharia de Requisitos e a Análise de
Stakeholders.
Pesquisa ação, porque o pesquisador e pessoas envolvidas no problema participam de
maneira cooperativa para a solução do problema em estudo. Esta cooperação acontece dentro
do Laboratório de Engenharia de Sistemas (LSIS) no Laboratório de Integração e Testes (LIT)
do Instituto de Pesquisas Espaciais (INPE). Assim, a participação do pesquisador na aplicação
contribuiu para o resultado final da proposta, como descrito na seção 7.10.
1.6 Estrutura da Tese
Este trabalho é constituído por 10 capítulos. No primeiro capítulo se contextualiza o
trabalho, se descreve o problema e a motivação para abordá-lo e se detalham os objetivos
geral e específicos. Também se esclarece a metodologia científica utilizada na elaboração.
O capítulo dois aborda uma breve descrição da Engenharia de Sistemas e contextualiza
o processo e escopo da mesma.
O capítulo três introduz a Engenharia de Requisitos, descreve de maneira geral o
processo e sua transcendência no desenvolvimento do sistema. Também se define o que é um
requisito e seu rationale, conceitos fundamentais para o entendimento da importância do
trabalho.
O capítulo quatro detalha o processo de Análise de Stakeholders e seu papel na
Engenharia de Requisitos. O capítulo também descreve algumas técnicas normalmente
utilizadas para a elicitação de necessidades.

21
O capítulo cinco aborda a cognição e suas representações mentais, para depois entrar
nos conceitos dos diferentes tipos de mapas cognitivos.
O capítulo seis apresenta a pesquisa bibliográfica realizada das técnicas de elicitação
de requisitos que também utilizam a abordagem da cognição, as quais são comparadas com o
processo proposto nesta tese.
O capítulo sete apresenta o Processo de Análise de Stakholders Utilizando Mapas
Cognitivos, objeto desta tese. O processo e seu contexto são modelados com um fluxograma e
com a modelagem IDEF0, respectivamente; para depois detalhar as atividades dentro de cada
subprocesso. Também detalham se as raízes do processo e a metodologia aplicada no seu
desenvolvimento.
O capítulo oito trata do exemplo de aplicação do processo proposto no estudo piloto
no Laboratório de Integração e Testes (LIT) do Instituto Nacional de Pesquisas Espaciais
(INPE).
O capítulo nove discute a utilização dos mapas cognitivos na Análise de Stakeholders,
o cumprimento dos objetivos do processo, a aplicação do processo, a comparação de este com
as outras abordagens estudadas no capítulo seis, e finalmente as vantagens e desvantagens da
utilização do processo proposto.
Por último, o capítulo dez conclui o trabalho realizado retomando os objetivos iniciais
da tese. Também identifica os trabalhos futuros.

22
2 Engenharia de Sistemas
“A Engenharia de Sistemas é arte e ciência. Pode-se comparar a Engenharia de
Sistemas a uma orquestra e sua habilidade de desempenhar uma sinfonia”.
(RYSCHKEWITSCH, SCHAIBLE & LARSON, 2009, p.1)
Figura 2 A orquestra do desenvolvimento.

Fonte: Site da empresa J-CDS
O texto extraído do artigo de Ryschkewitsch, Schaible & Larson (2009) The art and
science of Systems Engineering é representado pela definição gráfica da função do engenheiro
de sistemas proposta pela empresa J-CDS Concurrent Design Services and Solutions na
Figura 2. A Engenharia de Sistemas harmoniza as diferentes disciplinas envolvidas para um
balanceamento de projeto que produza as propriedades emergentes desejadas, que garantam a
entrega de valor do sistema a ser projetado.
O Conselho Internacional em Engenharia de Sistemas, INCOSE (2011, p.7), define a
Engenharia de Sistemas da seguinte maneira:
Engenharia de Sistemas é uma abordagem multidisciplinar que tem o

propósito de possibilitar a realização de sistemas de sucesso. Foca na definição das
necessidades do cliente e as funcionalidades requeridas no início do ciclo de
desenvolvimento, documentando requisitos, para depois proceder com a síntese do
projeto e validação do sistema enquanto considera o problema completo: operações,
custos e prazo, desempenho, treinamento e suporte, testes, manufatura, e retirada. A
Engenharia de Sistemas considera tanto as necessidades técnicas quanto as
necessidades de negócio de todos os clientes com o objetivo de fornecer um produto
de qualidade que satisfaça as necessidades do usuário. (grifo da autora)
23
A Administração Nacional do Espaço e Aeronáutica dos Estados Unidos, NASA
(2007, p.3), esclarece que:
A Engenharia de Sistemas é uma disciplina integrativa e holística, em que

as contribuições de engenheiros estruturais, engenheiros elétricos, projetistas de
mecanismos, engenheiros de potência, engenheiros de fatores humanos, e muitas
outras disciplinas são avaliadas e balanceadas, uma contra a outra, para produzir um
todo coerente que é denominado desde a perspectiva de uma única disciplina.
De modo similar, Kossiakoff, Sweet, Seymour & Biemer (2011, p.4) definem que:
A Engenharia de Sistemas é focada no sistema como um todo; enfatiza sua

operação total. Olha o sistema de fora, i.e., em suas interações com outros
sistemas e seu ambiente, do mesmo modo que de dentro. A Engenharia de
Sistemas se preocupa não somente com o projeto de engenharia do sistema, mas
igualmente com os fatores externos, os quais podem restringir significativamente o
projeto. Estes incluem a identificação das necessidades dos clientes, o ambiente
operacional do sistema, interfaces com outros sistemas, requisitos de suporte
logístico, capacidades do pessoal operacional, e outros fatores que devem ser
refletidos corretamente nos documentos de requisitos do sistema e alocados no
projeto do sistema. (grifo da autora)
Assim, pode-se concluir que, a Engenharia de Sistemas foca em três visões básicas de
um sistema, a primeira é a visão do sistema como um todo formado de partes que juntas
atingem um objetivo; a segunda é uma visão interna, como suas partes se inter-relacionam e
se integram; e finalmente uma visão externa, de como o sistema interage com seu contexto e
seu ambiente. Essas três visões devem ser levadas em consideração em todo o ciclo de vida do
desenvolvimento e sempre olhando a partir dessas três visões o ciclo de vida do produto. A
Engenharia de Sistemas antecipa, na concepção, como o sistema vai se comportar
internamente e com seu ambiente em cada fase de sua vida. Entenda-se por ciclo de vida do
produto, proposto pelo INCOSE (2011), como as grandes fases de pesquisa exploratória,
concepção, desenvolvimento, produção, uso, suporte e descarte.
A Engenharia de Sistemas se caracteriza pelo pensamento sistêmico a fim de integrar
as diferentes disciplinas envolvidas simultaneamente no desenvolvimento de sistemas
complexos, de seus processos altamente iterativos e o balanceamento entre alternativas de

24
solução. Tudo isto a fim de gerar as propriedades emergentes que melhor solucionem e
atendam às necessidades dos stakeholders.
2.1 Processo de Engenharia de Sistemas
Existem diferentes abordagens para descrever o processo de Engenharia de Sistemas.
O INCOSE (2011) aborda os processos que suportam a Engenharia de Sistemas. Ele os divide
em processos técnicos e processos de projeto. Os processos técnicos são definidos assim:
a. Definição dos requisitos de stakeholder
b. Análise de requisitos
c. Projeto de arquitetura
d. Implementação
e. Integração
f. Verificação
g. Transição
h. Validação
i. Operação
j. Manutenção
k. Descarte
Os últimos três processos se referem ao ciclo de vida do sistema e não do
desenvolvimento.
Por outro lado, a NASA (2007) divide os processos de Engenharia de Sistemas em
dois grandes blocos suportados por um bloco de processos de gestão técnica, aos que chama
de O Motor da Engenharia de Sistemas (The system engineering engine). O primeiro bloco é
chamado de Projeto do Sistema formado dos seguintes processos:

25
a. Definição das expectativas dos stakeholders
b. Definição dos requisitos técnicos
c. Decomposição lógica
d. Definição do projeto de solução
O segundo bloco é chamado de Realização do Produto:
e. Implementação do produto
f. Integração do produto
g. Verificação do produto
h. Validação do produto
i. Transição do produto
Tanto o INCOSE quanto a NASA não representam a modelagem do processo no alto
nível, o processo da Engenharia de Sistemas como um todo. O INCOSE detalha dentro de
cada processo, as entradas e saídas de cada um deles, a maneira de representar como eles se
inter-relacionam entre si. Já a NASA modela os grandes blocos de Projeto do Sistema e
Realização do Produto, para depois detalhar no nível seguinte de cada processo.
Um modelo que auxilia na visualização ao nível macro dos processos da Engenharia
de Sistemas no ciclo de vida do desenvolvimento, é o modelo em V, como mostra a Figura 3.
Nesse modelo pode-se apreciar como as informações vão se desdobrando ao nível
seguinte. É uma representação em camadas. Acompanha a transformação das informações, às
vezes abstratas no início do desenvolvimento, até especificações detalhadas e sua
materialização.
26
Figura 3 Modelo em V da Engenharia de Sistemas

Fonte: Adaptado de COELHO (2011)
O processo se inicia com a definição da missão e do conceito do sistema, o que se
refere à visão dos stakeholders do que o sistema deve fornecer. Com essas informações se
desdobram os requisitos e arquiteturas de sistema e subsistema, que é a transformação dos
requisitos dos stakeholders para a linguagem dos engenheiros de sistemas. De esta maneira o
sistema vai tomando forma em arquitetura, por meio dos requisitos até as especificações
técnicas para assim poder materializar o sistema aos poucos, integrando suas partes e
verificando contra seus respectivos requisitos em cada nível, até a validação do sistema por
parte dos stakeholders.

27
3 Engenharia de Requisitos
3.1 Requisitos
Os requisitos são uma parte da linguagem de comunicação na Engenharia de Sistemas.
Eles representam as necessidades, desejos e expectativas dos stakeholders. São analisados e
transformados em requisitos técnicos que descrevem o que o sistema deve fazer e são
desdobrados e detalhados conforme avança o processo de desenvolvimento até se converter
na especificação do sistema, a definição da solução, o como o sistema será implementado.
A NASA (2007, p. 274) define o requisito como: “A necessidade acordada, desejo,
vontade, capacidade (capability), capacidade (capacity) ou demanda por pessoal,
equipamentos, instalações, ou outros recursos ou serviços...”
Por outro lado, o INCOSE (2011, p. 362) define o requisito como: “Um enunciado que
identifica uma característica ou restrição de um sistema, produto ou processo, o qual é não
ambíguo, claro, único, consistente, individual (não agrupado), e verificável, e que é
considerado necessário para a aceitação do stakeholder”.
Finalmente Bahill & Dean (2009, p. 209) definem requisito da seguinte maneira:
Um requisito é um enunciado que identifica a capacidade ou função

necessária para um sistema satisfazer a necessidade de um cliente. Os requisitos
devem declarar ou expressar o que o sistema deve fazer, mas não devem especificar
como o sistema o fará.
Pode-se dizer que o requisito leva o “DNA” ou as “informações genéticas” da
concepção. O sistema é concebido em termos dos requisitos e são esses requisitos que vão se
desdobrando e robustecendo durante os processos de análise. É a partir deles que se
fundamenta a criação do sistema, são eles que levam as informações e a transformação dessas
informações para os seguintes níveis, independentemente da complexidade do sistema.

28
3.2 Rationale dos Requisitos
A palavra rationale não tem tradução oficial para a língua portuguesa, porém, é muito
utilizada no jargão da Engenharia de Sistemas, e para fins deste trabalho será utilizada em
inglês.
O rationale representa a justificativa ou arrazoado do requisito. Esclarece as intenções
daquele requisito (NASA, 2007), justifica sua existência. O rationale faz parte dos atributos
do requisito e ajuda na tomada de decisões na fase de projeto. Ajuda os desenvolvedores a
realizarem os trade-offs e decidir por uma ou outra implementação de solução com base no
rationale.
A NASA (2007, p.48) estabelece que o rationale deve incluir as seguintes
informações:
Razão do requisito: Comumente a razão do requisito não é obvia, e pode

ser perdida se não é documentada no momento em que o requisito está sendo
documentado. A razão pode indicar uma restrição ou um conceito de operações. Se
existe um requisito pai claro, ou um trade study que explique a razão, então
referenciá-lo.
Documentar os pressupostos: Se um requisito foi escrito pressupondo a

completude de um programa de desenvolvimento de tecnologia ou uma missão
tecnológica bem sucedida, documentar o pressuposto.
Documentar relacionamentos: Os relacionamentos com as operações

esperadas do produto (e.g. expectativas de como os stakeholders usarão um
produto). Este deve ser feito com uma ligação ao Conceito de Operações (ConOps).
Documentar as restrições de projeto impostas pelos resultados das

decisões feitas à medida que o projeto evolui. Se o requisito estabelece um método
de implementação, o rationale deve estabelecer porque a decisão foi feita para
limitar a solução para este método específico de implementação.
Assim, o rationale, faz parte do requisito e deve ser elicitado e capturado junto ao
requisito, pois representa informações valiosas nas fases de projeto, implementação e
memória do desenvolvimento.
29
3.3 Processo de Engenharia de Requisitos
O processo de Engenharia de Requisitos tem por objetivo gerar os requisitos a partir
das necessidades dos stakeholders.
Para poder chegar aos requisitos, existe um processo de elicitação e análise. Os
requisitos não são diretamente expressados pelos stakeholders.
Figura 4 Processo de Engenharia de Requisitos

Fonte: Bahill (2006) apud (BAHILL & DEAN, 2009, p. 228)
A Figura 4 representa o processo de Engenharia de Requisitos. Analisando a figura
podem-se identificar três grandes blocos. O primeiro bloco é de elicitação de requisitos e
definição do problema (identificar os stakeholders, entender as necessidades do cliente,
definir o problema, descobrir os requisitos e esclarecer os requisitos). O segundo bloco
representa a análise, desdobramento e organização dos requisitos e a forma de transição para a

30
solução (decompor requisitos, alocar requisitos, derivar requisitos e priorizar requisitos). O
terceiro bloco acontece em paralelo e se refere a atividades de gestão dos requisitos.
O INCOSE (2011) contempla dois processos referentes à Engenharia de Requisitos:
Processo de Definição de Requisitos de Stakeholder e o Processo de Análise de Requisitos. O
processo de Definição de Requisitos tem o propósito de:
Definir os requisitos para um sistema que possa fornecer os serviços

necessários pelos usuários e outros stakeholders num ambiente definido. Identifica
stakeholders, ou tipos de stakeholders, envolvidos com o sistema durante seu ciclo
de vida, e suas necessidades, expectativas, e desejos.
Já o propósito do processo de análise de requisitos é:
Transformar a visão do stakeholder [...]. em uma visão técnica do produto

requerido que possa entregar esses serviços.
Este processo constrói uma representação de um sistema futuro que atingirá

os requisitos do stakeholder e que, assim como as restrições o permitam, não
implicará em nenhuma implementação específica. Resultará em requisitos de
sistema mensuráveis que especifiquem, a partir da perspectiva do fornecedor, que
características deve possuir e em que magnitude a maneira de satisfazer os requisitos
de stakeholder.
Por outro lado, Hull, Jackson & Dick (2005) definem o escopo do processo de
Engenharia de Requisitos a partir da fase de concepção até a fase de projeto detalhado
dividindo os requisitos em requisitos de stakeholder, requisitos de sistema, requisitos de
subsistemas até os requisitos dos componentes, ou o nível de maior detalhamento do sistema.

31
Figura 5 Engenharia de Requisitos no modelo em V

Fonte: Adaptado de Hull, Jackson & Dick (2005, p.7)
A Figura 5 ajuda na visualização da transcendência e importância dos requisitos ao
longo do ciclo de vida do desenvolvimento. Os requisitos estão presentes desde o início da
concepção. Eles são a estrutura do desenvolvimento e é comparando com eles que se
verificam os componentes, subsistemas e o sistema integrado até sua aceitação por parte dos
stakeholders na validação do sistema. Na figura 5, a seta vermelha representa a rastreabilidade
dos requisitos desde o baixo nível até o nível mais alto de abstração, os requisitos de
stakeholder; e as setas azuis representam a ligação das atividades de testes aos requisitos. O
ciclo de vida do desenvolvimento é sempre suportado pelos requisitos, nos diferentes níveis
de abstração do sistema.
32
4 Análise de Stakeholders
4.1 Definição de Stakeholders
Antes de abordar a Análise de Stakeholder, é importante esclarecer o conceito de
stakeholder. A palavra stakeholder não tem uma tradução bem definida para a língua
portuguesa e que capture o conceito total, por tal motivo se utilizará o anglicismo stakeholder.
A palavra stakeholder se refere a qualquer pessoa, grupo de pessoas ou organização
que afeta ou pode ser afetada pelo sistema de interesse. Os stakeholders são os donos do
problema e aqueles envolvidos na implementação da solução, na utilização, manutenção e
descarte, enfim, em todas as fases do ciclo de vida do sistema: sejam estes envolvidos direta
ou indiretamente com o sistema.
Bahill & Deam (2009, p. 207) descrevem os tipos de stakeholders como segue:
Os stakeholders são todas as pessoas, organizações, e instituições que são

parte do ambiente do sistema porque o sistema fornece alguns benefícios para eles e
eles têm interesse no sistema. Isso inclui usuários finais, operadores, compradores,
donos, agências reguladoras, vítimas, patrocinadores, pessoas que dão manutenção,
arquitetos, gerentes, clientes, clientes substitutos, testadores, garantia da qualidade,
gestão de riscos, compras e o ambiente.
Verma (2009, p. 46) classifica os stakeholders em:
Stakeholders ativos
• São indivíduos ou organizações que interagem diretamente com o

sistema de interesse assim que ele está operacional e em uso.
• Incluem usuários do sistema, operários de manutenção do sistema,

pessoal de logística, assim como outros sistemas que irão interagir com o sistema de
interesse. Esses outros sistemas (ou os donos) fornecem requisitos operacionais e
restrições para o sistema de interesse.
• São representados num diagrama de contexto e devem ser incluídos

no Conceito de Operações do Sistema.
• Ajudam a definir as fronteiras lógicas e funcionais do sistema de

interesse.
Stakeholders passivos
33
• São outros indivíduos ou organizações que influenciam o sucesso

do sistema implementado.
• Não tem interface ativa com o sistema de interesse, mas podem

fornecer muitos requisitos e restrições.
• Eles não utilizam o sistema, mas influenciam sua definição

derivando requisitos para este.
• Podem ser influenciados pelo desempenho do sistema.
• Geralmente colocam requisitos não-funcionais no sistema –

restrições, regulamentos, etc.
Patrocinadores
• Os patrocinadores controlam o desenvolvimento do programa e os

recursos ou financiamento de aquisição.
• Eles compram ou produto ou o financiam com uma missão

específica em mente ou um objetivo lucrativo.
• Como tem o poder de dispor do dinheiro, o patrocinador é

indiscutivelmente o stakeholder mais importante.
4.2 A Análise das Necessidades dos Stakeholders
A Análise de Stakeholders se refere ao estudo de como os stakeholders entendem um
problema específico, sua visão e como eles se relacionam com o problema. A definição do
problema a ser resolvido e seu escopo é um dos primeiros passos na Engenharia de Sistemas
como esclarecido por Verma (2009, p. 37) “A prioridade de cada novo programa ou projeto é
definir e delimitar as expectativas dos clientes. Essas expectativas recaem na missão, as
capacidades requeridas ou nas oportunidades de mercado”.
Da mesma maneira, o INCOSE (2011. p. 55) esclarece que os requisitos de
stakeholders governam o desenvolvimento do sistema e são um fator essencial na futura
definição ou esclarecimento do escopo do projeto de desenvolvimento.
O processo do INCOSE que contempla a Análise de Stakeholders é o processo de
Definição dos Requisitos de Stakeholder, se limitando à atividade de “Elicitar requisitos de
stakeholder”, sendo que esta atividade requer um esforço significativo que deve ser
contemplado nas estimativas de custo e tempo do projeto.

34
As necessidades são dados subjetivos que utilizam uma linguagem livre e pertencem
ao stakeholder. Representam desejos, sentimentos, expectativas, percepções. Podem conter
necessidades ambíguas, contraditórias e não mesuráveis. As necessidades explicitam o
problema sob o ponto de vista do stakeholder.
Bahill & Dean (2009) recomendam não acreditar nas primeiras necessidades do
cliente. É necessário iterar o procedimento várias vezes junto com o cliente para verificar a
definição do problema. Para eles, é responsabilidade do engenheiro de sistemas entender as
necessidades dos stakeholders e o escopo e definição do problema para depois explicá-las a
eles, pois geralmente o stakeholder não percebe suas necessidades. Eles muitas vezes não
enxergam o todo do problema ou o todo do sistema.
Cada stakeholder tem sua própria visão do sistema ou do problema, mas sempre há
mais de um stakeholder, e essas várias visões do problema têm que convergir numa só. Essa
dificuldade também é ressaltada pelo INCOSE (2011, p. 60)
“Em muitos casos a integração das visões do usuário, o qual pode não ser
necessariamente harmonioso, é realizado pelo “comitê de ação”. No entanto, isto
pode levar à confusão e a uma tomada de decisão insatisfatória. Durante a aplicação
do processo de Engenharia de Sistemas, pode ser criado um paradigma comum para
examinar e priorizar informações disponíveis e determinar o valor das informações
agregadas. Cada uma das visões dos usuários dos sistemas requeridos pode ser
traduzida numa descrição comum de alto nível do programa e do sistema, que seja
entendida por todos os participantes, com todas as atividades de tomada de decisão
registradas para futuras análises”.
Verma (2009, p. 39) ressalta a importância do entendimento das expectativas dos
stakeholders:
O entendimento comum das expectativas dos clientes é essencial para o

sucesso do projeto [...] também fornece ao engenheiro de sistemas a visão do
rationale do sistema. O claro entendimento nos ajuda a definir prioridades para as
expectativas e requisitos mais detalhados dos clientes, a identificar os requisitos de
missão críticos ou critérios de aceitação, e conduzir os inevitáveis trade-offs.
35
4.3 Transição das Necessidades dos Stakeholders
Sob outra perspectiva, a Engenharia de Sistemas fornece os meios para transformar o
abstrato em um sistema tangível, seja este um serviço ou um produto.
O abstrato se refere às necessidades e restrições dos stakeholders, a definição e
entendimento do problema a ser resolvido e seu contexto. Essas informações vão se refinando
ao longo do ciclo de vida do desenvolvimento por meio dos processos da Engenharia de
Sistemas; até alcançar os objetivos desejados chegando ao sistema concebido, projetado e
materializado.
Dessa maneira, essas necessidades, restrições e funcionalidades se traduzem nos
drivers do desenvolvimento para que o sistema atinja o objetivo para o qual está sendo
projetado.
Loureiro (1999, p. 199), falando sobre a transformação dos requisitos descreve essa
transformação do abstrato ao material e esclarece que a fonte dessa transformação, são os
requisitos dos stakeholders:
O processo de análise de requisitos identifica stakeholders e seus requisitos

e traduz esses requisitos em requisitos técnicos. Os requisitos técnicos são o ponto
de partida para a análise funcional. Por meio da análise funcional, a arquitetura
funcional do produto, dos processos e das organizações são desenvolvidas e são a
base para derivar atributos funcionais. A arquitetura funcional é o ponto de partida
para a análise física. A análise física desenvolve ou identifica a arquitetura física do
produto, dos processos e das organizações pelas quais as arquiteturas físicas são
identificadas. Normalmente, cada função na arquitetura funcional tem seu requisito
técnico correspondente que justifica sua existência.
É importante ressaltar que Loureiro (1999) engloba a Análise de Stakeholders dentro
da Análise de Requisitos. O escopo deste capítulo é somente a Análise de Stakeholders.
A transformação do abstrato ao tangível é gradual ao longo do ciclo de vida do
desenvolvimento. A transição do domínio do problema para o domínio da solução acontece

36
gradualmente e sempre tendo ambas as partes presentes, mas uma delas de maneira mais
predominante como representado conceitualmente na Figura 6.
Figura 6 Transição do domínio do problema para o domínio da solução
O domínio do problema se refere ao problema que deve ser resolvido, seu contexto, as
necessidades funcionais e restrições. Tudo isto traduzido em requisitos. O domínio da solução
é representado pelos requisitos de sistema que se referem à solução a ser implementada e são
a contraparte dos requisitos dos stakeholders, ou seja na linguagem técnica e não do
stakeholder, para assim ser transformados nas especificações do sistema que implementam a
solução.
Os requisitos são a tradução e refinamento das necessidades para uma linguagem
técnica estruturada que ajudará aos projetistas da solução a entenderem as necessidades dos
stakeholders para poder propor alternativas de solução a tais requisitos.

37
4.4 Técnicas de Elicitação de Necessidades
Na literatura podem-se encontrar técnicas que são chamadas de elicitação de
requisitos. Em alguns casos essas técnicas elicitam necessidades e em outros, de fato, extraem
requisitos.
As ferramentas que extraem necessidades têm como característica principal a de lidar
diretamente com o stakeholder e trabalhar com dados subjetivos. As ferramentas que extraem
requisitos geralmente têm como principal característica a de serem tipos de modelagem que
ajudam no entendimento do problema, interfaces e de como as coisas acontecem dentro de um
cenário em estudo, como a linguagem SysML.
Algumas das técnicas mais utilizadas para elicitação de necessidades são detalhadas
por Courage & Baxter (2005):
Entrevista: É o meio mais comum para obter informações, a entrevista pode ser
estruturada ou não estruturada.
Pesquisa de marketing: é recomendada quando é um novo produto para conhecer as
necessidades e características do mercado.
Análise de Necessidades e Desejos (W&N- Wants and Needs analysis): é um método
do tipo brainstorming e acontece com grupos de stakeholders aos quais se pergunta o que
eles querem e desejam. O método ajuda na estruturação e priorização das informações. É
utilizado para capturar requisitos básicos de usuários.
Card Sorting: é um método que ajuda a entender como os clientes procuram as
informações nos produtos, qual é a organização de informações que mais vai satisfazer o
cliente. Utilizam-se cartões onde os clientes escrevem os itens ou objetos que fazem parte do
38
produto e pede-se para que o cliente organize os cartões em grupos que fazem mais sentido
para ele.
Group Task Analysis (GTA): o foco da análise é entender como as pessoas
desenvolvem seu trabalho a partir do ponto de vista físico e a partir do ponto de vista
cognitivo, para poder garantir a usabilidade do produto e o fluxo de informações correto.
Criam-se grupos de pessoas as quais discutem e definem a sequência de atividades para
realizar um trabalho.
Focus Groups: É uma metodologia de dinâmica de grupo de seis a dez participantes.
É um grupo de discussão onde se analisam experiências e opiniões de assuntos previamente
identificados pelo moderador.
Pesquisa de campo: refere-se a conhecer o ambiente do usuário ou cliente, observar
como realiza seu trabalho ou quais são as necessidades. As visitas podem incluir observação,
entrevista ou assumir o papel do usuário a maneira de aprendiz, para entender melhor suas
necessidades.
Alexander & Stevens (2002, p. 19) listam uma série de técnicas muito similares às
propostas por Courage & Baxter (2005):
a. Entrevistas
b. Workshops
c. Experiência como usuário
d. Observação de usuários no serviço
e. Simulando o que precisa acontecer
f. Protótipos
g. Reporte de problemas
h. Helpdesk
39
i. Consultores e treinadores
j. Sugestões e reclamações de clientes
k. Melhorias feitas pelos usuários
l. Uso do produto diferente do seu propósito
m. Produtos similares ou rivais
n. Projetos e especificações similares
o. Contratos mal escritos
Alexander & Stevens (2002) também enfatizam a importância de ter contato direto
com o stakeholder ao invés de questionários de pesquisa, já que se encoraja ao stakeholder a
expressar. Também ressaltam como o questionamento “por que?” pode levar à raiz do
requisito. Eles o ilustram com o seguinte exemplo (ALEXANDER & STEVENS, 2002, p.
21):
Usuário: A jarra do café deve ser feita de inox
Você: Por que precisa ser desse material em particular?
Usuário: Porque uma jarra de vidro pode quebrar
Você: Por que se quebraria?
Usuário: Porque a jarra é de uso comum entre muitas pessoas, que somente
passam, e o aquecedor não desliga quando a jarra esta vazia.
Você: Por que não desliga?
Usuário: Porque um requisito estava faltando!
Desta maneira se chega à raiz do requisito, à necessidade raiz: o aquecedor da jarra de
café deve desligar quando a jarra estiver vazia.
É o papel do engenheiro de sistemas ajudar ao stakeholder a entender suas
necessidades e seu problema.

40
5 Cognição
“Cognição abrange o estudo científico da mente humana e como esta processa
informações” (LEVITIN, 2002, p.xiii)
Fodor apud Goel (1995, p.1) descrevendo o processo cognitivo, afirma que:
... nossas melhores teorias psicológicas do processo cognitivo (como

tomada de decisão, aprendizagem, e percepção) pressupõem computação, e
computação pressupõe um sistema de representações internas. [...] sem
representações, não há computações; sem computações, não tem teoria da mente.
A palavra computações é utilizada por Fodor de maneira metafórica em sua Teoria
Computacional da Mente (CTM: Computational Theory of Mind). A palavra é interpretada
como o processamento das informações e representações realizadas pela mente. (GOEL, 1995
e WIKIPEDIA, 2012)
Ou seja, se não existem construções e relacionamento de conceitos, não existe o
entendimento.
Os relacionamentos de conceitos também são abordados por Glenn & Chignell (1992)
apud Okada, A. (2008, p.42) na definição da cognição humana:
“A natureza cognitiva da mente humana tem sido associada a modelos de

redes. O processo associativo da mente é muito diferente da estrutura linear usada
geralmente para organizar informações. A não linearidade está presente também na
recuperação da informação na memória humana. Esse processo de resgate de
recordações pode ocorrer também por meio de uma rede de associações semânticas.”
Na solução de problemas, Goel (1995, p.4) descreve sua relação com o cognitivismo
da seguinte maneira:
Solução de problemas – nossa habilidade para reconhecer estados

insatisfatórios de assuntos e transformá-los em estados satisfatórios – é fundamental
à capacidade cognitiva humana. Na maioria das definições, requer-se pelo menos as
seguintes condições: (i) que existam dois estados distintos dos assuntos, (ii) que o
agente esteja em um estado e queira estar no outro estado, (iii) que não seja
aparente para o agente como será passar de um estado para o outro, e (iv) que a
passagem de um estado para o outro seja racional, conscientemente orientada (pelo
41
menos no alto nível executivo), processo de múltiplos passos. Qualquer teoria de

cognição terá que dar conta deste processo de maneira robusta. (grifo da autora)
Assim, interpreta-se que o processo cognitivo acontece na solução de problemas,
desde sua estruturação até a geração de alternativas para uma possível solução.
5.1 Representações Mentais
How can I know what I think till I see what I say?

Karl E. Weick
Existem várias maneiras de transmitir nossos pensamentos, sejam estes, conhecimento,
visões, sentimentos, desejos; e as mais comuns são de maneira oral, escrita e gráfica. Cada
uma delas têm suas vantagens e desvantagens, mas todas elas ajudam na transmissão de
informações, conhecimento, sentimentos; enfim, tentam transmitir informações contidas na
nossa mente. Elas se complementam entre si, nenhuma delas tem a capacidade total de
comunicação, pois nem o conjunto delas consegue transmitir fielmente o que o indivíduo quer
transmitir e mais difícil ainda, conseguir que o receptor das informações entenda o que se
deseja transmitir.
Pentland e Fischler (1983) apud Fischler e Firschein (1987, p.308)
… enfatizam que as múltiplas representações são necessárias. Debilidades

no formalismo proposicional podem às vezes serem eliminados por meio do uso de
uma representação isomórfica, sempre que a representação dessa estrutura “se
espelhe” (seja isomórfica) em algumas propriedades do domínio que está sendo
representado, seja capaz de implicitamente representar essas propriedades
preservadas pelo isomorfismo.
Para que exista comunicação tem que existir um emissor e um receptor, o emissor
pode se auxiliar de diferentes técnicas de comunicação, mas não pode controlar o contexto do
receptor e a sua interpretação. Pode existir uma infinidade de interpretações, pois a mente de
cada indivíduo carrega experiências, cultura, conhecimento e contextos diferentes. Cada

42
indivíduo é único e irrepetível. Da mesma forma o emissor da informação tenta transmitir
uma percepção da realidade, a partir do seu ponto de vista e de suas vivências.
Kelly (1955), apud Fischler & Firschein (1987, p.68) defende essa teoria de percepção
do mundo através de um cristal diferente ao dos outros:
O homem vê o mundo utilizando padrões ou templates que ele cria, para

depois tentar “encaixar” esses templates às realidades das quais o mundo é
composto. O encaixe nem sempre é muito bom. O homem cria sua própria maneira
de ver o mundo no qual ele vive, o mundo não fornece isto para ele. Os mesmos
eventos podem frequentemente ser vistos à luz de dois ou mais sistemas, ainda que
os eventos nem pertençam a nenhum deles... Interpretações do universo nunca serão
perfeitas, e assim sempre estarão sujeitas à revisão ou substituição.
5.1.1 Representações Oral e Escrita
As linguagens oral e escrita são as mais utilizadas para transmitir pensamentos, visões
do mundo e também utilizadas no processo de aprendizagem. O fato de externar ideias ajuda a
estruturá-las e a entender melhor como elas são percebidas. Oslon (1994, p.xv) descreve a
escrita como “... uma função epistemológica importante. Escrever não somente nos ajuda a
lembrar o que foi pensado e dito como também nos convida a ver o que foi pensado e dito de
uma nova maneira”. Oslon (1994, p. xvii) ainda afirma “... não é de todo irracional aspirar a
uma teoria de como escrever contribui não somente para o nosso entendimento do mundo,
mas também para o entendimento de nós mesmos”.
Russell, apud Langer (1942, p. 82), apud Goel (1995, p. 8) dá uma explicação de
porque é tão difícil expressar, com palavras, assuntos que não são físicos, não são do mundo
físico que nos rodeia, e considera o texto com uma estrutura do mundo físico:
Pode bem ser que há fatos que não se prestam a este esquema muito
simples; se for, eles não podem ser expressos em linguagem. Nossa confiança na
linguagem se deve ao fato de que isso... compartilha a estrutura do mundo físico, e
portanto pode expressar essa estrutura. Mas se há um mundo que não é físico, ou não
no espaço do tempo, deve haver uma estrutura que não podemos pensar ou expressar
ou conhecer. Talvez seja por isso que sabemos muito de física e muito pouco do
resto.
43
5.1.2 Representações Visuais
Todos já escutaram a frase “uma imagem fala mais que mil palavras”. A linguagem
gráfica esclarece aspectos difíceis de explicar com palavras. As palavras podem ser
interpretadas de diferentes maneiras, sejam elas expressas oral ou textualmente. As imagens
simplificam e são efetivas quando existe uma quantidade suficiente de interações entre
conceitos ou elementos que compliquem sua explicação oral ou textual.
Na engenharia, as representações visuais têm um papel importante na solução de
problemas onde as soluções são difíceis de enxergar sem o auxílio dessas representações
gráficas. Algumas dessas representações utilizadas são modelos, mapas, desenhos e
diagramas; para mencionar algumas delas.
As mensagens transmitidas usando representações gráficas são fáceis de interpretar.
Existem sinais mundialmente conhecidos que atravessam as barreiras da língua e da cultura,
como os sinais de trânsito ou a famosa cruz vermelha, como mostra a Figura 7.
Figura 7 Símbolos universais
As imagens são uma das formas mais básicas de comunicar que inclusive, além do ser
humano, no reino animal também são reconhecidas e guardadas na memória. Por exemplo,
Fischler & Firschein (1987, p.222) mencionam “... abelhas e formigas utilizam pontos de
referência visuais para procurar seu caminho de volta para o ninho”.

44
Mas não é possível generalizar, qualquer informação como imagens, texto e discursos
podem ser interpretados de diferentes maneiras. O contexto do indivíduo que está recebendo
as informações vai gerar sua própria percepção da informação.
No caso da comunicação gráfica Fischler e Firschein (1987) descrevem 3 fenômenos
relacionados à visão. O primeiro fenômeno é a percepção pictórica e a cultura; este
fenômeno descreve como a percepção também tem um papel importante nas representações
gráficas devido a fatores culturais, i.e., os fatores culturais influenciam na percepção das
imagens. O segundo fenômeno é a memória visual, a qual utiliza imagens que nos ajuda a
lembrar, como é o caso dos símbolos universais abordados anteriormente. O terceiro é o
pensamento visual o qual Fischler e Firschein (1987) descrevem como o uso de imagens no
processo de raciocínio. O pensamento visual é aquele utilizado na engenharia. Fischler e
Firschein (1987) esclarecem este exemplo com a descoberta do químico Friedrich Kekule
para representar a estrutura do benzeno como um anel formado por uma cobra devorando seu
rabo, atualmente conhecido como o anel do benzeno; e o físico Richard Feynman e os
Diagramas de Feynman para representar a solução de um problema sem equações
matemáticas. Estas imagens são mostradas na Figura 8.
Figura 8 Exemplos do pensamento visual do químico Kekule e do físico Feynman

Fonte: Adaptado de Creativity web (1996) e Wikipedia (2012)
45
5.2 Mapas Cognitivos
Os mapas cognitivos podem ser considerados como uma ferramenta híbrida para
representar o pensamento. Eles utilizam texto e imagem, representam a sequência do
raciocínio naquele momento de sua criação. Os mapas cognitivos são uma fotografia do
pensamento naquele contexto e naquele estado de pensamento momentâneo, mas utilizando
todo o conhecimento, informações e valores já contidos na memória.
O mapa cognitivo representa os modelos mentais de um indivíduo ou grupo de
indivíduos relacionando conceitos e/ou informações de um problema ou assunto em
específico. Também ajuda no esclarecimento de ideias e induz à reflexão e análise de
informações expressas verbal, textual e graficamente por meio da construção do processo
cognitivo de mapeamento.
Okada (2006) apud Okada (2008, p.27) esclarece os benefícios da utilização dos
mapas cognitivos:
Mapas são interfaces úteis não apenas para visualizar o mundo concreto
físico – elementos geográficos e suas relações – como também o território
abstrato: mundo digital (ciberespaço) e o mundo mental (o pensamento humano).
A cartografia cognitiva pode facilitar a construção de novos conhecimentos. Eis
porque ela permite a visualização das diversas conexões, de vários ângulos e
níveis. Isso favorece a observação de trajetórias percorridas e caminhos a
percorrer. (Grifo da autora)
Os mapas cognitivos auxiliam a mapear a percepção do problema, o ponto de vista de
um indivíduo e o conhecimento relacionado. Identificam as relações, as quais, sem o mapa,
seriam difíceis de reconhecer ou inferir.
Existe uma ampla variedade de mapas cognitivos, mapas que representam uma visão
do pensamento. Dentre alguns deles estão os descritos nas seções a seguir.

46
5.2.1 Mapas Conceituais
A ferramenta de Mapas Conceituais foi criada por Joseph D. Novak e sua equipe em
1972. Novak (2006) adotou três ideias principais da Teoria de Assimilação de Ausbel,
relacionadas ao desenvolvimento cognitivo para a criação da ferramenta. Estas ideias que
foram adotadas foram descritas por Novak e Cañas (2006, p.4) da seguinte maneira:
Primeiro: Ausbel vê o desenvolvimento de novos significados como

construções em conceitos e proposições primárias relevantes. Segundo: ele vê a
estrutura cognitiva como uma hierarquia organizada, com conceitos mais gerais e
inclusivos ocupando níveis mais altos na hierarquia e conceitos mais específicos,
menos inclusivos, inseridos embaixo dos conceitos mais gerais. Terceiro: quando
acontece a aprendizagem significativa, relações entre os conceitos ficam mais
explícitas, mais precisas e melhor integradas com outros conceitos e preposições.
Como esclarecido por NOVAK (2006), os mapas conceituais consistem de nós ou
caixas contendo conceitos; os conceitos são formados por uma ou duas palavras. Esses
conceitos são conectados com linhas contendo palavras com a função de criar as ligações
entre os conceitos. Os conceitos são estruturados de maneira hierárquica, estando os conceitos
mais abrangentes no topo do mapa e os mais específicos na base do mapa.
De acordo com Josassen, et. al. (1993) apud Siau & Tan (2005, p.277) “...o
mapeamento conceitual é útil para gerar ideias, projetar uma estrutura complexa de ideias, e
adiciona aprendizagem integrando explicitamente conhecimento novo e antigo, assim como
para avaliar entendimento ou diagnosticar mal entendimento”.
5.2.2 Mapas Causais
Os mapas causais nascem da Teoria dos Construtos Pessoais. Essa teoria foi
desenvolvida por George Kelly na década de 1950. Ele trata da cognição humana partindo do
ponto de vista psicológico. O próprio Kelly criou, a partir dessa teoria, a técnica de entrevista
chamada de Repertory Grid.

47
Kelly (1955) apud Siau & Tan (2005, p.276-277) propõe que: “… uma série de
perspectivas individuais é um sistema de construtos pessoais e que os indivíduos utilizam seus
próprios construtos pessoais para entender e interpretar eventos”.
Os mapas causais são conceitos interconectados com linhas ou setas indicando a
relação de causalidade entre eles.
Existem algumas técnicas utilizando mapas causais, entre elas a desenvolvida por
Colin Eden no final da década de 1980 e início da década de 1990 chamada SODA: Análise e
Desenvolvimento de Opções Estratégicas por suas siglas em inglês (Strategic Options
Development and Analysis).
Ackermann, Eden & Cropper (1992) listam alguns dos benefícios, como a estruturação
de problemas, identificação e exploração de metas e objetivos, e dicas de como o entrevistado
está percebendo o problema. Os mesmos autores esclarecem que os mapas causais podem
“atuar como meios catárticos para os entrevistados, os quais, através do processo de
explicação das ideias e como elas se integram, começam a ganhar um melhor entendimento
do problema”.
Dentro desta categoria e com uma abordagem similar à de Ackerman e Eden na
metodologia SODA, está a metodologia proposta por Ensslin, Montibeller e Noronha (2001),
a qual é detalhada em seu livro Apoio à Decisão. Eles desenvolveram uma metodologia para a
estruturação de problemas e avaliação multicritério de alternativas utilizando mapas causais.
Eles descrevem o comportamento das representações mentais durante a construção do
mapa tanto do facilitador quanto do dono do problema (que eles chamam de decisor). A
Figura 9 captura esse comportamento no tempo. O decisor está inserido num contexto onde a
decisão deve ser tomada. Nesse contexto e nesse tempo (t1) o decisor tem representações
mentais, as quais servirão de fonte para gerar as representações discursivas no momento t2.
48
Essas representações discursivas irão influenciar as representações mentais prévias como
indicado pela seta L1. O discurso do decisor irá gerar representações mentais no facilitador a
respeito do problema no momento t3. O facilitador irá mapear essas representações mentais de
maneira gráfica no momento t4 para assim criar o mapa cognitivo. A visualização gráfica do
mapa, por sua vez, irá influenciar novamente as representações mentais do decisor no
momento t5 e representadas pela seta L2. (ENSSLIN, MONTIBELLER E NORONHA, 2001).
Figura 9 Articulação e Pensamento

FONTE: Adaptado de Montibeller, 1996, apud Ensslin, Montibeller & Noronha. 2001, p. 76
A metodologia desses autores, que servirá como base para a proposta deste trabalho,
consiste em nove passos referentes à estruturação de problemas dentro do Processo de Apoio
à Decisão utilizando-se uma Metodologia Multicritério (ENSSLIN, MONTIBELLER &
NORONHA, 2001).
Fase de identificação do contexto decisório
1. Identificação dos atores envolvidos no processo decisório
2. Escolha dos decisores
3. Definição das ações disponíveis
4. Definição da problemática de referência

49
Fase de Estruturação do Problema
5. Construção dos mapas cognitivos individuais dos decisores
a. Definição de um rótulo para o problema:
b. Definição dos Elementos Primários de Avaliação (EAP’s)
c. Construção de conceitos a partir dos EAP’s
d. Construção da hierarquia dos conceitos
6. Agregar mapas cognitivos individuais (caso de múltiplos decisores)
7. Congregar mapa agregado (caso de múltiplos decisores)
8. Análise dos Mapas Cognitivos
a. Identificação hierarquia de meios-fins
b. Identificação de conceitos cabeças e caudas
c. Identificação de laços de relacionamento entre conceitos
d. Identificação de clusters
e. Identificação das linhas de argumentação
f. Identificação dos ramos do mapa
9. Determinação da família de Pontos de Vista Fundamentais (PVF’s)
Fase de Estruturação do Modelo Multicritério
Fase de Avaliação das Ações Potenciais

50
6 Técnicas de Elicitação de Necessidades Utilizando Mapas Cognitivos
Na literatura se encontram técnicas que são chamadas de elicitação de requisitos, mas
existem algumas que extraem necessidades e outras que, de fato, extraem requisitos.
As ferramentas que extraem necessidades têm como característica principal a de lidar
diretamente com o stakeholder e trabalhar com dados subjetivos. As ferramentas que extraem
requisitos geralmente têm como principal característica a de serem tipos de modelagem que
ajudam no entendimento do problema, interfaces e de como as coisas acontecem dentro de um
cenário em estudo.
Neste capítulo são detalhadas as ferramentas de elicitação de necessidades que
utilizam a abordagem de mapas cognitivos ou a abordagem cognitiva; a fim de comparar com
o processo proposto, objeto deste trabalho. É importante salientar que neste capítulo listam-se
três dos casos mais representativos encontrados na literatura e todos eles utilizados na área de
Tecnologias da Informação.
6.1 Mapas Cognitivos de Maneira Geral
Os mapas cognitivos de maneira geral são utilizados na engenharia de software para a
elicitação de necessidades e requisitos dos usuários do sistema. Siau & Tan (2005) utilizam o
termo de Comunicação Técnica para alocar esta abordagem.
Siau & Tan (2005, p.279) consideram que:
Como advogados do diabo, comunicadores técnicos podem aplicar técnicas

de mapas cognitivos para capturar necessidades dos usuários de maneira mais
efetiva... (os mapas) podem servir tanto como ferramenta de comunicação em
entrevistas com usuários e desenvolvedores, quanto como uma ferramenta analítica
para verificar e priorizar necessidades dos usuários.
51
Siau & Tan (2005) sugerem a utilização de três diferentes técnicas de mapas
cognitivos para fins específicos na elicitação das necessidades dos usuários da seguinte
maneira:
a. Mapas causais e técnicas relacionadas: os quais descrevem relacionamentos
causa-efeito, que ajudam no entendimento da cognição dos tomadores de
decisões.
b. Mapas semânticos: descrevem conceitos salientes e suas estruturas espaciais.
Esses mapas também conhecidos como mapa de ideias. É parecido com o
brainstorming, mas relacionado com os conceitos. Os mapas representam o
processo criativo do brainstorming graficamente.
c. Mapas conceituais: descrevem conceitos salientes e suas estruturas espaciais.
Os mapas conceituais representam conceitos e o relacionamento entre esses
conceitos de maneira unidirecional, bidirecional ou sem direção. Ajuda na
comunicação de estruturas ou ideias complexas, além de gerar novo
conhecimento.
6.2 Laddering
O método de Laddering foi criado por Dennis Hinkle em 1965. Bourne & Jenkins
(2005) utilizaram os fundamentos da Teoria dos Construtos Pessoais de George Kelly para o
desenvolvimento de seu trabalho.
O método, de acordo com Bourne e Jenkins (2005, p.411) e descrito como:
...um método para elicitar abstrações de alto nível dos conceitos que as
pessoas utilizam para organizar seu mundo... No mais alto nível de explicação – o
mais alto nível dos conceitos pessoais – se colocam as prioridades de valor pessoal
individuais... O método Laddering se baseia na suposição de que deve ser possível
encontrar pontos de entrada no template da pessoa ou sistema de construtos e seguir
o caminho hierárquico até os construtos de mais alto nível.
52
Já Kjaergaard e Jensen (2008, p. 7) descrevem o método Laddering como “um método
que ajuda a elicitar as abstrações do mais alto ou mais baixo nível dos conceitos que as
pessoas utilizam para organizar seu mundo”.
Segundo Bourne e Jenckins (2005) esta metodologia tem sido utilizada em diferentes
áreas do conhecimento por vários autores:
 Psicologia: Adam-Webber (1979) e Wright (1970);
 Pesquisa de mercado: Gutman (1990), Reynolds & Gutman (1988) e Walker
& Olson (1991);
 Gestão de recursos humanos: Jolly, Reynolds & Slocum (1988)
 Elicitação de valores da alta gerência para a tomada de decisões: Armstrong
(1979) e Eden & Ackermann (1998).
Figura 10 Exemplo da aplicação de Laddering

Fonte: Bourne e Jenkins (2005)
A Figura 10 exemplifica a utilização da metodologia, numa aplicação para identificar
a partir de que ponto de vista dois colegas eram similares. Primeiro foi desenvolvida a linha
de argumentação do lado esquerdo da imagem, para depois identificar os polos opostos dos
53
conceitos extraídos. Os autores também relatam que se sabe que chegaram ao topo da escada
quando o entrevistado não tem mais informações a adicionar.
Bourne & Jenkins (2005) utilizam uma adaptação da abordagem do Laddering como
método de entrevista para elicitar valores no nível gerencial. A abordagem adaptada de
Bourne e Jenkins é com foco nas diferenças dos valores e não nas similaridades como
proposto por Dennis Hinkle apud Bourne & Jenckins (2005).
Do mesmo modo, Kjaergaard & Jensen (2008) realizaram um estudo de caso na área
de saúde. O objetivo era elicitar dos usuários informações que fazem sentido (sensemaking)
dos usuários, i.e., a equipe médica para aprimorar um sistema de informação chamado EPR
Histórico Eletrônico de Pacientes, por sua sigla em inglês (Electronic Patient Record).
É importante esclarecer que as informações sensemaking se referem a informações
com significado, com razão de ser, com propósito definido, ou seja, que fazem sentido. (neste
texto se utilizará o anglicismo sensemaking).
Para este propósito, Kjaergaard & Jensen (2008) utilizaram um conjunto de
metodologias e técnicas incluindo os mapas cognitivos propostos por Colin Eden e a técnica
de Laddering desenvolvida por Dennis Hinkle.
O processo adotado por Kjaergaard & Jensen (2008) é descrito a seguir:
Analise prévia
1. Observação das atividades e procedimento de trabalho do pessoal (médicos).
2. Criação de “cartões de inspiração” a partir das informações observadas ou de
documentos existentes. Cada cartão representava uma atividade ou um assunto
a ser analisado.
Abordagem individual
54
3. Priorização dos cartões por parte dos entrevistados
4. Relato de histórias dos entrevistados com relação aos cartões como forma de
aquecimento para a entrevista.
5. Entrevistas semi-estruturadas utilizando a técnica de Laddering. A
representação da técnica foi de maneira textual e não gráfica como no casso
anterior. Por exemplo:
 Entrevistador: O que você entende por...?
 Médico: observação 1
 Entrevistador: O que implica..?
 Médico: observação 2
 Entrevistador: Por que este [aspecto] é importante para você?
 Médico: Observação 3
 Entrevistador: Por que este [aspecto] é importante para você?
 ... até o entrevistado não ter mais resposta.
6. Transformar o texto da técnica de Laddering em mapa cognitivo individual,
somente considerando os conceitos mais relevantes, os conceitos sensemaking.
7. Integrar os mapas cognitivos dos participantes em um mapa cognitivo
agregado, categorizar os enunciados e as observações para construir os
relacionamentos entre eles.
8. Os entrevistados receberam o mapa agregado para validar o resultado.
Abordagem em grupo
9. Sessão em grupo para discutir o mapa agregado e validar as informações,
identificar conceitos relevantes e validar as conclusões extraídas da
intervenção.
55
6.3 SODA: Desenvolvimento e Análise de Opções Estratégicas
O foco da metodologia SODA nasce no contexto da Pesquisa Operacional como
suporte para tomada de decisões. Utiliza como fundamentos os mapas cognitivos e a Teoria
dos Construtos Pessoais de Kelly. A metodologia pertence ao campo dos Sistemas de Apoio à
Decisão em Grupo (GDSS por suas siglas em inglês).
Eden (1998, p.8) define os objetivos da metodologia SODA como “...ajudar a equipe a
‘definir’ a natureza de seu assunto, i.e., identificar questões chave dentro do problema e sua
relação entre elas, e estabelecer a natureza das metas do sistema dentro do qual os assuntos
estão definidos”.
A Figura 11 representa a estrutura genérica de um mapa SODA e sua nomenclatura. A
construção segundo Ackermann & Eden (1992) do mapa consiste de:
1. A descrição de um problema é dividida entre os principais tópicos do problema
e cada um deles é considerado como uma ideia ou conceito.
2. As ideias ou conceitos são ligados entre si para representar o problema de
maneira gráfica.
3. Geram-se os polos opostos de cada ideia para criar um contraste e reforçar o
significado da ideia. Os polos opostos referem-se ao conceito oposto do que foi
falado pelo decisor, i.e. o desejo oposto, o valor oposto, ao contrario de.
4. As ideias ou conceitos são interligados de maneira hierárquica para mostrar
relacionamentos meios-fins.
A metodologia SODA, citada como uma ferramenta de mapas causais no Capítulo 5
foi aplicada para elicitar requisitos no desenvolvimento de sistemas de informação como
publicado por Bryant (1997). O foco da aplicação foi em processos, para identificar metas dos
56
processos alinhados com a estratégia da organização. A metodologia foi utilizada para elicitar
perspectivas pessoais dos executivos e gerar debate, além de ajudar a integrar usuários do
sistema e desenvolvedores. Os resultados foram algumas metas que indicavam requisitos
funcionais (BRYANT, 1997).
Figura 11 Nomenclatura e Hierarquia do Mapa Cognitivo da metodologia SODA

Fonte: Adaptado de Ackermann & Eden (1992) e Eden (1998)
A aplicação consistiu dos seguintes passos (BRYANT, 1997):
Abordagem individual
1. Entrevista informal com os usuários ou representantes de cada processo chave
da organização de maneira individual. A entrevista é feita por meio de mapas
cognitivos mostrando o argumento da entrevista graficamente.

57
2. Breve análise das construções cabeça-cauda da cadeia de argumentos. Aonde
as cabeças representam objetivos e as caudas representam meios ou ações e
identificando metas pessoais e as não-metas.
3. Integração e revisão dos diferentes mapas gerados para poder identificar temas
em comum relevantes ao problema em análise.
4. Listagem dos assuntos chave desses temas em comum.
5. Criação de um mapa para cada assunto chave com as informações contidas no
mapa integrado.
6. Identificação das metas e não metas para o mapa de cada assunto e representá-
las numa tabela para criar pacotes de trabalho na sessão em grupo contendo
essas informações geradas pelos analistas com base nas entrevistas individuais
Abordagem em grupo
7. Formação de grupos de trabalho para cada assunto chave.
8. Construção dos mapas a partir dos pacotes do assunto para gerar mais ideias e
debate.
9. Identificação dos conceitos críticos e geração dos objetivos “hard” e soft”
para cada um deles.
10. Refinamento dos objetivos emergentes.
11. Organização das ideias de maneira hierárquica em: alto nível, atividades,
informações, pessoas e papeis e genéricas e representá-las numa tabela.
12. Para cada item desta tabela, os participantes definem: requisitos funcionais,
métricas e métodos de avaliação.

58
7 Processo de Análise de Stakeholders Utilizando Mapas Cognitivos
7.1 Escopo e Objetivos do Processo
7.1.1 Escopo
A delimitação do escopo da aplicação do Processo de Análise de Stakeholders
Utilizando Mapas Cognitivos é a mesma que delimita a Análise de Stakeholders na
Engenharia de Sistemas. A Figura 12 representa visualmente o escopo em vermelho deste
processo dentro da Engenharia de Sistemas.
A Análise de Stakeholders acontece dentro da primeira fase do modelo em V Missão e
Conceito do Sistema identificado na cor vermelha.
Figura 12 Escopo do Processo de Análise de Stakeholders dentro da Engenharia de Sistemas

Fonte: Adaptado de COELHO (2011)
O processo pode ser utilizado sempre que seja necessária uma Análise de Stakeholders
para a definição e estruturação de um problema a ser resolvido, esteja este em qualquer nível
de abstração ou detalhamento de um sistema. O modelo em V representado na Figura 12 é

59
genérico e de alto nível e, dependendo da complexidade do sistema, este pode ser aplicado ao
nível de subsistema ou de elemento do sistema. Desta maneira, o processo de Análise de
Stakeholders pode ser utilizado para a elicitação de informações durante a definição da missão
do sistema, de um subsistema, de um componente do sistema.
Para representar o escopo do processo de Análise de Stakeholders dentro da
Engenharia de Requisitos, retoma-se a Figura 4 para delimitá-lo graficamente, como se
mostra na Figura 13. As caixas pretas são as que estão totalmente dentro do escopo do
processo, já a caixa cinza é abordada de maneira parcial, pois não se chega até a definição dos
requisitos, mas existe uma análise e seleção de informações que serão transformadas em
requisitos.
Figura 13 Processo de Engenharia de Requisitos

Fonte: Adaptado de Bahill & Dean (2009, p.228)
O processo pode ser utilizado sempre que seja necessário elicitar informações de um
stakeholder para entender o ponto de vista dele e suas necessidades. O processo pode ser
60
iniciado a partir de uma simples frase ou desejo para o desenvolvimento de um novo sistema
ou até mesmo com a estruturação de informações precedendo a escrita formal dos requisitos.
O processo termina na identificação de informações relevantes para a criação dos requisitos.
O processo não contempla a transformação dessas informações em requisitos formais.
Entendam-se requisitos formais como a tradução da necessidade para um padrão de escrita de
requisitos, com léxico semântico definido, claros o suficiente para serem implementados pelos
desenvolvedores no projeto.
Após a identificação das necessidades relevantes, as informações podem servir de
entrada para aplicar a técnica QFD (Quality Function Deployment) para converter as
necessidades, que no caso seriam os atributos do cliente, em requisitos e seu desdobramento.
(HAUSER & CLAUSING, 1988)
7.1.2 Objetivos
O objetivo do processo é ajudar na elicitação de informações relevantes para a
concepção e desenvolvimento de sistemas, assim como manter a justificativa das informações
mais relevantes.
Objetivos específicos do processo proposto
1. Auxiliar na elicitação de informações de stakeholders de maneira exaustiva,
até o mesmo não ter mais resposta.
2. Auxiliar na estruturação das informações extraídas para consequentemente
estruturar o problema.
3. Capturar o rationale ou justificativa das informações relevantes para assim
manter a rastreabilidade do requisito, o que auxilia no momento dos trade-offs
que levam à solução a ser implementada.

61
4. Auxiliar no nivelamento do entendimento entre stakeholder e engenheiro de
desenvolvimento e o engenheiro de sistemas.
7.2 Interpretação da Modelagem do Processo
A descrição do processo proposto ocorre primeiramente no seu nível mais alto, ou
seja, a nível de processo, para depois descrever cada subprocesso junto com suas atividades.
Para auxiliar no detalhamento do processo se utilizam dois tipos de modelagem.
Primeiro se apresenta no modelo de IDEF0 para descrever o ambiente do processo: entradas,
saídas, mecanismos e controle. A descrição dos fluxos se apresenta no Apêndice A.
Depois se utiliza uma modelagem de fluxograma para descrever o comportamento do
processo, a qual é feitas nos primeiros dois níveis do processo, no qual se identificam as
atividades mais críticas de cada subprocesso. O detalhamento do terceiro nível do processo
será de maneira descritiva. Os níveis do processo se definem como processo, subprocesso,
atividades e tarefas.
O Apêndice B apresenta a modelagem do fluxograma no segundo nível de
detalhamento do processo completo, com suas vinte e uma atividades, e não por subprocesso
como se apresenta neste capítulo.
É importante ressaltar que se trata de um processo iterativo, que, em qualquer estágio
do mesmo pode-se voltar a qualquer atividade anterior, à raiz de novas descobertas que não
tinham sido levadas em consideração para a análise do problema. Também se pode reformular
a necessidade inicial identificada e seu contexto; e assim levar à identificação de novos
problemas e/ou necessidades.
Existem diferentes tipos de aplicação do processo descritos no Apêndice C.

62
7.3 Processo de Alto Nível
Existem três funções principais no processo proposto. A primeira é o entendimento e
estruturação do problema a ser resolvido pelo sistema a ser concebido. A segunda é a
elicitação de informações relevantes para o entendimento das necessidades dos stakeholders,
as quais serão transformadas em requisitos. A terceira é a captura gráfica do rationale da
necessidade, o que formará parte do rationale sobre o requisito para ajudar na tomada de
decisões durante os trade-offs.
Figura 14 IDEF0 Processo de Análise de Stakeholders Utilizando Mapas Cognitivos
A Figura 14 representa o contexto do processo de alto nível. As entradas representam
todas as informações que estejam disponíveis para a análise inicial da necessidade, sejam
documentos ou conversas. Essas entradas são processadas com dois tipos de recursos e três
tipos de controle ao longo de todo o processo. Os recursos se referem a no mínimo dois
engenheiros de sistemas e um software de apoio para o mapeamento. Os tipos de controle se

63
referem à validação dos engenheiros de sistemas, que também são os recursos do processo, a
validação dos próprios stakeholders e finalmente a validação dos engenheiros de
desenvolvimento, clientes desse processo. Assim, o processo gera a descrição do problema
analisado, problema estruturado graficamente, informações relevantes identificadas como
necessidades, medidas de efetividade (MoE’s), restrições, pressupostos etc., o rationale dessas
informações relevantes e um entendimento nivelado entre os stakeholders e entre os
stakeholders e os engenheiros de requisitos.
Figura 15 Processo de Análise de Stakeholders Utilizando Mapas Cognitivos Nível 1
A Figura 15 representa as grandes etapas do processo, que serão chamadas de
subprocessos, e sua sequência. O processo se inicia com a entrada da necessidade inicial, que
pode ser um ativador do processo. Com essa necessidade se inicia a análise do contexto dessa
necessidade (subprocesso 1.0), se valendo de diferentes tipos de fontes de informações, como
se lista nas entradas da Figura 14. Após analisar o contexto e ter uma visão mais detalhada da
necessidade e de ter identificado os stakeholders dessa necessidade, se parte para a elaboração
de uma estratégia de intervenção (subprocesso 2.0), pois em cada caso serão requeridas ações
que mais se adaptem à situação em estudo. Após a elaboração da estratégia, se parte para a
64
implementação dessa estratégia, que tem como finalidade a elicitação das informações dos
stakeholders por meio da criação dos mapas cognitivos (subprocesso 3.0). Assim que se
elaboram os mapas junto aos stakeholders, os engenheiros de sistemas analisam os mapas
resultantes (sub-sistema 4.0), identificam clusters, identificam informações confusas,
contraditórias ou omissas, ou até novos assuntos a serem explorados, além da integração de
mapas, caso aplicável para depois complementar e validar os mapas analisados com os
stakeholders. Finalmente, após a validação dos mapas por parte dos stakeholders e dos
engenheiros de sistemas, é o momento de reunir as informações e estudar o problema como
um todo, identificar as necessidades raiz, identificar o rationale das necessidades raiz e
descrever o problema (subprocesso 5.0).
7.4 Subprocesso 1.0 Análise do Contexto
1.0 ANÁLISAR O CONTEXTO
A função principal é analisar o contexto da situação problemática ou necessidade
inicial para que os engenheiros de sistema tenham informações suficientes e assim poder
abordar os stakeholders, criar as trigger questions e fazer questionamentos estratégicos para a
elicitação de informações.
A Figura 16 representa o contexto do subprocesso 1.0 Analisar o Contexto. As
entradas representam todas as informações possíveis para analisar o contexto da necessidade,
sejam estas escritas, formais, informais ou de maneira verbal. O subprocesso se desenvolve
com no mínimo dois engenheiros de sistemas como recursos e como mecanismo de controle,
a validação dos próprios engenheiros de sistemas e dos stakeholders iniciais acessíveis até
esta etapa do processo. Assim, o subprocesso gera, como resultados, o contexto detalhado da
necessidade, uma lista de stakeholders do problema e, caso aplicável, uma lista de cenários da
situação.
65
Figura 16 IDEF11.0 Analisar o Contexto
A Figura 17 representa o fluxo de atividades do subprocesso 1.0 Analisar o Contexto.
O subprocesso se inicia com a entrada da necessidade inicial. Com essas necessidades se
inicia a análise do contexto da situação (atividade 1.1). Assim que o contexto foi analisado,
apresenta-se um fluxo com condições complexas representado pelo asterisco dentro dum
losango. Isso quer dizer que as três atividades a seguir são iterativas, sem sequência definida,
podem acontecer em paralelo, mas uma pode retroalimentar a outra. A identificação de
cenários (atividade 1.4) e a análise de informações (atividade 1.3) podem levar à identificação
de novos stakeholders (atividade 1.2) e vice-versa, além do que a análise de informações pode
levar à identificação de novos cenários e vice-versa. Assim que o máximo de informações do
contexto foi analisado e os stakeholders e cenários do sistema foram identificados, prossegue-
se com a elaboração da estratégia de intervenção (subprocesso 2.0).

66
Figura 17 Subprocesso 1.0 Analisar o Contexto
Entrada: Necessidade inicial
A Necessidade identificada inicialmente é geralmente uma frase, uma ideia de que um
sistema deve ser criado ou deve ter uma melhoria para atender melhor alguma necessidade ou
atender novas necessidades que não foram contempladas anteriormente.
Quem identifica a necessidade inicial, geralmente é um dos principais stakeholders.
Atividade 1.1 Analisar o contexto da necessidade
O objetivo desta atividade é que o engenheiro de sistemas conheça o contexto para
poder definir a abordagem mais apropriada ao estudo do problema.
1.1.1 Identificar a necessidade inicial.

67
1.1.2 Conhecer o contexto da necessidade inicial, a organização e sua cultura por meio
de conversas informais com os stakeholders essenciais ou em documentos relacionados ao
ambiente da necessidade. Cultura organizacional sendo entendida como os valores da
organização, a maneira de trabalhar e de resolver problemas e suas as melhores práticas.
1.1.3 Criar linhas de estudo para a identificação e entendimento do problema.
A continuação se descrevem três atividades que são iterativas no processo (1.2, 1.3 e
1.4), elas se retroalimentam e geram informações relevantes entre si. Não existe
sequenciamento entre elas, uma pode levar à outra.
Atividade 1.2 Identificar stakeholders
O objetivo desta atividade é que o engenheiro de sistemas descubra quais são os
stakeholders que, com as informações que se têm até o momento e com a ajuda do
stakeholder inicial que deu a entrada no processo, são os mais relevantes para definir o
problema ou a missão.
1.2.1 Identificar stakeholders.
Alternativas para identificação de stakeholders:
a. Conversas informais com pessoas relacionadas à necessidade, entre elas o
stakeholder que identificou a necessidade inicial.
b. Análise de cenários fornece a maneira mais exaustiva para a identificação dos
stakeholders em todas as fases do ciclo de vida do sistema. Essa opção é
válida, sempre que exista uma versão anterior do sistema, dado que se o
sistema é inexistente, seria prematuro inferir o ciclo de vida do mesmo. Mas
cada caso é particular, e é responsabilidade do engenheiro de sistemas decidir a
maneira mais adequada para a identificação dos stakeholders.

68
c. Revisão de documentos existentes referentes à necessidade inicial.
1.2.2 Priorizar stakeholders estabelecendo critérios próprios. Ex. poder econômico,
poder político, influência, etc.
1.2.3 Classificar stakeholders nas seguintes categorias e suas possíveis combinações
para a participação no processo de análise:
a. Acessíveis pessoalmente
b. Não acessíveis pessoalmente
c. Com disposição
d. Sem disposição
e. Com disponibilidade
f. Sem disponibilidade
g. Substitutos
Iteração com a atividade 1.2: A identificação de stakeholders pode levar a outros
cenários e os cenários ajudam na identificação dos stakeholders.
Iteração com a atividade 1.4: a análise de informações pode ajudar a identificar novos
stakeholders e a identificação de novos stakeholders pode levar a outras informações.
Atividade 1.3 Analisar informações existentes da necessidade inicial
O objetivo desta atividade é que o engenheiro de sistemas se contextualize para assim
poder abordar a problemática. Se ele tem o conhecimento do contexto e da necessidade
inicial, tem capacidade para conduzir o processo de elicitação de informações, o que levará a
requisitos de qualidade no que se refere a conteúdo.
1.3.1 Procurar informações referentes à necessidade e/ou aos cenários de interesse. Ex.
pesquisa de mercado, relatórios e estatísticas de serviço ao cliente, artigos publicados,

69
procedimentos documentados, relatórios técnicos, minutas de reuniões, e tudo o que for
considerado essencial.
1.3.2 Identificar informações essenciais para o entendimento do contexto e do
problema.
1.3.3 Se necessário, representar informações graficamente para sua melhor análise.
1.3.4 Identificar possíveis stakeholders que não tenham sido identificados
anteriormente ou atualizar priorização de stakeholder com base em novas informações.
1.3.5 Identificar novos cenários relevantes.
1.3.6 Separar o contexto ou problema em grandes temas, sempre que tiver as
informações suficientes.
Iteração com a atividade 1.2: As informações analisadas podem identificar cenários
relevantes e os cenários relevantes podem levar à obtenção de novas informações.
Iteração com a atividade 1.3: a análise de informações pode ajudar a identificar novos
stakeholders e a identificação de novos stakeholders pode levar a outras informações.
Atividade 1.4 Identificar os cenários relevantes nas fases do Ciclo de Vida do
Sistema
O objetivo desta atividade é dar completude ao processo, evitar excluir qualquer
informação e cenário valioso para o processo de elicitação e estruturação do problema. É
fundamental que a definição do problema leve em consideração os diferentes cenários do
sistema e assim cumpra com a abordagem sistêmica que caracteriza a Engenharia de
Sistemas. O fato de olhar para todos esses cenários é o que vai garantir uma solução sistêmica
e integral; do contrário, a solução será projetada somente para uma parte do problema o que
70
não garante a solução do problema total, e inclusive pode trazer novos problemas pela falta da
análise sistêmica. Isto é o que caracteriza à Engenharia de Sistemas, o olhar sistêmico.
Esta atividade é aplicável quando a missão já foi definida e esteja se analisando a
partir do nível de sistema. Quando se está no nível da missão, ainda não se está lidando com
conceitos de solução para poder assim definir um ciclo de vida. No nível de missão, apenas se
está entendendo a necessidade, o problema que é preciso resolver.
1.4.1 Identificar as fases do ciclo de vida do sistema de interesse.
1.4.2 Identificar as fases de interesse a serem analisadas em detalhe.
1.4.3 Identificar os cenários de interesse para as fases identificadas, que serão
estudados durante o Processo de Análise de Stakeholders.
Iteração com a atividade 1.3: A identificação de stakeholders pode levar a outros
cenários e os cenários ajudam na identificação dos stakeholders.
Iteração com a atividade 1.4: As informações analisadas podem identificar cenários
relevantes e os cenários relevantes podem levar à obtenção de novas informações.
7.5 Subprocesso 2.0 Elaboração da Estratégia de Intervenção
2.0 ELABORAR ESTRATÉGIA DE INTERVENÇÃO
A Figura 18 representa o contexto do subprocesso 2.0 Elaborar Estratégia de
Intervenção. As entradas representam as informações que foram geradas no subprocesso
anterior: contexto da necessidade, lista de stakeholders e cenários do problema ou sistema
(caso aplicável). O subprocesso se desenvolve com no mínimo dois engenheiros de sistemas
como recursos e como mecanismo de controle, a validação pelos próprios. Assim, o
subprocesso gera a estratégia de intervenção. Esta estratégia descreve que stakeholders serão
71
abordados e se será uma abordagem individual ou em grupo. Também formula as trigger
questions, que são a base para obter um mapa cognitivo rico em informações.
Figura 18 IDEF1 2.0 Elaborar estratégia de intervenção
A Figura 19 representa o fluxo de atividades do subprocesso 2.0 Elaborar Estratégia de
Intervenção. O subprocesso vem na sequência da Análise do Contexto (subprocesso 1.0).
Com a lista de stakeholders identificada, se faz o contato e se verifica sua disposição de
cooperação com a análise, além da disponibilidade para participar das sessões (atividade 2.1).
Já com a definição, estabelece-se quais stakeholders, de que maneira serão abordados e a
estratégia para gerar os mapas cognitivos (atividade 2.2). Dependendo dos tipos de
stakeholders que resultarem, são geradas as trigger questions (atividade 2.3) adequadas para
cada stakeholder ou grupo de stakeholders. Assim que a estratégia é estabelecida e as trigger
questions elaboradas, prossegue-se à elicitação das informações dos stakeholders
(subprocesso 3.0).
72
Figura 19 Subprocesso 2.0 Elaborar Estratégia de Intervenção
Atividade 2.1 Contatar stakeholders identificados
O objetivo desta atividade é entrar em contato com os stakeholders, procurar por
contatos afins ou preparar material formal de solicitação da participação da concepção do
sistema.
Atividade 2.2 Estabelecer estratégia de intervenção
O objetivo desta atividade é determinar qual será a abordagem, que recursos e
stakeholders estão disponíveis e se esses stakeholders podem ser abordados em grupo ou de
maneira separada.
73
2.2.1 Definir, com base na priorização e classificação dos stakeholders, o seguinte:
a. Stakeholders que serão entrevistados individualmente
b. Grupo de stakeholders que serão entrevistados simultaneamente
c. Stakeholders que serão solicitados a escrever texto
2.2.2 Definir que documentos existentes serão utilizados como texto fonte para a
criação do mapa.
2.2.3 Identificar que trigger questions serão aplicadas para quais stakeholders.
Atividade 2.3 Construir trigger questions
O objetivo desta atividade é preparar os questionamentos chave para provocar a
reflexão dos stakeholders nas possíveis capacidades chave do sistema.
A boa formulação das trigger questions é fundamental para a qualidade das
informações extraídas durante o processo. São elas que desencadeiam o inicio do processo de
elicitação. Se elas não são bem formuladas, a intervenção com o stakeholder pode não obter
bom resultados, ou pode-se obter resultados com poucas informações relevantes, a ponto de
desanimar o stakeholder para as próximas intervenções.
2.3.1 Selecionar as necessidades relevantes identificadas na atividade 1.4.
2.3.2 Identificar assuntos pontuais.
2.3.3 Analisar informações.
2.3.4 Derivar trigger questions a partir da análise. As trigger questions devem ser
construídas para incitar à reflexão e desencadear uma série de pensamentos e associações do
stakeholder. Esta deve elicitar e não direcionar a resposta.

74
7.6 Subprocesso 3.0 Elicitação das Informações dos Stakeholders com Mapas
Cognitivos
3.0 ELICITAR INFORMAÇÕES DOS STAKEHOLDERS COM MAPAS
COGNITIVOS
Neste subprocesso acontece a implementação da estratégia de intervenção para
cumprir com a função principal que é a construção dos mapas cognitivos com os stakeholders
de maneira iterativa e interativa e a partir das trigger questions elaboradas estrategicamente.
Figura 20 IDEF1 3.0 Elicitar Informações dos Stakeholders com Mapas Cognitivos
A Figura 20 representa o contexto do subprocesso 3.0 Elicitar Informações dos
Stakeholders com Mapas Cognitivos. As entradas representam as informações que foram
geradas nos subprocessos anteriores: contexto da necessidade, lista de stakeholders e cenários
do problema ou sistema, caso aplicável, a estratégia de intervenção e as trigger questions. O
subprocesso se desenvolve com no mínimo dois engenheiros de sistemas e um software de

75
suporte para a geração dos mapas como recursos e como mecanismo de controle, a validação
dos próprios engenheiros de sistemas. Assim, o subprocesso gera, como resultados, as
informações elicitadas no formato de mapas cognitivos, principal objetivo deste processo.
Figura 21 Subprocesso 3.0 Elicitar Informações dos Stakeholders com Mapas Cognitivos
A Figura 21 representa o fluxo de atividades do subprocesso 3.0 Elicitar Informações
dos Stakeholders com Mapas Cognitivos. O subprocesso vem na sequência da Elaboração da
Estratégia de Intervenção (subprocesso 2.0). O processo se inicia com a entrada da estratégia
de intervenção, na qual se pode ter três tipos de situações. A primeira é que os stakeholders
aceitaram participar pessoalmente da construção dos mapas. Nesse caso, se elicitam
informações dos stakeholders construindo os mapas (atividade 3.1), seja de maneira

76
individual ou em grupo de stakeholders. A segunda situação é que o stakeholder não possa
participar interagindo diretamente, mas que disponibilize textos (atividade 3.2) respondendo
às trigger questions, que não sendo a melhor opção, ainda assim podem ser elicitadas
informações relevantes. A terceira alternativa é que o stakeholder não esteja acessível, seja
qual for o motivo, e se utilizem documentos que possam ter informações do ponto de vista
daquele stakeholder (atividade 3.3) para que sirvam como fonte para a construção do mapa.
Nas últimas duas alternativas, após ter acesso aos textos, elicitam-se os textos elaborando os
mapas (atividade 3.4). Assim que os mapas cognitivos foram construídos, prossegue-se com a
análise dos mapas resultantes (subprocesso 4.0).
Atividade 3.1 Elicitar informações dos stakeholders construindo mapas cognitivos
O objetivo desta atividade é elicitar todo tipo de informações que possam vir do
stakeholder como necessidades, expectativas, MoE’s, restrições, sentimentos, valores,
vontades, objetivos, suposições, entre outras, e ajudar ao stakeholder a colocar em ordem sua
visão do problema e ser mais analítico com a situação ajuda na estruturação do problema.
A construção do mapa pode ser realizada tanto com a utilização de software quanto
manualmente.
3.1.1 Realizar uma introdução à intervenção.
É importante explicar para o stakeholder o significado da palavra stakeholder e porque
ele esta sendo considerado como tal; quais são os objetivos da entrevista com ele e explicar
como será o processo a ser seguido. Isto, para que ele não se sinta acuado, constrangido ou
desconfortável com a série de questionamentos aos que será submetido.
Cabe também explicar a ele que o processo é altamente iterativo, que o mapa
dificilmente é concluído na primeira abordagem e que o mapa é sujeito a muitas mudanças

77
realizadas por ele, após a visualização gráfica de suas próprias expressões. Nos casos em que
a elicitação ocorre em grupo, o fato de conhecer a visão do problema sob outro ponto de vista,
também gera reorganização das ideias o que leva a novas considerações por parte dos outros
membros do grupo.
3.1.2 Escrever as “trigger questions” na parte inferior da área onde será gerado o
mapa, como se mostra na Figura 22.
Figura 22 Inicio do mapa com trigger questions
3.1.3 Realizar a primeira trigger question ao stakeholder e anotar as respostas no
sentido superior e associando as respostas às perguntas por meio de setas como mostra a
Figura 23. Todas as informações que o stakeholder expresse em frases, serão consideradas
como conceitos.
78
Figura 23 – Primeiros conceitos a partir das “trigger questions”
3.1.4 A partir das respostas dadas pelo stakeholder desdobrar no nível seguinte aquela
resposta por meio das perguntas “Por que?”, “Como?”, “Quando?” ou qualquer outra
pergunta que o engenheiro de sistemas queira fazer. Na seta se escreve a pergunta que foi
realizada. Quando não se tem um questionamento específico, a pergunta “Por que?” ou “Por
que isso é importante?” ajuda a elicitar novos conceitos como se mostra na Figura 24.
A pergunta “por quê?”, é a pergunta padrão e que deve ser realizada para incentivar
mais a elicitação. É o andamento do mapa que vai indicar com qual pergunta continuar.
Também o conhecimento e habilidade do engenheiro de sistemas ajudam a conduzir a
elicitação.
A construção do mapa é de baixo para cima mantendo o rationale, interligando as
setas, sempre mantendo representada na seta a pergunta que levou ao próximo conceito para
que o rationale seja capturado.

79
Figura 24 – Processo de elicitação do mapa cognitivo
Atividade 3.2 Solicitar texto aos stakeholders inacessíveis pessoalmente
O objetivo desta atividade é de capturar qualquer informação que possa ser valiosa
para a análise dos stakeholders e não se limitar às intervenções presenciais. Durante a Análise
de Stakeholders é comum que alguns stakeholders não estejam acessíveis pessoalmente, seja
por questões geográficas, de agenda ou de nível hierárquico. Nestes casos considera-se a
solicitação de textos, a maneira de não excluir informações valiosas destes stakheolders que
não podem participar da intervenção.
Esta maneira de abordagem ao stakeholder pode não ser tão enriquecedora em termos
de informações extraídas, mas não se pode descartar nenhuma oportunidade de obtenção de
informações de um stakeholder ainda mais se este for essencial para o problema em estudo.
Nestes casos também se pode optar pela ajuda do software. Atualmente o software
livre Cmap Tools (http://cmap.ihmc.us/) dá essa oportunidade. Os mapas podem ser criados
80
iterativamente por meio da internet e várias pessoas participam em tempo real na elaboração
colaborativa de um mapa cognitivo. Isto pode ser aplicado sempre que o stakeholder tenha
vontade e disponibilidade.
3.2.1 Contatar o stakeholder.
3.2.2 Realizar ou enviar a introdução da intervenção ao stakeholder.
3.2.3 Enviar trigger questions e solicitar responder a no mínimo três por que’s? após
responder cada trigger question.
Atividade 3.3 Identificar documentos existentes relacionados à análise.
O objetivo desta atividade é aproveitar informações valiosas e relevantes que já
tenham sido elicitadas em documentos existentes.
Esta atividade somente é desenvolvida se não se tem acesso ao stakeholder ou
stakeholder substituto.
3.3.1 Identificar o problema ou cenário que está sendo analisado.
3.3.2 Solicitar documentos aos stakeholders acessíveis e relacionados ao problema ou
cenário.
3.3.3 Contatar novos stakeholders que possam fornecer documentos de referência.
Para este ponto podem ser levados em consideração os documentos identificados na atividade
1.4 Analisar informações existentes.
Atividade 3.4 Elicitar informações dos documentos construindo mapas cognitivos.
O objetivo desta atividade é elicitar dos documentos gerados pelos stakeholderes ou
dos documentos identificados. O mapa permitirá analisar e compreender o ponto de vista do

81
stakeholder e, assim, dar mais fundamentos para questionar e encontrar gaps nas informações
fornecidas que, para o stakeholder podem parecer óbvias, mas, para a análise e entendimento
do problema, não sejam tão óbvias assim.
Outro dos objetivos desta atividade é resgatar informações que possam não ser
aproveitadas, além de focar a análise de documentos que foram gerados por outras pessoas
que não estejam mais em contato e que tenham deixado conhecimento valioso nesses
documentos. O mapa cognitivo ajudará na organização daquelas informações e poderá ser
ponto de partida para novas considerações ou detalhamento de informações. Será uma espécie
de gestão e análise do conhecimento.
Quando não se tem nenhum tipo de acesso ao stakeholder ou stakeholder substituto,
existe a opção de criar o mapa cognitivo a partir de documentos existentes, onde possam ser
extraídas as informações na forma de um mapa cognitivo e integradas aos mapas resultantes
com os outros stakeholders na forma de complemento.
O mapa é construído, se for possível, a partir das trigger questions, ou a partir de
informações chave dentro daqueles documentos.
3.4.1 Representar as trigger questions na área inferior onde será desenvolvido o mapa.
3.4.2 Elicitar do documento informações relevantes.
3.4.3 Construir o mapa a partir das trigger questions e os conceitos identificados
dentro do texto.
3.4.4 Quando possível, representar questionamentos ou tipo de relacionamento entre
os conceitos, i.e. representando graficamente os questionamentos nas setas.

82
7.7 Subprocesso 4.0 Análise dos Mapas Cognitivos
4.0 ANALISAR MAPAS COGNITIVOS
A função de analisar os mapas cognitivos previamente gerados consiste em duas
etapas. A primeira etapa é identificar clusters de assuntos nos mapas, sejam estes individuais
ou em grupo. A segunda etapa acontece no caso de haver vários mapas individuais a respeito
da mesma necessidade, assunto ou cenário; os mapas individuais são integrados num mesmo
mapa que represente a visão dos vários stakeholders o que também funciona como ferramenta
de consenso.
Figura 25 IDEF1 4.0 Analisar Mapas Cognitivos
A Figura 25 representa o contexto do subprocesso 4.0 Analisar os Mapas Cognitivos.
As entradas representam as informações elicitadas dos stakeholders, resultantes do
subprocesso anterior. O subprocesso se desenvolve com no mínimo dois engenheiros de
sistemas e um software de suporte para a geração dos mapas como recursos e como
83
mecanismo de controle, a validação pelos próprios engenheiros de sistemas e a validação
pelos stakeholders participantes da geração dos mapas. Assim, o subprocesso gera como
resultados os mapas cognitivos individuais validados, o mapa cognitivo integrado e validado,
caso aplicável, e o problema estruturado graficamente.
Figura 26 Subprocesso 4.0 Analisar Mapas Cognitivos
A Figura 26 representa o fluxo de atividades do subprocesso 4.0 Analisar Mapas
Cognitivos. O subprocesso vem na sequência da elicitação das informações dos stakeholders
(subprocesso 3.0). Nesse processo, é responsabilidade dos engenheiros de sistemas analisar as
informações elicitadas (atividade 4.1), identificar inconsistências nos mapas e identificar
informações faltantes ou assuntos novos a serem explorados, e identificar clusters de
informações referentes a um assunto em específico; para depois levar essa análise aos
stakeholders para sua validação (atividade 4.2) e no caso, para completar os mapas com novas
84
informações (atividade 4.3). Em caso de haver vários mapas individuais de um mesmo
assunto, cenário ou tipo de stakeholder, os engenheiros de sistemas integram esses mapas
individuais num só mapa (atividade 4.4) para depois validar com os stakeholders autores dos
mapas que foram integrados (atividade 4.5) e realizar modificações ou complementar o mapa
com novas informações emergentes após a integração dos mapas (atividade 4.6). Assim que
os mapas foram analisados e validados pelos stakeholders e pelos engenheiros de sistemas,
finalmente se prossegue à identificação de necessidades e análise do problema (subprocesso
5.0).
Atividade 4.1 Analisar os Mapas Cognitivos
O objetivo desta atividade é analisar clusters de necessidades de maneira isolada. Esta
atividade ajuda no entendimento e na identificação de tópicos importantes dentro do
problema, ou seja, ajuda a quebrar o problema em partes para sua análise.
A análise do mapa é feita a partir de duas abordagens, uma, é o entendimento do mapa
pelo engenheiro de sistemas e outra, é a identificação de clusters dentro do mapa.
I. Entendimento pelo engenheiro de sistemas:
4.1.1 Analisar o mapa e entender os conceitos que foram expressos pelo(s)
stakeholder(s).
4.1.2 Identificar aqueles conceitos para os quais existe dúvida.
II. Identificação dos clusters individuais:
4.1.3 Identificar uma ou mais linhas de pensamento do stakeholder focadas num
mesmo assunto.
85
4.1.4 Rearranjar graficamente as linhas de pensamento sobre o mesmo assunto para
que fiquem próximas umas das outras.
4.1.5 Diferenciar o cluster criado e dar um nome que melhor os represente.
4.1.6 Realizar com o resto do mapa até ter todos os conceitos inseridos num cluster.
É possível haver conceitos que possam pertencer a mais de um cluster; para esse caso,
é necessário localizar no cluster mais representativo e sempre manter seus relacionamentos
com os outros conceitos. O rearranjo do mapa em clusters não deve eliminar nenhuma seta de
relacionamento entre conceitos.
É importante analisar o mapa e garantir que o engenheiro de sistemas entenda o que
foi expresso, que fique claro para ele, pois será ele que trabalhará com esses dados na frente
do processo ou na geração dos requisitos formais.
Figura 27 Identificação gráfica de clusters

86
A Figura 27 representa um exemplo da identificação de clusters. Um cluster é uma ou
mais linhas de pensamento do stakeholder. Essas linhas muitas vezes estarão focadas num
tópico em específico, o que possibilitará a identificação de clusters dentro do mapa individual
o que simplificará a análise do mapa individualmente e, por outro lado, a integração dos
diferentes mapas individuais, já que é mais simples integrar clusters inteiros do que atividades
isoladas.
Atividade 4.2 Validar os mapas cognitivos com os stakeholders
O objetivo desta atividade é revisar e analisar as informações geradas junto ao
stakeholder para que valide que o mapa realmente represente o que ele transmitiu. Quando o
stakeholder vê graficamente seu pensamento e raciocínio sobre um assunto em específico,
confronta novas inferências sobre o assunto, muda de ideia e chega à conclusão que dois
conceitos não têm mais relação ou, ao contrário, que dois conceitos que acreditava que não
tinham relação, agora o relacionamento entre eles é muito claro. Pode acontecer que, na
realidade, não exista problema ou se identifique uma solução tão simples que não se requeira
um sistema para dar solução ao problema identificado. A atividade 4.2 permite que o
stakeholder repense nos conceitos e reformule conclusões ou que crie conclusões que antes de
gerar o mapa não teria condições de visualizar.
4.2.1 Fornecer total ou parcialmente os mapas aos stakeholders para que estes tenham
o mapa resultante para análise.
No caso de ser via texto, enviar ao stakeholder o mapa extraído do texto gerado por
ele e pedir para validar o mapa, se este representa fielmente o que ele expressou textualmente.
4.2.2 Modificar os mapas com as indicações dos stakeholders e se for o caso, agir
como mediador na solução de conflitos entre stakeholders.

87
Esta atividade pode ser feita num intervalo da sessão com stakeholders ou no final de
uma sessão, para continuar na sessão seguinte ou enviar de maneira eletrônica. O cenário
ideal é que aconteça numa sessão com os stakeholders presentes, pois ajuda na solução de
conflitos.
No caso de ser via texto, solicitar ao stakeholder complementar o mapa com
informações que considere relevantes e/ou responda questões que possam ter surgido ao
engenheiro de sistemas.
4.2.3 Identificar conceitos que geram conflitos e documentar os acordos feitos durante
a análise e validação dos mapas.
Atividade 4.3 Reformular e analisar mapas cognitivos com os stakeholders
O objetivo desta atividade é complementar ou corrigir o mapa cognitivo junto ao
stakeholder. No momento da validação, é comum que apareçam novas informações ou que a
percepção do stakeholder respeito do problema, tenha mudado após rever expresso no papel a
sequência de suas ideias.
Pressupõe-se que esta atividade aconteça pelo menos uma vez, pois é o processo
natural de estruturação do conhecimento ou percepção de um problema sob o ponto de vista
do stakeholder. Ele tem que ser reformulado para que melhor represente a situação real.
Atividade 4.4 Integrar os mapas cognitivos individuais
O objetivo desta atividade é integrar os diferentes pontos de vista do problema dos
diferentes stakeholders numa estrutura só. Isto provavelmente levará a conceitos conflitantes,
mas o objetivo é resolver estas contradições utilizando o mapa. Como resultado se obtém a
integração do problema. Os clusters resultantes podem definir ou ajudar na estrutura do

88
documento de requisitos na forma de atributo do requisito dando uma estrutura desde o ponto
de vista de problemas a serem solucionados.
I. Analisar os Clusters dos diferentes mapas individuais
Na atividade 4.1 Analisar os Mapas, identificam-se os clusters para cada mapa
individual. Nesta atividade se aproveitam estes clusters previamente identificados para serem
integrados num só mapa. Ou seja, os clusters existentes em mais de um mapa são integrados
para assim poder analisar os mapas em conjunto.
4.4.1. Montar uma tabela de relacionamento de clusters como se mostra no Quadro3.
Na coluna do lado esquerdo listam-se todos os clusters que resultaram de todos os mapas
individuais. Na linha superior listam-se os diferentes stakeholders donos dos mapas
individuais.
Quadro 3 - Tabela de relacionamento de Clusters

Mapa Stakeholder A Mapa Stakeholder B Mapa Stakeholder C
Cluster I X X
Cluster II X X X
Cluster III X X
Cluster IV X X
Cluster V X
4.4.2. Identificar a relação cluster-stakeholder com um xis.
4.4.3. Identificar clusters iguais ou com o mesmo significado e propor um nome que
represente ambos.
4.4.4. Identificar clusters que possam ser absorvidos ou absorver um ao outro cluster.
4.4.5. Identificar clusters que devam ser divididos para a melhor análise do problema.
89
No exemplo do Quadro 3, o mapa do stakeholder A resultou em três clusters
identificados, o mapa do stakeholder B resultou em dois clusters identificados e o mapa do
stakeholder C resultou em quatro clusters identificados.
Também se pode observar que o Cluster II foi reincidente nos três stakeholders e o
conteúdo será mantido em um só cluster. O Cluster V somente foi identificado pelo
stakeholder C, portanto não sofre mudanças na integração.
II. Agregar os conceitos
A integração dos conceitos pode ser confusa e trabalhosa porque a quantidade de
conceitos gerada é grande. Para auxiliar no gerenciamento e análise desses conceitos,
propõem-se duas alternativas:
a. Criar uma tabela com os conceitos extraídos de vários stakeholders e, junto
com a classificação preliminar de cluster, facilita a análise dos conceitos.
b. Utilizar post-its com os conceitos gerados, e diferenciar com cores ou letras os
conceitos de cada stakeholder
4.4.6 Identificar conceitos similares entre os clusters iguais.
4.4.7 Manter aquele conceito que mais represente o que os stakeholders tentaram
externar.
4.4.8 Identificar quais stakeholders repetiram esse conceito. É importante documentar
essa reincidência para ajudar na identificação de informações relevantes que acontece na
atividade 4.1 “Identificar as informações ou conceitos relevantes”. É muito provável que
aquele conceito que foi expresso por mais de um stakeholder seja transcendente para a
definição do problema e na geração de requisitos a partir destas informações.

90
Nesse processo é fundamental tentar respeitar o pensamento do stakeholder para que o
engenheiro de sistemas não influencie no resultado do mapa.
Um exemplo de quais conceitos devem ser levados em consideração é representado no
Quadro 4. O conceito número 18 é muito provável que tenha um peso maior em relação aos
outros devido ao fato de que três stakeholders identificaram essa mesma necessidade. Os
conceitos 4 e 19 também devem ser levados em consideração por sua incidência. Este é um
exemplo simples, mas quando aumenta a quantidade de conceitos e de stakeholders, aumenta
a complexidade para poder visualizar essas necessidades reincidentes.
Quadro 4 - Tabela de relacionamento de conceitos dos diferentes mapas individuais dos stakeholders.
Id. Descrição do Stakeholder A Stakeholder B Stakeholder C
Conceito conceito
23 Conceito 23 X
15 Conceito 15 X
4 Conceito 4 X X
6 Conceito 6 X
7 Conceito 7 X
18 Conceito 18 X X X
19 Conceito 19 X X
III. Agregar os clusters por meio dos conceitos integrados
Assim que os conceitos forem integrados, é possível integrar os clusters por meio dos
conceitos. Aqueles conceitos que foram reincidentes em vários mapas podem nos ajudar nesta
tarefa para poder conectar os clusters dos diferentes stakeholders. Assim, evita-se uma
estrutura de pequenos mapas individuais ilhados dentro de um cluster e facilita-se a inter-
relação dos mapas por meio desses conceitos integrados.
Também pode acontecer que os diferentes clusters estejam relacionados entre si.
91
É importante ressaltar a importância de que os stakeholders estejam todos
relacionados ao mesmo tópico específico, ou seja, ao mesmo cenário, na mesma discussão, do
contrário, a integração resultará em um mapa com uma grande quantidade de conceitos com
clusters ou blocos de clusters independentes, sem linhas de relacionamento.
Atividade 4.5 Validar mapa cognitivo integrado com os stakeholders
O objetivo desta atividade é revisar e analisar as informações integradas dos diferentes
mapas cognitivos junto aos stakeholders que participaram dos mapas individuais. Já que é o
engenheiro de sistemas o responsável pela integração do mapa, tem que ser validado que a
integração dos mapas seja fiel à situação analisada, que tenha sido coerente com o
pensamento dos stakeholders. Os stakeholders têm que validar que ainda na integração dos
mapas se respeitem suas visões e concordem com o mapa inteiro; o que pode levar a conflitos,
mas que também pode ser uma ferramenta para negociações e consenso.
Na validação do mapa integrado, os stakeholders têm oportunidade de conhecer os
diferentes pontos de vista dos outros stakeholders que participaram da elicitação, ver como os
outros enxergam o problema e conhecer aspectos que não tinham levado em consideração.
Os stakeholders devem analisar, principalmente, os seguintes aspectos:
a. Que os conceitos que foram extraídos de mais de um stakeholder e foram
unidos pelo engenheiro de sistemas tenham respeitado o significado, e
mantiveram a essência do conceito que quis ser transmitido.
b. Que as setas de relacionamento adicionadas pelo engenheiro de sistemas
estejam corretamente colocadas.
c. Que os clusters estejam bem identificados.

92
Atividade 4.6 Reformular mapa cognitivo integrado com os stakeholders
O objetivo desta atividade é, além de gerar novas e melhores conclusões e conceitos, a
de facilitar, por meio da estruturação gráfica das informações, um consenso entre os
stakeholders.
Na reformulação se realizam as mudanças identificadas durante a validação pelos
stakeholders para assim poder aproximar o mapa da realidade o máximo possível.
É na reformulação do mapa que acontece a resolução de conflitos entre os
stakeholders, o ideal é que aconteça com todos os stakeholders envolvidos no mapa,
presencialmente, numa sessão em grupo. Se isso não for possível, é tarefa do engenheiro de
sistemas resolver esses conflitos conversando com os envolvidos iterativamente, até chegar a
um consenso do mapa.
7.8 Subprocesso 5.0 Identificação de Necessidades e Análise do Problema
5.0 IDENTIFICAR NECESSIDADES E ANALISAR DO PROBLEMA
A função de analisar o problema consiste em três etapas principais. A primeira é
identificar conceitos relevantes nos clusters para serem transformados em requisitos; a
segunda etapa é identificar o rationale desses conceitos selecionados e finalmente realizar
uma descrição textual do problema analisado.
A Figura 28 representa o contexto do subprocesso 5.0 Identificar Necessidades e
Analisar o Problema. As entradas representam as informações geradas nos subprocessos:
contexto, mapas cognitivos individuais validados e o mapa cognitivo integrado e validado. O
subprocesso se desenvolve com no mínimo dois engenheiros de sistemas como recursos e
como mecanismo de controle, a validação dos próprios engenheiros de sistemas, a validação
dos stakeholders participantes da geração dos mapas e, futuramente, a validação dos

93
engenheiros de desenvolvimento que, uma vez que recebam os requisitos, validarão se os
resultados deste processo foram suficientes para o projeto do sistema. Assim, o subprocesso
gera como resultados a descrição do problema com sua descrição gráfica dos mapas
analisados, informações relevantes elicitadas pelos stakeholders (necessidades, medidas de
efetividade (MoE’s), restrições, suposições, etc), o rationale dessas informações relevantes e
o nivelamento do entendimento do problema entre os stakeholders e entre os stakeholders e
os engenheiros de sistemas.
Figura 28 IDEF1 5.0 Identificar Necessidades e Analisar o Problema
A Figura 29 representa o fluxo de atividades do subprocesso 5.0 Identificar
Necessidades e Analisar o Problema. O subprocesso vem na sequência da análise dos mapas
cognitivos (subprocesso 4.0). Já com os mapas validados pelos stakeholders, os engenheiros
de sistemas identificam as informações relevantes (atividade 5.1) que serão a fonte para criar
os requisitos, e identificarão seu rationale (atividade 5.2) o qual também faz parte dos
94
atributos do requisito resultante. Para concluir o processo, documentam-se adequadamente
essas informações relevantes e seu rationale (atividade 5.4) e gera-se um documento com a
descrição do problema e resultados da análise (atividade 5.3) Assim que o problema for
analisado e definido e as informações relevantes claramente identificadas junto com seu
rationale, conclui-se o processo de Análise de Stakeholders e prossegue-se com a criação dos
requisitos dentro do processo da Engenharia de Requisitos.
Figura 29 Subprocesso 5.0 Identificar Necessidades e Analisar o Problema

95
Atividade 5.1 Identificar as informações ou conceitos relevantes para gerar
requisitos
O objetivo desta atividade é ajudar na identificação estruturada de informações
relevantes para a criação dos requisitos, estabelecimento de MoE’s dos requisitos e restrições,
entre outras. Esta atividade documenta graficamente o rationale do requisito e a visão do
stakeholder em relação ao assunto em análise, podendo ser este um cenário, um problema
dentro do cenário ou um problema específico. É basicamente a elicitação do conhecimento e
das necessidades dos stakeholders.
5.1.1 Estabelecer formatos para identificar visualmente os diferentes tipos de
informações que serão identificadas no mapa. Exemplo, necessidades, objetivos, restrições,
etc. É importante especificar a nomenclatura do mapa.
5.1.2 Identificar conceitos relevantes para a criação de requisitos de stakeholder e/ou
requisitos de sistemas. Levar em consideração os conceitos que já foram identificados como
relevantes na atividade 3.3 “Analisar e integrar os mapas”.
Os Conceitos podem ser: necessidades, expectativas, restrições, desejos, sentimentos,
vontades, objetivos, MoE’s, suposições e tudo o que o stakeholder desejar expressar em
relação a aquelas Trigger Questions e a necessidade inicial.
Atividade 5.2 Identificar o rationale das informações relevantes
O objetivo desta atividade é representar textual e graficamente o rationale. Essas
informações ajudaram na tomada de decisões dos desenvolvedores para entenderem porque
esse requisito foi documentado, porque o stakeholder pensou nessa necessidade, nessa
restrição, por exemplo. O rationale pode ser considerado como o nascimento e justificativa do
96
requisito, o requisito começa a ser concebido na elicitação da necessidade. Desta maneira o
desenvolvedor conhece o real desejo do stakeholder para melhor atendê-lo.
No mapa o rationale é representado pela sequência dos conceitos que antecedem e
sucedem o requisito. Esta sequência de conceitos representa a linha que o stakeholder seguiu
para chegar naquele conceito identificado como importante.
O rationale pode ser referenciado com os números dos conceitos que o conformam.
A Figura 30 representa o resultado final de um mapa analisado com a identificação das
informações relevantes e seu rationale.
Figura 30 Mapa Analisado e identificado necessidades raiz e seu rationale

97
Atividade 5.3 Descrever e documentar o problema e/ou missão do sistema
O objetivo desta atividade é concluir a análise, criar um relatório da situação detalhada
para que informe às próximas fases do projeto o problema que deve ser resolvido e seu
contexto.
Esta é uma das principais contribuições da ferramenta, o entendimento do problema o
mais detalhado possível e próximo da realidade. O documento deve delimitar o problema,
suas interações e restrições. Todo o trabalho realizado resulta na identificação e descrição
detalhada do problema. O problema pode estar inserido em diferentes níveis de abstração:
nível de missão, nível de sistema, nível de subsistema e assim por diante na estrutura
hierárquica de um sistema.
Existem documentos na Engenharia de Sistemas que têm, entre um de seus objetivos,
apresentar esta descrição; o mais comum é o ConOps: Conceito de Operações, o qual tem
foco no cenário de operação do sistema.
A descrição proposta nesta atividade pode ocorrer para qualquer cenário do sistema e
para qualquer nível hierárquico do sistema. É por isso que não se recomenda nenhum
documento específico. Cada organização decidirá a classificação da documentação.
Atividade 5.4 Documentar informações relevantes para a geração de requisitos e
seu rationale
O objetivo desta atividade é preparar as informações relevantes de maneira estruturada
para que sirvam de entrada para a criação de requisitos.
5.4.1 Analisar a estrutura do mapa resultante com os clusters definidos e avaliar se os
clusters resultantes são válidos para dar a estrutura ao documento de requisitos.

98
5.4.2 Documentar os conceitos relevantes.
5.4.3 Identificar que tipo de informação é o conceito. Exemplo: necessidade, restrição,
suposição, medida de efetividades, etc.
5.4.4 Documentar o rationale de cada conceito relevante. A documentação do
rationale pode ser feita textualmente, desde a trigger question até o conceito relevante,
incluindo as perguntas representadas nas setas. Também pode ser feita graficamente, criando
um relacionamento entre o conceito relevante e o mapa onde está inserido o conceito; isto
pode ser feito manualmente ou pela ajuda de um software de requisitos que permite o
relacionamento de informações com documentos externos.
7.9 Desenvolvimento do Processo
O Processo apresentado neste capítulo foi o resultado de quatro estudos que
contribuíram para a evolução da proposta de uma ferramenta de elicitação de requisitos para o
Processo de Análise de Stakeholders. Os quatro estudos se descrevem a seguir:
Engenharia de Requisitos e Análise de Stakeholders: Estudou-se a literatura relevante
na Engenharia de Requisitos e Análise de Stakeholders e seus processos e recomendações.
Este estudo contribuiu com atividades padrão na Análise de Stakeholders.
Mapas Cognitivos: Estudou-se a ferramenta de Mapas Cognitivos no contexto da
Pesquisa Operacional. A metodologia proposta por Ensslin, Montibeller & Noronha (2001) da
a principal contribuição ao processo, ela foi customizada para atender as necessidades da
Análise de Stakeholders.
Pesquisa de Campo no cluster aeroespacial de São José dos Campos (Dias, López e
Belderrain, 2012): Na pesquisa dos problemas da engenharia de requisitos também se
trabalhou com Mapas Cognitivos, mas com o objetivo de estruturar os problemas na área.
99
Esta pesquisa resultou numa adaptação à metodologia de Mapas Cognitivos proposta posta
por Ensslin, Montibeller & Noronha (2001), a qual também contribuiu para o processo
proposto.
Aplicação da ferramenta num exemplo prático: A aplicação aconteceu antes da versão
detalhada deste processo. A aplicação contribuiu com a identificação de subprocessos e
atividades que deveriam ter sido feitos ou que foi necessário realizar durante a aplicação de
maneira improvisada. Também contribuiu com o detalhamento das atividades e tarefas.
A Figura 31 mostra a sequência dos estudos tanto na revisão da literatura quanto na
pesquisa-ação, até a evolução do processo proposto, e mostra como a evolução para um
processo aconteceu após o exemplo de aplicação.
Figura 31 Desenvolvimento do Processo de Análise de Stakeholders Utilizando Mapas Cognitivos
7.10 Raízes e Contribuições do Processo Proposto
1.0 Analisar o Contexto
A Figura 32 diferencia com cores as raízes das atividades do subprocesso 1.0:

100
 Vermelho – Raiz: Exemplo de Aplicação: atividade 1.1
 Preto – Raiz: Engenharia de Requisitos e Análise de Stakeholders: atividades
1.2, 1.3 e 1.4
Figura 32 Raízes do subprocesso 1.0 Analisar o Contexto
O Quadro 5 descreve para cada atividade do subprocesso 1.0 sua raiz e como estas
atividades contribuem para a Engenharia de Requisitos e a Análise de Stakeholders.
Quadro 5 – Raízes e Contribuições das atividades do subprocesso 1.0 Analisar o Contexto (continuação)
Contribuições ao Processo de Engenharia de Requisitos e
Processo Proposto Raiz
de Análise de Stakeholders
O entendimento da necessidade inicial. É na fase preliminar
1.1 Analisar o
da aplicação da ferramenta que é necessário conhecer o
contexto da Exemplo de Aplicação
contexto para poder definir a abordagem mais apropriada ao
necessidade
estudo do problema.
101
Quadro 5 – Raízes e Contribuições das atividades do subprocesso 1.0 Analisar o Contexto (conclusão)
É indispensável para análise, a análise é feita a partir dos
1.2 Identificar Engenharia de
stakeholders, portanto, a qualidade é influência dos
stakeholders Requisitos
stakeholders fundamentarão o sucesso da análise.
É fundamental o entendimento pelo engenheiro de sistemas
1.3 Analisar referente à necessidade inicial e seu entorno para assim
informações Engenharia de poder abordar a problemática. Se ele tem o conhecimento,
existentes da Requisitos tem capacidade para conduzir o processo de elicitação de
necessidade inicial informações, o que levará a requisitos de qualidade no que
se refere a conteúdo.
1.4 Identificar Esta atividade é importante para a delimitação de pequenas
cenários relevantes Engenharia de análises e agrupamento de stakeholders e assuntos a serem
nas fases do ciclo de Requisitos abordados. São as partes do problema separadas para sua
vida do sistema análise.
2.0 Elaborar Estratégia de Intervenção
 Preto – Raiz: Engenharia de Requisitos e Análise de Stakeholders: atividade
2.1
 Vermelho – Raiz: Exemplo de Aplicação: atividades 2.2 e 2.3

102
Figura 33 Raízes do subprocesso 2.0 Elaborar Estratégia de Intervenção
Quadro 6 – Raízes e Contribuições das atividades do subprocesso 2.0 Elaborar Estratégia de Intervenção
2.1 Contatar
Engenharia de
stakeholders
Requisitos
identificados
A elaboração da estratégia ajuda a delimitar o escopo da
2.2 Estabelecer
análise e agrupar aos stakeholders por classe ou cenário para
estratégia de Exemplo de Aplicação
que as informações a serem elicitadas sejam dentro do
intervenção
mesmo escopo ou contexto.
Para que a elicitação de informações seja efetiva depende
2.3 Construir trigger diretamente da estruturação das trigger questions. São essas
Exemplo de Aplicação
questions perguntas que terão o poder de elicitar as informações
necessárias para a estruturação do problema do stakeholder.
103
3.0 Elicitar Informações dos Stakeholders com Mapas Cognitivos
 Azul – Raiz: Adaptação da Metodologia de Ensslin, Montibeller & Noronha
(2001): atividade 3.1
 Laranja – Raiz: Aplicação na Pesquisa de Campo (Dias, López e Belderrain,
2012): atividades 3.2 e 3.4
 Vermelho – Raiz: Exemplo de Aplicação: atividade 3.3
Figura 34 Raízes do subprocesso 3.0 Elicitar Informações dos Stakeholders com Mapas Cognitivos
104
Quadro 7 – Raízes e Contribuições das atividades do subprocesso 3.0 Elicitar Informações dos Stakeholders
com Mapas Cognitivos
Elicitar todo tipo de informações que possam vir do
3.1 Elicitar stakeholder como necessidaes, expectativas, MoE’s,
Adaptação da
informações dos restrições, sentimentos, valores, vontades, objetivos,
metodologia de
stakeholders suposições, entre outras. Ajudar o stakeholder a colocar em
Ensslin, Montibeller &
construindo mapas ordem sua visão do problema e ser mais analítico com a
Noronha (2001).
cognitivos situação. Ajuda na estruturação do problema. Este começa a
ser destrinchado para sua análise.
3.2 Solicitar texto aos Utilizando uma técnica comum para a elicitação de
Pesquisa de Campo
stakeholders requisitos mais incorporada e processada com a ferramenta
(Dias, López e
inacessíveis proposta. A contribuição são as informações elicitadas por
Belderrain, 2012)
pessoalmente do questionário.
3.3 Identificar
Pesquisa de informações relevantes para o estudo do
documentos existentes Exemplo de Aplicação
problema.
relacionados à análise
Documentos gerados pelos stakeholders: Elicitar
informações valiosas de um stakeholder que poderia não ser
entrevistado a raiz de sua disponibilidade. O mapa permitirá
analisar e compreender o ponto de vista do stakeholder e
assim dar mais fundamentos para questionar e encontrar
gaps nas informações fornecidas que para o stakeholder
3.4 Elicitar sejam óbvias, mas para a análise e entendimento do
informações dos Pesquisa de Campo problema não sejam tão óbvias.
documentos (Dias, López e Documentos existentes: Resgatar informações que possam
construindo mapas Belderrain, 2012) não ser aproveitadas, além de voltar a análise de documentos
cognitivos que foram geradas por outras pessoas que não estejam mais
em contato e que tenham deixado conhecimento valioso
nesses documentos. O mapa cognitivo ajudará na
organização daquelas informações e poderá ser ponto de
partida para novas considerações ou detalhamento de
informações. Será uma espécie de gestão e análise do
conhecimento.
105
 Azul – Raiz: Adaptação da Metodologia de Ensslin, Montibeller & Noronha
(2001): atividades 4.1 e 4.2
 Verde – Raiz: Metodologia de Ensslin, Montibeller & Nornonha (2001):
atividades 4.3, 4.5 e 4.6
 Laranja – Raiz: Aplicação na Pesquisa de Campo (Dias, López e Belderrain
(2012)): atividade 4.4
Figura 35 Raízes do subprocesso 4.0 Analisar Mapas Cognitivos

106
Quadro 8 – Raízes e Contribuições das atividades do subprocesso 4.0 Analisar Mapas Cognitivos
Adaptação da Analisar clusters de necessidades de maneira isolada ajuda
4.1 Analisar mapas metodologia de no entendimento e na identificação de tópicos importantes
cognitivos Ensslin, Montibeller & dentro do problema, ou seja, quebrar o problema em partes
Noronha (2001). para sua análise.
É aqui onde acontecem as propriedades emergentes da
ferramenta, quando o stakeholder vê graficamente seu
pensamento e raciocínio de um assunto em específico, se
depara com novas inferências referentes ao assunto, pode
Adaptação da
4.2 Validar mapas mudar de ideia e chegar à conclusão de que dois conceitos
metodologia de
cognitivos com os não tem mais relação ou ao contrario, dois conceitos que
stakeholders acreditava não tinham relação, agora o relacionamento entre
Noronha (2001).
eles é muito claro. Pode acontecer que, na realidade, não
exista problema ou se identifique uma solução tão simples
que não se requeira de um sistema para dar solução ao
problema identificado.
4.3 Reformular e
Metodologia de Permite que o stakeholder repense nos conceitos e reformule
analisar mapas
Ensslin, Montibeller & conclusões ou que crie conclusões que antes de gerar o mapa
cognitivos com os
Noronha (2001). não teria condições de visualizar.
stakeholders
Integrar os diferentes pontos de vista do problema dos
4.4 Integrar mapas Pesquisa de Campo diferentes stakeholders numa estrutura só. Isto
cognitivos (Dias, López e provavelmente levará a conceitos conflitantes, mas o
individuais Belderrain, 2012) objetivo é resolver estas contradições utilizando o mapa. O
resultado é a integração do problema.
Na validação do mapa integrado os stakeholders têm
4.5 Validar mapa Metodologia de oportunidade de conhecer os diferentes pontos de vista dos
cognitivo integrado Ensslin, Montibeller & outros stakeholders que participaram da elicitação, ver como
com os stakeholders Noronha (2001). os outros enxergam o problema e conhecer aspectos que não
tinham levado em consideração.
4.6 Reformular e Durante a reformulação se obtém o nivelamento do
Metodologia de
analisar mapa conhecimento entre os stakeholders alem de servir como
cognitivo integrado ferramenta para a resolução de conflitos entre conceitos e
Noronha (2001).
com os stakeholders visões dos stakeolders.
107
 Vermelho – Raiz: Exemplo de Aplicação: atividades 5.1, 5.2, 5.3 e 5.4
Figura 36 Raízes do subprocesso 5.0 Identificar Necessidades e Analisar o Problema

108
Quadro 9 – Raízes e Contribuições das atividades do subprocesso 5.0 Identificar Necessidades e Analisar o
Problema
Ajuda na identificação estruturada de informações relevantes
para a criação dos requisitos, estabelecimento de MoE’s dos
5.1 Identificar requisitos e restrições, entre outras. Mantem documentado
informações ou graficamente o rationale do requisito e a visão do
conceitos relevantes stakeholder em relação ao assunto em análise, podendo ser
para gerar requisitos este um cenário, um problema dentro do cenário ou um
problema específico. É basicamente a elicitação e/ou
elicitação do conhecimento e necessidades do stakeholder
A representação textual e gráfica do rationale. Estas
informações ajudaram na tomada de decisões dos
5.2 Identificar o desenvolvedores para entenderem porque esse requisito foi
rationale das documentado, porque o stakeholder pensou nessa
informações necessidade, nessa restrição, etc. É o nascimento e
relevantes justificativa do requisito. Dessa maneira o desenvolvedor
conhecerá o real desejo do stakeholder para melhor atendê-
lo
5.3 Descrever e Esta é uma das principais contribuições do processo. O
documentar o entendimento do problema o mais detalhado possível e
problema e/ou próximo da realidade. O documento deve delimitar o
missão do sistema problema, suas interações e restrições.
5.4 Documentar
informações Esta é um dos fins do processo proposto, as informações
relevantes para a Exemplo de Aplicação elicitadas e analisadas se resumem na lista de necessidades e
geração de requisitos seu rationale para serem convertidas em requisitos.
e seu rationale
109
8 Exemplo de Aplicação do Processo
8.1 Contexto
O exemplo de aplicação da tese acontece na implementação de um projeto piloto do
Laboratório de Engenharia Simultânea de Sistemas (LSIS) no Laboratório de Integração e
Testes (LIT) do Instituto Nacional de Pesquisas Espaciais (INPE) brasileiro localizado na
cidade de São José dos Campos, SP. O projeto piloto é descrito mais detalhadamente na seção
8.2.
O LIT foi projetado para atender as necessidades do Programa Espacial Brasileiro no
que se refere à integração e testes tanto de satélites quanto de suas partes, além de ser
considerado um dos instrumentos mais sofisticados na qualificação de produtos industriais
sejam estes da indústria aeroespacial, médica, automotiva ou qualquer que exija alto grau de
confiabilidade.
O LSIS visa prover suporte às atividades de desenvolvimento de Equipamentos de
Suporte em Solo, GSE’s (Ground Support Equipment) para Montagem, Integração e Testes
funcionais e ambientais de cargas úteis espaciais.
8.2 A Shunt Box
A Shunt Box é um Equipamento Eletrônico de Suporte em Solo, EGSE (Electronic
Ground Support Equipment). Foi desenvolvida para fazer interface entre as fontes de potência
e a Câmara de Termo Vácuo durante os Testes de Balanço Térmico (TBT) do Satélite Sino-
Brasileiro de Recursos Terrestres, CBERS (China-Brazil Earth Resources Satellite).
O processo de Análise de Stakeholder utilizando mapas cognitivos foi aplicado na
análise de uma melhoria incremental do equipamento previamente desenvolvido para os testes
do CBERS. O equipamento original está apresentado na Figura 37.

110
Figura 37 Versão orginal da Shunt Box

Fonte: Fornecida pelo Laboratório de Integração e Testes (LIT)
8.3 Aplicação do Processo de Análise de Stakeholders
SUBPROCESSO 1.0 ANALISAR O CONTEXTO
1.1 Analisar o contexto da necessidade
A necessidade inicial foi fornecida pelo stakeholder 2 quem é considerado como o
stakeholder inicial, já que foi delegado pelo stakeholder 1 para representá-lo durante o
desenvolvimento do projeto piloto do LSIS.
A análise do contexto foi por meio de reuniões com pessoas que não tinham
envolvimento direto com a Shunt Box nem com a área térmica, a principal cliente, mas que
entendiam o contexto da situação e a necessidade inicial.
A necessidade no início do projeto e que foi a entrada ao processo foi: multiplexar o
número de canais para a transmissão de potência para a realização do teste de balanço
térmico dos satélites 3&4.
Para o melhor entendimento do contexto, e devido ao fato de que o engenheiro de
sistemas não conhecia fisicamente a Shunt Box e seu contexto, iniciou-se com a elaboração de
um desenho para ajudar no entendimento da situação. A Figura 38 apresenta um dos desenhos
iniciais.
111
Figura 38 Contexto da Shunt Box Versão 0
1.2 Identificar os stakeholders
Apesar de ter uma primeira identificação de stakeholders, durante o processo todo de
aplicação identificaram-se novos stakeholders. O processo foi iterativo sempre avançando e
voltando aos passos iniciais.
Primeiramente, teve-se contato com o stakeholder inicial, o engenheiro de
desenvolvimento A, que indicou à técnica de desenvolvimento A para ser o ponto de contato
no desenvolvimento do projeto piloto. Desta maneira os primeiros stakeholders identificados
são apresentados no Quadro 10.
Quadro 10 - Lista de Stakeholders inicial

Id Stakeholder Tipo Área
Desenvolvedor Desenvolvimento de Hardware e Manutenção
1 Engenheiro A
de Sistemas
Técnica de Desenvolvimento de Hardware e Manutenção
2 Desenvolvedor
desenvolvimento A de Sistemas
Com a ajuda do stakeholder 2 e utilizando a ferramenta de mapas cognitivos, se
elicitaram novos e stakeholders como se mostra na Figura 39.

112
Figura 39 Mapa cognitivo para elicitar stakeholders

113
Desta maneira a lista de stakeholders aumentou como mostra o Quadro 11.
Numa terceira iteração, após o contato com o stakeholder 4 se extraíram dois
stakeholders adicionais (stakeholders 7 e 8), os quais participariam representando o
stakeholder 4.
Finalmente, durante a interação com o stakeholder 3, se identificou o stakeholder 9 e
nas fases finais da análise se identificou o stakeholder principal do contexto, o stakeholder
10. Desta maneira a lista final de stakeholders se mostra no Quadro 12 com a descrição do
perfil de cada stakeholder.
Quadro 11 - Lista de Stakeholders após eleicitação.

Desenvolvedor Desenvolvimento de Hardware e Manutenção de
1 Engenheiro A
Sistemas
Técnico de Desenvolvimento de Hardware e Manutenção de
2 Desenvolvedor
desenvolvimento A Sistemas
3 Engenheiro B Cliente interno Térmica
4 Engenheiro C Cliente interno Aquisição de dados
Usuário – Desenvolvimento de Hardware e Manutenção de

5 Técnico A
Configurador Sistemas
Desenvolvimento de Hardware e Manutenção de
6 Técnico B Suporte - manutenção
Sistemas
É importante ressaltar que a lista de stakeholders gerada foi com foco na necessidade
inicial. Ao final da análise, se identificou um sistema maior, para o qual a análise não foi
concluída, por tanto a lista de stakeholders elicitada inicialmente como mostra a Quadro 12, é
incompleta para a definição final do problema.

114
Quadro 12 - Lista final de stakeholders identificados

Id Stakeholder Tipo Perfil
Engenheiro Sênior de desenvolvimento de hardware e
1 Engenheiro A Desenvolvedor
desenvolvedor principal da Shunt Box.
Técnica de Engenheira Junior de desenvolvimento de hardware, que
2* Desenvolvedor
desenvolvimento A teve participação no desenvolvimento da Shunt Box.
Engenheiro Sênior da área térmica quem participou na
3 Engenheiro B Cliente interno
concepção da Shunt Box.
Engenheiro Sênior da área de aquisição de dados. Seus
4 Engenheiro C Cliente interno
equipamentos têm interface direta com a Shunt Box.
Usuário – Engenheira Junior de desenvolvimento de hardware, que
5* Técnica A
Configurador configura a Shunt Box para seu uso.
Engenheira Junior de desenvolvimento de hardware, que
6* Técnica B Suporte - manutenção
dá manutenção à Shunt Box.
Técnico da Aquisição de Dados que recebe e manipula
7 Técnico C Cliente interno
dados adquiridos.
Técnico da Aquisição de Dados que recebe e manipula
8 Técnico D Cliente interno
dados adquiridos.
Engenheiro Sênior que participa da definição do perfil
9 Engenheiro D Cliente interno
dos testes de balanço térmico.
Engenheira Sênior que especifica o perfil de testes do
10 Engenheiro E Cliente externo
satélite.
* Os stakeholders 2, 5 e 6 são a mesma pessoa, quem desempenha funções diferentes dentro da organização.
1.3 Analisar informações existentes da necessidade inicial
Esta atividade não foi aplicada. Solicitou-se material, mas no momento não se
identificou algum material descritivo que pudesse ser disponibilizado para análise. Toda
informação elicitada nessa fase foi por meio de conversas informais.
1.4 Identificar os cenários relevantes nas fases do Ciclo de Vida do Sistema
Para o propósito da pesquisa se utilizou somente o cenário de operação. Para ajudar na
contextualização da necessidade neste cenário se desenvolveu um apoio visual, como se
mostra na Figura 40, que representa o contexto e pode ser usado como material de apoio na
115
abordagem com os stakeholders para a elicitação de informações. A Figura 40 sofreu diversas
transformações durante o contato com os stakeholders até chegar à sua versão 4. A evolução
destas transformações se apresentam no Apêndice D.
Figura 40 Contexto operacional da Shunt Box Versão 4
SUBPROCESSO 2.0 ELABORAR ESTRATÉGIA DE INTERVENÇÃO
2.1 Contatar os Stakeholders identificados
Os stakeholders foram contatados durante todo o processo já que foram sendo
identificados em diferentes iterações. Todos os stakeholders foram contatados, à exceção do
stakeholder 10, o responsável pelo planejamento dos testes do satélite, já que sua
identificação aconteceu no final desta análise e por questões de tempo, não foi abordado. Nem
todos os stakeholders tiveram a disponibilidade para participar.
2.2 Estabelecer a Estratégia de Intervenção
A estratégia de intervenção, por ser um projeto pequeno foi a de abordar todos aqueles
stakeholders que tiveram a disponibilidade para realizá-lo e foi na ordem em que surgiam,
pois a identificação, como descrito na atividade 1.2, foi por etapas. O Quadro 13 apresenta os
stakeholders que foram abordados.

116
Quadro 13 - Lista de stakeholders abordados

Desenvolvedor
1 Engenheiro A Desenvolvimento de Hardware e Manutenção de Sistemas
Técnico de
2 Desenvolvedor Desenvolvimento de Hardware e Manutenção de Sistemas
desenvolvimento A
Usuário –
5 Técnico A Desenvolvimento de Hardware e Manutenção de Sistemas
Configurador
6 Técnico B Suporte - manutenção Desenvolvimento de Hardware e Manutenção de Sistemas
7 Técnico C Cliente interno Aquisição de Dados
8 Técnico D Cliente interno Aquisição de Dados
9 Engenheiro D Cliente interno Térmica
A estratégia de intervenção foi a de realizar entrevistas individuais realizando as
mesmas trigger questions e com o apoio de desenhos do contexto.
A estratégia foi selecionada dessa maneira e de maneira arbitrária pelas seguintes
razões:
a. Desconhecimento do engenheiro de sistemas do tipo de informações que cada
stakeholder forneceria.
b. Desconhecimento do engenheiro de sistemas do contexto da situação num
nível desejável para elaborar uma estratégia adequada ao contexto.
c. Cultura organizacional do trabalho individual, desta maneira, as abordagens
foram individuais para não gerar qualquer tipo constrangimento entre os
stakeholders que pudesse prejudicar os resultados do estudo.
d. Stakeholders de áreas de trabalho diferentes.

117
e. Esta atividade ainda não estava definida no processo até depois da aplicação.
Esta atividade é uma lição aprendida da aplicação.
2.3 Construir as Trigger Questions
Construíram-se três blocos de questionamentos. O primeiro era com o objetivo de
entender as necessidades iniciais e as perguntas foram as seguintes:
1. Qual é a missão da Shunt Box?
2. Por que é necessária a Shunt Box?
3. Qual é a função principal da Shunt Box?
O segundo bloco foi para identificar novos stakeholders
1. Quem tem interesse na Shunt Box?
O terceiro bloco de questionamentos foi baseado na norma IEEE 1362 TM ConOps
(Conceito de Operações), e propõe na sua seção 4.4.2 a “Descrição das Mudanças Desejadas”.
Nesta seção da norma se apresentam oito tipos de mudanças que poderiam ser consideradas
para uma mudança incremental do sistema: capacidade, processamento do sistema, interface,
recursos humanos, ambiente, operacional, suporte e outras. As perguntas foram construídas da
seguinte maneira:
1. Que mudança é necessária referente à capacidade do Shunt Box?
2. Que mudança é necessária referente a interfaces da Shunt Box?
3. Que mudança é necessária referente a processamento da Shunt Box?
4. Que mudança é necessária referente ao ambiente da Shunt Box?

118
5. Que mudança é necessária referente a recursos humanos da Shunt Box?
6. Que mudança é necessária referente a suporte para o uso da Shunt Box?
7. Que mudança é necessária referente à operação da Shunt Box?
8. Que outro tipo de mudança é necessária?
Inicialmente, a estratégia de intervenção era a de realizar as mesmas trigger questions
para todos os stakeholders. No entanto, quando surgiu o stakeholder 9, a necessidade passou a
ser o entendimento do contexto dos testes de balanço térmico que a Shunt Box devia atender.
Por tal motivo as trigger questions foram focadas para este entendimento. Desta maneira as
trigger questions para o stakeholder 9 resultaram assim:
1. Quando utilizam o perfil de testes IRA (Infra Red Array)?
2. Por que utilizam o perfil de testes IRA?
3. Quando utilizam o perfil de testes de lâmpadas infravermelhas?
4. Por que utilizam o perfil de testes de lâmpadas infravermelhas?
5. Quando utilizam o perfil de testes com placas aquecedoras com skin heaters?
6. Por que utilizam o perfil de testes com placas aquecedoras com skin heaters?
7. Quando utilizam o perfil de testes com skin heaters?
8. Por que utilizam o perfil de testes com skin heaters?
9. Por que utilizam o simulador solar?
SUBPROCESSO 3.0 ELICITAR INFORMAÇÕES DOS STAKEHOLDERS
COM MAPAS COGNITIVOS
3.1 Elicitar informações dos stakeholders construindo mapas cognitivos

119
Durante a intervenção com os stakeholders se obtiveram resultados completamente
diferentes.
É importante relembrar que a stakeholdesrs 2, 5 e 6 estão representados pela mesma
pessoa que desenvolve funções diferentes dentro da organização, mas no momento da
abordagem não se fez distinção de papéis. Para fins práticos, sempre é chamada de
stakeholder 2.
As intervenções iniciaram com uma explicação do projeto piloto e a finalidade de
conceber uma nova Shunt Box após a análise. Também foi detalhado o processo de
elaboração dos mapas cognitivos com contínuos questionamentos, para que eles não se
sentirem desconfortáveis com a situação.
Utilizou-se como apoio a Figura 40 para auxiliar na elicitação e entendimento do
contexto.
De esta forma as intervenções não foram somente elaboração de mapas cognitivos,
também teve explicações verbais fora dos questionamentos e adaptações na Figura 40.
As intervenções duraram em media 90 minutos.
Stakeholder 2
Com a stakeholder 2 obtiveram-se os melhores resultados, o processo aconteceu de
forma natural e como esperado. A participação dela sempre foi aberta e cooperativa.
Tiveram-se duas intervenções de 90 minutos cada uma para a realização dos mapas.
Os mapas elicitados do stakeholder 2 se mostram nas Figuras 41, 42 e 43.

120
Figura 41 Mapa das necessidades essenciais – Stakeholder 2

121
Figura 42 Mapa das necessidades por tipo de mudança 1 de 2 – Stakeholder 2

122
Figura 43 Mapa das necessidades por tipo de mudança 2 de 2 - Stakeholder 2

123
Stakeholder 3
Apesar da disposição em participar do stakeholder e sua abertura para resolver dúvidas
e dedicar tempo na intervenção, não foi possível a criação dos mapas. O perfil do stakeholder
era de explicar com detalhes técnicos, sem pausas que facilitassem a captura do que estava
sendo elicitado. De uma trigger question resultavam relatos longos e não respostas curtas, o
que dificultava a criação de conceitos e seus relacionamentos. Por ser uma linguagem muito
técnica não foi possível acompanhar as explicações do stakeholder. Neste caso não foram
desenvolvidos os mapas cognitivos.
Stakeholder 9
O objetivo desta intervenção foi diferente, em vez de abordar as mudanças possíveis, o
foco foi em entender o contexto no qual a Shunt Box estava inserida. O propósito foi entender
os diferentes perfis de testes que podem ser adotados um Teste de Balanço Térmico e em
quais destes a Shunt Box representaria um benefício.
Os mapas elicitados do stakeholder 9 são apresentados nas Figuras 44, 45, 46, 47, 48 e
49.
124
Figura 44 Mapa Perfil Testes – IRA 1/2 – Stakeholder 9

125
Figura 45 Mapa Perfil Testes – IRA 2/2 – Stakeholder 9

126
Figura 46 Mapa Perfil Testes Skin Heater – Stakeholder 9

127
Figura 47 Mapa Perfil Testes Lâmpadas Infravermelhas – Stakeholder 9

128
Figura 48 Mapa Perfil Testes Placas Aquecedoras com Skin heaters – Stakeholder 9
129
Figura 49 Mapa Perfil Testes Simulador Solar – Stakeholder 9
Stakeholders 7 e 8
Os stakeholders 7 e 8 foram abordados em grupo, apesar de não estar contemplado na
estratégia inicial.
Não se obtiveram resultados com a elicitação dos stakeholders a partir das trigger
questions para a criação do mapa. Não foi possível elicitar nenhum só conceito, apesar de ter
explicado a técnica dos mapas cognitivos e explicar os objetivos da análise. A representação
gráfica do cenário de operação mostrado na Figura 40 teve mais sucesso na elicitação de
informações.
O resultado da utilização dos mapas pode ter diferentes motivos, desde o desinteresse
em participar, a falta de conhecimento do stakeholder no assunto ou a má formulação das
trigger questions nesse contexto, ou bem o conjunto de todas elas.

130
3.2 Solicitar texto aos stakeholders inacessíveis pessoalmente
Esta atividade não foi aplicada, pois todos os stakeholders identificados estavam
acessíveis pessoalmente.
3.3 Identificar documentos existentes relacionados à necessidade, cenário ou
problema em análise.
No momento do estudo do caso, não existiam documentos relacionados à necessidade.
3.4 Elicitar documentos construindo mapas cognitivos.
Esta atividade não foi aplicada, em função da inexistência de documentos para elicitar.
SUBPROCESSO 4.0 ANALISAR MAPAS COGNITIVOS
4.1 Analisar os Mapas
Stakeholder 2
Durante a análise, surgiram dúvidas no momento de passar os mapas ao software
Cmap Tools, devido à construção dos mapas ter sido feita em papel. Essas dúvidas se
identificavam no mapa para serem esclarecidas durante a validação.
A identificação de clusters foi feita identificando os diferentes assuntos abordados no
mapa e os conceitos referentes a esse assunto. Realizou-se a delimitação dos conceitos dentro
desses assuntos para assim formar os clusters como se mostra nas Figuras 50, 51 e 52.
Identificaram-se sete clusters:
1. Endereçamento de tensão e corrente
2. Monitoramento
3. Capacidade de transmissão de corrente

131
4. Programação
5. Interface Elétrica
6. Desarme de disjuntor
7. Sobrecarga no circuito
Stakeholder 9
Nos mapas do stakeholder 9 não foram identificados clusters. Devido à criação dos 5
mapas, cada um se referia a um tópico em específico. Cada mapa representa um cluster, um
cluster para cada tipo de perfil de teste. Os cinco clusters resultantes foram:
1. Perfil de testes com IRA (Infra-Red Array)
2. Perfil de testes com lâmpadas infravermelhas
3. Perfil de testes com skin heatesrs em placas aquecedoras
4. Perfil de testes com skin heaters
5. Perfil de testes com simulador solar

132
Figura 50 Análise do Mapa Necessidades Essenciais – Stakeholder 2

133
Figura 51 Análise do Mapa Necessidades por tipo de Mudança 1 de 2 – Stakeholder 2

134
Figura 52 Análise do Mapa Necessidades por tipo de Mudança 2 de 2 – Stakeholder 2

135
4.2 Validar os mapas cognitivos com os stakeholders
Stakeholder 2
Os mapas foram validados e não se detectaram maiores mudanças. Durante a
validação, o stakeholder gostou de continuar o mapa, mas por questões de prazo, no projeto
piloto do LSIS, não foi possível dar continuidade. A stakeholder expressou que o mapa a fez
refletir com relação aos assuntos analisados e teria gerado novas ideias sobre o assunto.
Stakeholder 9
Os mapas foram validados informalmente após a realização dos mapas, confirmando
as informações elicitadas. Não se teve um segundo contato.
4.2 Reformular e analisar mapas cognitivos
Stakeholder 2
Os mapas foram validados somente pelo stakeholder 2. Foram feitas menores
correções no texto.
Stakeholder 9
Não houve reformulação
4.4 Integrar os mapas cognitivos individuais
Esta atividade não foi aplicada porque se abordaram dois assuntos diferentes com cada
stakeholder. Com o stakeholder 2 se focaram nas necessidades e nas possíveis mudanças para
uma melhoria incremental à Shunt Box, enquanto com o stakeholder 9 foram questões
referentes aos cenários que existiam no sistema de alto nível (Teste de Balanço Térmico) para
entender o contexto e os cenários nos quais a Shunt Box poderia ter uma função. A partir da
136
estratégia de intervenção se esperava que esta atividade fosse desenvolvida, pois o objetivo
era realizar as mesmas perguntas aos diferentes stakeholders, mas o estudo da necessidade
levou a ter questionamentos diferentes aos stakeholders para o melhor entendimento do
problema.
De esta maneira, se obtiveram mapas que tratavam assuntos diferentes, portanto, não
foi possível integrá-los.
4.5 Validar mapa integrado com os stakeholders
Esta atividade não foi aplicada, pois não teve mapa integrado.
4.6 Reformular e analisar mapa integrado com os stakeholders
Esta atividade não foi aplicada, pois não teve mapa integrado.
SUBPROCESSO 5.0 IDENTIFICAR NECESSIDADES E ANALISAR O
PROBLEMA
5.1 Identificar as informações ou conceitos relevantes para gerar requisitos
Os conceitos considerados mais relevantes e possíveis candidatos para a geração de
requisitos foram identificados graficamente no mapa com uma linha mais grossa para
diferenciá-los dos demais conceitos e facilitar sua identificação, à primeira vista, no mapa.
Também se identificaram pontos no mapa onde a elicitação pode ser continuada, às
vezes, durante a construção do mapa não é possível perceber, mas depois da análise isto fica
muito claro. Estes pontos se representam com setas com destino a um signo de interrogação
(?).
Stakeholder 2
137
Um exemplo claro da identificação de um conceito relevante é na linha do conceito
M1 ao conceito M5, como mostra a Figura 53. O stakeholder iniciou com a necessidade de
reduzir o número de canais e, através dos questionamentos, conseguiu-se chegar à
necessidade raiz que é a de “Suportar maiores cargas de corrente nas trilhas” (M5).
Figura 53 Exemplo de identificação de conceitos relevantes
As Figuras 54, 55 e 56 apresentam os mapas cognitivos com os conceitos relevantes
identificados com linhas mais grosas dentro dos clusters do stakeholder 2.
Stakeholder 9
Os mapas do stakeholder 9 auxiliaram na contextualização do sistema e não na
elicitação de requisitos. As informações elicitadas foram cenários dentro do sistema completo,
e no qual a Shunt Box participaria somente em dois cenários: no perfil de testes com skin
heaters e no perfil de testes com placas aquecedoras com skin heaters.

138
Figura 54 Mapa com Conceitos Relevantes das Necessidades Essenciais – Stakeholder 2

139
Figura 55 Mapa com Conceitos Relevantes das Necessidades por Tipo de Mudança 1/2 – Stakeholder 2
140
Figura 56 Mapa com Conceitos Relevantes das Necessidades por Tipo de Mudança 2/2 – Stakeholder 2
141
5.2 Identificar o Rationale das informações relevantes
Na Figura 57, o rationale da necessidade raiz N13 se representa pela linha desde a
trigger question até o conceito N13, desta maneira pode-se concluir que o rationale pode ser
textualmente representado pela sequência de conceitos N11-N12-N13. O rationale textual fica
da seguinte maneira: “Prover sinais de dados, para poder monitorar a tensão e corrente
transferidas para poder manter as tolerâncias”. Isso quer dizer que a necessidade raiz é a de
“Manter as tolerâncias”.
Figura 57 Captura do rationale
A identificação do rationale se representa graficamente com uma seta percorrendo o
caminho da pergunta inicial até o conceito relevante, como mostram as Figuras 58, 59 e 60.
O rationale nem sempre é representado de baixo para cima, este pode emergir após ou
antes da necessidade ter sido elicitada.
Stakeholder 9
Esta atividade não se aplica, já que os mapas tiveram a função de contextualização e
entendimento do sistema de alto nível mais do que para elicitação de necessidades.

142
Figura 58 Mapa A: Mapa das Necessidades Essenciais com seu Rationale – Stakeholder 2
143
Figura 59 Mapa B: Mapa das Necessidades por tipo de Mudança com seu Rationale – Stakeholder 2
144
Figura 60 Mapa C: Mapa das Necessidades por tipo de Mudança com seu Rationale – Stakeholder 2
145
5.3 Descrever e documentar o problema e/ou a missão do sistema
A necessidade inicial foi definida como: “Possibilitar o teste do modelo térmico dos
satélites CBERS 3&4 com filosofia ou perfil de teste de skin heaters e resistências tubulares
com um número de até 300 cargas.”
A filosofia ou perfil de teste se refere à estratégia para o teste, que tipo de aquecedores
são utilizados e em quais seções do satélite. No caso do satélite CBERS 3&4 foram películas
aquecedoras e resistências tubulares, mas para cada satélite ou algum outro sistema são
situações diferentes.
A Shunt Box tinha seu papel na parte de teste com as películas aquecedoras devido à
alta demanda de canais fornecedores de potência.
A Shunt Box dá suporte ao Teste de Modelo Térmico. Inicialmente, esta foi
desenvolvida porque era necessário um número elevado de ramos de alimentação para testes
na câmara de termo – vácuo, o número de ramos das fontes era insuficiente e se viu a
necessidade de criar um EGSE que pudesse distribuir o número de ramos a partir das fontes
disponíveis.
Analisando o problema que a Shunt Box visa resolver, deparou-se com o fato do
contexto do problema ser maior e a Shunt Box ser somente uma parte da solução.
A Shunt Box é um meio para o Teste de Modelo Térmico na Câmara Vácuo –
Térmica. O perfil ou filosofia do teste é definido levando em consideração múltiplos critérios
e diferentes combinações destes mesmos critérios.
É importante entender como a filosofia do teste é definida e se existe alguma outra
limitação dentro deste modelo para ser levada em consideração na análise e estudo do
problema.
146
O problema inicialmente identificado tinha um escopo reduzido: somente os testes
onde a Shunt Box é necessária. A análise evoluiu durante o estudo do contexto da Shunt Box
para o melhor entendimento do Teste de Balanço Térmico, que representava o sistema maior
em que a Shunt Box estava inserida.
A análise do problema foi documentada no Apêndice E. A descrição do problema não
somente foi com base nos mapas cognitivos, já que com outros stakeholders com os quais não
se teve a oportunidade de realizar mapas, e até com os próprios stakeholders que participaram
dos mapas, também forneceram informações relevantes nas conversas e apoios visuais para o
entendimento do problema.
É importante ressaltar que a análise do problema inicial não foi concluída. O objetivo
inicial que era analisar a Shunt Box existente para uma melhoria incremental, mudou após a
Análise de Stakeholders. O problema inicial mudou de escopo para o sistema de alto nível,
Sistema Teste de Balanço Térmico, que precisa ser entendido, pois é ele quem imporá as
necessidades para a Shunt Box ou para um novo produto diferente da Shunt Box que satisfaça
as necessidades para o mesmo. Desta maneira, é necessário realizar uma nova Análise de
Stakeholders, olhando o sistema maior.
5.4 Documentar informações relevantes para a geração de requisitos e seu
rationale
As informações relevantes identificadas foram documentadas numa tabela com outros
atributos dessa necessidade, como se mostra no Quadro 14.

147
Quadro 14 - Necessidades raiz identificadas nos mapas cognitivos elicitados. (continuação)

Requisito (exemplo ilustrativo de
Id Necessidade Cluster/mapa Rationale Stakeholder transformação)
1 Otimizar potência das fontes (N1) Mapa A NA Stakeholder 2
A shunt box é necessária – pelas saídas de
tensão e corrente – porque facilita o fato do
Endereçar tensão e corrente para Endereçamento de
cabo sair direto ao scanner com tensão e
2 os scanners de aquisição de dados tensão e corrente / Stakeholder 2
corrente – porque os cabos da shunt box já
(N3) Mapa A
estão mapeados para endereçar tensão e
corrente para os scanners.
Prover sinais de dados – para monitorar a O sistema deve fornecer sinais para
Manter as tolerâncias Monitoramento /
3 tensão e corrente transferidas – para manter Stakeholder 2 manter as tolerâncias estabelecidas
estabelecidas para o teste (N13) Mapa A
as tolerâncias pelo perfil de testes do satélite
Diminuir o número de canais – porque com
Capacidade de menor número de canais aumenta a distância
Aumentar o fluxo de corrente por
4 transmissão de entre trilhas – assim pode aumentar a largura Stakeholder 2
trilha (M5)
corrente / Mapa B das trilhas – para poder passar maior
corrente em cada trilha
Trocar a interface do conector DB50 –
porque o conector é um gargalo de corrente -
porque o acesso das trilhas para a carreira
Capacidade de
Aumentar o fluxo de corrente por central do conector é gargalo. São 3
5 transmissão de Stakeholder 2
trilha (M9) carreiras, se fossem 2 ajudaria - para
corrente / Mapa B
aumentar o valor da corrente que passa pela
trilha – quanto maior a trilha, maior é a
corrente que passa pela trilha
148
Quadro 14 - Necessidades raiz identificadas nos mapas cognitivos elicitados. (conclusão)

Requisito (exemplo ilustrativo de
Id Necessidade Cluster/mapa Rationale Stakeholder
transformação)
Mudar a interface para configuração e
Facilitar a programação e Programação/ Mapa programação – porque o risco de erro é
6
configuração (M10/M11) B grande – porque se programam 100 jumpers Stakeholder 2
manualmente – poderia ser via software
Não sobrecarregar os circuitos Sobrecarga no Requer-se uma mudança para melhorar o
7 Stakeholder 2
(M32) circuito / Mapa C suporte – porque pode ter sobrecarga no
circuito e abrir um ramo ou canal – pode ser
evitado passando a corrente máxima correta
– se um heater falha, muda a quantidade de
corrente nos outros heaters – A Shunt Box
tem um circuito de proteção – o circuito abre
a fonte e deixa de alimentar os heaters de
esse ramo ou canal – tem que parar todo o
Aumentar a confiabilidade da Sobrecarga no
8 teste desse Shunt Box e das 10 fontes Stakeholder 2
programação (M40) circuito / Mapa C
conectadas ao Shunt Box (10 fontes são
distribuídas em até 50 ramos) –
Desconectando a Shunt Box, as 9 fontes
restantes deixam de alimentar os circuitos
que em ela estão ligados – Diminuir o erro
na programação ajuda a não dar falha
durante o teste.
149
8.4 Lições Aprendidas Durante a Aplicação
1. O detalhamento do processo aconteceu somente após a aplicação no projeto
piloto. Durante o projeto piloto, tinha-se uma noção do que devia ser feito, mas
o processo foi se criando durante a execução. Ainda assim, com a aplicação,
identificou-se que houve etapas que deveriam acontecer antes de outras. A
última versão do processo espelha a prática com as melhorias identificadas
após a análise da aplicação.
2. Nem todos os stakeholders estão prontos para participar do processo por
diferentes motivos que se identificaram a seguir:
a. Falta de interesse no assunto.
b. Falta de interesse em resolver o problema.
c. Não enxergarem problema a ser resolvido.
d. Não reconhecerem seu papel como stakeholder.
e. Falta de conhecimento da situação, sistema ou produto.
f. Falta de interesse em participar com o uso de mapas cognitivos e seus
constantes questionamentos.
3. Na maioria dos casos, o stakeholder quer ir para a implementação da solução, é
preciso continuar lembrando que deve ter foco no problema e não em como
pode ser resolvido. Observou-se que, às vezes é difícil para o stakeholder parar
de pensar na solução. Ele não consegue se abstrair para focar o problema,
simplesmente não enxerga.
4. No caso da Shunt Box, teve-se acesso a pessoal muito técnico. E era muito
comum que eles tivessem sempre uma tendência para o detalhamento técnico
150
da solução. Eles não enxergavam o sistema maior no qual o problema estava
inserido que era o Teste de Balanço Térmico do satélite.
5. O processo é iterativo, é comum voltar ao ponto inicial, ao perceber novas
necessidades ou ainda que o problema analisado é muito maior, como no
exemplo de aplicação.
6. É fundamental a contextualização do engenheiro de sistemas na situação ou
problema que está sendo analisado. É importante, para poder questionar o
stakeholder, não se deixar levar pelos detalhamentos nem as soluções do
stakeholder, ao contrário, conseguir trazer o stakeholder ao nível do sistema
para ele compreender o problema como um todo e não somente o que a ele
concerne.
7. O engenheiro de sistemas deve ter conhecimentos básicos da área do
conhecimento que está sendo analisada, para entender o jargão do cliente.
Durante o estudo de caso, teve-se muita dificuldade para acompanhar as
explicações dos stakeholders, que era muito voltada para duas áreas em
específico, a área térmica que era o sistema de alto nível e a área de eletrônica,
à qual pertencia o sistema de interesse.
8. O exemplo de aplicação confirmou que, o que se acreditava que era a
necessidade principal do cliente, acabou sendo somente uma parte de um
problema maior, o que demanda uma nova Análise de Stakeholders para esse
novo problema descoberto. Cada stakeholder enxerga somente sua parte da
necessidade e não a necessidade maior.

151
9 Discussão
O trabalho realizado nesta tese contribui para a área da Engenharia de Sistemas e em
especial para a Engenharia de Requisitos, pois oferece uma nova alternativa para o esforço de
elicitação de stakeholders. Ainda que sendo uma alternativa diferente, existem outras
pesquisas e aplicações que fazem parte de uma abordagem maior que é o estudo da cognição
para a elicitação de stakeholders. Esta linha de pesquisa se deve ao fato de que os
stakeholders são humanos que estruturam problemas utilizando processos cognitivos.
Para entender o problema do stakeholder, é importante entender a maneira como eles o
percebem; como o entendem e estruturam. Isto não significa que é a melhor maneira de
representar o problema, ou ainda, se é o problema real que deve ser analisado. O que dará a
objetividade necessária para saber se é o problema real para ser estudado e resolvido, é o
constante aparecimento de informações relevantes entre os diferentes stakeholders;
considerando sempre o mesmo contexto, no mesmo cenário ou o mesmo tipo de stakeholder
dentro da análise.
Uma expressão comumente utilizada na área de Pesquisa e Desenvolvimento é que os
stakeholders raramente sabem o que querem. Por isso, é essencial que o engenheiro de
sistemas ajude o stakeholder no entendimento e estruturação de suas reais necessidades sob o
ponto de vista do stakeholder, de seu contexto e suas experiências. Após esta análise do
problema de maneira individualista, se parte para analisar o problema em um nível de
abstração maior, no contexto do todo. O stakeholder somente enxerga uma parte do problema.
É necessário juntar as diferentes partes do problema para entender o problema como um todo
e poder dar uma solução integrada a essas partes.

152
É desta maneira como “os requisitos dos stakeholders governam o desenvolvimento
do sistema e são um fator essencial para futuramente definir ou esclarecer o escopo do projeto
de desenvolvimento.” INCOSE (2011, p. 55).
9.1 Cumprimento dos Objetivos do Processo Desenvolvido
9.1.1 Objetivo 1: Auxiliar na elicitação de informações de stakeholders.
Auxiliar na elicitação de informações de stakeholders de maneira exaustiva: O
objetivo se cumpriu, o processo viabiliza a elicitação exaustiva devido ao constante
questionamento ao stakeholder, até ele não ter mais resposta para os questionamentos. Mas é
necessário levar em consideração a disposição e o conhecimento do stakeholder. Para que a
elicitação seja exaustiva não somente depende do processo e sim de uma série de fatores que
viabilizem o processo. Alguns desses fatores identificados durante a pesquisa foram: a
formulação das trigger questions; o prévio conhecimento do contexto por parte do engenheiro
de sistemas; a disposição em participar do stakeholder e dos conhecimentos do stakeholder.
9.1.2 Objetivo 2: Auxiliar na estruturação das informações extraídas
Auxiliar na estruturação das informações extraídas para consequentemente estruturar o
problema: O objetivo se cumpriu, os mapas cognitivos ajudam na estruturação das
informações por meio do processo da criação dos clusters e a visualização gráfica dos
assuntos e do relacionamento dos conceitos.
Com a pesquisa-ação pode se estruturar partes do problema, mas não se teve uma
estruturação total do mesmo, pois se requeria uma maior participação dos stakeholders para
poder ter resultados conclusivos da análise, além da mudança de escopo do problema em
análise. Foram enfrentados problemas reais de falta de interesse de alguns stakeholders e falta
de conhecimento ao respeito do problema de outros, e sem dúvida, pelo fato se trabalhar com
153
a abordagem pela primeira vez tanto dos stakeholders quanto do facilitador do processo, neste
caso, a autora.
9.1.3 Objetivo 3: Capturar o rationale
Capturar o rationale ou justificativa das informações relevantes, para assim manter a
rastreabilidade do requisito, o que auxilia no momento dos trade-offs que levam à solução a
ser implementada: O objetivo se cumpriu, durante a pesquisa ação foi interessante observar
como este rationale ficava claro e como podia acompanhar a transição de uma necessidade
fortemente orientada à solução para uma real necessidade, a evolução do stakeholder em
entender esta necessidade.
Porém, nem todas as informações resultaram na mesma evolução. Além do que, não
foi possível saber se as informações realmente ajudarão nas decisões dos trade-offs já que o
processo não segue até este ponto.
9.1.4 Objetivo 4: Auxiliar no nivelamento de entendimento
Auxiliar no nivelamento de entendimento entre stakeholder e engenheiro de
desenvolvimento e o engenheiro de sistemas: O objetivo foi atingido parcialmente. O
processo gerou conhecimento para o engenheiro de sistemas, apesar deste não ter
conhecimento técnico sobre o problema em análise. O entendimento do nível macro pode-se
concluir que foi satisfatório, mas não o suficiente para afirmar que o nivelamento do
conhecimento foi total.
9.2 A Utilização dos Mapas Cognitivos para a Análise de Stakeholders
A Análise de Stakeholders lida com a mente humana, como esta enxerga e estrutura
uma situação ou um problema. A mente humana é um sistema complexo de relacionamentos e
muitas vezes de difícil expressão, para uns mais que para outros. É aqui que nascem os
154
problemas de comunicação, o que um quis dizer, ou que um disse, o que o outro escutou ou
viu e o que entendeu.
De esta maneira a cognição humana e sua rede de relacionamentos devem ser levadas
em consideração para a análise do problema do stakeholder. É nesta complexidade que os
mapas cognitivos têm um papel importante na elicitação das informações, auxiliando na
visualização desses relacionamentos.
Ensslin & Montibeller (2001) descrevem como este processo acontece como foi
mostrado na Figura 9.
O processo é iterativo por natureza, uma vez que os mapas cognitivos guiam o
pensamento e convidam à reflexão, mudando inúmeras vezes o modelo mental do stakeholder
a respeito do problema até o entendimento deste amadurecimento durante o processo como
representado na Figura 61.
Tempo 1: O stakeholder escuta a pergunta realizada pelo engenheiro de sistemas para
entender o problema sob o ponto de vista do stakeholder e entender suas necessidades.
Tempo 2: O stakeholder reflete a pergunta e traz um modelo mental do problema;
Tempo 3: O stakeholder expressa verbalmente seu modelo mental para o engenheiro
de sistemas. Assim que a descrição verbal é feita, o mesmo stakeholder reflete o que está
falando e alimenta o modelo mental original, criando um melhor entendimento próprio da
situação;
Tempo 4: O engenheiro de sistemas cria um modelo mental e uma percepção do
problema que esta sendo descrito pelo stakeholder;

155
Tempo 5: O engenheiro de sistemas representa as informações que estão sendo
verbalizadas num mapa cognitivo;
Tempo 6: O stakeholder visualiza a representação gráfica de seu ponto de vista do
problema, o que o leva a uma nova reflexão para criar um novo modelo mental da situação em
análise. Para voltar a retroalimentar o mapa até este ficar mais próximo da realidade do
stakeholder.
Figura 61 Linha do tempo do pensamento

FONTE: Adaptada de Lopez & Loureiro (2012)
É desta maneira que acontece a elicitação de informações, levando o stakeholder a
entender suas necessidades e a refletir a respeito do problema o que inevitavelmente levará a
algumas alternativas de solução, ainda que a aplicação do processo sempre com o objetivo de
entender o problema e não precipitar a solução.

156
9.3 Comparação com Abordagens Similares de Elicitação de Necessidades.
A pesquisa bibliográfica para este trabalho foi feita paulatinamente desde que foi
tomada a decisão de abordar o tema de Mapas Cognitivos na elicitação de necessidades de
stakeholder. Durante os estudos e a pesquisa se descobriam novas formas de chamar este tipo
de abordagem assim como novos autores a serem pesquisados. O que no começo foi uma
pesquisa com resultados quase nulos foi dando melhores resultados com as novas descobertas
durante a pesquisa. No início, a pesquisa era feita somente com as palavras chave “mapas
cognitivos” e “elicitação de requisitos” tanto em português quanto em inglês. As palavras
chave começaram a aumentar e a pesquisa foi mais bem sucedida com palavras como SODA,
Comunicação Técnica, Sensemaking, Laddering, entre outros.
Durante a pesquisa bibliográfica não foi possível identificar alguma abordagem similar
para a elicitação de requisitos no desenvolvimento sistemas desde o ponto de vista de
produtos, pois a grande maioria era em desenvolvimento de software.
9.3.1 Mapas Cognitivos de Maneira Geral
Os autores Keng Siau e Xin Tan iniciaram suas publicações na área entre os anos de
2002 e 2003 pelo que podem ser considerados como os que têm a maior trajetória no assunto
de modelos mentais na elicitação de requisitos de sistemas de informação.
A abordagem deles é com mapas conceituais, mapas semânticos e mapas causais.
Nenhuma dessas três abordagens de mapas cognitivos se assemelha à proposta pelo Processo
de Análise de Stakeholders Utilizando Mapas Cognitivos. Eles não estressam os
questionamentos até chegar à necessidade raiz e são utilizados para outros fins.
a. Mapas Conceituais: são utilizados como modelagem de situações complexas.

157
b. Mapas Causais: são utilizados para entender causalidades no processo da
tomada de decisões.
c. Mapas Semânticos: são utilizados como brainstorming para a geração de
ideias.
9.3.2 Laddering
Os autores Annemette Kjaergaard da escola de negócios de Copenhagen e Tina
Blegind Jensen da Escola de Negócios da Universidade de Aarhus também na Dinamarca,
têm vários trabalhos publicados na área de sensemaking e métodos cognitivos a partir do ano
2008 aproximadamente.
Eles abordam o termo de Users’ sensemaking. O termo demonstra a preocupação em
identificar aquelas necessidades que realmente façam sentido para o stakeholder, que sejam
verdadeiras e que tenham propósito definido para que ajudem na definição do sistema de
informações.
A linha de pesquisa deles é muito parecida com a abordagem proposta neste trabalho.
Eles estressam o questionamento para chegar nessa necessidade raiz, mas eles não utilizam o
mapeamento gráfico e livre. Eles seguem um mapeamento textual e linear, identificando os
opostos de cada conceito para o melhor esclarecimento da informação sensemaking, para
depois criar o mapa cognitivo com os conceitos mais relevantes, mas sem a participação do
stakeholder.
9.3.3 SODA
O autor James Bryant, pesquisador da Universidade Sheffield Hallam no Reino Unido,
foi o único trabalho abordando mapas cognitivos similares aos utilizados neste trabalho, para
a elicitação de requisitos.
158
A aplicação da metodologia SODA para a elicitação de requisitos ocorreu no início da
década de 1990 e até o momento não se identificou nenhuma outra aplicação do SODA nessa
mesma linha. O autor do artigo foi contatado via email em 25 de julho 2012 (Anexo A) para
validar a utilização dessa abordagem em outras ocasiões. Ele desconhecia outras utilizações
da ferramenta com o mesmo propósito. Ele continua atuando na área de tomada de decisões
em grupo, mas não aplicou a abordagem de elicitação de requisitos em nenhum outro estudo
de caso.
Apesar de sua principal linha de pesquisa ser na utilização de teoria dos jogos para
gerenciar situações conflitantes, segundo conversa com ele por correio eletrônico (Anexo A);
o trabalho de Bryant (2012) é um dos mais antigos na abordagem, mas acredita-se que não
teve uma grande repercussão devido à utilização do termo SODA, o que é difícil de relacionar
com mapas cognitivos, ainda que se explicitem as siglas. No entanto, pode-se considerar esta
como um das primeiras utilizações de mapas cognitivos (BRYANT, 1997) na elicitação de
requisitos para o desenvolvimento de sistemas de informação.
A diferença com o processo proposto neste trabalho, é que a metodologia SODA foca
numa hierarquia de conceitos meios-fins onde os fins ficam no topo da pirâmide e os
conceitos tipo meios ficam na base da pirâmide. O mapa representa o relacionamento desses
conceitos e seus polos opostos que ajudam a reforçar os conceitos. O mapa ajuda a criar
estratégias para implementar as metas identificadas.
Já o Processo de Análise de Stakeholders Utilizando Mapas Cognitivos, a criação do
mapa é livre, realizando questionamentos livremente, sem importar se os relacionamentos são
meios e fins ou não. O objetivo não é identificar metas e os meios para consegui-las. O
objetivo é elicitar necessidades raiz, sem importar onde estejam localizadas no mapa nem com
um relacionamento meio-fin.
159
9.4 Vantagens do Processo
Geração de Conhecimento
Os ciclos de pensamento e reflexão durante a construção dos mapas gera e captura
conhecimento gráfica e verbalmente.
Nivelamento do conhecimento
O comum entendimento entre stakeholders e engenheiros de sistemas traz benefícios
emergentes, além do entendimento do problema.
A utilização de mapas cognitivos faz com que o engenheiro de sistemas tenha um
claro entendimento das necessidades reais devido a seu papel de facilitador para que o
stakeholder entenda e estruture o problema, o contexto e as necessidades raiz.
O nivelamento do conhecimento se da entre os stakeholders, para que todos os
participantes entendam e conheçam o problema desde outro ponto de vista. Também para que
o nivelamento do conhecimento aconteça entre os stakeholders e os engenheiros de sistemas,
que o engenheiro de sistemas capture a visão do stakeholder para poder analisar o problema.
Exaustividade
A visualização gráfica da informação permite ao engenheiro de sistemas retomar
assuntos não concluídos durante a construção do mapa, por exemplo, se uma trigger question
extrai 4 tópicos importantes, o processo de desdobramento de cada tópico é individual, ou
seja, um de cada vez. O desdobramento resulta numa árvore de conceitos difíceis para
desdobrar todos seus galhos. Se o processo de captura de informações extraídas fosse somente
textual, seria impossível retomar e desdobrar assuntos que foram também identificados. Com
o mapa cognitivo é fácil identificar aqueles finais de galho que podem ser explorados com
160
mais detalhe ou que simplesmente ainda não foram explorados. Dificilmente se escutarão
expressões do tipo: “Por que eu estava falando isto?”, “O que mais que eu tinha falado?”.
O processo proposto ajuda a desenvolver as habilidades de elicitação, pois a mesma
ferramenta é exaustiva por natureza, ela leva o questionamento ao limite, até a pessoa não ter
mais resposta. E é essa exaustividade que ajuda o stakeholder a chegar à necessidade de fundo
ou necessidade raiz. Ele começa a se questionar por que realmente necessita de aquilo, por
que realmente se sente desconfortável com aquilo.
Captura do rationale
Levando em consideração as vantagens anteriores, os rationale de qualquer
necessidade relevante identificada no mapa, podem ser traçados, uma vez que o mapa captura
o caminho do pensamento até aquele ponto. Esse caminho pode ser enfatizado graficamente e
capturado textualmente como um atributo resultante daquela necessidade.
Os mapas cognitivos dos stakeholders permitirão visualizar os relacionamentos meios-
fins ou causa-efeito, o que contribui com a captura do rationale daquela informação relevante
extraída do stakeholder. A transcendência disso ocorre quando os requisitos chegam aos
desenvolvedores e é necessário priorizar e realizar trade-offs sobre aqueles requisitos
desdobrados das informações dos stakeholderes. Nesse momento, é vital ter documentado o
rationale do requisito para ter bases na tomada de decisões. Com os mapas cognitivos, este
rationale é capturado textual e graficamente.
Isso permanece nos registros e as informações extraídas podem ser reutilizadas
durante todo o processo de desenvolvimento e, inclusive, nas futuras inovações incrementais,
isto é, quando um sistema é melhorado com novas funções ou tecnologias.
Estruturação do problema
161
A Engenharia de Sistemas divide seus processos em dois domínios. O primeiro
domínio é o domínio do problema e o segundo, o domínio da solução. Na teoria, é lógico que
aconteça primeiro a definição do problema para partir para a solução. Na prática, não é tão
simples quanto parece. É da natureza humana partir para a solução, e na menos grave das
hipóteses, estrutura-se o problema com certa influência da possível solução ao problema. É
difícil se abstrair completamente da solução. O objetivo é minimizar essa tendência de pensar
na solução.
A Análise de Stakeholders requer primeiramente uma identificação do problema e, a
partir daí, a definição e estruturação do mesmo. O problema deve estar claramente
identificado e estruturado para poder abordá-lo de maneira a identificar alternativas de
solução.
O processo além de elicitar informações ajuda a estruturar o problema ao identificar os
principais fatores problemáticos, o escopo e delimitações do problema, suas restrições e seu
contexto por meio do processo de entendimento do problema. As trigger questions ajudam
também na construção estruturada da análise do problema.
9.5 Desvantagens do Processo
Trigger questions
Um dos fatores principais que influenciam o resultado bem sucedido do mapeamento
cognitivo é a correta formulação das trigger questions. Deve existir um entendimento prévio
do contexto da necessidade inicial além do need statement para ajudar na formulação. Um
resultado favorável da construção de um mapa cognitivo rico em informações dependerá
disso.
162
Cañas & Novak (2006), criadores da teoria de mapas conceituais, descrevem a mesma
dificuldade como uma das três dificuldades que prevalecem nos mapas conceituais entre as
diferentes disciplinas. Ainda que os mapas conceituais tenham uma abordagem diferente dos
mapas utilizados neste processo, esta dificuldade prevalece.
Na pesquisa-ação foi notado que quando a trigger question não representa nada para o
stakeholder, é impossível desenvolver o mapa. Durante a pesquisa, este comportamento se
observou em várias ocasiões. Isto poderia ser ocasionado por vários motivos ou uma
combinação desses:
a. Falta do conhecimento da área e contexto do problema do engenheiro de
sistemas;
b. Falta de conhecimento do funcionamento e de interação com o sistema por
parte do stakeholder;
c. Falta de conhecimento da Engenharia de Sistemas/Engenharia de Requisitos
por parte do stakeholder, a fim de conhecer o destino do trabalho, das
intenções da criação do mapa; e
d. Falta de conhecimento do engenheiro de sistemas em relação aos mapas
cognitivos, a criação das perguntas chave para a elicitação de informações e
construção do mapa.
Integração de vários mapas
Dependendo da complexidade do problema e/ou quantidade de stakeholders para
desenvolver a análise, a quantidade de mapas pode ser grande. A complexidade emerge no
momento de integrar os mapas a fim de ter a visão do todo. A integração requer o
conhecimento e visão adquiridos pelo engenheiro de sistemas durante a construção dos mapas
163
individuais para poder criar uma estrutura lógica do problema como um todo e ainda obter a
validação dos stakeholders.
Falta de completude na análise
Além do que o processo oferece uma abordagem exaustiva, sempre será necessário
utilizar outras técnicas de elicitação de requisitos para completar a Análise de Stakeholders. O
processo oferece esta maneira de elicitar necessidades e informações relevantes, mas nem
todos os stakeholders terão disposição ou disponibilidade de participar ou não se sentirão
confortáveis com a abordagem questionadora.
É fundamental que o stakeholder tenha desejo de participar e aceite ser questionado
sucessivamente. Existirão casos em que o stakeholder não deseje continuar o processo de
construção do mapa, não dando tempo para o engenheiro de sistemas escrever as informações
que estão sendo relatadas.
Nessas situações se deve recorrer a processos menos invasivos para a elicitação de
informações.
164
10 Conclusão
Para concluir este trabalho, retomam-se os objetivos para assim avaliar e concluir cada
um deles. Inicia-se com os objetivos específicos para depois finalizar com o objetivo geral do
trabalho realizado.
10.1 Objetivos Específicos
Objetivo 1: Analisar os problemas existentes durante a Análise de Stakeholders.
O objetivo foi cumprido sob três pontos de vista. O primeiro foi sob o ponto de vista
da literatura sobre o assunto, como pode ser observado nas seções 4.2 e 4.4. O segundo foi
utilizando a pesquisa de campo, estudando os problemas que os profissionais da área
enfrentavam no dia a dia, trabalhados por Dias, López e Belderrain (2012). E o terceiro foi a
partir da experiência da autora na aplicação do processo num caso piloto, como apresentado
na seção 8.4.
Objetivo 2: Desenvolver e detalhar um processo de Análise de Stakeholders.
O objetivo foi cumprido, o processo foi desenvolvido e detalhado em sua totalidade no
Capítulo 7. Para cumprir este objetivo se receberam contribuições da literatura da Engenharia
de Requisitos e Análise de Stakeholders, da literatura dos Mapas Cognitivos e a metodologia
proposta por Ensslin, Montibeller e Noronha (2001), do estudo de campo documentado em
Dias, López e Belderrain (2012) e do exemplo de aplicação, como se mostra nas seções 7.9 e
7.10.
Objetivo 3: Aplicar o processo desenvolvido num exemplo prático
O objetivo foi cumprido parcialmente conforme relatado no Capítulo 8, já que a
aplicação foi feita num caso piloto e não num projeto real, mas ainda assim, pode-se realizar
165
uma aplicação interagindo diretamente com o stakeholder e sentindo na prática a aplicação do
processo.
Objetivo 4: Avaliar os resultados da aplicação e discutir os resultados
O objetivo foi cumprido quase em sua totalidade, a avaliação dos resultados por parte
dos stakeholders foi de maneira informal, durante as aplicações, como apresentado na seção
8.3. Também teve a avaliação da autora deste trabalho tomando o papel do engenheiro de
sistemas. Finalmente faltou a avaliação pelos desenvolvedores, pois como o estudo foi num
caso piloto onde o produto já tinha sido desenvolvido, os dados gerados não seguiram o fluxo
do desenvolvimento.
Objetivo 5: Comparar o processo com abordagens similares
O objetivo foi cumprido como apresentado na seção 9.4. Comparou-se a abordagem
do processo proposto com abordagens similares que estão sendo propostas por outros autores,
o que demonstra uma abordagem de cognição para a Análise de Stakeholders e elicitação de
requisitos, ainda que na engenharia de software.
10.2 Objetivo Geral
O objetivo geral desta tese foi detalhar um processo de Análise de Stakeholders
utilizando uma ferramenta de mapas cognitivos customizada para que auxilie na fase de
Análise de Stakeholders dentro da Engenharia de Sistemas. O objetivo do processo é ajudar
na elicitação de informações relevantes para o desenvolvimento de sistemas, assim como
manter a justificativa das informações mais relevantes.
O objetivo geral foi atingido parcialmente. O detalhamento do Processo de Análise de
Stakeholder utilizando Mapas Cognitivos foi atingido plenamente. A pesquisa-ação permitiu
dar detalhamento ao nível de descrição de atividade. O que foi conclusivo deste objetivo geral
166
foi a relevância das informações extraídas nas fases seguintes do ciclo de desenvolvimento da
Engenharia de Sistemas. Não é possível saber se as informações realmente ajudaram na
concepção da solução apropriada nem se o rationale das informações ajudou na tomada de
decisões de projeto.
Também se conclui que é uma abordagem nova, apesar de ter abordagens similares
como se mostrou na revisão da literatura do Capítulo 3. As técnicas, ainda que similares, não
coincidiam na liberdade da construção do mapa ao fazer qualquer tipo de questionamentos,
não se limitando a um tipo de pergunta como proposto pela metodologia SODA que se limita
aos comos? e por ques?.
O Processo de Análise de Stakeholders Utilizando Mapas Cognitivos, apesar das
desvantagens apresentadas no Seção 9.6, pode ser considerado como uma opção válida na
hora de decidir a estratégia de Análise de Stakeholders. Facilita a aproximação com o
stakeholder e fornece uma ferramenta iterativa e interativa que incita à reflexão tanto para o
stakeholder expressar suas necessidades quanto para o engenheiro de sistemas gerar
questionamentos e ambos construir em conclusões do problema e seu contexto dando partida
à concepção da solução.
O mapeamento cognitivo mostrou ser uma ferramenta adequada para o processo de
Análise de Stakeholders. As vantagens obtidas justificam a presença da ferramenta como
parte do processo. Os fatores críticos para obter sucesso nesta abordagem são: o completo
envolvimento do stakeholder e a prévia contextualização do problema por parte do
engenheiro de sistemas, a fim de facilitar o processo e elicitar informações ricas e relevantes
para a concepção e desenvolvimento do novo sistema.

167
10.3 Trabalhos Futuros
Aplicação do processo proposto num projeto real
Aplicação do processo proposto num projeto real, aonde aconteça a transformação das
necessidades em requisitos e estes sejam utilizados para a especificação do sistema, a maneira
de validar se as informações elicitadas e seu rationale foram de ajuda na definição da solução.
Aplicabilidade do processo dentro da Engenharia Cognitiva
Existe uma área dentro da Engenharia de Sistemas chamada de Engenharia Cognitiva
que segundo Leveson (2000) integra a Engenharia de Sistemas, psicologia cognitiva e os
fatores humanos. Essa abordagem reconhece o ser humano como elemento de um sistema
complexo. O desenvolvimento desses sistemas deve considerar as capacidades e limitações do
ser humano. Leveson (2009) propõe uma abordagem para escrever especificações de
software, o que chama de intent-specifications (especificações com intenção ou motivo), que
são especificações centradas no humano para sistemas safety-critical (críticos em termos de
segurança).
É com foco na área da Engenharia Cognitiva que se pretende continuar com esta
pesquisa, e analisar se existe aplicabilidade do processo em sistemas onde as funções do ser
humano são fundamentais para o funcionamento harmônico do sistema, como no caso da
aviação.
Aplicabilidade do processo no desenvolvimento de sistemas de inteligência
artificial.
Estudar a aplicabilidade do processo proposto para um caso de desenvolvimento de
sistemas de inteligência artificial, já que a mesma estudada a cognição humana a maneira de
entender a maneira do ser humano tomar decisões e implementá-las na área.

168
Aplicabilidade do processo na captura do rationale de projeto.
Durante a definição da solução a ser implementada, seja no nível que for dentro do
desenvolvimento, são tomadas decisões de implementação e para a memória da organização é
necessário que essas decisões e seu rationale sejam documentadas, para que num futuro, no
momento de melhorar o produto ou desenvolver produtos similares facilitar as decisões ou
ainda a identificação de falhas por causa de essas decisões.
O processo proposto pode ser customizado para que em vez de entrevistar aos
stakeholders, sejam entrevistados os projetistas ou desenvolvedores que tomaram as decisões
para poder documentar a maneira de mapa cognitivo, o rationale dessas decisões de projeto.
169
Referências
1. ACKERMANN, F.; EDEN, C.; CROPPER, S. Getting started with cognitive mapping. In:
YOUNG OR CONFERENCE, 7., 1992, Coventry. Proceedings...Convetry: University of
Warwick, 1992. p. 65-82. (Tutorial paper)
2. ALEXANDER, I. F.; STEVENS, R. Writing better requirements. London: Pearson

Education Ltd, 2002. 86 p.
3. BAHILL, A. T.; DEAN, F. F. Discovering systems requirements. In: SAGE, P. A.;

ROUSE, B.W. Handbook of systems engineering and management 2nd ed. New
Jersey: John Wiley & Sons, 2009, 4, p. 205-266
4. BOURNE, H.; JENKINS, M. Eliciting managers’ personal values: An adaptation of the

Laddering interview method. Organizational Research Methods, v. 8, n.4, p. 410–428,
October 2005.
5. BRYANT, J. Autorização para cópia de publicação. 2012 [menssagem pessoal].

Mensagem recebida por brenda.villafranca@lit.inpe.br em 25 jul. 2012
6. BRYANT, J. Requirements capture using SODA. European Journal of Information

Systems, v. 6, n. 3, p. 155-163, 1997.
7. CAÑAS, A.; NOVAK, J. D. Re-examining the foundations for effective use of concept
maps. In: INTERNATIONAL CONFERENCE ON CONCEPT MAPPING, 2., 2006, San
José. Proceedings… San José: Editorial Universidad de Costa Rica, 2006. p. 494-502.
8. COELHO, S. A. Desenvolvimento integrado de sistemas espaciais – Design for AIT-

projeto para montagem, integração e testes de satélites D4AIT. 2011. 455f. Tesis
(PhD Engenharia de Sistemas) – Instituto Tecnológico de Aeronáutica, São José dos
Campos.
9. COURAGE, C.; BAXTER, K. Understandig your users: A practical guide to user

requirements methods, tools, and techniques. San Francisco: Elsevier, 2005. 781p. (The
Morgan Kaufmann series in interactive technologies)
10. CREATIVITY WEB. Kekule. 2nd Oct 1996. 1 imagem. Disponível em:
<http://members.optusnet.com.au/charles57/Creative/Brain/kekule.htm>. Acesso em: 21
jul. 2012.
11. DA SILVA, E. L.; MENEZES, E. M. Metodologia da pesquisa e elaboração da

dissertação 4ª ed. Florianópolis: UFSC, 2005. 138p.
12. DIAS, R.; LOPEZ, V. B.; BELDERRAIN, M. C. N. Mapeamento cognitivo como uma
técnica para apoio à engenharia de requisitos. In: EUROPEAN CONFERENCE ON
170
CREATIVITY AND INNOVATION, 12., 2011, Lagos. Proceedings… Lagos:

Universidade do Algrave, 2012. p. 772-807.
13. EDEN, C. Cognitive mapping. European Journal of Operational Research, v. 36, n. 1,

p. 1-13, July 1998.
14. ENSSLIN, L.; MONTIBELLER, G. N.; NORONHA, S. M. Apoio á decisão:

metodologia para estruturação de problemas e avaliação multicritério de alternativas.
Florianópolis: Insular, 2001. 296p.
15. FISCHLER, M. A.; FIRSCHEIN, O. Intelligence: the eye, the brain and the computer.
Reading: Addison-Wesley, 1987. 331p.
16. GOEL, V. Sketches of thought. Cambridge: MIT, 1995. 279p.
17. HAUSER, J. R.; CLAUSING, D. The house of quality. Harvard Business Review, May
01, 1988
18. HULL, E.; JACKSON, K.; DICK, J. Requirements Engineering 2nd ed. [S.l.]: Springer,
2005. 198p.
19. INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. IEEE Std 1362:

IEEE guide for information technology: system definition: concept of operations
(ConOps) document. New York, 2007. 21p.
20. INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING. Incose: TP-2003-

002.1: systems engineering handbook a guide for system life cycle processes and
activities Version 3.2.1. San Diego, January 2011. 374p
21. J-CDS CONCURRENT DESIGN SERVICES AND SOLUTIONS. Solutions: Main

pillars of the J-CDS solution. 2012. 1 imagem. Disponível em: <http://www.j-
cds.nl/index.php?site=solutions&search=oc&block_id=66>. Acesso em: 30 jun. 2012.
22. KJAERGAARD, A.; JENSEN, T. B. Appropriation of information systems: using

cognitive mapping for eliciting users' sensemaking. In: INTERNATIONAL
CONFERENCE IN INFORMATION SYSTEMS, 2008, Paris. Proceedings... Paris:
AISeL, 2008. Paper 64.
23. KOSSIAKOFF, A.; SWEET, W. N.; SEYMOUR, S. J.; BIEMER, S. M. Systems

engineering principles and practice 2nd ed. New Jersey: John Wiley & Sons, 2011.
528p. (Wiley Series in Systems Engineering and Management. Andrew P. Sage, Series
Editor)
24. LEVESON, N. G. Intent specifications: an approach to building human-centered

specifications. IEEE Transactions on Software Engineering, v. 26 , n. 1, p. 15-35,
January 2000.
171
25. LEVITIN, D. J. Foundations of cognitive psychology: core readings. Cambridge: MIT

2002. 813p.
26. LOPEZ, B. C. V.; LOUREIRO, G. Stakeholder analysis using cognitive mapping. In:
ISPE INTERNATIONAL CONFERENCE ON CONCURRENT ENGINEERING, 19.,
2012, Trier. Proceedings… Trier: Springer, 2012. v. 2. P. 1069 -1080.
27. LOUREIRO, G. Systems engineering and concurrent engineering framework for the
integrated development of complex products. 1999. 530p. Thesis (PhD in Systems
Engineering) - Loughborough University, Loughborough.
28. NOVAK, J. D.; CAÑAS, A. J. The origins of the concept mapping tool and the continuing
evolution of the too. Information Visualization Journal, v. 5, n. 3, p. 175-184,
September, 2006.
29. OKADA, A. Cartografia cognitiva: mapas do conhecimento para pesquisa,

aprendizagem e formação docente. Cuiabá: KCM, 2008. 390p. (Série CoLearn)
30. OSLON, D. R. The world on paper: the conceptual and cognitive implications of writing
and reading. Cambridge, CA: University Press, 1994. 318p.
31. RYSCHKEWITSCH, M.; SCHAIBLE, D.; LARSON, W. The art and science of systems
engineering. NASA, 2009. Disponível em:
<http://sse.stevens.edu/fileadmin/sse/academics/resources/Art_and_Science_of_Systems_
Engineering.pdf> Acesso: 20 agosto 2012
32. SIAU, K.; TAN, X. Technical communication in information systems development: the
use of cognitive mapping. IEEE Transactions on Professional Communication, v. 48,
n. 3, p. 269-284, September 2005.
33. THAGARD, P.; GABBAY, D. M.; WOODS, J. Philosophy of psychology and cognitive
science. 1st ed. North Holland: Elsevier, 2007. 502p. (A volume of the handbook of the
Philosophy of Science Series)
34. UNITED STATES. National Aeronautics and Space Administration. NASA/SP-2007-

6105 Rev1: Systems engineering handbook. Washington, D.C., December 2007. 340p
35. VERMA, D. Stakeholder expectations and requirements definition. In: LARSON, J. W.;
KIRKPATRICK, D.; SELLERS, J.J.; THOMAS, L.D.; VERMA, D. Applied space
systems engineering. [S.l]: McGraw-Hill, 2009, 2, p. 37-63. (Space technology series)
36. WIKIPEDIA. Computational Theory of Mind. 26th Nov. 2012. Disponível em:
<http://en.wikipedia.org/wiki/Computational_theory_of_mind>. Acesso em: 18 dez.
2012.
172
37. WIKIPEDIA Feynman diagram. 19th Aug. 2012. 1 imagem. Disponível em:
<http://en.wikipedia.org/wiki/Feynman_diagram>. Acesso em: 21 jul. 2012.
173
APÊNDICE A: Fluxos do Diagrama de Contexto IDEF0 do Processo
Proposto
O contexto do Processo de Análise de Stakeholders Utilizando Mapas Cognitivos é
representado por Entradas, Saídas, Mecanismos de Controle e Recursos, especificados a
seguir:
Fluxos de entradas e saídas
Contexto: descrição do ambiente onde está inserido o problema ou necessidade, o
contexto, cultura e valores da organização ou organizações envolvidas.
Descrição do problema estruturado: a descrição do problema é o principal resultado
da Análise de Stakeholders. É possível compreender a situação do stakeholder, o contexto do
problema e o descobrimento do problema real no caso deste não ter sido esclarecido desde o
início, até para o mesmo stakeholder.
Documentos existentes: Os documentos existentes podem ser análises da área de
marketing ou da área de serviço ao cliente como melhorias para um sistema existente ou
qualquer tipo de documento que ajude no entendimento da necessidade e seu contexto.
Entendimento nivelado do problema entre os stakeholders e engenheiros de sistemas:
Os engenheiros de sistemas sempre terão a vantagem de conhecer o ponto de vista de todos os
stakeholders, mas os stakeholders poderão ter esse nivelamento somente quando o mapa
cognitivo for coletivo.
Estratégia de Intervenção:
a. Agrupamento de stakeholders: grupos de stakeholders por cenário, assunto ou
classe, que serão entrevistados, quais deles participarão em grupo e quais deles
174
terá participação individual. Isso é definido em função da disponibilidade do
stakeholder.
b. Tipo de aplicação: definição do tipo de aplicação do processo individual, em
grupo, de documentos, ou a combinação deles.
Informações elicitadas no formato de mapas cognitivos: Informações extraídas no
formato de mapa cognitivo. Podem ser mapas cognitivos individuais ou mapas de um grupo
de stakeholders.
Informações não oficiais: As informações não oficiais geralmente vêm de conversas
informais que expressam uma necessidade chave ou aspectos e contexto da mesma.
Informações relevantes dos stakeholders: Informações relevantes para a criação dos
requisitos que serão entregues aos desenvolvedores. Os tipos de informações podem ser:
necessidades, restrições, suposições, desejos, sistemas legados, MoE’s, etc.
Lista de cenários do ciclo de vida do sistema (quando aplicável): É aplicável quando a
missão do sistema já foi definida, e se tem os dados suficientes para definir os cenários do
ciclo de vida do sistema.
Lista de stakeholders: Os stakeholders envolvidos diretamente com o problema ou
necessidade inicial, dentro do contexto. A partir dessas listas são identificados aqueles que
irão participar da análise.
Mapas cognitivos individuais validados: As informações elicitadas a partir de mapas
cognitivos gerados por somente um stakeholder.

175
Mapa cognitivo integrado validado (quando aplicável): Os vários mapas individuais
ou e em grupo integrados em um mapa só representando a necessidade, o problema ou o
cenário em análise.
Necessidade inicial (need statement): a necessidade inicial pode vir do cliente, da
empresa desenvolvedora ou algum outro stakeholder do sistema. Pode vir de maneira formal
ou informal, detalhada ou uma simples frase expressando um desejo.
Problema estruturado graficamente: são os mapas mostrando uma estrutura de
clusters, os quais representam grandes assuntos emergentes do problema, dando assim a
estrutura ao problema, dividindo o problema em partes para facilitar sua análise.
Rationale das informações relevantes: O rationale das informações relevantes
registrados graficamente nos mapas cognitivos, ou sua versão em texto descritivo.
Trigger questions: São os questionamentos iniciais para dar início à elicitação de
informações e se fundamentam na necessidade inicial e no contexto do problema.
Fluxos de controle
Validação pelos stakeholders: O mecanismo de controle da representação das
informações sempre será a validação do stakeholder, dado que ele é a fonte de informação. É
ele quem vai validar se a informação capturada representa sua visão do problema e suas
necessidades.
Validação pelos stakeholders iniciais: O mecanismo de controle da interpretação das
informações é se o entendimento da necessidade e seu contexto é o mais próximo da realidade
dos stakeholders iniciais.

176
Validação pelos engenheiros de desenvolvimento: O mecanismo de controle da
qualidade das informações são os engenheiros de desenvolvimento que poderão verificar se os
requisitos gerados a partir dessas informações são suficientes para a implementação no
projeto.
O engenheiro de desenvolvimento se refere ao engenheiro especialista que projeta e
implementa a solução.
Validação pelos engenheiros de sistemas:
Na análise do contexto, o mecanismo de controle da completude das informações são
os engenheiros de sistemas. Eles analisarão se as informações são suficientes para o
entendimento do problema e seu contexto.
Na elaboração da estratégia de intervenção, eles validam se a estratégia é a mais viável
para a situação e contexto que está sendo analisado.
Na elicitação das informações dos stakeholders com mapas cognitivos, eles analisam
se realmente o mapa está com suficientes informações para continuar com a análise do
problema ou se é necessário voltar a conversar com os stakeholders.
Na análise dos mapas cognitivos, eles analisam se as informações são suficientes para
criar requisitos de qualidade, cumprindo com características como completude, clareza, entre
outros; já que provavelmente serão eles que transformem as informações em requisitos.
Na identificação de necessidades e análise do problema, eles analisam todas as
informações geradas e se elas são suficientes para finalizar a análise e estruturação do
problema.
Fluxos de recursos
177
Dois engenheiros de sistemas:
Os engenheiros de sistemas são os que participam da concepção, têm a visão de todo o
sistema e suas fases do ciclo de vida. Conhecem o funcionamento do sistema no alto nível, e
não são especialistas em alguma área em especifico, i.e. mecânica, elétrica, estruturas, etc.
Estipulam-se dois engenheiros de sistemas como número mínimo, dependendo da
complexidade da análise, podem ser necessários mais de dois.
Na análise do contexto, ambos têm a mesma função de analisar o contexto da situação.
Na elaboração da estratégia de intervenção, ambos têm a mesma função de elaborar a
estratégia de intervenção
Na elicitação de stakeholders com mapas cognitivos, um engenheiro de sistemas é
responsável pelos questionamentos e o outro é responsável pela captura das informações
extraídas do stakeholder, ou seja, pela criação do mapa.
Na análise dos mapas cognitivos, ambos são responsáveis pela análise dos dados do
mapa. Sempre é importante ter mais de uma opinião na análise, além do que, as informações
são muitas e é difícil que um engenheiro de sistemas tenha o entendimento total do que foi
extraído.
Na identificação de necessidades e análise do problema, ambos, com o conhecimento
nivelado ao respeito do problema ou necessidade, analisarão as informações extraídas para
concluir a análise e descrever o problema.
Software de suporte para gerar mapas: Existem vários softwares livres e comerciais
que oferecem meios para a criação dos mapas. Para este trabalho foi utilizado o software livre
178
Cmap Tools, desenvolvido pelo criador dos mapas conceituais Joseph Novak e sua equipe de
trabalho. O software pode ser descarregado no site: http://cmap.ihmc.us/

179
APÊNDICE B: Fluxograma do Processo de Análise de Stakeholders Utilizando Mapas Cognitivos.

180
APÊNDICE C: Tipos de Aplicação do Processo de Análise de
Stakeholders Utilizando Mapas Cognitivos
O processo pode ser utilizado de três maneiras; aplicação individual, aplicação em
grupo e documento fonte. Isso dependerá da situação em específico para cada tipo de
problema, a disponibilidade dos stakeholders, os documentos disponíveis com informações
referentes ao problema ou a qualquer outra informação relevante. O processo tem a
flexibilidade suficiente para se adaptar às situações variadas, porém, os resultados podem ser
mais produtivos para uns casos, mais do que para outros. Também pode ser aplicado de
maneira mista, podendo aplicar os dois ou três tipos simultaneamente.
Aplicação Individual
Na aplicação individual, são entrevistados diferentes stakeholders com relação a um
cenário ou problema específico, mas de maneira individual, para depois, o engenheiro de
sistemas integrar os mapas individuais num único mapa e validar o resultado com todos os
stakeholders participantes.
Aplicação em grupo
Na aplicação em grupo, reúnem-se todos os stakeholder chave para aquele cenário ou
problema em avaliação, e todos participam da criação do mapa de maneira conjunta,
respondendo às mesmas perguntas do engenheiro de sistemas, sempre de maneira ordenada
para possibilitar a captura do que cada um tem a opinar.
Documentos fonte
Essa alternativa de aplicação se utiliza quando o stakeholder é de difícil acesso, seja
pessoal ou simplesmente não se tenha acesso a ele. Em caso de não ter acesso a um encontro
181
cara a cara com o stakeholder pode-se recorrer à alternativa de solicitar um texto ao
stakeholder onde ele possa expressar a problemática e suas opiniões a respeito, e tentar guiar
o texto com algumas Trigger questions predefinidas pelo engenheiro de sistemas.
Outra alternativa é quando se quer reaproveitar informações contidas em documentos.
Esses podem ser relatórios, minutas, reclamações dos usuários do sistema, documentos de
requisitos de versões anteriores do sistema, normas, documentos oficiais, entre outros.
Aplicação combinada
Essa alternativa é utilizada quando se pode ter acesso e disponibilidade de um grupo
de stakeholders de participar em conjunto e alguns que prefiram participar de maneira
individual e se tenham documentos relevantes para a Análise de Stakeholders. Como
resultado podem-se integrar todos os mapas resultantes para sua validação.

182
APÊNDICE D: Evolução da Figura de Apoio para a Análise de
Stakeholders do estudo piloto Shunt Box.
Figura D1 Contexto gráfico da Shunt Box Versão 0

183

184
Figura D6 Contexto gráfico do Teste de Termo Vácuo sem as funções da Shunt Box
185
APÊNDICE E: Detalhamento do Estudo do Problema
A necessidade inicial
A necessidade inicial era possibilitar o teste do modelo térmico dos satélites CBERS 3&4 com
filosofia de teste de skin heaters e resistências tubulares com um numero de até 300 cargas.
Stakeholders identificados
Quadro E1 - Lista de stakeholders identificados

Desenvolvedor Desenvolvimento de Hardware e Manutenção
1 Engenheiro A
de Sistemas
Técnico de Desenvolvimento de Hardware e Manutenção
2* Desenvolvedor
desenvolvimento A de Sistemas
4 Engenheiro C Cliente interno Aquisição de dados
Usuário – Desenvolvimento de Hardware e Manutenção

5* Técnico A
Configurador de Sistemas
Desenvolvimento de Hardware e Manutenção
6* Técnico B Suporte - manutenção
de Sistemas
7 Técnico C Cliente interno Aquisição de Dados
8 Técnico D Cliente interno Aquisição de Dados
9 Engenheiro D Cliente interno Térmica
10 Engenheiro E Cliente externo Engenharia de Satélites
O problema
Analisando o problema que a Shunt Box visa resolver, deparou-se com o fato de que o
contexto do problema é maior e a Shunt Box é somente uma parte da solução.

186
A Shunt Box é um meio para o Teste de Modelo Térmico na Câmara de Vácuo –
Térmica. O perfil ou filosofia do teste é definido levando em consideração múltiplos critérios
e diferentes combinações destes mesmos critérios.
É importante entender como a filosofia do teste é definida e se existe alguma outra
limitante dentro deste modelo para ser levada em consideração na análise e estudo do
problema.
O problema inicialmente identificado tinha um escopo reduzido, somente os testes
onde a Shunt Box é necessária. A análise evoluiu durante o estudo do contexto da Shunt Box
para o melhor entendimento do teste do modelo térmico.
Missão
O sistema deve capacitar a área Térmica do LIT para realizar o teste de diferentes
modelos térmicos na câmara de Vácuo-Térmica 6m x 8m
Antecedentes
Perfil ou Filosofia do Teste do CBERS 3&4
Perfil A: Lâmpadas
No ano de 2009 seriam testados os satélites CBERS 3&4 e era necessário recriar o
ambiente térmico do espaço dentro da câmara de vácuo térmica 6x8m do LIT. O ambiente
térmico seria simulado com lâmpadas para que estas gerassem o calor dentro da câmara; com
base nessa premissa foram especificadas e compradas 20 fontes com capacidade para 100.000
Watts, com 20 saídas por fonte.
Perfil B: Skin heaters e resistências tubulares

187
Após a compra das fontes, houve uma mudança na filosofia do teste. O novo perfil ou
filosofia era que o satélite seria aquecido por meio de skin heaters e resistências tubulares, o
que demandava menos potência, mas requeria o fornecimento de potência distribuída em
pequenos fluxos.
Por que a mudança de lâmpadas para skin heaters?:
a. Controle de tolerâncias: Era muito difícil controlar a intensidade do calor que
precisava ser gerado, ou seja, manter as tolerâncias para a idêntica simulação
do ambiente no espaço.
b. Contaminação: Se o fluxo de potência aumentasse mais do que as lâmpadas
suportavam, estas estourariam e contaminariam o interior da câmara de Vácuo-
Térmico e o satélite.
O problema que motivou o desenvolvimento da Shunt Box
A mudança na filosofia do teste de lâmpada para skin heater acarretou alguns
problemas em torno às fontes:
a. Capacidade: As fontes têm capacidade para fornecer 100.000 Watts de
potência, mas num teste de satélite de grande porte, o máximo a ser utilizado
são 2000 watts, o que representa 5% da capacidade disponível.
b. Distribuição de cargas: As fontes só contam com 50 ramos de saída de
fornecimento e para um teste de porte grande são necessários até (300 ou 600)
ramos de fornecimento de potência para cada skin heater.
Solução: Shunt Box

188
A Shunt Box dá suporte ao Teste de Modelo Térmico. Inicialmente, a Shunt Box foi
desenvolvida porque era necessário um número elevado de ramos de alimentação para testes
na câmara de termo – vácuo, o número de ramos das fontes era insuficiente e se viu a
necessidade de criar um EGSE que pudesse distribuir o número de ramos a partir das fontes
disponíveis.
Descrição do Sistema
Árvore do Sistema
Teste de
Balanço
Térmico
Sub-sistema a Câmara de
EGSE MGSE
ser testado Têrmo-Vácuo
Sensores Fontes Shunt Box Scanners
Figura E1 Árvore do Sistema do Teste de Balanço Térmico
Representação gráfica do cenário de operação do sistema: Teste de Balanço Térmico
as-is
Figura E2 Cenário de operação do sistema

189
Descrição da Shunt Box as-is
Propósito
O rack de Shunt Boxes foi desenvolvido para atender a demanda do teste do CBERS
no ano 2009
Função
1. A Shunt Box pode fornecer tensão e corrente para diferentes propósitos, mas
até agora só foi utilizado para aquecer com skin heaters.
2. Os sinais que fornece são enviados para os scanners que ficam dentro do
mesmo rack de Shunt Boxes
3. A Shunt Box é utilizável em qualquer das 5 câmaras de termo vácuo (6x8, 3x3,
1x1 e 2 de 250lt) porque tanto as entradas das câmeras quanto as saídas das
Shunt Boxes são padronizadas
4. Até o momento, só tem sido utilizada nas câmaras de 6x8 e 3x3
5. Até o momento, só tem sido utilizado em testes de subsistemas espaciais que
são os que demandam mais cargas. Para sistemas menores, da indústria, por
exemplo, as cargas da fonte são suficientes para a demanda do teste.
Capacidade
1. Cada Shunt Box é capaz de distribuir as fontes em até 5 ramos por fonte
2. Cada Shunt Box tem capacidade para receber (n) número de fontes
3. Pode ser utilizada com:
a. Skinheaters
b. Radiômetros
c. Suprir baterias que não entraram no teste

190
d. Qualquer outro equipamento que precise de tensão e corrente
Interface
Quadro E2 - Lista de interfaces da Shunt Box

Elemento Tipo de interface
Rede elétrica Conectores
Câmara de vácuo térmica Conector DB50 - Conector Deutsch
Fontes Conector DB25
Scanner Flat cable
Programador da Shunt Box Manual
Programador da câmara Manual
Estrutura Física
Existe um rack que contém 6 Shunt Boxes
Frequência de utilização
Uma vez por ano em média
Restrições iniciais do sistema de interesse
As restrições iniciais do sistema de interesse são as que atualmente são impostas pela
Câmara de Vácuo-Térmica e pelo perfil ou filosofia do teste:
1. Câmara de Vácuo-Térmica
2. Potência
3. Entradas
4. Filosofia do Teste
5. Tipos de Aquecedores
6. Tipos de Espécime
191
Figura E3 Arquitetura do sistema e suas restrições

192
ANEXO A: Correspondência com o Pesquisador PhD. James Bryant
-------- Mensagem original --------

Assunto:RE: Requirements capture using SODA
Data:Mon, 3 Sep 2012 15:56:35 +0100
De:Bryant, James <J.W.Bryant@shu.ac.uk>
Para:Brenda <brenda.villafranca@lit.inpe.br>
Hi Brenda
Thanks for being so understanding. There's been plenty to do waiting for

me on my return from holiday too. So I hope this isn't too late.
Anyway AMAZINGLY I just went into my study here at home and the first files
I found related to the ICW (Integrated Cooperative Workplace) Project
within which the work on which we've been corresponding was carried out.
In what I write below I've gone back to these documents rather than to the
published paper (I hope there aren't too many contradictions!)
I see to my surprise that the initial meeting for this Demonstrator project
was in early October 1993 (!!). By the end of the month we'd agreed to
focus on the Health Circulars process as our pilot application, and it was
early December when I and a colleague carried out the first 6 interviews
with senior staff. (I'm afraid it was my own enthusiasm for SODA that made
us use the approach - other people were happy to let me get on with it!)
From these we realised that it would be important also to talk with more of
the middle-level staff who were the ones who would have to respond to the
Circulars and so we interviewed 6 more people in January 1994. The
Workshop session was held as soon as possible after these interviews (so it
was all fresh in participants' minds) on 11 February. It was a half-day
event at my University - we wanted to take people off-site - concluding
with lunch.
The interviews were mostly held in respondents' own offices and each was
allowed 45 minutes. We began by introducing the project and then invited
their comments on the collaborative processes in which the interviewee was
involved. We didn't record the interviews (not as a matter of principle,
but there were two of us available anyway and we shared the questioning and
both recorded what was said). The two of us facilitators created a map
from our notes as soon as we could after the interviews. We didn't return
these maps to people for their elaboration/confirmation (as we 'should'
have done) mainly through lack of time. The hand-drawn maps were initially
hand drawn and then transcribed first into a spreadsheet package and later
(when Graphics COPE software finally became available just before the
Workshop) into cognitive mapping software. Each map had about 30
constructs. We did some rough head/tail analysis but couldn't do much more
because of the absence of software. [Obviously if we'd been able to repeat
the project we'd have done the confirmatory sessions and used (today)
Decision Explorer from the very start.
I went through the maps and identified themes (again, in many circumstances
this is something I'd prefer to do WITH the participant group) and grabbed
all the fragments of argumentation that related to each one, pulling these
into 9 Issue Sheets and 9 Issue Maps which we provided to the workshop
attendees.
193
In the target-setting workshop we divided those present into 3 sub-groups,

each working on 3 separate Issue areas. The idea was that each sub-group
would develop precise targets for assessing achievement around each of
their Issues.
Finally there was a plenary discussion to bring together the
recommendations from the syndicates and to agree a way forward.
So the process you've set down in your initial note to me seems to capture
it all pretty well.
Just one comment. Like any such process, what we designed and carried out
was a process that was shaped to a considerable extent by the circumstances
(e.g. the elapsed time available, the presence/absence of software, the
skills/training of the interviewers, the physical accommodation available,
etc.) and was in no sense an 'ideal' template. Even if we'd repeated it a
few months later we'd have done things differently, and today of course we
would probably have had fresh opportunities available (e.g. notably the
technology for creating/working with cognitive maps 'on the hoof' and at-a-
distance). So while it's interesting in a nostalgic sort of way to look
back at the project, if one were going to do something similar now one
should really be familiar with how mapping-based approaches are being used
(which is why I suggested contacting Fran Ackermann - and at the very least
being familiar with the book that she and Colin Eden produced now over 10
years ago called 'Making Strategy').
I've no problem with you citing things I've said in these exchanges if you
think anyone else would be interested! As a complete aside, while I still
love cog. maps, my main field of work remains in the area of conflict and
collaboration management and I've been working on software support for a
specific approach there for years: the principal audience for this happens
to be in South America!
Good luck with what you're doing. If you have any further queries/comments
on the things we've been discussing please don't hesitate to get in touch.
Best wishes,
Jim
________________________________________
From: Brenda [brenda.villafranca@lit.inpe.br]

Sent: 31 August 2012 17:05
To: Bryant, James
Subject: Re: Requirements capture using SODA
Hi Jim,
No worries at all! I imagined you were enjoying the olimpics!
I wold like your authoriztion to citate our email exchanges on my

research. I am conluding that you were one of first (I din't find any
oldest reference or even from that time) using this approach and one of
the reasons that didn't have continuity was because of the title of the
article. The term SODA is very specific and whom does not belong to that
research area, don't understand the real mening of the approach.
Thank you very much. Have a great weekend

194
Em 28/08/2012 15:47, Bryant, James escreveu:

> Hi Brenda
> Sorry not to have replied to you but I'm just back from holiday. Will
look out my old papers just to check what you said but I'm pretty sure you
have interpreted it correctly.
> Best wishes
> Jim
>
> ________________________________________
> From: Brenda [brenda.villafranca@lit.inpe.br]
> Sent: 27 July 2012 13:36
> To: Bryant, James
> Subject: Re: Requirements capture using SODA
>
> Dear Jim,
>
> Thank you very much for your answer. My serch key words were cognitive
mapping and requirements elicitation. SODA is a specific approach, so I
found your paper after founding SODA.
>
> I found other author sing cognitive mapping for that purpose, but
different kind of maps. Thank you for the advice, I'll contact Mrs.
Ackermann.
>
> I would like your opinion of what I understood on your paper. Please let
me know if I'm wrong, my understanding of the application process was as
follows:
>
> 1st Phase: Individual Interviews
>
> 1. Informal interview with the users or each key processes of the
organization through rough cognitive mapping, showing graphically the
argument chain.
>
> 2. Short analysis of the head-tail argument chains. The heads
representing the objectives and the tales representing means and actions.
Identification of personal goals and not-goals.
>
> 3. Integration and review of the different individual maps to
identify common themes relevant to the problem
>
> 4. List the key issues of the common relevant themes
>
> 5. Construct a map for each key issue with the information of the
integrated map
>
> 6. Goals and not-goals identification in the key issue maps.
Represent them on a table to create work packages, which will be used on
the collaborative session. The work packages will contain the information
elicited by the analyst based on the map
>
>
>
> 2nd Phase: Collaborative work (The Workshop)
>
> 7. Create the working groups for each key issue
>
> 8. Construct the maps based on the Issue Work Packages, to generate
new ideas, debate and consensus.
>
195
> 9. Identify the critical concepts and generate the hard and soft
objectives for each of them
>
> 10. Refine the emerging objectives
>
> 11. Organize the ideas in a hierarchical manner in a table format with
the following labels: Top level, Activities, information, People & Roles,
and General
>
> 12. For each item of the table, the participants define the following
information: Functional Requirements, Metrics and Evaluation Methods.
>
> Thank you very much for your disposition.
> Sincerely,
>
> Brenda
>
>
> Em 25/07/2012 21:30, Bryant, James escreveu:
>
> Hi Brenda
>
> How nice to have your message! I can remember few follow up enquiries
after that paper which I therefore assumed had vanished without trace as
they say!
> I used cognitive mapping because it's a technique that I particularly
like and I persuaded the others in the team that it was the right thing
for us to employ and it worked well enough.
> I'm not by trade a systems engineer - my principal research is in the use
of game-theory models to manage conflict situations - so I cannot comment
on other work in requirements elicitation.
> My best suggestion s that you contact Fran Ackermann at Strathclyde
University as she will probably know (or know someone who knows) whether
SODA has been used in this way elsewhere.
>
> All the best with your own work. If I can provide any more information
(including details of what we did all those years ago) just get in touch.
>
> Jim
>
> ________________________________________
> From: Brenda
[brenda.villafranca@lit.inpe.br<mailto:brenda.villafranca@lit.inpe.br>]
> Sent: 25 July 2012 23:12
> To: j.w.bryant@shu.ac.uk<mailto:j.w.bryant@shu.ac.uk>
> Subject: Requirements capture using SODA
>
> Dear Mr. Bryant,
>
> I'm a MSc. student at the Technological Institute of Aeronautics (ITA-
Brazil) My research work is on the Systems Engineering field. We are
proposing a method to elicit requirements using cognitive mapping. The
focus of the method is on product development.
>
> The approach we are proposing is similar to your work on "Requirements
capture using SODA" (1997). Yours was the only work I found, using this
kind of maps.
>
> I was wondering if there were more works on requirements elicitation
using SODA and if it weren't, I was wondering the reasons for that, since I
find it very appropriate for that purpose.
196
> Sincerely,
>
>
>
> --
> Brenda C. Lopez Villafranca
>
> LSIS - Concurrent Systems Engineering Laboratory
> LIT- Laboratory of Integration and Testing
> INPE -The Brazilian Institute for Space Research
>
www.lit.inpe.br<http://www.lit.inpe.br><http://www.lit.inpe.br><http://www.
lit.inpe.br>
> Tel. +55 12 3208-6346
FOLHA DE REGISTRO DO DOCUMENTO
1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA REGISTRO N° N° DE PÁGINAS
DM 14 de janeiro de 2013 DCTA/ITA/DM-095/2012 196

5.
TÍTULO E SUBTÍTULO:
Processo de análise de stakeholders utilizando mapas cognitivos

6.
AUTOR(ES):

7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica – ITA

8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Análise de Stakeholders, Mapas Cognitivos, Engenharia de Requisitos

9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Administração de projetos; Partes interessadas; Esquemas conceituais; Especificação formal; Planejamento

estratégico; Administração.
10.
APRESENTAÇÃO: (X) Nacional ( ) Internacional
ITA, São José dos Campos. Curso de Mestrado. Programa de Pós-Graduação em Engenharia Aeronautica e
Mecânica. Área de Produção. Orientador: Prof. Dr. Geilson Loureiro. Defesa em 07/12/2012. Publicada em 2012
11.
RESUMO:
Objetivo do trabalho é propor um processo para a Análise de Stakeholders utilizando mapas cognitivos a fim
de auxiliar no processo da elicitação de necessidades raiz. O processo proposto aborda desde o estudo do
contexto até a identificação das necessidades e informações relevantes para serem transformadas em requisitos
e a estruturação do problema a partir do ponto de vista do stakeholder. A motivação do trabalho vem da
dificuldade no entendimento das necessidades dos stakeholders no desenvolvimento de sistemas, sejam eles
produto, processo ou serviço. O processo proposto se fundamenta nos conceitos da Engenharia de Sistemas e
da Cognição e seus Mapas Cognitivos. O trabalho aporta três principais contribuições, a primeira é a
elicitação exaustiva com o stakeholder até chegar à necessidade raiz, utilizando o processo cognitivo por meio
dos repetidos questionamento até chegar à raiz do assunto. A segunda contribuição é na captura gráfica do
rationale das necessidades mais relevantes. A terceira contribuição é a de ajudar ao stakeholder a entender
sua própria necessidade e/ou problema, também com a ajuda do processo cognitivo utilizado na criação dos
mapas. De esta maneira obtendo como resultado informações relevantes elicitadas junto com seu rationale e o
entendimento do problema. O processo proposto foi aplicado num estudo piloto dentro do Laboratório de
Integração e Testes (LIT) do Instituto Nacional de Pesquisas Espaciais (INPE). O Processo de Análise de
Stakeholders Utilizando Mapas Cognitivos pode ser considerado como uma opção válida na hora de decidir a
estratégia da Análise de Stakeholders; ele facilita a aproximação com o stakeholder e fornece uma ferramenta
iterativa e interativa que incita à reflexão tanto para o stakeholder expressar suas necessidades quanto para
que o engenheiro de sistemas possa gerar questionamentos e ambos construírem conclusões do problema e seu
contexto dando partida à concepção da solução.
12.
GRAU DE SIGILO:
(X ) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO

Tese M - Análise de Stakeholders Mapas Cognitivos 64016

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tese M - Análise de Stakeholders Mapas Cognitivos 64016

Enviado por

Direitos autorais:

Formatos disponíveis

ii

Dados Internacionais de Catalogação-na-Publicação (CIP)

Tese de Mestrado – Engenharia Aeronáutica e Mecânica na Área de Produção – Instituto Tecnológico de

1. Análise de Stakeholders 2. Mapas Cognitivos 3. Engenharia de Requisitos. I. Instituto Tecnológico de

LÓPEZ VILLAFRANCA, Brenda Carolina. Processo de Análise de Stakeholders

NOME DO AUTOR: Brenda Carolina López Villafranca

É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta

Brenda Carolina López Villafranca

PROCESSO DE ANÁLISE DE STAKEHOLDERS

Brenda Carolina López Villafranca

Composição da Banca Examinadora:

Profa. Dra. Ligia Maria Soto Urbina Presidente – ITA

Prof. Dr. Geilson Loureiro Orientador – ITA

Prof. Dr. Luís Gonzaga Trabasso ITA

Dr. Paulo Tadeu de Mello Lourenção Embraer

Dedico este trabajo a la Brenda de ayer que aceptó el desafío

A Christian, mi compañero de vida que siempre creyó

A mis padres que siempre se entregaron junto conmigo

A mis hermanos, que aunque estando lejos,

Agradeço ao Brasil e ao Instituto Tecnológico de Aeronáutica, porque ainda sendo

que foi muito mais do que um grau acadêmico.

Objetivo do trabalho é propor um processo para a Análise de Stakeholders utilizando

mapas cognitivos a fim de auxiliar no processo da elicitação de necessidades raiz. O processo

proposto aborda desde o estudo do contexto até a identificação das necessidades e

informações relevantes para serem transformadas em requisitos e a estruturação do problema

a partir do ponto de vista do stakeholder. A motivação do trabalho vem da dificuldade no

entendimento das necessidades dos stakeholders no desenvolvimento de sistemas, sejam eles

produto, processo ou serviço. O processo proposto se fundamenta nos conceitos da

Engenharia de Sistemas e da Cognição e seus Mapas Cognitivos. O trabalho aporta três

principais contribuições, a primeira é a elicitação exaustiva com o stakeholder até chegar à

chegar à raiz do assunto. A segunda contribuição é na captura gráfica do rationale das

necessidades mais relevantes. A terceira contribuição é a de ajudar ao stakeholder a entender

Nacional de Pesquisas Espaciais (INPE). O Processo de Análise de Stakeholders Utilizando

estratégia da Análise de Stakeholders; ele facilita a aproximação com o stakeholder e fornece

ambos construírem conclusões do problema e seu contexto dando partida à concepção da

Lista de Siglas e Acrônimos

CBERS China-Brazil Earth Resources Satellite

ConOps Concept of Operations

EGSE Electronic Ground Support Equipment

GSE Ground Support Equipment

IDEF0 Integration Definition for Function Modeling

IEEE Institute of Electrical and Electronics Engineers

INCOSE International Council on Systems Engineering

INPE Instituto Nacional de Pesquisas Espaciais

IRA Infra-Red Array

LIT Laboratório de Integração e Testes

LSIS Laboratório de Engenharia Simultânea de Sistemas

MGSE Mechanical Ground Support Equipment

MoE’s Measure of Effectiveness

NASA National Aeronautics and Space Administration

SODA Strategic Options Development and Analysis

TBT Teste de Balanço Térmico

1.1 CONTEXTO E ESCOPO DA TESE .......................................................................................................... 12

1.2 PROBLEMA ................................................................................................................................... 13

1.3 MOTIVAÇÃO ................................................................................................................................. 15

1.4.1 Objetivo Geral.................................................................................................................. 18

1.4.2 Objetivos Específicos ....................................................................................................... 18

1.5 METODOLOGIA ............................................................................................................................. 18

1.6 ESTRUTURA DA TESE....................................................................................................................... 20

2 ENGENHARIA DE SISTEMAS ......................................................................................................22

2.1 PROCESSO DE ENGENHARIA DE SISTEMAS ........................................................................................... 24

3 ENGENHARIA DE REQUISITOS ..................................................................................................27

3.1 REQUISITOS .................................................................................................................................. 27

3.2 RATIONALE DOS REQUISITOS ............................................................................................................ 28