Software Requirements Analysis: From the Art of Tidying Up to the Art of Abstraction

Requirements analysis is more than just tidying up, it’s about understanding the complexity of structures. An explanation inspired by the art of Ursus Wehrli:

Is Requirements Analysis just a kind of Tidying Up?

Recently I discussed with some project responsibles, the option to use an issue management system (namely JIRA) for gathering software requirements. The people obviously thought of requirements as a big set of snippets, that have to be collected and ordered, very much like a stamp collection. This seems to be a common misunderstanding of the nature of requirements, which can be elucidated nicely by the art of Ursus Wehli.

Ursus Wehrli is a Swiss comedian and artist, who makes books in which he “tidies up” works of art, for example, sorts the elements of a Kandinsky painting by colour and size, or orders the letters of an alphabet soup alphabetically. (more here: NYT)

Why Tidying Up is not enough

Let’s picture this little Wehrli-forgery here, a unjumbled version of a public transport map:

wehrli zürich tidyIt has lines (heavy for city trains, double for long distance), station names and station nodes. So, what is missing? What exactly makes the difference to a complete map? Obviously, it’s the relationships among the map elements that are missing here.

However, since the elements can still be classified and ordered, there must be some relationships left, determined by the elements’ properties. In this kind of representation they are made explicit, such that it becomes easy to ‘query’ e.g. if there is a station named ‘Opfikon’, or what line is the longest. Thus, simplification by ‘tidying up’ also has certain benefits.

Why Managing Relationships is not enough

wehrli zürich relationSo, why not simply add the relationships to the list, as in (Public Transport related)? It defines the relations name to station node, and station node to line, with station nodes identified by numbers 1 to 11.

So, technically all information would be available. However, for humans it’s still too hard to deal with. The relationships are now manageable by the system, but they are not yet expressed in a human-oriented notation. This is why an issue management system (IMS) is not enough to deal with requirements, even if it’s capable of managing relationships. An IMS’ focus is on sorting and grouping things, for example to make a todo-list of requirements, or to support the management of the analysis process.

And why even Visualisation is not enough

wehrli zürich transport mapFor the typical use of a public transport map, a diagram as (Public Transport) is certainly appropriate, i.e. the human understandability can be accomplished simply by choosing an appropriate notation. And even if the lines and stations become just more, we simply can increase the size of the map. However, if the structure gets more complex, i.e. the elements are ‘closer’ related, diagrams quickly become hard to understand. Visualisation scales well concerning size, but not concerning complexity.

Visualisation of relationships is usually what modelling tools are good at. However, as we have seen the tidy perspective has its advantages, too. Thus, beyond visualising the modelling results (i.e. diagrams), modelling tools should provide ‘tidy’ perspectives (like an IMS), in order support the modelling process. In other words, working out models is more than just documenting them.

Abstraction for Analysis

wehrli zürich airportIf things get more complex – just think of a map with a more complex system of stations and lines (trams, etc) – it might become beneficial to create views on the model, e.g. all available lines from the airport, as in figure (Airport Transport), with connecting lines indicated at each station. Similarly, think of a requirements model of a whole software application, decomposed into data, use-case, state, etc. views/ diagrams. This goes beyond visualisation, this is about abstraction. Thus, as compared to the ‘art of tidying up’, choosing appropriate views on a model, in order to understand its complexity, constitutes the ‘art of abstraction’ (so to say).

By the way, this is also what distinguishes modelling from simple drawing tools. (Just in case, the next project wants to do requirements analysis with VISIO)

So long

Notice that additionally to the relations in (Public Transport related) the diagram (Public Transport) contains the coordinates of the stations. Although, they are only schematic, they provide an approximate geographical location information.
Ursus Wehrli

Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , , , , , , | Leave a comment

Modelling with Classes: Square and Rectangle revisited

Classic problem in class-modelling: how to express that a square is a special kind of rectangle?  Practically the best approach is in general to refrain from subclassing and add a boolean method isSquare() to the rectangle class instead.

In order to deepen understanding, let us scrutinize the situation a bit closer here, using logical/ structural foundations of modelling:  Undoubtedly, Square is a subclass of Rectangle, since all squares constitute a proper subset of all rectangles. This could be simply describes as:

