Rigourous Problem Analysis and Formulation with Coloured Cognitive Maps
John R. Venable
School of Information Systems, Curtin University of Technolgoy, Perth, Australia
Keywords: Problem Formulation, Requirements Analysis, Information Systems Development, Cognitive Mapping,
Coloured Cognitive Mapping.
Abstract: This position paper argues that methodical and rigourous attention to problem formulation should be an
essential part of requirements analysis and proposes a method for modelling problems and potential
solutions. Currently, most IS Development Methodologies ignore the issue of problem formulation.
Furthermore, in practice, most IS development projects ignore or pay little attention to this issue. In this
paper we argue that the resulting lack of proper problem analysis and formulation is a major cause of IS
failures. In place of this lack of attention, this paper proposes and reports on research in progress on the
development and evaluation of a new technique, Coloured Cognitive Maps (CCM), for use in problem
formulation at the early stages of Information Systems Development. The notation of coloured cognitive
maps and a procedure to use them for problem analysis and solution derivation are briefly described. Initial
anecdotal results in employing CCM by students and practitioners are briefly described.
The IS/IT field is the poor track record of system
development and introduction. Information Systems
Development (ISD) projects commonly (1) are late
and over budget, (2) deliver a system that doesn’t
meet requirements, cannot be used as intended, is
hard to use, or is completely unusable, or (3) fail to
deliver a system altogether (project never
completed). High failure rates in ISD are widely
Methodological solutions proposed for these
problems address various perceived causes. Design
and software engineering methodologies address
technical difficulties in making complex systems
work properly to insure that requirements are
properly translated into designs and
implementations. Requirements analysis
methodologies precisely state requirements and
ensure that they correct and consistent. Project
management methodologies aim to overcome poor
estimation of time and costs, scope creep, and poor
project planning and control. To varying degrees, all
of the above try to address changing needs during
However, we assert that many failures are due to
poor practices at the very front end of development,
when stakeholders are (or should be) grappling with
a problematic situation in order to decide what
problems are to be solved and what sort of IS would
contribute to that solution. This lack of attention to
problems and the organisational situation leads to
poor understanding of the problem(s), often to
solving the wrong problem(s) (also known as an
error of the third kind, Mitroff and ), and commonly
to poor acceptance and adoption of system(s), a
major form of IS failure. None of the above types of
methodologies address this issue.
It is the contention of this position paper that
absent or cursory problem analysis and formulation
is a key weakness in system development. Problems
are sometimes completely unstated. Often, they are
only weakly examined. Typically, problem diagnosis
and formulation are poorly performed, if at all.
Commonly, solutions are proposed in the form of a
system request without any examination of the
problem situation whatsoever. Furthermore,
agreement about problems may not be sought.
Proposed solutions are then accepted for IS
Development without consideration of the proposed
systems’ effectiveness in solving the unstated
R. Venable J. (2008).
IMPROVING REQUIREMENTS ANALYSIS - Rigourous Problem Analysis and Formulation with Coloured Cognitive Maps.
In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 466-470
DOI: 10.5220/0001727204660470
problem(s) or addressing the needs of various
different stakeholders.
Instead, this paper proposes that methodical and
rigourous attention needs to be paid to developing
problem formulations that are clear, correct,
properly scoped and prioritised among other
problems, and agreed by relevant stakeholders.
Further, ISD processes should then incorporate
effective transition from problem definition to
solution generation, choice, and implementation (via
detailed IS development and installation). While
some important work has been done in this area
(e.g., Soft Systems Methodology, Checkland, 1981,
Checkland and Scholes, 1990 and Multiview, Wood-
Harper et al., 1985, Avison & Wood-Harper 1990 –
see below), it is still an area of perennial weakness
and in need of much more attention.
Various methods and techniques have been proposed
that address problem formulation.
An important, relevant method is Soft Systems
Methodology (SSM) (Checkland 1981, Checkland &
Scholes 1990, Checkland and Holwell, 1998). SSM
is a general problem solving method especially for
use where there are differences among stakeholders
about their understandings and goals. It can be
applied to the formulation and agreement about any
kind of problem to be solved and the design of any
kind of solution. It is not specifically designed to be
applied to Information Systems solutions, although
Checkland and Holwell (1998) do so.
SSM incorporates a number of useful techniques,
including Rich Pictures, CATWOE Criteria, Root
Definitions, and Conceptual Models. Rich Pictures
are especially used to model and explore a
problematic situation.
The Multiview methodology (Wood-Harper et al.
1985, Avison & Wood-Harper 1990) incorporates
Rich Pictures. Multiview can be described as an
eclectic method, which draws on a number of other
methods and their techniques and builds those into a
coherent, overall approach to systems development.
Multiview incorporates techniques from SSM,
Human-Computer Interface (HCI) design methods,
and Structured Analysis and Design methods, among
others (Wood-Harper et al. 1985, Avison & Wood-
Harper 1990).
Mathiassen et al. (2000) incorporate Rich
Pictures into their Object-Oriented Analysis and
Design methodology. They also incorporate revised
versions of CATWOE and Root Definitions, which
they call FACTOR and System Definitions. These
revised versions are specifically tuned for modelling
the concerns of scoping and defining information
systems to be designed and built.
However, none of the above methods have a
technique for formally and rigourously modelling
problems and their causes. A form or modelling that
includes causal analysis is needed. Fortunately, other
work addresses this need.
Problematiques (Roberts 1994) are a diagram for
causal analysis that can be used to explore a problem
or group of problems, their causes, and their
consequences. The technique consists of nodes and
links, where the nodes are succinct statements of
parts of problems and the links being arrows from a
cause to a consequence of that cause. However,
problematiques are somewhat limited in their
semantics compared to Cognitive Maps, as described
in the next paragraph.
Cognitive Maps (Eden 1988, Eden & Ackermann
2001, Ackermann & Eden 2001) were developed
primarily for strategy development, not for problem
analysis. A key element of cognitive maps is that the
text in a node may have two ‘poles’, a primary pole
which is the content, and a secondary pole, which
provides more meaning through contrast (e.g.
“increased sales … (as opposed to) continuing poor
sales”). While this technique was not developed for
problem analysis, the notation can be used to explore
conceptualisations of problems and solutions at the
front end of ISD.
Venable (2005) proposed a new form of
cognitive maps, called Coloured Cognitive Maps
(CCMs) to address the above issue and added
various enhancements, including: (1) a
conceptualisation of two forms of problem
statements and corresponding forms of coloured
cognitive maps: problems as difficulties, which
focus on the current undesirable or problematic
situation and problems as solutions, which focus on
statements of some different, desirable future
situation, (2) a procedure for straightforward
conversion between these two forms of cognitive
maps, (3) colouring of nodes to indicate desirability
or undesirability, and (4) an overall process for
problem analysis with cognitive maps.
CCM supports rigourous problem diagnosis and
formulation through drawing a model of the problem
as difficulties. CCM also supports derivation of
alternative problem solutions, which could include
IMPROVING REQUIREMENTS ANALYSIS - Rigourous Problem Analysis and Formulation with Coloured Cognitive
IS solutions and their features. Through the use of
the CCM method, problem solutions and their
features are rigourously related back to the original
problem. The method supports contrasting of
different solutions as to how they apply to solving
the different aspects of the problem(s) to be solved.
Therefore, it also supports contrasting of alternatives
for decision making.
Based on the above advantages, we propose that
Coloured Cognitive Mapping (Venable, 2005) could
be used effectively to support methodical and
rigourous problem formulation at the front end of
Requirements Analysis in ISD. We will now briefly
summarise the notation and mapping process for
using Coloured Cognitive Maps (Venable 2005).
3.1 Notation
Two symbols are used in coloured cognitive maps:
nodes and arrows (see figure 1). Nodes are drawn
with rounded rectangles, ovals or some other
convenient symbol and represent some aspect of a
problem. Text is placed within each node, which
captures the meaning of the node. The text in the
node can also be split into two parts or poles, which
are separated by an ellipsis symbol (“…”).
In coloured cognitive maps, the nodes are
coloured to indicate whether the node represents
something that is desirable or something that is
undesirable. Green nodes represent desirable
circumstances and red nodes indicate undesirable
circumstances. Generally, one of the poles in a node
should be desirable and the other one undesirable,
with the colour corresponding to the primary pole
(the text that comes first). Where colour cannot be
used, another indication is needed, such as bold
print, darker lines, darker shading, or a different
node shape for undesirable nodes, as shown in figure
1 below.
Nodes are connected to each other with arrows.
Arrows represent causality between the nodes, i.e.
the node at the tail of the arrow causes the node at
the head of the arrow. Table 1 shows some further
synonyms for the meaning of causality. Note that the
arrows do not mean flow of information or goods
and should never be used as such.
- Goal, activity, problem,
cause, implication, etc.
- Poles separated by ellipsis,
- Red/bold = undesirable, Green = desirable
- Causal or contributory
- Plus sign or minus sign (plus assumed)
Figure 1: Coloured Cognitive Mapping Notation.
Table 1: Synonyms for the meaning of the arrow.
n arrow with
a plus (or no)
sign means
n arrow with a minus sign
Causes Causes the opposite pole
Implies Implies the opposite pole
Enhances Reduces
Contributes to Detracts from
Increases Decreases
llows Disallows
Enables Prevents
Arrows may optionally have plus or minus signs
attached to them. If there is no sign, a plus sign is
assumed. If a minus sign is attached, the node at the
tail prevents (rather than causes) the node at the head
or causes its opposite pole. Table 1 also shows
alternative meanings for the arrow when it has a
minus sign attached.
3.2 A Procedure for Analysing
Problems with Cognitive Maps
The coloured cognitive mapping procedure is
divided into three stages (see figure 2). First is
Problem Diagnosis, in which a cognitive map is
developed of the problem as difficulties. The second
stage is CCM Conversion, which converts the
cognitive map of the problem as difficulties into a
cognitive map of the problem as solutions. The
resulting cognitive map is incomplete, but a basis for
progressing in the third stage. The third and final
stage is Solution Derivation, in which the cognitive
Poor …
+ or -
Good … Poor
ICEIS 2008 - International Conference on Enterprise Information Systems
Figure 2: Procedure for Problem Analysis with Cognitive Maps.
Figure 3: Example Conversion to an Initial Cognitive Map of a Problem as Solutions.
map of the problem as solutions is expanded with
various candidate or potential solutions.
The goal of problem diagnosis is to obtain a clear
(and hopefully agreed) understanding of the causes
and consequences of the problematic situation.
Solving a problem effectively requires that the
problem solver(s) develop a rich understanding of
the problematic situation before proceeding. The
problem solvers need to understand what is
undesirable about a problematic situation, why it is
problematic to the stakeholders, and what the causes
of the problem are – i.e. what things allow the
undesirable circumstances to exist. Note that
cognitive maps of problems as difficulties will
primarily have nodes that are undesirable (coloured
red, bolded, and/or oval shaped), but some nodes
will likely be desirable ones. As they say, “Every
cloud has a silver lining.”
Cognitive Map Conversion is the process of
converting a CCM of the problem as difficulties into
an initial CCM of the problem as solutions. Figure 3
below shows an example. This step is a (nearly
completely) mechanical process of changing every
node in the CCM of the problem as difficulties from
either undesirable to desirable or desirable to
undesirable. The colour of every node is changed
and the text is changed by switching the poles and
rewording so that it makes sense. The example is of
Cognitive Mapping
of a Problem as
CCM Conversion:
Convert from CCM of
Problem as Difficulties
into CCM of Problem
as Solutions
Derivation: Cognitive
Mapping of a Problem
as Solutions
Poor … good
poorly …
… enough
much …
right amount
of work
Lower ….
normal repeat
enough …
insufficient time
workload … too
much work
Do work well
… poorly
Increase …
lower repeat
Improve …
poor customer
poles of
implications, or
IMPROVING REQUIREMENTS ANALYSIS - Rigourous Problem Analysis and Formulation with Coloured Cognitive
course extremely simplified compared to a normal
problematic situation.
In Solution Derivation, the initial CCM of a
problem as solutions is enhanced to explore different
potential solutions and the consequences if someone
were to implement one or more of the potential
solutions. Solutions cause the reduction or
elimination of causes and therefore indirectly solve
or alleviate problems.
In the case of using CCM to support
Requirements Analysis for IS Development,
Solution Derivation would add nodes pertaining to
IS solutions to the problems at hand. In the example
given in figure 3, nodes would be added showing
means for reducing workload or providing enough
time. One can imagine various different IS-based
means for reducing workload. Placing them on the
diagram allows one to visualise what problems will
be solved or reduced by an IS solution, and what
consequences there will be of introducing an IS
solution. Of course, one must also ask what other
consequences there might be, some of which might
be undesirable.
One can also consider alternative candidate
solutions and analyse tradeoffs or one alternative vs.
others through the use of the CCM diagram of the
problem as solutions.
Thus, using CCM can be helpful for rigourously
and systematically analysing a problematic situation
and considering potential IS (or other) solutions.
The author has taught the CCM technique to one of
the principal owners/operators of a small company
engaged in IT infrastructure and systems
development, who have introduced CCM into their
organisational practice. The owners report that use
of the technique is straightforward and easily learned
and adopted by their staff. They also report
significant (ca. 20%) drops in project completion
time, due to fewer problems being encountered
during projects that use the technique.
While the above initial result is encouraging,
much more rigourous and detailed evaluation of the
technique is needed. We plan to undertake action
research so that we develop a richer understanding
of CCM in use.
This paper asserts the importance of methodically
and rigourously analysing and formulating the
problem(s) to be solved when analysing
requirements for solution via IS Development –
before deciding on a solution and trying to
implement it. In particular we have proposed that
Coloured Cognitive Mapping could be usefully
employed to improve the efficiency, effectiveness
and efficacy of ISD.
Ackermann, F. and C. Eden, 2001. SODA – Journey
Making and Mapping in Practice, Chapter 3 in
Rational Analysis for a Problematic World Revisited.
J. Rosenhead & J. Mingers (eds.), Wiley, Chichester,
Avison, D. E. and Wood-Harper, A. T., 1990. Multiview:
An Exploration in Information Systems Development.
McGraw-Hill, New York City, USA.
Checkland, P. B., 1981. Systems Thinking, Systems
Practice. Wiley, Chichester, UK.
Checkland, P. B. and S. Holwell, 1998. Information,
Systems, and Information Systems. Wiley, Chichester,
Checkland, P. B. and J. Scholes, 1990. Soft Systems
Methodology in Action. Wiley, Chichester, UK.
Eden, C., 1988. Cognitive Mapping, European Journal of
Operational Research, Vol. 36, pp. 1 – 13.
Eden, C. and F. Ackermann, 2001. SODA – The
Principles, Chapter 2 in Rational Analysis for a
Problematic World Revisited. J. Rosenhead & J.
Mingers (eds.), Wiley, Chichester, UK.
Mathiassen, L., Munk-Madsen, A., Nielsen, P. A., and
Stage, J., 2000. Object Oriented Analysis & Design.
Marko Publishing, Aalborg, Denmark, http://marko-
Roberts, P., 1994. Systems and the Problematique.
Futures, Vol. 26, No. 7, September, pp. 730-740.
Venable, J. R., 2005. Coloured Cognitive Maps for
Modelling Decision Contexts. Proceedings of the First
International Workshop on Context Modeling and
Decision Support, Paris, France, 5 July 2005, CEUR
Workshop Proceedings, ISSN 1613-0073, online
(accessed 30 October 2005).
Wood-Harper, A. T., L. Antill, and D. E. Avison, 1985.
Information Systems Definition: The Multiview
Approach. Blackwell Scientific Publications, Ltd.,
Oxford, UK.
ICEIS 2008 - International Conference on Enterprise Information Systems