Modeling & Abstraction at the very heart of Business Requirements Analysis

In between Business Engineers and IT Architects, how does a Business Analyst (BA) for requirements fit in? From industrial practice we know a BA definitely makes a lot of sense. So, now we try to conceptualise this extra benefit. As we’ll see, it’s mainly based on abstraction (and thus modeling).

Business and Technology perspectives

Say, your company performs the business tasks described in figure (BizTasks):

Biz Tasks. CEO vs Janitor.

If you asked the CEO what her company is doing here, she would say sth like “We send greetings and invoices”, where ‘send’ means write and ship it, since a CEO doesn’t care if it is performed in 1, 2, or more steps, she solely has the business perspective.

If you asked the janitor, or whoever may be responsible for the tasks’ infrastructure, he would say sth like “We write ‘stuff’ and ship it”. The essential difference for him is, that he has to provide the writers with, say, a typewriter and a pen, and the mail office with, say, envelopes, stamps and a mail box nearby, in other words he has the technology perspective.

So, now that we have the biz and tech views, what is the requirements analyst’s view on this? And, moreover, is an analyst just a bit biz and a bit IT person, or does an analyst’s view makes sense on its own?

How Abstraction makes the Business Analyst

Although the janitor’s view is determined by technology, it doesn’t contain any technology itself, i.e. it consists of biz concepts (completely understandable to the CEO) only. Such a view is pretty exactly that of a BA in software requirements analysis: providing the implementors with relevant information about the business, in a technology free way.
Thus, does the BA have to be a technology specialist, in order to state relevant requirements?

Not if the BA can use an abstraction that hides the technology details. Notice, that abstraction is more than just reduction. It also has a ‘practical aspect’ (Stachowiak), in plain words, the abstraction has to make some ‘sense’ in it self. This is why a BA is not just a half-and-half biz and IT semi-specialist. The abstracting nature of the BA’s perspective makes software requirements analysis a self-contained discipline.

Information System as the Abstraction of Choice

As practice shows the concept of Information System (IS) is a ‘quite good’ abstraction for software requirements. For our purposes, by an IS we mean a system of information flows among participants. Moreover we assume an IS to be analytic, not designed, i.e. extracted from the world (by abstraction), not constructed into it. There are various definitions of IS* that are more or less all come down to data, functions, and interfaces.

In other words, analysis of software requirements means describing the world in terms of data, functions, and interfaces. No need of technology knowledge – in theory, of course. In practice some tech and biz knowledge is required as well, however the core competency – in which the BA differs – is the capability of abstracting (and thus modelling) the IS from the business. Also notice, that this is far more than just the ability to ‘think analytically’ often found in BA job ads.

So, remember: If you do not abstract, it is not analysis.

So long

* textbook e.g.: Antoni Olive (2007) Conceptual Modeling of Information Systems.

For now, of course the open issue left, is a closer look on how an IS fits the above purpose.

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

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