(R1) Rectangle: real a, real b, {a>0}, {b>0}
(S1) Square: real a, {a>0}
A method area() would look like: a * b in Rectangle and a² in Square.

However, additionally we have the challenge of inheritance, that is, we want to obtain the description of Square by just extending the description of Rectangle. This is not satisfied by the solution above, since Square drops the b. Notice, that we talk about just the description of the classes here. Their extensions (rectangles and squares) remain unaffected. Of course, one could specify it like this:

(S2) Square: real a, real b, {a>0}, {a=b}
But here b is redundant and e.g. area() could be a * b or a² arbitrarily.

Thus, for a subclass Square we can choose to drop inheritance or accept redundancy. Now, inheritance is a very desirable feature.  For example, it allows the area() method of (S2) to remain unchanged in the Square class.  Just imagine, how confusing developing would become, when subclasses exhibit methods of superclasses differently structured or named.

This is why it’s recommendable to accept redundancy for the benefits of inheritance here. To implement this either by a subclass Square, as in (S2), or inside the Rectangle class, as with an isSquare() method, is left to practical considerations.

So long

Posted in Software_Engineering | Tagged , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Roaming the Subsumption Continuum

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by basic concepts of graph theory.

In the recent post we defined 4 cases of subsumption. In order to get from these basic cases to real world situations, we see the 4 cases as the corners of a ‘continuum’ A, B, C, D, and thus we get figure (subsumption continuum).

continuum of subsumption

Here the following areas – well known from graph theory – can be identified:

CC Connected Component

A connected component is a subgraph in which any two vertices are connected to each other by paths, and which is connected to no additional vertices in the supergraph.* This is what we get when we reduce the density of A, i.e. components become less obvious to abstract/model just by their internal composition alone.

CY Connectivity

The connectivity asks for the minimum number of elements (nodes or edges) which need to be removed to disconnect the remaining nodes from each other. A higher degree of connectivity is what we get when we increase the strength of A, i.e. components become less obvious to abstract/model just by their external relationships alone.

MO Module

In a module all members have the same set of neighbors among nodes not in the module. This is what we get when we add edges to C, i.e. the abstraction/model of the class structure becomes a multi-level tree.

CL Concept Lattice

All formal concepts of a bi-partite graph constitute a lattice. This is what we get when we reduce edges from C, i.e. the abstraction/model of the class structure becomes a multi-level lattice.

EX Expander

An expander is a sparse graph that has strong connectivity properties. It is ‘quite’ hard to decompose by subsumption into classes or components. For this reason expanders are used to design robust IT networks etc.

Finally, we get E by reducing the edges in A and C and then joining them to a ‘cube’ that can not reasonably be structured by classes or components.

Thus …

we can take parts of graph theory for describing typical problem situations of abstraction. However, most of these parts of graph theory* do not address the issues of the actual abstracting mapping from original to model, as required for ‘modelling for the purpose of understanding’. This is what a theory of modelling should be about.

So long

* apart from formal concept analysis

Posted in Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , | Leave a comment

Craftsman or Engineer?

A brief word on a practical software engineering issue:

A lot has been written on the differences between Craftsman and Engineer.  Recently I came across a simple example by Hofstadter & Sander, that nicely shows the basic difference in thinking. We start with a little exercise:

“Draw a square, a rectangle, a rhombus, and a parallelogram.”

Some people draw a solution as in (a), some draw solution (b).  Both are perfectly acceptable in their way:
shapes abstraction

  • With (a) you show your detail knowledge, of how the shapes are defined, s.t. you are able to give a typical example for each class.
  • With (b) you show your ability to abstract, of how the shapes are related to each other, s.t. you are able to give a special case valid for all conditions.

shapes concept lattice and context

The latter is an abstraction by constructing formal concepts, i.e. by deriving the concept (lattice) from the (context). Imho, being able to ‘navigate’ the concept lattice – that of course looks much more complex for real world subject areas – is what separates the thinking of Engineer and Craftsman.

So long

For example, from my personal experience in business analysis I may say, that typically there are lots of people on the expert side with type (a) knowledge, so what they need an analyst (on engineer-level) for, is help them to create type (b) understanding from it.

Posted in Abstract Thinking, Software_Engineering | Tagged , , , , , , , , , , , , , , , , , , | 4 Comments

Reflections on Abstractions: Subsumption I

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic relational mathematics.

