When to call a system “small”

Some reflections on the work of Dirk Siefkes on formal methods and small systems
Part I

When would you call a system “small”?
This is best answered by a question: “compared with what?”. Among all these possible ‘whats’, the human being is a case of high practical relevance in its ambition to analyze, control or participate in a system. Systems can be social, technical or hybrid. They are said to be small iff humans can communicate within them or deal with them easily.  Ok, it’s not a precise concept, but that’s not what it is all about.

How would you deal with an “unsmall” system?
It’s as easy as eating a schnitzel: cut it into pieces each of which is bite-sized i.e. ‘small’. Trivial? Depends: when looking at people structuring things, many break down their schnitzels to atom size, since they seemingly don’t differentiate between structuring and detailing. In fact, as far as my experience goes, this is one of the most common mistakes in industrial requirements modeling.  It’s probably a good idea then, to keep in mind that ‘small’ units are a sort of lower bound for structuring things in the real world.


  • How to deal with heroes? (they don’t like things that are easy to deal with)
  • What about sliced bread? (compared with schnitzel)

About modelpractice

Modeling Theory and Abstraction Awareness in strive for scientific rigour and relevance to information systems engineering.
This entry was posted in Epistemology and tagged , , , , , , , , , , . Bookmark the permalink.

4 Responses to When to call a system “small”

  1. Salieri says:

    Small is beautiful!

    But, is schnitzel such a good example? How to put the pieces back together in a small way?

    • Hi ‘Toni’

      I must admit Siefkes’ concepts on this didn’t really convince me so, I omitted the part. He suggested to keep communication ‘small’. Think this just leaves you with an increasing communication overhead. Perhaps abstraction can help? Not sure …


  2. Good structuring skill comes with experience.
    In math the age/maturity threshold is higher than in software development. That allows unskilled people to enter the requirements design room and take a seat there.
    This is not bad since this is the way to learn. Evolution will kick in few years out of the room all people who don’t learn the skill.

    • Hi Alex,

      totally agree. Hope that the maturisation will go towards better structuring and will not just lead to better requirements ‘administration’. For my taste there is much too much stuff on the latter and too little progress in foundations of the former. That’s one reason why I like B.C. Smith’s paper (see above).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s