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)
Loading ...