We’re going to look at a subsuming mapping from lhs original to rhs model. When we assume subsumption, i.e. non-lhs-uniqueness, a single rhs node in model ‘contains’ , i.e. is mapped from, 1..n nodes of original.

Two model nodes with no edge

subsumption 2 nodes 0 edgeNext, as in figure (no edge), we look at two rhs nodes a and b with no (rhs) edge amongst them. From no edge on the rhs we can derive that not all lhs nodes in node a have a (lhs) edge with all lhs nodes in b, else we would need a negation in the mapping rule to map from all-to-all edges on lhs to no edge on rhs. Among the remaining mapping options, the rule ‘no lhs edge iff no rhs edge’ is the strictest (the ‘opposite’ of all-to-all, so to say).

Moreover, in this case no edge among the lhs nodes of a and b would make no sense, since the abstraction could not be justified by the structure of the graph. Thus, the nodes of a and b must be connected amongst themselves. Again, we take the strictest case of all-to-all connection as in figure (no edge).

Two model nodes with one edge

subsumption 2 nodes 1 edgeNext, as in figure (one edge), we look at two rhs nodes a and b with one (rhs) edge amongst them. From one edge on the rhs we can derive that one lhs nodes in node a has a (lhs) edge with one lhs node in b, else we would need a negation in the mapping rule to map from no edges at all on lhs to one edge on rhs. Among the remaining mapping options, the rule ‘all-to-all lhs edges iff one rhs edge’ is the strictest  (the ‘opposite’ of no edge at all, so to say) .

Moreover, in this case all-to-all edges among the lhs nodes of a and b would make no sense, since the abstraction could not be justified by the structure of the graph. Thus, the nodes of a and b must not be connected completely amongst themselves. Again, we take the strictest case of no edge at all connection as in figure (one edge).


abstraction subsumption

… we get four cases of subsumption as in figure (strictest cases), which next can be developed into a continuum with the four cases as corner points.

So long

Or in terms of adjacency matrices:

4 cases abstraction by subsumption adjacency

Posted in Reflections on Abstractions | Tagged , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: From ‘Siamese’ Graphs to Concept Lattices

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic graph theory and formal concept analysis.

Lets bring the definition of abstraction by subsumption, i.e. of not always lhs-unique mappings, to life. We want to detect complete subgraphs in graphs and build an abstract graph (model) from them. Think of this as building components, where their elements are extremely tightly bound. Notice that this is stronger than ‘connected components’ of graph theory.

Abstraction by ‘Siamese’ Edge

roa complete graph rhs unique not rhs uniqueFor example

(rhs-unique) gives a pretty nice example of abstraction by subsumption, where rhs-uniqueness holds. We get two rhs nodes with an edge amongst them, that ‘survived’ the mapping.

(not-rhs-unique) – a kind of ‘siamese graph’ – leaves us with the choice to simply map the middle node to two different nodes, and then introduce an additional type of edge for ‘having common node’ (e.g. meaning ‘these two rooms have a common wall’) or to introduce any other kind of construct.

Abstraction by Concept Lattice

There is an elegant construct for bi-partite graphs (that correspond to an object – attribute, or extension – intension situation) from formal concept analysis:

roa complete graph bi-partite concept lattice(bi-partite) shows an example where nodes 1 and 2 together with a and b are ‘as complete as possible’ since they have all connections allowed amongst them in a bi-partite graph. This kind of completeness corresponds to a ‘concept’ in formal concept analysis.  Thus we can draw a concept lattice as in (bi-partite), with 1-3 as objects and a-c as attributes. Notice that the edges here are read from bottom to top as generalisations, i.e. we can completely refrain from object-attribute edges here (no mesh up as by the ‘having common node’ edge above).

So long

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Subsumptions and Omissions

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently we provide a simple visualisation of some basic concepts.

In addition to the recent posting Abstractive and Functional Mappings we provide a simple visualisation.  There we defined abstraction by subsumption as a not lhs*-unique mapping, and abstraction by omission as a not lhs-total mapping. This, and the combination of both to an ‘omsumption’ (excuse the word), is illustrated below.

abstraction subsumption omission

So long

* lhs = left hand side

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: Abstractive vs Functional Mappings

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of  basic binary relation theory.

From Bijection to Function

