Roland Dürre
Friday October 30th, 2009

Hot-Spots at TUM – “Requirement Engineering”

On October, 8th, 2009, I attended another one of the »Hot Spots of Software Development— HSE« at TUM.
The series was initiated in 2002 with the VSEK-project and now takes place on an annual basis at Munich Technical University. It aims at providing a platform for the exchange of experience on current topics in software engineering.

You can read more about the individual meetings on theHot-Spots-Site of TUM. This site is highly recommendable, since it offers extensive explanations of the topics and Conference Proceedings to every one of them. As a general rule, you will also find the slides used during the individual presentations. On the whole, it is an excellent concept.

This year’s conference was about Requirement Engineering


Again, the conference was extremely exciting, which was probably due to the fact that “Requirement Engineering” is a very special topic.

Though I did not have enough time to attend all the individual sessions, I would still like to say a word or two about a few of the themes discussed during the presentations:

Requirement Engineering versus Design/Architecture    
Themes must be strictly divided. Unfortunately, I also noticed during the conference that even an experience “Requirement Engineer” can easily fall victim to almost automatically constructing the product, instead of doing what is his real task:  critically questioning the requirements for a product and then clearly defining them.

Divide et impera!

This saying is as old as ancient Rome: divide and reign (over) the affairs. This is doubtless a reasonable procedure in order to gain access to complex situations. However, it can only be done if you know exactly what you want and can structure it clearly from top to bottom. Yet the actual challenge in requirement engineering is that you or your customers mostly do not know what they want. Instead, you have to find out and describe it in a combined effort.

Dialectics and Logic

Clear definitions, looking for requirements, defining  syllogisms, generating “flags”: these are all extremely important issues in inter-human communication. They have played a central role for 2,500 years. Requirement engineering in particular necessitates the application of these disciplines with a high degree of precision and accuracy. It sounds almost like a good joke to me if requirement engineering tries to “re-invent the wheel”.

“Cheap Design”

What I missed was a contribution about the role requirement engineering might play if you also want to keep the product description simple. Meaning simple as defined by Rolf Pfeifer, in this Interview. Rolf Pfeifer is the founder and director of the Artificial Intelligence Laboratory, Department of Informatics, University of Zurich. Among other things, he wrote the book “How the Body Shapes the Way We Think: A New View of Intelligence” (Bradford Books). He invented the term “cheap design” and later made it popular.

Creative Products

This is an area where I totally miss reasonable approaches in requirement engineering. How can you find creative approaches for products that do not yet even exist? I am sure that “top down” approaches cannot be applied. After all, there is no “top”. Neither can I see iterative methods as a solution so far.

Faith in Tools

I got the impression that some of the orators believed you could solve the complexity problem by using tools. In my opinion, this is rather bold. Just imagine philosophy relying on tools for doing its work, for instance UML technology!

On the whole, I get the impression that we now have reached a phase where we try to “make things less complicated” even in requirement engineering by using process overkill and tools. Unfortunately, this does not work. In fact, the result is the opposite of the desired effect. It might be a good idea to admit it and return to the old principle “KISS” (keep it simple and stupid).

RMD
(Translated by EG)

3 Kommentare zu “Hot-Spots at TUM – “Requirement Engineering””

  1. Chris Wood (Monday November 2nd, 2009)

    This is another area where compromises work best. “Bottom up” is a bad design method, but “top down” is not the whole answer. Innovation is driven partly by recognition of requirements, but also by recognition of what can be done.
    Incidentally, the KISS principle in English is usually spoken as “Keep it simple, stupid”, (compare http://en.wikipedia.org/wiki/KISS_principle with the German version). This indicates that the one spoken to has been stupid enough to propose a complex solution. English humour is more brutal than German.

  2. Michael Greulich (Monday November 2nd, 2009)

    Ich wuerde der Aufzaehlung von Roland Duerre gerne noch das Folgende hinzufuegen:
    Bei aller Suche nach moeglichst einfachen Loesungen muss auch immer die Angemessenheit der Loesung beruecksichtigt werden. D.h. die Komplexitaet der Loesung muss in einem angemessen Verhaeltnis, zur Komplexitaet des Problems stehen. Im Zweifelsfall aber immer erst mal der einfacheren Loesung den Vorzug geben.

  3. Chris Wood (Tuesday November 3rd, 2009)

    I do not see a simple relationship between the complexity of a problem and that of its solution.
    The problems in the relationship between a man and his wife may be very complicated; the solution can be just a push while walking in the mountains.
    It is known that a mountain in the Canary Islands threatens to fall into the ocean, creating a wave that will drown much of New York. This seems a fairly simple problem, but any solution will be very complicated.

Kommentar verfassen

*