Here is my report about what I presented at TUM.
On April, 13th, 2010, I gave a presentation at “Hot Spots of Software Development 2010” on:
Requirements Engineering (RE) in Small and Medium-Sized Enterprises.
The event was organized by TU Munich in cooperation with BICC-NET and VSEK.
When I prepared for the speech, our experts for requirement engineering, Michael Greulich and Johannes Naumann were a huge help. Many thanks to Michael for his precious advice and Johannes for the beautiful slides for the presentation RE ([download#77]).
The general motto of my talk was:
Talking about problems inflates the problems.
Talking about solutions improves the solutions.
I first read this “great sigh” on twitter. It was written by a suffering human being belonging to my business sector.
The sentence made me thoughtful. Don’t we all want problems to get less acute as we talk about them? And don’t we medium-sized enterprises especially wish for efficient, simple, small, smart and perhaps even beautiful solutions? Instead of huge systems that eventually force us to sacrifice our processes before the altar of systematic requirements and restrictions?
My presentation was divided into three parts:
- Personal experience,where you got to hear three examples from different times in my IT life.
- Terminologyand structuring of the words used in connection with agile technologies SCRUM or KANBAN. Unfortunately, I sadly miss a clear definition of the terms “Requirement Engineering, Professional Architecture and Requirement Management” on conferences and even in presentations.
- A list of necessary and useful inter-disciplinary qualities for RE.
For those who prefer reading it, instead of listening to the live-talk, I especially recommend the third chapter.
1. Personal Experience
RE is something that accompanied me in my projects through all my life. Here are three examples:
Development of operating systems:
During the second half of the 1970ies, I worked at Siemens in the system technology sector (UB D DF 131). My place of work was at the laboratory for Transdata. and SNA (System Network Architecture). My first project was about introducing “Logical Connections” in Transdata. The project was called “Connection Handling”. When I asked: what is the intended goal of these Logical Connections, the answer was: We are doing this because IBM also does it in SNA (System Network Architecture). In the sense of RE, this is certainly a reasonable answer, yet it is not altogether one that makes you happy. As it happens, we continued to develop our own solution for Transdata. It contained dynamic and pre-defined connection handling and won us quite some advantages in our projects.
Application Project
Around 1980, we won a tendering procedure of the “Deutsche Bundesbank” for Softlab (which is now Cirquent). It was about the “Second Automatization Stage”. Naturally, we had no idea what our customers really wanted. However, we soon found out that the customer was not capable of precisely defining what his requirements were, either.
With S/E/TEC (Softlab Software Development Technology), we had a tool that made it possible for us to document graphical program processes on PetMaestro. so we made a virtue out of necessity. Numerous clerks were trained for S/E/TEC at Softlab and then they wrote down their commercial goals. During this project phase, we earned excellent money by teaching courses and supporting everyone in RE. In 1981 we paid the price for this: we needed a truck to carry all the documents containing the system description.
Well, we had earned a lot of money coaching people. The result was a truckload of paper. As I remember it, the truck was 7.5 tons. Of course, the first attempt at the project never made it to the actual realization. But still, we gained lots of precious experience.
Modern application projects:
Here is a more recent example: a professional procedure with similar functionality was developed by two different providers totally independent from each other. They had no design matching whatsoever, only the final end was identical. Both solutions were (quite by accident) also developed with the same technology.
The first solution “A” had a very restricted budget and very strict controlling in RE. The second solution “B” was processed on a continually increasing dynamic budget through Change Requests (CR) after the definition of a basic concept. Today, both applications are used in production.
Here is the result: the relation of “lines of code” is 1:4, with the smaller solution being better accepted by the users. Of course, the costs of development and maintenance are lower for the smaller solution. The reason was a misdirected (because turnover-oriented) RE.
The last example also shows why a provider who thinks in terms of turnover will always have a problem. CR-s are usually realized without further considerations, because all CR is turnover and mostly “business cream”.
Consequently, it is mostly an advantage if at least the provider of the solution thinks in terms of “medium-sized business”. Instead of wanting the best from the customer (his money), he will aim at the best for the customer. In general, that is how medium-sized enterprises think. After all, they live by the trust of their customers and trust is something that will not develop through exploitation. Of course, the best RE projects would be those where both (provider and customer) think in terms of medium-sized enterprises.
2. Terminology
Nowadays, if you attend an event in order to learn something new, or – even worse – if you give a presentation yourself, you should have made yourself familiar with the central terms around the topic you are going to discuss.
The same is true for RE. And in RE especially, a precise terminology is vitally important. Here is the link to RE in Wikipedia. RE is part of Requirement Management, so we are dealing with the what and not with the how! In the ideal case, this is where concepts with open solution potential should be developed.
Requirement Engineering is characterized by:
- Listening and understanding (analysis),
- completeness, also in the sense of „Top-Down“,
- communication in the language and on the level of the stake holder.
- Basically, it is all about
- “Taking stake holders along“,
- reviews,
- questioning the requirements,
- requirements later turning out to differ from what they seemed at first sight,
- implicit requirements,
- whether or not the granularity of the requirement is adequate, functional and non-functional requirements.
Above all, Requirement Engineering must be clearly and meticulously separated from Professional Architecture!
Professional Architecture as such is part of the system analysis (Systemanalyse). At Informatics of TUM, you can also find a very recommendable description (Beschreibung). In Wikipedia, you will find a not altogether wrong but still incomplete description under Information Architecture (Informationsarchitektur).
Unfortunately, the term “Professional Architecture” does not yet exist in Wikipedia. How about one of my readers taking pity and working on it for publication in Wikipedia?
Professional Architecture is also about reaching a consensus between the relevant stake holders. More often than not, the requirements of various stake holders are at opposite ends with respect to whether and in how far, for instance, one requirement should differ from that of comparable other systems
In any case, I recommend – not just for medium-sized enterprises – that you apply the KISS principle most scrupulously. And I do not only mean the original definition KIS,S (see my article), but in particular the terms that contain the “S” like in simple or smart, and, being a mathematician, also as in nice (schön) – just think of all those nice and yet simple proofs in mathematics.
The most important thing is that you distinguish accurately between Requirement Engineering and design/architecture! On a recent conference on this topic, an experienced requirement engineer gave a presentation on RE and kept talking about the development of professional architecture all the time. He entirely forgot his actual task, which would have been to ask critical questions about the requirements of a product and come up with a clear definition.
Another term you should clearly keep apart from RE is Requirement Management (RM). You can also find an excellent article on it in Wikipedia. It is all about administration (Tracability), control, priorities, documentation of the “what”, i.e. the variants and reasons for the requirements. As opposed to Requirement Engineering, Requirement Management tackles agile methods, such as SCRUM.
I recommend the following formula:
The product design is the result of the sum of Requirement Engineering and Professional Architecture. This product design, however, is assumed to be a given in SCRUM. It is added to the development process by the product owner (one of the roles in SCRUM).
3. Inter- Disciplinary Qualities
Here is a list of what is often forgotten yet probably extremely important:
Divide et Impera!
Even the emperors in ancient Rome found this maxim a good one to follow: divide and rule (over) all. It is certainly a reasonable approach towards finding a way around complex situations. But in order to be able to adhere to this principle, you must know what you want and be able to divide it top to bottom in a suitable way. The challenge of Requirement Engineering, however, is that mostly you do not really know what you or your customers really want. Instead, you have to find out together and describe it.
Here is an example outside the software developing world. Laws are certainly something you can compare with software, since laws are subject to modifications by the executive and judicative systems. Just like software is important for applications, laws and their execution are very important for our social structure and our social systems.
In Europe alone, tens of thousands of new laws are introduced each year. They are virtually “programmed” without a true goal. Our former Prime Minister, “Father” Stoiber tries to “cut down on the EU- bureaucracy” and once in while manages – like a small programmer in a huge system – to simplify or annul an individual law. But the Europeans no longer understand what it is all about.
So here is another example where some reasonable Requirement Engineering before introducing the flood of laws would have helped to define what Europe and the Europeans actually need. A lot of Europe and EU frustration could have been avoided. But no! We continue with all our programming without ever knowing what we really want.
The example shows that it is not enough to just implement at your heart’s content without having done some profound thinking first.
Dialectics, Logics, Ethics
Clear definitions, looking for requirements, a constructive and dialectical climate during discussions, constructing a syllogism (Syllogismus), designing “Flags” (a philosophical term, unfortunately not yet to be found in Wikipedia, either), all these are issues of inter-human communication.
All these issues already played a huge role much more than 2,000 years ago. Especially in Requirement Engineering, we need an application of these disciplines with high precision and accuracy (and joy). Consequently, instead of “inventing the wheel anew” you should rely on knowledge that has been successfully applied for generations.
In one of today’s presentations, we learned that medium-sized enterprises take advantage of linguists for Requirement Engineering. I would even go one step further: it cannot be done without philosophers.
In RE, we need two types of philosophers:
The “classical ground-roots philosopher”: He has to be a master of wordplay and dialectics. Immanuel Kant might be a good example.
The “Heretic philosopher”: I have the great philosophers of enlightenment in mind. They asked questions about concepts that were allegedly self-evident. And they (successfully) shredded the foundations. They were full of moral courage and constructive disobedience. Maybe Friedrich Nietzsche can be called prototypical.
So here is my advice: put Kant and Nietzsche into RE projects! There might well be another advantage to medium-sized enterprises, because this is where we are more likely to find the moral courage for putting the customer’s benefit above the own profit, instead of, for instance, implementing any CR we come across. I am sure there is also an ethical component to this concept.
Here are a few more reasons why RE is so difficult and philosophy and enlightenment are so necessary:
The market dominance of Microsoft and SAP and a few more companies.
Paradox requirements: A good example for this is the Firewall Problem. It is supposed to be totally secure, yet all “entitled” persons must be able to enter at all times. Consequently, you get firewalls with 10,000 rules (defined exceptions). Naturally, this is no way of doing it. You get totally senseless security demands and consequences up to virtual barracks life (gated communities). With more than 100,000 participants, this is obviously not possible and totally dumb.
These are the kinds of challenges we can no longer meet with traditional methods.
“Cheap Design”
Now what is the role requirement engineering can or must play in order to define the requirements of a product if we aim at keeping it simple, economically priced and as efficient as possible?
The term Cheap Design was introduced by Rolf Pfeifer. Here is the Interview. Rolf Pfeifer is founder and director of the Artificial Intelligence Laboratory, Department of Informatics, University of Zurich. He first came up with the term “Cheap Design” and later established it. His most famous products are the cheap robots. Through totally innovative (cheap) approaches, they paved the way for completely new approaches in Robotics and Artificial Intelligence.
I recommend you all read his inspiring book: “How the Body Shapes the Way We Think: A New View of Intelligence” (Bradford Books).
Creative Products
Of course, conservative Requirement Engineering must fail when trying to give us a suitable approach. How can you describe the system requirements for a product you do not yet have any idea about? “Top down” approaches will certainly not work, since there is not yet any “top” to work with. Neither can I see iterative methods being a success. So are we supposed to start in an agile fashion in the sense of “plan”?
But even here, there are some reasonable methodical approaches. Let me just mention the already quite lively phenomenon of “Crowd Sourcing”. Our student apprentice Monika Bi wrote a research paper on this theme for InterFace. I gladly introduce the results of her work to you.
Tools
It happens all the time that I find myself in a situation where people try to solve problems simply by using new tools. Such tool devoutness gives me pause. In fact, this kind of procedure mostly causes a tool (and employment) overkill that does more damage than good.
Complexity is something you basically cannot solve with additional tools. Besides, we are already quite well-equipped with the tools we have, such as gira, svn, ea, uml and many more. What we need is not more tools, but alternative tools.
In my way of thinking, the so-called “creative tools” (as I recently experienced them in a project with UnternehmerTUM at TUM in a very attractive way) is one of them. But I am also thinking of internet technologies such as forums, blogs, twitter and the like. And, above all, videos and as a logical consequence soon Virtual Reality.
Even today, the fastest way to learn how to use Apple or Google is through videos.
Last not least: here is the most important factor. Let us call it
Psychology
It all starts wish how you ask your questions. As also the discussions about the previous presentations show, most of the questions are direct ones. This is most natural. After all, we usually have a pre-defined opinion which we prefer not to have openly questioned. Instead, we first want a confirmation. When working as partners, we are probably sometimes prepared to accept an opposite position after it has been really well presented.
However, if I want to understand another person’s problem and only ask questions that allow either “yes” or “no” for an answer, then all I get (if the negation is reasonable) is, for instance, ten times the answer “no”. But how can I presume to understand another person’s problem if all he did was answer “no” ten times in a row?
At first sight, it seems such an easy thing to ask open questions – but just try it and you will find how extremely difficult it is. Somehow or other, we have been conditioned to ask closed questions, perhaps because we are all a bunch of dogmatists.
Team versus Group
Terminologically spoken, it is not easy to differentiate between a team (Team) and a group at work (Arbeit) or in the army (Militär). In Wikipedia, too, I find too many contradictions.
In my understanding, a group is something that has been organized and trained. There are requirements to be met. The results will be measured and a reward will be granted accordingly.
I prefer the term “team”. In a team, we have a huge measure of self-organization. The problem is the common enemy, not the colleague in the team. People working in a team are capable and willing to listen.
And it is the highest priority of all team members to solve the task they have given themselves to the best of their ability and with the optimum result for the stakeholder through a common learning process. Unfortunately, this is not something that goes without saying. In my experience, it rarely happens, especially with processes of Requirement Engineering. And if it happens, then mostly only in medium-sized enterprises.
RMD
(Translated by EG)
P.S.
A lot of thanks to Evelyn for the translation of this so long post 🙂 !!!
Loading ...