We consider mappings from and to nodes of graphs from a domain lhs to a codomain rhs. The most trivial mapping is the 1-1 mapping, where each lhs node has exactly one rhs node, and vice versa. In mathematics this is said to be a bijection.

Such a bijection can be generalised, by dropping some of its properties. Therefore, we apply the four basic properties of binary relations*:

1. lhs-total, i.e. every node in lhs is mapped to rhs
2. lhs-unique, i.e. every node from rhs is mapped from max one node in lhs
3. rhs-total, i.e. every node in rhs is mapped from lhs
4. rhs-unique, i.e. every node from lhs maps to max one node in rhs

Thus, the most specialised concept is the bijection, having all four properties. A more general concept is that of a function, where just properties 1 and 4 must always apply, i.o.w. 2 and 3 MAY be dropped.  Functions are a pretty useful concept in mathematics and its applications. However, as we will see next, for describing graph-to-graph abstractions, other combinations of the properties 1 to 4 are more suitable.

From Bijection to Abstraction

In a graph-to-graph mapping the absence of the four properties can be thought of in the following way:

1. Not lhs-total: a ‘deflating’ mapping by picking certain nodes and omitting others. Examples: all leaf nodes of a tree;  all business process steps with an external interface.

2. Not lhs-unique: a ‘deflating’ mapping by subsuming nodes of lhs in rhs. Examples: the concept of connected component in graph theory; structuring an object-oriented class model by building components.

3. Not rhs-total: an ‘inflating’ mapping, adding extra nodes to rhs, not mapped to from lhs. This can be thought of as adding a new context to the lhs. Examples: adding a ‘bottom node’ to a taxonomy s.t. it becomes a lattice; Adding dots to a drawing s.t. the shape becomes clear, a popular kind of puzzle.

4. Not rhs-unique: an ‘inflating’ mapping, that splits a node from lhs into two or more nodes in rhs. In some way this reveals the ‘internals’ of the node. Examples: two nodes from one (e.g. if it belongs to two cycles or 1 node incoming, 1 node outgoing edges); wall belonging to two rooms (which is also not lhs-unique)

Thus, in order to achieve the (strictly) reductional property of an abstraction, property 1 or 2 (or both) MUST be dropped. We suggest to call a not lhs-total mapping subsuming, and a not lhs-unique one omitting abstraction.  Whereas dropping properties 3 and 4 each constitute a reverse abstraction, i.e. ‘inflating’ from lhs to rhs, and ‘deflating’ from rhs to lhs. Notice that subsuming functions may exist (props 1, not 2, 4).

Thus …

we can see that the concept of function is less important here. Central to abstraction, and thus to relational modelling, are the concepts of subsumption and omittance. Look here for an illustration. In other words, not lhs-total and/or not rhs-unique is the necessary property to constitute an (non-trivial) abstraction.

So long

* basic properties of binary relations:

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , | 3 Comments

Modelling explained (to Journalists)

Party lines for software modellers #4312

In journalism dog bites man or man bites dog, makes a big difference. In modelling it’s the same entities with the same relation, just in different directions.

So long

Posted in Software_Engineering | Tagged , , , , , , , , , , | Leave a comment

What can Software Modellers learn from Innovation Methodologies?


Recently I came across this HBR (Harvard Business Review) article A Taxonomy of Innovation on the Luma institute design methodology. It contains three categories of techniques to help innovators develop products and services: Looking, Understanding, and Making.  From my viewpoint as a modelling theorist especially the ‘Understanding’ part seemed quite similar to  what software modelling for the sake of understanding (e.g. as in requirements analysis) is about.

Subsequently, I take a closer look at the techniques that this methodology provides for gaining a better ‘Understanding’ of what users want. It is hoped to gain inspiration and ideas for software modelling (esp. modelling of requirements).  The innovation methodology comes with assistance and description of collaboration, notation, and the logical structure for each of the single techniques. As a modeller I focus mainly on the structural aspects.


Some techniques like Persona Profile or Importance/ Difficulty Matrix are quite generic and are already successfully in use in software modelling and/or engineering. However, others like Affinity Clustering or Concept Mapping strongly underestimate the structural aspect. They are not aware that structures grow over 1-sheet size, have dependencies, or change during the project.  The techniques simply do not deliver the promise to  scale with ‘the complexity of the systems in which you operate’.

