Upload
vothuy
View
222
Download
0
Embed Size (px)
Citation preview
622
MAPEAMENTO COGNITIVO COMO UMA TÉCNICA PARA APOIO À ENGENHARIA DE REQUISITOS.
Raquel Dias Instituto Tecnológico de Aeronáutica ITA
Praça Marechal Eduardo Gomes 50, Vila das Acácias. São José dos Campos, SP, Brasil.
Brenda López Instituto Tecnológico de Aeronáutica ITA
Praça Marechal Eduardo Gomes 50, Vila das Acácias. São José dos Campos, SP, Brasil.
Mischel Carmen Neyra Belderrain Instituto Tecnológico de Aeronáutica ITA
Praça Marechal Eduardo Gomes 50, Vila das Acácias. São José dos Campos, SP, Brasil.
RESUMO Este artigo aborda conceitos de engenharia de requisitos e propõe aplicação de mapas
cognitivos como ferramenta colaborativa e de suporte à identificação dos problemas dos stakeholders, durante o processo de levantamento de requisitos de sistemas, apresentando estudo de caso do cluster aeronáutico de São José dos Campos, São Paulo.
A técnica de mapeamento cognitivo foi criada, a partir de pesquisas em psicologia, para representar pontos de vista dos indivíduos gerando mapas cognitivos, que agregados expressam graficamente o ponto de vista coletivo para tomada de decisão, demonstrando eficiência colaborativa.
Aplicada à engenharia de requisitos revelou potencial para promover a convergência dos diferentes pontos de vista sobre as necessidades reais dos stakeholders, de forma inovativa. Demonstrou eficiência ao aproximar os requisitos declarados no início do processo de desenvolvimento com os implementados ao longo do ciclo de vida do sistema/produto.
Palavras-chave: mapa cognitivo, engenharia de requisitos, tomada de decisão, representação
do conhecimento, ferramenta colaborativa.~
1 Introdução
O ciclo de desenvolvimento de produtos tem como fase principal o levantamento das
necessidades dos stakeholders. É neste momento que são identificados os problemas que
desenvolvedores e os stakeholders precisam resolver, e para isso buscam ferramentas de
apoio para a elicitação do conhecimento. A maioria das dificuldades em todo o processo de
desenvolvimento de produtos está associada ao perfeito entendimento entre os stakeholders
e os desenvolvedores, estes, responsáveis pelo levantamento dos requisitos do futuro
623
produto. É comum a existência de retrabalhos, atrasos de cronograma, custos alterados e
insatisfação, de ambos os lados, ocasionada pela deficiência na fase de levantamento dos
requisitos.
Durante a fase de validação, os desenvolvedores confirmam se os requisitos
especificados correspondem às solicitações dos stakeholders, bem como suas reais
necessidades.
Em geral utilizam-se revisões e checklists como técnicas de apoio ao processo de
validação, junto às partes interessadas, tais como clientes, usuários e engenheiros,
analistas. Os requisitos serão revisados, os problemas identificados e sanados.
Alguns problemas mais comuns são: Kotonya (1998).
falta de conformidade com padrões de qualidade;
requisitos mal formulados, ambíguos, confusos;
erros no modelo de sistema;
conflitos entre requisitos, os quais não foram detectados e tratados na fase de análise.
Na fase de análise o detalhamento permite completo conhecimento dos problemas e
dos requisitos mais importantes, embora haja a possibilidade de mudanças ao longo do
processo de desenvolvimento, exigindo intensa iteração no processo, de forma a impactar o
mínimo possível as atividades das fases posteriores.
Estruturar o ambiente decisório de forma a identificar os problemas que os
desenvolvedores de produtos aeronáuticos enfrentam, durante a fase de levantamento de
requisitos junto aos stakeholders, foi altamente motivador pois vislumbramos a possibilidade
de criar um cenário que permitisse extrair um modelo para minimizar as deficiências que, em
geral, ocorrem nessa fase.
O objetivo deste estudo foi demonstrar a eficiência do uso de mapas cognitivos como
ferramenta de suporte à engenharia de requisitos para a identificação e estruturação dos
problemas associados à fase de levantamentos de requisitos no setor aeronáutico.
2 Engenharia de requisitos.
O objetivo da Engenharia de requisitos é capturar, analisar, validar e refinar requisitos
para o desenvolvimento de um sistema através do uso de ferramentas que auxiliam no
processo de identificação, detalhamento e gestão dos requisitos.
Existem diretrizes para a engenharia de requisitos ditadas, dentre outras, por normas
como a Electronic Industries Alliance (EIA) stander - 632 (America National Standards
Institute ANSI (1998) e Institute Electrical and Electronics Engineers (IEEE ) stander STD
(1220-1998), IEEE (2005).
624
Requisitos podem ser conceituados como atributos de um sistema que permitem
identificar a capacidade e fator de qualidade que revele a utilidade do produto para o cliente
ou usuário, Young (2003). Os requisitos podem ser classificados como:
requisitos de negócios: definem o alinhamento do produto/sistema às metas de negócios
do stakeholder;
requisitos de alto-nível: revelam a visão do stakeholder, e são descritos na sua
linguagem. Permitem a definição do escopo de um sistema, bem como a estimativa de
custos e prazos necessários para o seu desenvolvimento;
requisitos funcionais: definem as funções que o sistema/produto deve atender;
requisitos desempenho: definem o padrão de desempenho exigido pelo cliente;
requisitos de interface: definem o padrão de operacionalidade, e
requisitos de verificação e validação: definem o grau de atendimento às solicitações dos
stakeholders.
A especificação de requisitos é composta pela relação das características que os
stakeholders desejam ver implementadas através do sistema de forma a atender
plenamente suas necessidades para resolução de seus problemas. A especificação é
elaborada usando-se a linguagem dos stakeholders.
É necessário que os requisitos sejam submetidos à análise técnica para que possam
ser traduzidos para linguagem técnica (de baixo nível) expressando o papel de cada
componente do sistema de forma a atender as necessidades especificadas pelos
stakeholders.
O processo de engenharia de requisitos é composto por quatro etapas principais:
levantamento e elicitação dos requisitos, análise e negociação, modelagem, e validação dos
requisitos. Estas etapas se processam de forma iterativa e recursiva devido às mudanças
que, normalmente, ocorrem durante o processo de desenvolvimento do sistema, conforme
pode ser visto no modelo espiral apresentado pela figura 1, a seguir.
625
Fig. 1 - Processo em espiral de Engenharia de Requisitos, Alves (2007)
Os requisitos podem, simplesmente, migrarem da forma que estão para a linguagem
técnica e neste caso recebem a denominação de requisitos transferidos, no caso de
requisitos novos, serão denominados por requisitos derivados.
Os requisitos tratados pela engenharia de requisitos possuem as seguintes
características:
Rastreabilidade: os requisitos de alto e baixo níveis devem estar estreitamente
relacionados, já que são apenas conversões de linguagem. A rastreabilidade permite
que ao se verificar e validar os requisitos de baixo nível seja possível identificar o
atendimento das solicitações do cliente.
Evolução: os requisitos sofrem modificações ao longo do processo de detalhamento, e
por isso muda de status à cada nova modificação tornando-se requisito definido,
aprovado, alocado, projetado, implementado, testado e verificado.
Alocação: os requisitos têm que ser alocados onde são necessários no sistema, como se
fossem componentes físicos.
As diferentes atividades para o cumprimento da fase inicial do ciclo de vida de um
sistema são conhecidas como análises de requisitos. As atividades a serem
desenvolvidas nessa fase, são as seguintes: Kotonya (1998).
I - Identificação e Levantamento de requisitos
Atividade em que são identificados os stakeholders, e os requisitos são extraídos
através de consultas a esses envolvidos, aos documentos, ao domínio do conhecimento,
e aos estudos de mercado; as atividades envolvidas nesta fase incluem:
626
Compreensão do domínio: busca estabelecer processo eficaz de comunicação entre o
desenvolvedor e os stakeholders.
Captura: corresponde à extração dos requisitos pretendidos, através de iteração com os
stakeholders.
Identificação e análise de problemas: descrição conjunta dos problemas e das soluções
propostas.
II - Análise e negociação dos requisitos
Atividade em que os requisitos são detalhados e analisados, podendo ser
recusados ou aceitos. Algumas das atividades envolvidas na análise de requisitos
incluem:
funcionamento pretendido para o sistema.
Resolução de conflitos: é comum a existência de conflitos nos requisitos identificados ao
longo do processo de identificação dos mesmos; tais conflitos devem ser resolvidos o
mais breve possível.
Confirmação: é confirmada com os stakeholders a completude dos requisitos, sua
consistência e validade.
III - Modelagem dos requisitos
A Especificação e Documentação formalizam os requisitos aceitos em um nível de
detalhamento adequado. Em todos os tipos de especificação há dois tipos de requisitos a
considerar:
Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema opere,
de forma completa e consistente para atender aos propósitos para os quais foram
desenvolvidos.
Requisitos não-funcionais: descrevem os aspectos não-funcionais do sistema, como
restrições nas quais o sistema deve operar, ou propriedades emergentes do sistema.
Costumam ser divididos em Requisitos não-funcionais de utilidade, de confiança, de
desempenho, de suporte e de escalabilidade.
A especificação resulta no Documento de Especificação de Requisitos incluindo
uma combinação dos requisitos dos diversos stakeholders. A utilidade desse documento
é diferenciada, conforme cada envolvido no processo Kotonya (1998), Sommerville
(2007).
Clientes: utilizado para confirmar a completude dos requisitos e solicitar modificações de
forma a atender suas necessidades.
627
Gestores: utilizado para orçamentar o sistema e planejar o desenvolvimento.
Engenheiros: utilizado para compreender o sistema que será desenvolvido.
Engenheiros (testes): utilizado para elaborar e aplicar os testes para validação do
atendimento dos requisitos.
Engenheiros (manutenção): utilizado para compreensão do sistema e o interdependência
de suas partes.
IV - Validação dos requisitos
Nesta fase de validação, os requisitos especificados são verificados e confirmados
pelos decisores, de forma a refletirem perfeitamente as solicitações dos stakeholders.
Em geral são feitas várias revisões e checklists que auxiliam a execução do
processo de validação, que envolve todos os stakeholders de forma a identificar os
problemas e as possíveis ambiguidades na descrição dos requisitos.
Finalizada esta fase, é possível admitir-se que há um nivelamento do
conhecimento relacionado aos requisitos de sistema, embora modificações possam ser
exigidas ao longo do processo de desenvolvimento. Alves (2007).
Estas fases não são independentes entre si, pois uma informação obtida numa
delas pode ser utilizada nas demais. A identificação e análise de requisitos é um
processo iterativo que se inicia com a familiarização do domínio do futuro sistema, e
culmina na confirmação dos requisitos, aumentando o grau de compreensão do sistema,
a cada fase do ciclo de desenvolvimento deste.
Uma das atividades mais importantes e complexas que ocorrem no ciclo de
desenvolvimento de sistemas é a gestão dos requisitos. Trata-se de atividade em que os
requisitos são controlados em função das mudanças ambientais. A gestão dos
requisitos tem início na sua especificação formal.
Esse documento precede a definição do escopo e as estimativas de custo e
prazos, por isso qualquer mudança na base dos requisitos causam impactos, e muitas
vezes propiciam situações críticas em todo o projeto.
Os requisitos de um sistema estão em evolução constante, por diversas razões,
como por exemplo, o problema abordado não ter sido completamente definido antes da
produção do documento de requisitos, ou pela alteração dos próprios requisitos no
decorrer do projeto devido às evoluções tecnológicas ou alterações na organização na
qual será utilizado.
A resolução de conflitos entre requisitos busca o equilíbrio no atendimento das
necessidades das diferentes partes interessadas.
628
O planejamento é uma parte importante da gestão de requisitos. Devem estar
definidas desde o início políticas para:
5. gestão de mudanças: o conjunto de procedimentos que permitam avaliar o custo e
impacto das alterações;
6. tratamento dos requisitos: procedimentos para tratamento dos requisitos. Como
mencionado, o processo é iterativo ao longo de todo o ciclo de desenvolvimento
do sistema.
A atividade de validação dos requisitos culmina na elaboração de documento dos
cliente e fornecedores. Este documento norteará todos os esforços das fases seguintes
do ciclo de vida do produto. A especificação dos requisitos deve ser objetiva e clara de
forma a evitar retrabalho, minimizando custo e esforço de implementação.
Em praticamente todos os domínios do conhecimento, a extração das
características ou dos requisitos do sistema tem como principal dificuldade o fator
comunicação.
Roger Pressman ilustra o problema com uma declaração de um cliente a um
analista:
certo de qu
(1995).
3 Mapas cognitivos.
Os mapas cognitivos são expressões gráficas de discursos realizadas por um
indivíduo ou grupos de indivíduos (atores) com o objetivo de demonstrar objetos (o
problema) em contextos de interações particular, segundo Cosset & Audet (1992).
A representação gráfica é o resultado da interpretação mental do(s) ponto(s) de vista
de indivíduo(s) capturada pelo facilitador relativa aos discursos dos atores sobre
determinado problema.
O facilitador deve permanecer o mais neutro possível ao longo de todo o processo
discursivo-reflexivo-recursivo, de forma a não interferir com informações pessoais na
elaboração do mapa cognitivo; porém é, praticamente, impossível a neutralidade total. Isto
porque o facilitador precisa interpretar e construir os eventos baseado nos seus conceitos de
valores e de visão subjetiva.
Na abordagem cognitiva, o problema é identificado, detalhado e analisado através de
um processo de interação entre o facilitador e os stakeholders, em busca de uma definição
precisa, admitindo-se a intersubjetividade do grupo ou do individuo. Desta forma os mapas
629
cognitivos podem ser utilizados para resolução de conflitos de pontos de vista na definição
dos requisitos no processo de desenvolvimento de sistemas.
Os mapas cognitivos demonstram ser bastante úteis tanto como produto quanto como
ferramenta, possuindo caráter dinâmico, admitindo-se alterações e ajustes durante sua
utilização, face as modificações por parte dos decisores diante de problemas complexos.
Os componentes dos mapas cognitivos podem ser de:
Identidade - determinam as chaves do problema (eventos, processos e atores);
categorização definem escalas e perfis revelando os relacionamentos das entidades
envolvidas no problema;
causais ou de argumentação - apresentam alternativas para mudança de estado ou
posição no mapa (linhas de argumentação).
Os mapas cognitivos podem ser:
organizacionais busca-se um mapa coletivo que represente uma ferramenta de suporte
para ações organizacionais;
individuais apresentam pontos de vista individuais, isolados, e são utilizados para a
construção dos mapas coletivos. Cosset & Audet (1992).
3.1 Construção do mapa cognitivo individual
A construção de um mapa cognitivo depende de dois fatores:
abordagem inicial por parte do facilitador demonstrando empatia e
estabelecimento de um processo de negociação.
As entrevistas devem ser espontâneas permitindo ao entrevistado tranquilidade para
expor seu ponto de vista e suas informações sobre o problema. Isto porque a expressão
corporal e reações constituem-se informações relevantes para o entendimento do facilitador
sobre o problema.
O mapa cognitivo é uma hierarquia de conceitos relacionados por ligações entre os
objetivos meios e fins, que representam o sistema de valores do(s) decisor(es) na forma de
objetivos estratégicos (os conceitos superiores na hierarquia).
O processo de extração do conhecimento é cansativo, por esta razão não deve
ultrapassar mais que 90 minutos, por reunião.
O processo de elaboração de mapas é composto por quatro passos conforme
descritos a seguir: adaptação de Eden (1998), Ensslin (1998), Montibeller (1996) , Bana
(1992).
1º Passo: Definição de um rótulo para o problema.
Reuniões entre facilitador e decisor(es) para definição de rótulo para o problema
baseado em questões relevantes levantadas pelo(s) decisor(es).
630
2º Passo: Definição dos elementos primários de avaliação.
Os Elementos Primários de Avaliação (EPAs) representam os objetivos, metas,
valores, ações, alternativas, apreensões dos decisores e são definidos a partir de
entrevistas entre facilitador e decisor(es).
3º Passo: Construção dos conceitos a partir do EPAs.
Os conceitos são transformados em ações e organizados conforme existência de
similaridades, e hierarquizados por constructos subordinados e superiores, Eden (1998).
A estrutura é representada pelos constructos individuais organizados
hierarquicamente. Para garantir a corretude da percepção do facilitador face às
informações do(s) entrevistado(s), utiliza-se a observação do contraste, ou seja, o pólo
oposto psicológico, de forma explícita ou não, para a construção dos mapas.
Em geral, o facilitador adota a primeira descrição anunciada pelo(s) decisor(es),
obtida na primeira percepção que lhe vem à mente, seja esta positiva ou não.
Algumas diretrizes podem servir de orientação ao longo do processo de
construção dos conceitos, constituindo-se em boa estratégia Eden (1998).
Cada conceito deve ser orientado por uma ação, e ser claro e conciso, expresso por
apenas uma frase.
Deve-se utilizar a linguagem do(s) decisor(es), aproveitando-se as palavras e expressões
usadas, de forma a preservar o perfil do(s) decisor(es).
Deve-se identificar os valores, opções, meios e fins.
O decisor deve ser interrompido sempre que o facilitador não conseguir registrar as
percepções, porém deve-se preservar a linha de raciocínio.
Identificar, registrando na parte superior do mapa os conceitos que representam objetivos
estratégicos e/ou as metas mais importantes para o(s) decisor(es), que possam
representar ações estratégicas.
Identificar os conceitos muito explicados e justificados através das ligações com outros
conceitos e aqueles expressos emocionalmente pelo(s) decisor(es).
Evitar palavras como pode, precisa, deve.
A validação das informações contidas no mapa, devem ser realizados em um curto
período de tempo.
4º Passo: Hierarquização dos conceitos e analise do Mapa
A estrutura dos mapas cognitivos é composta por conceitos-fins identificados
-meios
631
ele pode ser alca
O processo prossegue até que o(s) decisor(es) responda(m) que o conceito é
importante por que é importante, caracterizando que se chegou ao nível hierárquico mais
alto do mapa.
Os conceitos relacionados por ligações de casualidade, par-a-par são
representados por setas.
Pode ocorrer situação em que um objetivo fim possa ser explicado por mais de um
objetivo meio, conflitantes. Neste caso Ensslin recomenda a adoção da análise
Multicritério. Ensslin (1998), Jardim (1999).
A análise dos mapas
Identificação dos clusters.
Pode-se definir um cluster como um grafo composto por um conjunto de nós inter-
relacionados. A sua identificação possibilita uma visão macro do mapa, e proporciona
redução da sua complexidade já que ressalta as ligações mais fortes que são as
intracomponentes, pois agrupam os conceitos que apresentam áreas de interesse
específicas baseadas nos conteúdos dos conceitos, e permitem uma análise separada de
cada cluster.
A detecção dos Pontos de Vista Fundamentais é feita através da observação da
topografia do mapa. Observa-se o conjunto de linhas do grafo. Essas linhas formam os
eixos de avaliação do problema Ensslin (1998), Ensslin (1996).
A análise dos ramos do grafo busca estruturar os caminhos que levam ao
conceito-fim do problema.
Esses caminhos, denominados por linha de argumentação, são compostos por
conceitos que sofrem influência e estão em posição hierárquica superior a um conceito-
meio. As linhas de argumentação dos clusters são consideradas linhas de argumentação
internas.
Os ramos do mapa são compostos por linhas de argumentação que representam
similaridade de conteúdo em relação ao ambiente de decisão.
Identificação dos Pontos de Vista Fundamentais.(PVFs)
Os pontos de vista fundamentais (PVFs) são base para ações que culminam na
tomada de decisão já que são oportunidades de escolhas entre alternativas. Os PVFs
632
carregam no seu bojo os valores considerados mais importantes pelo decisor(es) no
ambiente, permitindo antecipar as consequências advindas de tais ações.
A definição dos PVFs é feita a partir do enquadramento do mapa, quando se
determinam para cada ramo:
localização dos conceitos relacionados com o pensamento estratégico do(s) decisor(es).
localização dos conceitos que revelam ações potenciais.
localização dos conceitos que revelam ideias relacionadas com o candidato a PVF do(s)
decisor(es).
À medida que aumenta o grau de controle sobre o ponto de vista do(s) decisor(es)
é importante levar em conta as ações que influenciam tal PVF naquele ramo.
A propriedade essenciabilidade do ponto de vista no ramo configura-se
característica importante, a ser observada, ao longo da análise meios-fins, pois se trata
da necessidade de que o PVF corresponda à consequência dos objetivos estratégicos.
As propriedades controlabilidade e exaustividade dos conceitos devem ser
verificadas na análise dos objetivos fins-meios.
Realizadas as verificações das propriedades mencionadas, é possível estabelecer
critérios para avaliação de desempenho das ações conforme o PVF avaliado.
3.2 Construção do Mapa Cognitivo de Grupo ou Mapa Congregado
Quando o contexto exige mais de um decisor, configura-se a necessidade da
construção de mapa cognitivo coletivo.
O poder de decisão neste caso é compartilhado, porém os interesses podem ser
conflitantes, devido à representatividade de diferentes áreas, bem como diferenças de
perfis, personalidades, valores e etc... Ensslin (1998).
O mapa cognitivo que representa o modelo decisório de um grupo é denominado por
mapa cognitivo congregado, e pode ser abordado de duas maneiras:
Iniciar diretamente com o grupo;
Iniciar com os mapas cognitivos individuais.
Quando o levantamento é incompleto ocorre grande perda de qualidade prejudicando
a análise posterior.
O mapa congregado pode ser elaborado observando-se as seguintes etapas:
agregação dos mapas individuais através da união dos conceitos similares devendo ser
unificados pelos conceitos de sentido mais amplo; Eden (1998).
conexão entre conceitos: conectar os conceitos por ligações de influência.
633
O mapa cognitivo do grupo é obtido através da negociação entre o facilitador e os
decisores.
Uma vez elaborado o mapa agregado, com a evidência da contribuição de cada
decisor individual, este deve ser apresentado ao grupo que passará, então, a negociar
inclusão ou exclusão de conceitos, bem como suas respectivas ligações de influências para
decisores, gerando uma estrutura cognitiva coletiva denominada por mapa cognitivo
congregado.
A análise desses elementos pode levar ao estabelecimento de ações que convirjam
para a resolução dos problemas melhorando o desempenho dos processos de
desenvolvimento dos produtos/sistemas.
4 Aplicação prática A engenharia de requisitos depende muito da interação entre os stakeholders para
minimizar qualquer problema na definição de requisitos, que é a base para execução de
todo o ciclo de vida do sistema. O maior desafio dos profissionais envolvidos com o
desenvolvimento de produtos é elicitar o conhecimento de forma a entender, plenamente,
as necessidades e desejos dos stakeholders, traduzindo-as sob a forma de requisitos.
Aos requisitos estão vinculados os principais problemas que ocorrem durante o ciclo
de desenvolvimento de produtos como por exemplo, requisitos que não correspondem às
reais necessidades dos clientes, requisitos incompletos e mudanças nos requisitos já
definidos são problemas que propiciam retrabalhos, insatisfações e oneram os projetos.
Em geral, os requisitos se alteram durante o desenvolvimento de um sistema, e por
esta razão há que se estabelecer processos de engenharia de requisitos bem definidos,
definindo padrões, e dominando, conceitualmente, o problema a ser analisado e
solucionado.
Foi com a intenção de melhorar o processo de levantamento de requisitos que
realizamos a experiência de aplicar mapas cognitivos para identificar os pontos de gargalos
e as principais dificuldades enfrentadas pelos stakeholders durante a fase de elicitação dos
requisitos.
4.1 O método utilizado
Para a elaboração e análise dos mapas seguimos as teorias e recomendações
descritas na literatura publicada pelos autores Ensslin e Montibeller.
Foi utilizada a abordagem individual, com a construção do mapa cognitivo através de
entrevistas com cada decisor.
634
As entrevistas foram realizadas em ambiente neutro, tanto aos decisores, como ao
facilitador, com duração entre 60 e 90 minutos. Além das entrevistas, como informações
complementares, foi solicitado a um fornecedor a elaboração de um texto com descrição das
principais dificuldades enfrentadas por ele na qualidade de fornecedor de produtos
aeroespaciais, em ambiente clusterizado como se configura a cidade de São José dos
Campos.
À todos decisores foi solicitado que estabelecessem rótulo(s) para o(s) problema (s)
relevantes, com liberdade total de expressão.
As entrevistas aconteceram em clima de espontaneidade, colaboração e confiança de
todos os envolvidos.
A hipótese defendida de que os mapas cognitivos se prestam à melhoria do processo
de levantamento de requisitos, na identificação dos problemas impactantes, bem como a
compreensão da sistemática de elaboração do mapa, foi confirmada à medida em que foi
possível identificar e estruturar as dificuldades detectadas ao longo do processo de
engenharia de requisitos.
Os facilitadores, levando em conta os aspectos e o ambiente em que o processo
cognitivo ocorreu, concluíram que:
a liberdade de expressão e a informalidade contribuíram, sobremaneira, para o
desenvolvimento do trabalho de forma acelerada;
durante as entrevistas iniciais foi preciso redirecionar o foco para manter a linha de
raciocínio voltada para as questões levantadas pelos decisores.
4.2 Ferramenta utilizada para elaboração dos mapas. Marinho (2008)
Foi utilizado o software O IHMC CmapTools, um organizador gráfico, como
ferramenta, de apoio, para criar, editar, compartilhar, navegar e comentar mapas
conceituais.
Trata-se de um software para autoria de Mapas Conceituais desenvolvido pelo
Institute for Human Machine Cognition da University of West Florida. É uma ferramenta
colaborativa que permite interação em rede facilitando o processo de feitura dos mapas,
principalmente quando há mais de um facilitador envolvido, como foi o caso deste estudo.
Apresenta flexibilidade permitindo que módulos sejam instalados à medida em que
suas funcionalidades sejam requeridas, ao longo da feitura dos mapas.
Permite exportação dos mapas criados em formato XML/XTM, permitindo o uso dos
mapas em outros ambientes.
Disponibiliza recursos para formatação dos Mapas, permitindo que estes sejam
utilizados como imagens, vídeos, textos e até mesmo outros Mapas para detalhamento do
conhecimento.
635
4.3 Construção do modelo
Apresentamos, a seguir, como foi elaborado o modelo para estruturar e apoiar a
identificação das principais dificuldades no processo de levantamento de requisitos para
desenvolvimento de sistemas no setor aeroespacial de são José dos Campos. Os dois
clientes escolhidos demonstraram experiência e conhecimento no desenvolvimento de
foguetes e de aeronaves.
Um dos clientes, por possuir experiência como fornecedor, foi entrevistado também na
condição de fornecedor. O outro fornecedor atua no seguimento de desenvolvimento de
computador aeronáutico.
As influências externas são representadas pelo mercado profissional e concorrência
com outras empresas do ramo.
Os decisores revelaram heterogeneidade em termos de visão, métodos de atuação e
valores.
Foram construídos quatro mapas cognitivos individuais (Anexo I) como ferramentas
básicas de apoio à estruturação e identificação dos principais problemas que impactam o
processo de levantamento de requisitos.
4.3.1 Contexto decisório
Trata-se do ambiente de desenvolvimento de produtos aeroespaciais no cluster
aeronáutico em São José dos Campos, SP, durante a fase de levantamento de requisitos
junto aos stakeholders.
4.3.2 Estruturação do modelo
Para elaborar o modelo foram realizadas reuniões individuais com os dois clientes e
dois fornecedores.
Cada decisor expôs os problemas que vivencia no seu dia-a-dia com a engenharia de
requisitos.
A vantagem das entrevistas terem sido individuais, foi que o processo de
levantamento foi puro, ou seja, os decisores não foram influenciados uns pelas ideias dos
outros.
Os quatro decisores entrevistados falaram sobre seus valores, experiências e embora
a visão de cada um sobre aspectos relevantes da engenharia de requisitos foram
diferenciadas, todos convergiram a um objetivo principal que é desenvolver o produto para
satisfazer as necessidades dos stakeholders.
Apesar dos quatro decisores terem expressado o mesmo objetivo, o mapa foi
enriquecido devido aos conceitos diferentes já que foram abordados vários problemas
críticos na engenharia de requisitos o que se observa na heterogeneidade dos clusters.
636
O resultado foi a obtenção de uma visão mais abrangente dos problemas na área. Isto
pode ser constatado quando observamos a quantidade de conceitos que foram unidos com
outros similares, e que em um total de 81 conceitos, apenas 3 foram congregados
(identificados com caixas em gris no mapa congregado), além dos principais objetivos de
produzir o sistema e satisfazer as necessidades dos stakeholders. A grande maioria dos
conceitos foi relacionada por ligações de influências.
Para realizar os clusters, optou-se pela inclusão do objetivo final em cada cluster,
visando proceder a análise de cada cluster como um mapa individual.
1º Passo: Definição de um rótulo para o problema.
Na primeira reunião foi ainda solicitado aos decisores que informassem um rótulo para
definir os objetivos principais. Cabe observar que um dos fornecedores disponibilizou as
informações através de um texto, já que não dispunha de horário para participação nas
reuniões.
Os rótulos escolhidos pelos clientes foram:
Gerenciar o desdobramento dos requisitos desde o início do problema.
Satisfazer as necessidades do cliente.
Com relação aos desenvolvedores o rótulo escolhido foi:
Garantir a qualidade dos requisitos
2º Passo: Definição dos elementos primários de avaliação.
Ao final da primeira reunião foi solicitado a cada decisor que refletisse sobre os
aspectos que consideravam importantes quando pensavam nos problemas enfrentados
com engenharia de requisitos, permitindo a elaboração da lista de elementos primários de
avaliação (EPAs), resultando nas EPAs, mostrados na Tabela 1:
637
Tabela 1 Lista de Elementos Primários de Avaliação (EPAs).
Decisor Elemento Primário de Avaliação (EPA)
Cliente 1: foguete 1) Diferentes processos de engenharia de requisitos podem ser
um problema se não for bem gerenciado.
2) Questões de Comunicação.
3) Mudanças gestão/impacto das mudanças.
4) Sistema para gerenciamento dos requisitos.
Cliente 2: Aeronaves 5) Nem sempre a empresa captura a vontade do cliente.
6) Dinâmica do processo: cliente quer algo hoje e amanhã quer
outra coisa (mudanças no pedido).
7) Fator cultural.
8) Requisitos deficientes, com erros.
Fornecedor 1:
Aeronaves
9) Má qualidade dos requisitos.
10) Não levantamento dos requisitos.
11) Erros na comunicação.
Fornecedor 2:
Computador
aeronáutico
12) Treinamento.
13) Aprimoramento dos processos de engenharia de
requisitos e a integração com outros processos da empresa.
14) Escolha da ferramenta certa para o gerenciamento e
gestão de requisitos.
15) Base de requisitos estáveis.
3º Passo: Construção dos conceitos a partir do EPAs.
Ainda nesta primeira reunião foram elaborados um conceito inicial para cada EPA
indicando ação sobre cada aspecto que os decisores julgavam importantes para analisar
no contexto decisório considerado.
4º Passo: Hierarquização dos conceitos e análise dos mapas
Os facilitadores realizaram a primeira versão dos mapas cognitivos individuais,
com base nas informações colhidas na reunião. Foram, então, construídos quatro mapas,
sendo dois dos clientes e dois dos fornecedores.
Durante a reunião cada decisor foi questionado sobre o porquê da importância e
como se alcançar as ações expressadas pelos conceitos informados possibilitando a
obtenção de sequenciamento das ações meios-fins e as relações de influência
formalizando a topografia dos mapas, e corrigindo possíveis ambiguidades.
É importante notar que se dois ou mais conceitos estiverem posicionados em
mesma linha horizontal não significa que estarão no mesmo nível hierárquico.
638
Desta forma, a partir dos conceitos iniciais foram elaborados os conceitos meios e
fins resultando em 87 conceitos conforme mostrado na Tabela 2.
Tabela 2 Conceitos elaborados a partir dos conceitos iniciais.
Decisor Conceitos elaborados
Cliente 1: Foguete 23 conceitos
Cliente 2: Aeronaves 21 conceitos
Fornecedor 1: Aeronaves 18 conceitos
Fornecedor2 :
Computador aeronáutico
25 conceitos
TOTAL 87 conceitos.
Os mapas foram enviados a cada decisor pra confirmarem se a orientação das
ações estava de acordo com seus pontos de vista.
Os mapas foram novamente encaminhados aos decisores para validação e
rearranjo possibilitando identificação dos clusters.
Mapas Cognitivos do Grupo ou Mapa Agregado.
Uma vez elaborados e validados os mapas individuais, procederam-se ao
processo de agregação dos conceitos na tentativa de representar o que o grupo de
decisores considerou importante observar durante o processo de análise das dificuldades
enfrentadas pela engenharia de requisitos para o desenvolvimento de sistemas
complexos. Os facilitadores,
seja, grupos de conceitos que tratam do mesmo aspecto e apresentam forte relação de
influência.
Os mapas individuais foram agregados formando o mapa agregado do grupo, e
novamente enviados aos decisores Montibeller (1996).
Os decisores tiveram a liberdade de realizar qualquer modificação nos conceitos e
nas suas relações de influência. Os facilitadores analisaram as modificações inseridas
pelo grupo e realizaram as alterações enviando novamente o mapa agregado para
validação final do grupo.
A análise dos mapas - Identificação dos clusters
Com o mapa agregado validado, procederam-se à sua análise, inicialmente,
identificando-se os clusters, ou áreas estratégicas de interesse dos decisores para obter
o mapa congregado. Assim os conceitos cujo conteúdo apresentaram similaridade foram
agrupados formando os clusters.
639
Observa-se, na tabela 3, que ocorreram casos de conceitos pertencerem a mais
de um cluster, Cunha (1999).
Tabela 3 Identificação de clusters existentes
no mapas individuais. MAPA Clusters
Cliente 1 Necessidades
Mudanças
Cliente 2 Qualidade
Comunicação
Fornece
dor 1
Mudanças
Conhecimento
Processos
Ferramentas
Fornece
dor 2
Necessidades
Ferramentas
Gestão
A tabela 4 auxiliou no processo de identificação dos clusters em comuns de cada
mapa, resultando na detecção de oito clusters.
Tabela 4 Identificação o de clusters comuns existentes nos mapas. Cluster Cliente 1 Cliente 2 Fornecedor 1 Fornecedor 2
Necessidades X X
Mudanças X X
Qualidade X
Comunicação X
Conhecimento X
Processos X
Ferramentas X X
Gestão X
O resultado dessa análise é mostrado, através dos mapas cognitivos mostrados pelas
figuras 2 e 3 , apresentadas , a seguir.
640
Fig
2 -
Map
a co
gniti
vo c
ongr
egad
o
641
Fig
3
- Map
a co
gniti
vo c
ongr
egad
o co
m a
def
iniç
ão d
os c
lust
ers
642
Linhas de Argumentação do Mapa Cognitivo Congregado
As linhas foram identificadas através da composição dos conceitos respeitando-
se a organização do mapa devido às influências e hierarquias, e tomando como ponto de
-os até
os co
A tabela 5 mostra as linhas de argumentação detectadas na topologia do mapa
congregado.
Tabela 5 Linhas de Argumentação.
Cluster Linhas de argumentação
Sequência de conceitos
Gestão A1 C81 - C80 - C79 - C78 - C38 - C37 Gestão A2 C81 - C80 - C79 - C77 - C70 - C69 - C38 - C37 Gestão A3 C81 - C80 - C79 - C77 - C72 - C71 - C38 - C37 Gestão A4 C76 - C74 - C73 - C72 - C71 - C38 - C37 Gestão A5 C75 - C73 - C72 - C71 - C38 - C37 Treinamento A6 C63 - C62 - C58 - C77 - C70 - C69 - C38 - C37 Treinamento A7 C63 - C62 - C59 - C57 - C38 - C37 Treinamento A8 C63 - C62 - C59 - C56 - C38 - C37 Treinamento A9 C63 - C62 - C61 - C60 - C55 - C38 - C37 Treinamento A10 C63 - C62 - [C58] - C77 - C70 - C69 - C38 - C37 Treinamento A11 C63 - C62 - [C58] - C77 - C72 - C71 - C38 - C37 Ferramentas A12 C53 - C51 - C49 - C38 - C37 Ferramentas A13 C53 - C51 - C50 - C38 - C37 Ferramentas A14 C53 - C52 - C50 - C38 - C37 Ferramentas A15 C53 - [C54] - C68 - C65 - C64 - C38 - C37 Ferramentas A16 C53 - [C54] - C68 - C66 - C64 - C38 - C37 Ferramentas A17 C53 - [C54] - C68 - C67 - C64 - C38 - C37 Processos A18 C68 - C65 - C64 - C38 - C37 Processos A19 C68 - C66 - C64 - C38 - C37 Processos A20 C68 - C67 - C64 - C38 - C37
Necessidades A21 C32 - C27 - C25 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A22 C31 - C27 - C25 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A23 C30 - C27 - C25 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A24 C29 - C27 - C25 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A25 C28 - C27 - C25 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A26 C31 - C27 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A27 C30 - C27 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A28 C29 - C27 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A29 C28 - C27 - C26 - C24 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A30 C32 - C27 - C26 - C24 - C22 - C21 - C20 - C19 -
643
C38 - C37 Necessidades A31 C23 - C22 - C21 - C20 - C19 - C38 - C37 Necessidades A32 C33 - C22 - C21 - C20 - C19 - C38 - C37
Necessidades A33 C36 - C35 - C34 - C22 - C21 - C20 - C19 - C38 - C37
Qualidade A34 C9 - C8 - C1 - C38 - C37 Qualidade A35 C10 - C8 - C1 - C38 - C37 Qualidade A36 C11 - C8 - C1 - C38 - C37 Qualidade A37 C12 - C8 - C1 - C38 - C37 Qualidade A38 C13 - C15 - C14 - C1 - C38 - C37 Qualidade A39 C16 - C15 - C14 - C1 - C38 - C37 Qualidade A40 C17 - C15 - C14 - C1 - C38 - C37 Qualidade A41 C18 - C15 - C14 - C1 - C38 - C37 Comunicação A42 C2 - C44 - C1 - C38 - C37 Comunicação A43 C3 - C44 - C1 - C38 - C37 Comunicação A44 C4 - C44 - C1 - C38 - C37 Comunicação A45 C5 - C44 - C1 - C38 - C37 Comunicação A46 C6 - C44 - C1 - C38 - C37 Comunicação A47 C7 - C44 - C1 - C38 - C37 Mudanças A48 C48 - C45 - C43 - C41 - C40 - C39 - C38 - C37 Mudanças A49 C46 - C43 - C41 - C40 - C39 - C38 - C37 Mudanças A50 C47 - C43 - C41 - C40 - C39 - C38 - C37 Mudanças A51 C42 - C40 - C39 - C38 - C37 [Cx]: Ligação a outro cluster
Ramos do Mapa Cognitivo.
Baseado nas linhas de argumentação buscamos detectar os ramos do mapa, ou
seja, o conjunto de linhas de argumentação que congregam preocupações similares no
contexto.
644
A tabela 6 mostra os ramos detectados em nossa análise.
Tabela 6 Ramos do Mapa Cognitivo Congregado.
Cluster Ramos Linhas de Argumentação que compõem o ramo
Gestão B1 A1, A2, A3
Gestão B2 A4, A5
treinamento B3 A6, A7, A8, A9, A10, A11
Ferramentas B4 A12, A13, A14, A15, A16, A17
Processos B5 A18, A19, A20
Necessidades B6 A21, A22, A23, A24, A25, A26, A27, A28, A29, A30
Necessidades B7 A31, A32
Necessidades B8 A33
Qualidade B9 A34, A35, A36, A37
Qualidade B10 A38, A39, A40, A41
Comunicação B11 A42, A43, A44, A45, A46, A47
Mudanças B12 A48, A49, A50, A52
Fig. 3 Mapa congregado exibindo clusters e Ramos.
Árvore dos Pontos de Vista Fundamentais
Para a identificação e análise dos Pontos de Vista Fundamentais (PVFs),
Como mencionamos, anteriormente, o mapa cognitivo representa uma hierarquia
de conceitos relacionados por ligações de influência entre meios e fins. Montibeller
(2000).
Os clusters são aspectos essenciais e desejáveis de serem levados em
consideração durante a avaliação de ações eixos da avaliação do problema.
Isto posto, foram identificados os candidatos aos Pontos de Vista Fundamentais
Montibeller (1996), Lima (1997) e Ensslin (1998).
645
A transição dos mapas para a elaboração da árvore de Pontos de Vista
Fundamentais foi realizada sem a presença dos decisores, conforme orientação de
Montibeller. Belton apud Montibeller (1996 ), Belton (1997).
O método adotado foi o descrito por Ensslin. Os ramos do mapa foram percorridos
em busca da identificação dos pontos de vista, no sentido meios-fins, observando-se o
grau de essenciabilidade do ponto de vista expresso pelo decisor no ramo analisado, e
no sentido fins-meios, o grau de controlabilidade dos conceitos que compõem os ramos.
Desta forma foram identificados os elementos para a composição da árvore de pontos de
vista fundamentais conforme apresentada, a seguir: Ensslin (2001).
646
Fig
4 Á
rvor
e de
Pon
tos
de v
ista
fund
amen
tais
.
647
Por último o mapa congregado e a árvore dos candidatos à pontos vista
fundamentais foi enviada aos decisores para análise conjunta com os facilitadores
sobre as ações estratégicas que poderão reduzir dificuldades no processo de
engenharia de requisitos para desenvolvimento de sistemas complexos.
Atendimento às propriedades dos Pontos de Vista Fundamentais (PVFs)
Compreensibilidade: Os pontos de vista fundamentais foram concebidos de forma
que todos os envolvidos na construção do modelo demonstraram compreensão.
Consensualidade: Os PVFs representam o consenso do grupo de decisores.
Aceitabilidade: os PVFs foram aceitos por todos que fizeram parte do processo
decisório;
Exaustividade: não existem ações pontuadas pelos decisores da mesma forma.
Coesividade: existe compatibilidade entre o papel que cada PVF em relação às
preferências dos decisores em torno dos objetivos
Não-redundância: Os PVFs prestam-se à avaliação de aspectos diferentes.
5 Resultados.
O resultado deste trabalho consistiu na elaboração de quatro mapas cognitivos
individuais, e um congregado. (Anexo1) que possibilitaram a identificação das
dificuldades enfrentadas ao longo do processo de levantamento de requisitos para
construção de sistemas complexos, neste caso, direcionados para o desenvolvimento
de produtos aeroespaciais em São José dos Campos, SP.
Os mapas revelaram oito áreas de interesse (clusters) sobre as quais convergem
a maioria das dificuldades detectadas.
A Tabela 7 mostra as ações estratégicas, reveladas pelo mapa, para análise
posterior de ações que poderão impactar as áreas de interesse .
648
Tabela 7 Áreas de impacto e ações estratégicas para cada área.
Área de Impacto Ações estratégicas.
1) Gestão 1) tomar decisão se corta ou não um requisito.
2) Manter o cronograma.
3) evitar gerar custo adicional.
2) Conhecimento 1) Investir em treinamento.
3) Ferramentas 1) escolher ferramenta que auxilie na implementação dos processos de
Engenharia de Requisitos.
2) escolher ferramenta que seja integrada a outras ferramentas da empresa.
4) Processos 1) Diminuir mudanças nos processos de Engenharia de Requisitos.
2) Aprimorar os processos de Engenharia de Requisitos.
5) Necessidades 1) Dar opções de solução ao cliente.
2) minimizar a subjetividade dos conceitos.
6) Qualidade 1) Medir as características dos requisitos.
7) Mudanças 2) Ter agilidade no desenvolvimento
8) Comunicação 3) Informar as revisões dos requisitos.
6 Conclusão
Os objetivos pretendidos deste trabalho foram alcançados de forma satisfatória,
criando oportunidade para o estabelecimento de ações que minimizem os problemas
detectados e fontes de conflitos entre fornecedores e clientes de sistemas complexos,
específicos do domínio aeronáutico.
O mapa cognitivo revelou-se uma ferramenta eficiente para a captura de
percepções individuais subjetivas já que considera o perfil de cada envolvido como
substrato de suas experiências, formação de valores, e poder de decisão no domínio
estudado.
De acordo com os desenvolvedores e clientes pesquisados neste estudo, a
atividade de validação foi considerada a mais importante, e os problemas de
comunicação foram considerados como a fonte principal de conflitos e dificuldades em
todo o processo de desenvolvimento, por vezes provocando mudanças tão
expressivas que culminam na especificação de um novo produto.
Este estudo levantou as principais dificuldades enfrentados por desenvolvedoras
de produtos aeroespaciais, considerados complexos, durante o processo de
engenharia de requisitos. Os principais resultados do estudo incluem os aspectos
descritos, a seguir:
7. Comprometimento do cronograma e atendimento aos requisitos dos
clientes.
649
8. Para os entrevistados os problemas elencados tem como fator gerador a
falta de conhecimento de todo o ciclo de desenvolvimento por parte dos
desenvolvedores, e falta de clareza das solicitações do clientes e,
principalmente, comunicação deficiente dificultando a interação
desenvolvedor-cliente.
Além de instrumento eficiente para a negociação, o processo de
desenvolvimento dos mapas cognitivos permitiram a participação de um ou mais
decisores promovendo aprendizagem a todos os envolvidos face à indução à reflexão
e a natureza recursiva que dominam todo o processo, além de estabelecer um cenário
rico para decisões racionais e confiáveis considerando que é específico para o
contexto analisado e suas particularidades..
Este cenário é relevante quando tratamos de desenvolvimento de sistemas
complexos em ambiente competitivo, heterogêneo, e com a presença de interesses
conflitantes, bem como visões diferenciadas do processo de tomada de decisão e dos
impactos propiciados pelo levantamento de requisitos de forma deficiente.
O estudo de caso do trabalho configurou-se na estruturação do ambiente para
identificação dos problemas que impactam o processo de desenvolvimento de
sistemas complexos. Construiu-se o mapa cognitivo, que demonstrou todos os
conceitos e suas ligações, que expressaram os sentimentos e as visões dos
decisores, matéria prima para a construção da árvore dos pontos de vista
fundamentais permitindo a identificação dos problemas.
6.1 Recomendações
Cabe ressaltar que os resultados apresentados correspondem a um passo inicial
para a estruturação dos problemas detectados, carecendo de continuidade, com
agregação de maior número de fornecedores e clientes, com vista à tentativa de
generalização dos pontos de gargalos no processo de levantamento de requisitos, à
luz da Engenharia de Requisitos.
Recomendamos a partir dos mapas elaborados, a estruturação de cada
problema detectado e o uso de ferramenta de decisão multicritério para a escolha das
alternativas mais adequadas para introdução de melhorias nos processos de
levantamento de requisitos e de relacionamento entre cliente e fornecedor, gerando
base para tomada de decisões ao longo do ciclo de desenvolvimento dos sistemas
complexos.
650
Agradecimentos
Agradecemos aos decisores Marina Mendonça Natalino Zenun e Francisco C.
De Amorim Terceiro e aos demais decisores que participantes desta pesquisa, e aos
colegas Tiago José Menezes Gonçalves (mestrando) e Amanda Cecília Simões da
Silva (doutoranda) pelos relatos de experiência com mapas cognitivos, e fornecimento
de literatura sobre o assunto tratado. Todas as contribuições foram essenciais para
que chegássemos ao termo deste trabalho.
7 Referências Bibliográficas.
ALVES, Carina F Uma Experiência de Engenharia de Requisitos em Empresas de Software. UFPe, Publicações CEUR . Vol 488.2007
ANSI/EIA 632, Processes for Engineering a System, Electronic Industries Alliance, 1999.
Tese de Doutorado. Universidade Técnica de Lisboa. Instituto Superior Técnico.1992
BANA e COSTA, C.A. (1995). Processo de Apoio à Decisão: Problemáticas, Actores e Acções. Apostila de Metodologias Multicritérios de Apoio à Decisão do curso de Mestrado da Engenharia de Produção e Sistemas - EPS Universidade Federal de Santa Catarina - UFSC.
BELTON, V. ; ACKERMANN, F.; SHEPHERO, I. Integrated support from problem solving through to alternative e valuation using Cope and Visa. Journal of Multi-Criteria Decision Analysis, volume 6, 1997.
BELTON, V.; MONTIBELLER, G.;ACKERMANN, F.; ENSSLIN, L. Reasoning maps for decision aid: an integrated approach for problem-structuring and multi-criteria evaluation. Journal of the Operational Research Society. Jan. 2007.
COSSETTE, P., AUDET, M. Mapping of an Idiosyncratic Schema. Journal of Management Studies. 1992. v. 29, n. 3, pp. 325-348.
CUNHA, A.C. Um modelo de avaliação para organizar e gerar aperfeiçoamento de vendas em uma empresa. Dissertação apresentada ao Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina para obtenção do grau de Mestre em Engenharia, 1999.
EDEN C., Ackermann, F. Making Strategy. London, 1998. Sage publications Ltda.
ENSSLIN, L., MONTIBELLER NETO, G. ZANELLA, I., J., NORONHA, S., M., D. Metodologias Multicritério em Apoio à Decisão. Santa Catarina, 1998. LabMCDA. Universidade Federal de Santa Catarina.
ENSSLIN, L., MONTIBELLER NETO, I., J., NORONHA, S., M., D. Apoio à Decisão: Metodologia para estruturação de problemas e avaliação multicritérios de alternativas. Florianopolis: Insular, 2001.
IEE Norma IEEE std 1220:2005 - IEEE Standard for Application and Management of the Systems Engineering Process.
651
JARDIM, S. B. Aplicabilidade de algumas técnicas de análise multiobjetivo ao contexto decisório dos comitês de bacia hidrográfica. Porto Alegre, 1999. Dissertação (mestrado) Instituto de Pesquisas Hidráulicas/Universidade Federal do Rio Grande do Sul.
KOTONYA, Gerald; Sommerville, Ian. Requirements engineering processes and techniques. Chichester : J. Wiley, 1998
MARINHO, Simão P. P. IHCM CMAP TOOLS - Manual de uso rápido. UFMG. 1ª ed. 2008
MONTIBELLER NETO, G. Mapas Cognitivos: Uma Ferramenta de Apoio à Estruturação de Problemas - Dissertação de Mestrado, Departamento de Engenharia de Produção e Sistemas, UFSC, 1996.
MONTIBELLER, G.; BELTON, V. Qualitative operators for reasoning maps: evaluating multi-criteria options with networks of reasons. European Journal of Operational Research. V. In Press, Corrected Proof, 2007.
PRESSMAN Roger S.; Software Engineering; 5th Edition, Mac Graw Hill, 2002.
SOMMERVILLE .Software Engineering Ian Sommerville. Addison Wesley. 2007.
YOUNG, Ralph R. The Requirements Engineering Handbook; Artech House. USA, 2004.
Bibliografia complementar
Baseada numa Arquitetura dv.18, n. 1, 2008.
CHENG, L. C.; Melo Filho, L.D. R. QFD: Desdobramento da Função Qualidade na Gestão de Desenvolvimento de Produtos. Ed. Blucher, São Paulo, SP, 2007.
DECISION EXPLORER. Reference Manual. Banxia Software. Glasgow. UK. Endereço: http://www.banxia.co.uk/banxia, 2001
Rio de Janeiro: PUC-Rio, 2006.
GONZÁIn: Workshop em Engenharia de
Requisitos (WER07). Anais. Toronto, mai. 2007.
IEEE Swebok, Guide to the Software Engineering Body of Knowledge, California, 2004.
KULAK, D. and Guiney, E., Use Cases Requirements in Context, Addison -Wesley, 2000.
652
MARTINS, L.E.G. Uma metodologia de Elicitação de Requisitos de Software Baseada na Teoria da Atividade. 2001. 182f. Tese Doutorado Universidade Estadual de Campinas, Faculdade Elétrica e de Computação. Campinas, SP. 2001.
SOARES Introdução, Identificação e Análise em Engenharia de Requisitos. Antonio Lucas Soares.2005.