Overall, there is nothing to learn for software modellers concerning structures. However, for collaborative aspects one or the other detail might be worth considering. This is not surprising, since the Luma methodology is almost solely focused on notation and collaboration, whereas software modelling is mainly focused on structure.

However, vice versa, innovation methodologies, like the one considered here, could strongly benefit from the structural thinking in software modelling. This would make them able to scale large and complex structures and handle their changes over the product life-cycle.  In other words, making the step from sketching to modelling.

Why are results from software modelling not considered by other disciplines?  Why does no one come around asking software people for help on structural issues? Are software people mainly seen as technology guys, due to the public unawareness that informatics/ computing is a structural science?


Part I: Patterns & Priorities
Part II: People & Systems
Part III: Problem Framing
More detailed descriptions of the single techniques can be found in the article

Part I: Patterns & Priorities

Affinity Clustering

Affinity Clustering‘A graphic technique for sorting items according to similarity.’

As we know from modelling theory (see here) we can structure things basically by their attributes, internal or external relationships or any combination of it. Here, it remains unclear which way is intended. So you are likely to end up wondering where to put the engine:  as part of a car or in the group of engines. In other words, sorting things is more complex, than just putting things into buckets.

 Bull’s Eye Diagramming

 ‘A way of ranking items in order of importance using a target diagram.’

We all know what happens when we ask a customer for a prioritization:
Everything is prio A. There are several ideas to address this, however none can be found here.

Importance/ Difficulty Matrix

Importance Difficulty Matrix‘A quad chart by placing items by relative importance and difficulty.’

In software engineering this is the basic chart for any testing strategy. However, since testing moves more and more towards the early stages of the software process, starting a 2-dimenisnal ABC analysis of this kind already during requirements analysis is certainly no bad idea.

Visualize the Vote

‘A quick poll of collaborators to reveal preferences and opinions.’

Analytically this is about creating views and understanding viewpoints. This always should be approached in two ways: collaboratively, by involving people, and structurally, by systematically creating perspectives on the subject matter (typically in software engineering these involve user, architectural, management perspectives etc). Unfortunately, this method here omits the structural way completely. Typically, this leads to underrepresentation of stakeholders not directly involved in the development process, like users or operators.

Part II: People and Systems

Concept Mapping

Concept Mapping‘A way of depicting the relationships between various concepts in a given topic area.’

Entities with relationships – great idea! :o)
However, as we know from modelling theory, when the number of entities increases some methods for structuring, like modules or generalisation can become very helpful.

 Experience Diagramming

Experience Diagramming‘A way of mapping a person’s journey through a set of circumstances or tasks.’

This can be done for example on classifier level, as use case, or on instance level, as test case. However, when you have a lot of them, the question of keeping them consistent remains unaddressed.  see here

Persona Profile

‘An informed summary of the mindset, needs, and goals typically held by key stakeholders.’

In software development techniques like this come in on the needs level (to understand where the requirements ‘come from’). This can be very useful, especially in consumer software development.

Stakeholder Mapping

‘A way of diagramming the network of people who have a stake in a given system.’

Also in software development, a very useful thing to do, for people having a stake in the final product as well as in its development process.

Part III: Problem Framing

Abstraction Laddering

Abstraction Laddering‘A way of reconsidering a problem statement by broadening or narrowing its focus.’

Asking for the why and how of requirements is a familiar technique in software engineering, for example by modelling business processes or prototyping.

Problem Tree Analysis

‘A way of exploring the causes and effects of a particular issue.’

In software, functionality maps effects to causes (plainly, input to output), and thus software modelling knows a variety of techniques of structuring like classes, components, and interfaces.

Rose, Thorn, Bud

‘A technique for identifying things as positive, negative, or having potential.’

A pretty generic technique. Like with the ‘Visualize the Vote’ technique, it is just collaboration based, no structural support offered.

Statement Starters

Statement Starters‘An approach to phrasing problem statements that invites broad exploration.’

This is a bit like textual entity relationship modelling. Of course you can write down ‘Person drives Car’, but how do you keep the overview of a larger amount of sentences if not by modelling? This makes it more an elicitation than a modelling technique (similar to user stories).

So long

Posted in Abstract Thinking, Model Thinking, Software_Engineering | Tagged , , , , , , , , , , , , | 2 Comments