Goals are intended, Requirements are imposed

A popular discussion in requirements engineering courses is about the difference between goals and requirements. One view is that goals are requirements on the highest level of abstraction. My question: Why should you call a requirement differently depending on the level of abstraction? A requirement is a requirement. I say this because I am convinced that it is only worth introducing a new term if it carries a different meaning, if it denotes a different concept.

Let us first look at the definition of a requirement. I prefer the definition by Alan Davis from [1]: “A requirement is an externally observable characteristic of a desired entity.” It provides two important statements about a requirement:

1. it shall be observable (on the entity as a black box) whether the requirement is fulfilled and
2. it is a required characteristic of an entity that does not yet exist, of a future entity.

A desired entity can be a system/product, an organisation, a business process or something similar. For the current discussion, I restrict requirements to those concerning desired systems/products. Justification follows in the next commentary.

Goals are defined in [2] as follows: “Goals are a stakeholder’s (e.g. a person’s or an organisation’s) description of a characteristic property of the system to be developed or the development project.” I share the view that goals are what people or organisations intend to achieve. Things have no goals, only human beings have. But I doubt that it is useful to express goals as properties of the desired system or of the project developing it. This is just another phrasing of the view that goals are requirements on the highest level of abstraction and, consequentially, requirements are refinements of goals. Until which level of refinement should we talk about goals? On which level should we start to talk about requirements?

I offer another view. Goals are a stakeholder’s (i.e. a person’s or an organisation’s) description of the benefit intended in the context of the system; this change is carried out in a project that may also, but does not need to, deliver an IT system. Typical intended benefits are: a business process shall be executed faster, with less resources, with more consistent quality, etc. This can be achieved by organisational measures and/or with improvement of the IT systems used. These systems must possess characteristics that contribute to the achievement of the stakeholder’s goals. That is what we require from them.

This view has the advantage that it helps us to evaluate requirements. If the implementation of a requirement contributes to the achievement of at least one goal, then it is justified to state it. If the implementation of a requirement does not contribute to the achievement of any goal, then it is not justified. Perhaps not justified yet. It can be that some valuable goal is not stated yet.

I have no doubt that this view is helpful.

We express the change/improvement in system context that we want to achieve in measurable goals. In most of the cases we will modify or develop IT systems to achieve these goals. We express the desired characteristics of these IT systems as requirements. And we check for every requirement whether its implementation contributes to the achievement of goals. This is useful. Besides the system context diagram with actors and external interfaces, the check against goals is the only means to evaluate the justification of requirements. I don’t know any other criteria to objectively decide whether a requirement is justified or not. But I am happy to learn about them if I missed any. With the definition of goals according to [2], I can’t see any benefit in distinguishing between goals and requirements.

So far I only dealt with IT projects that realise business process changes. But this concept is beneficial also for product development projects. There, the goals are seldom business process related. They usually express intended market achievements with the modified or new product. The goals are characteristics of the market that should be attacked: geography, segment, population, etc. It is possible, again, to evaluate the justification of requirements against goals expressed in such terms.

Figure 1 illustrates both cases for goals and requirements.

In summary, using the two terms goals and requirements is only justified if they denote different concepts. I suggest that goals should be statements about the desired system context, while requirements are statements about the desired system. Systems have no goals, people and organisations have goals. This concept provides a valuable means to check whether a requirement is justified for the considered IT system (or product): if its implementation contributes to the intended change in the system context, then it is.

Karol Frühauf

P.S: Thanks to Oliver Hoeffleur/INFOGEM who shared first my doubts and helped me to sharpen them. I also thank the reviewer for the suggested generalisation of goals as statements about the system context.

References and Literature

[1] Alan M. Davis: Just Enough Requirements Management. Dorset House, 2005, 
ISBN 0-932633-64-1.
[2] Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals. Rooky Nook Inc., 2011, 1. Edition, ISBN 98-1-933952-81-9.

This article was originally published in the Requirements Engineering Magazine, Issue 2017-01: All lights on green

When shall does not need to be must

I doubt whether it is always useful to include the priority in the wording of a requirement. A requirement expresses a need that a future system is supposed to satisfy. The priority of a requirement is intended to indicate how urgent it is to have the requirement implemented.

The Internet Engineering Task Force [1] did a great deal of work to define the modal verbs to be used to express priority of requirements in the standards issued by IETF.

IEEE standard [2] uses the term “degree of necessity” instead of priority. Instead of modal verbs, values of the requirements attribute “degree of necessity” are defined.

Of course, this can be applied to requirements other than functional ones too.

I especially like that the IEEE standard recommends use of the modal verb “shall” independently of the degree of necessity. If something is required, then it needs to be done. Therefore, it is natural to use a strong imperative to express a requirement. When (versus if) it needs to be done does not contribute anything to the understanding of the requirement, i.e. does not need to be included in the requirement’s expression.

The point in time when a requirement needs to be implemented can change during a project. If it is included in the expression of the requirement itself, then the requirement’s statement needs to be modified every time the requirement’s degree of necessity changes. This does not make sense to me. There is a good reason why in the agile world the priority is expressed by ranking in the backlog but not in the requirement’s description.

There is one exception. Calls for bids will usually not be maintained during the course of a project, so the degree of necessity of the requirements will not change during the project. In this case the attribute values essential, conditional and optional could be expressed e.g. in modal verbs shall, should and may. This does not mean that requirements or their degree of necessity will not or even must not change during the course of the project, but these changes will be reflected in other documents than the call for bid document.

The official IREB book [3] uses the term “degree of legal obligation” instead of priority / degree of necessity of a requirement and defines modal verbs to be used, but also opens a back door.

My view in summary:

1. A requirement is a statement about a future system.
2. The priority or degree of necessity or degree of legal obligation (I will use only degree of necessity from now on) is not a statement about the product but a characteristic of the requirement, needed for planning.
3. The two things thus serve different purposes and shall therefore be separated, i.e. the expression of the requirement shall not include its degree of necessity. This shall be managed as an attribute of the requirement or by other mechanisms of planning.
4. In order to simplify the handling, the degree of necessity can be included in the expression of the requirement using different modal verbs, provided the degree of necessity does not change (too often). I have so far identified two areas where this applies:
   1. Standards
      They are revised every 5 years. A clear definition of the modal verbs to express the degree of necessity and their consistent use in the standard’s requirements simplifies the standard document.
   2. Calls for bids
      They are revised rarely or not at all. Again, a clear definition of the modal verbs to express the degree of necessity and their consistent use in the requirements simplifies the call for bid document

My view can be considered as detailing the IREB definition.

I know that I did not consider all the nuances used in the field to express the degree of necessity. That was not my intention. My intention was to show the different nature of a requirement expression and the requirement’s degree of necessity. I doubt whether the two exceptions cover all situations where the inclusion of degree of necessity in the expression of the requirement is justified by a simplified handling of the requirements document. I am sure the readers of the RE Magazine can help me to get rid of this doubt.
A hint: If you’re interested in the topic you may visit
http://reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should/
and read “Using the correct terms – Shall, Will, Should”, posted on: October 9th, 2012 by Lou Wheatcraft with 15 comments.

Karol Frühauf

P.S: Thanks to Oliver Hoeffleur who shared first my doubts and helped me to sharpen them.

References and Literature

[1] S. Bradner: Request for Comments: 2119, The Internet Engineering Task Force (ITEF), Network Working Group March 1997
[2] IEEE Std – 830-1998 – IEEE Recommended Practice for Software Requirements Specifications
[3] Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals, Rooky Nook, Inc,, 2011, 1. edition, ISBN 98-1-933952-81-9.

This article was originally published in the Requirements Engineering Magazine, Issue 2016-03: An eye for detail.

Do you know what acceptance criteria are?

I doubt whether I understand what “acceptance criteria” are. I have no doubts how I interpret the term. In my interpretation, they have nearly nothing to do with requirements and certainly nothing to do with requirements engineering. Looking around in the real world of requirements engineering, I encounter the term being used with a completely different meaning. I doubt that introducing this meaning to the term is needed and useful.

In my simple world of software engineering, there are requirements and there are test cases. The tests of the system against the requirements are often called “acceptance tests”. What matters for acceptance tests, is who carries them out, rather than whether they are against system requirements. The test of a GUI component by a prospective user can be declared an acceptance test. Hence, what is of importance is the consequence of the test result. If it is used to decide whether the subject under test is fit for productive use, then the test is an acceptance test. By the way, the supplier can never take this decision.

What role do acceptance criteria play in my simple world of software engineering?

Acceptance criteria are a kind of counterpart to the contract. The most abstract acceptance criterion would be: are all contractual agreements fulfilled? To arrive at this decision, a checklist is usually developed and used to determine whether the overall criterion is satisfied.
The checklist contains acceptance criteria concerning:

• completeness of delivery (code, documents, training material, etc.),
• completeness and correctness of the functionality and properties of the software (e.g. records of executed tests),
• readiness of the organisation to use the system (e.g. successful training, availability and mastering of operational procedures in the user environment),
• readiness of the organisation to operate the system (e.g. availability and mastering of operational procedures in the operations unit), or
• readiness of the organisation to maintain the system.
  This list is not exhaustive. The checks are an investigation into whether the delivered items are o.k. and audits of the organisations that need to be ready.

We thus have a clear distinction between acceptance, acceptance test, and acceptance criteria. Acceptance is the decision whether the contractual obligations have been fulfilled. Acceptance test is a test with the purpose to find out whether the subject under test is fit for use. Its results will be used to decide upon product acceptance if they are subject of acceptance criteria. Acceptance criteria are the conditions that are checked in order to be able to take the decision to accept or reject (not yet accept) a product.

How are acceptance criteria used in the actual world of requirements engineering?

I encounter requirements engineering practices where “acceptance criteria” are a deliverable of the requirements engineer. My observations revealed in this context two uses for acceptance criteria:

1. acceptance criteria define conditions that are not stated in the requirement
2. acceptance criteria reformulate the requirement and mention data to be used to test whether the requirement is satisfied
   The first case is rather unfortunate, since the requirement seems incomplete without the acceptance criteria. How should one decide what shall be included in the requirement and what shall be expressed as an acceptance criterion? Why do we need two vehicles for the same thing? What is the benefit of expressing acceptance criteria as an addendum to a specification versus a complete specification of the requirement?

The second case is more adequate, but not quite. In this case, the so-called acceptance criteria are nothing else than the list of test cases the requirements engineer thinks should be executed. Instead of declaring the required coverage of the requirement and letting the test designer determine the test cases, the requirements engineer determines the test cases (and usually fails to declare which coverage criterion was applied). I don’t mind the requirements engineer (partially) doing the job of the tester. But why should we call what he is doing specification of acceptance criteria and not specification of a minimal set of (acceptance) test cases? (Hint: The required coverage is actually a management decision – it has to do with risks and money.)

The second approach resembles Specification by Example, though it has a different order of activities and less rigor in expressing the test cases (the acceptance criteria).

I doubt whether I grasped all the uses of the term “acceptance criteria” out there in the field. I have no doubts that what I did observe (mostly the half-hearted description of “test cases”) does not justify the use of the term “acceptance criteria” instead of test cases.

By the way, it is a shame I could not find the original source of acceptance criteria in the literature, neither in “agile” nor elsewhere. Thus, I have another doubt: acceptance criteria have no theoretical foundation. They are a pragmatic invention that cause more confusion than necessary.

I will be happy if you prove my ignorance or otherwise dispel my doubts.

Karol Frühauf, June 2016

P.S: Thanks to Oliver Hoeffleur who shared first my doubts and helped me to sharpen them

This article was originally published in the Requirements Engineering Magazine, Issue 2016-02: Take the broader view.

von Gundolf S. Freyermuth

Verlag Heinz Heise, 2002, ISBN 3-88229-191-5

Geschichte der Telekommunikation mit Tipps

Ich erwartete Tipps und Tricks, wann ich welches Kommunikationsmittel wie einsetzen soll. Ich kann nicht behaupten, ich habe nicht welche bekommen. Immer wieder fand ich mich in einem Kapitel mit "Top n Regeln für etwas". Aber es war insgesamt etwa nur jede sechste Seite, die mir das richtige Benehmen beim Nutzen eines Mediums beibringen wollte. Fünf von sechs Seiten sind der Geschichte der Telekommunikation vom Höhlenfenster unserer Urahnen bis zu Videokonferenzen mit Zeitgenossen gewidmet. Durchaus lehrreich und mit leichtem Tastendruck geschrieben. Nur, ich habe es nicht deswegen gekauft. Kommunikette ist ein Etikettenschwindel. Unnötig. Wenn der Autor (oder der Verlag) die richtige Erwartungshaltung mit dem Titel wecken würde, dann würde man das Buch entspannter lesen und es durchaus geniessen können. Die Regeln übrigens sind alle sehr sinnvoll; wenn man sie befolgt, kann man sich einige Peinlichkeiten ersparen und die Wirkung der Mitteilungen steigern.

Karol Frühauf, Mai 2010

von Corey Ladas
Modus Cooperandi Press, 2008, ISBN 978-0-578-00214-9

Lean gar nicht so dick aufgetragen

Der Titel ist irreführend. Dem Autor geht es mitnichten um eine Kombination von Scrum und Kanban, eher umgekehrt, Ladas erläutert uns, was an Scrum unzulänglich ist und dafür mit Lean in Form von Kanban für die Software-Entwicklung besser beherrscht werden kann. Es sind auch keine Essays im eigenen Recht, sondern eine fliessende Abhandlung der Lean Entwicklung mit Kanban. Da mein Interesse vor allem dem Wesen von Kanban in der Software-Entwicklung galt, bin ich sehr zufrieden mit dem Buch, weil es sehr anschaulich die Entwicklung des Prozesses von Scrum zum Kanban beschreibt. Leicht verständliche Sprache, ausreichend illustrierte Sachverhalte, unaufgeregt, überzeugend, etwas polemisch gegenüber Scrum. Deshalb wäre Swanban als Titel zutreffender.

Wenn ich für einen Augenblick die These von Ladas akzeptiere, dass Scrum eine niedrigere Stufe der Evolution des agilen Vorgehens ist, dann vermisse ich die Aussage, in welchen Situationen Scrum wohl hinreichend ist und ab wann ich erst mit Kanban glücklich werde. Mein Eindruck ist stark, dass dies bei grossen Teams der Fall ist; Kanban ist Scrum von Scrums überlegen. Je mehr Sie vom Scrum überzeugt sind, umso mehr lohnt sich das Buch zu lesen. Nicht, weil Sie den Glauben verlieren sollten, sondern weil Sie einem anderen in Ihrer Gedankenwelt Platz einräumen sollten; es könnte sein, dass das eine oder andere Prinzip, z.B. "ziehe das Abschliessen einer Arbeit immer dem Beginnen mit einer neuen Aufgabe vor" auch für Sie hilfreich ist. Und egal mit welcher Vorgehensweise Sie sich gerade herumplagen, das Prinzip "passe die aktuelle Arbeit in Bearbeitung deiner verfügbaren Kapazität an" müsste Balsam auf Ihre gepeinigte Seele sein. fangen Sie damit an, heute.

Karol Frühauf, 31. März 2010

von Susan M. Weinschenk, Ph.D.
New Riders, 2009, ISBN 0-321-60360-6

Bewusst das Unbewusste ansprechen animiert zum Kauf

Der Titel macht nicht neugierig, eine Usability Lesegruppe hat mir das Buch "aufgezwungen". Nach der Einführung ins Menschsein im Unterschied zum Tiersein werden 10 Prinzipien erläutert, nach denen wir handeln, wenn wir uns für das Eine oder Andere entscheiden, sei es eine Ware oder ein Mensch, wobei dieser Entscheid öfter irrational, d.h. unbewusst erfolgt als wir es uns einbilden. Das Glück dabei ist, dass unbewusst getroffene Entscheide nachhaltiger sind als die auf rationaler Analyse beruhenden. Sowohl in der Partnerschaft als auch beim Kauf von Kunstwerken. Durch wissenschaftliche Experimente nachgewiesen. Wie alle anderen Aussagen auch. Die Experimente sind kurz und anschaulich beschrieben. Die Ergebnisse nie quantifiziert, ihre Signifikanz muss der Skeptische in den immer referenzierten Originalen nachlesen.

Das Buch liest sich leicht, wenn man gute Augen hat. Der Kontrast des Texts auf dem unruhigen Hintergrund ist nicht lesefreundlich. Bei einem Buch über Benutzerfreundlichkeit irritierend. Jedes Kapitel hat eine Bottom Line mit der Essenz des Kapitels. Da manch eine dieser Aussagen bereits in einem Kasten im Text hervorgehoben wurde, liest man alles Wichtige mindestens drei Mal. Meine Augen lassen zwar nach, aber das Gedächtnis tut es noch ziemlich gut, ich kam mir manchmal wie in der Schulbank vor. Wenn Sie dabei sind, eine Web-Seite (neu) zu kreieren und Sie möchten mehr als nur informieren, finden Sie genug Nützliches im Buch, das den Kauf des Buches rechtfertigt.

Karol Frühauf, 25. Februar 2010

2005, Johanna Rothman und Esther Derby
The Pragmatic Programmer, 2005, ISBN 0-9766940-2-6

Keine grossen Entdeckungen, einige nützliche Tipps

Der Titel verspricht mehr als je von einem Buch wird wahr gemacht werden können. Das grosse Management erfolgt nicht hinter geschlossenen Türen. Dagegen bleibt es Geheimnis, warum es die einen schaffen und die anderen nicht, Menschen dazu zu bringen Sachen zu tun, die sie selbst nicht für möglich halten, tun zu können. Zu Ihrer Beruhigung: Die beiden Damen haben es auch nicht heraus gefunden. Was sie geschafft haben: ein paar praktische Hinweise zusammenzustellen, die in alltäglichen Situationen in Projekten nützlich sein können. Es sind primär Checklisten und Verhaltensregeln. Nichts, was einem in einer oder anderer Form nicht bereits begegnet wäre, aber gut zusammen gestellt. Schade, dass der Verlag am Papier spart, und zwar nicht an der Menge, der Zeilenabstand ist gross genug, sondern an der Qualität: Taktil ist das Buch ein unangenehmes Erlebnis. Der Schreibstil ist gar kein Erlebnis, aber ganz und gar nicht störend.

von Ivars Peterson

Vintage Books, 1996, ISBN 0-679-74027-9

Über Fehler lernen um aus Fehlern lernen zu können

Wir wissen es von Henry Petroski ('To Engineer Is Human'), dass man aus (katastrophalen) Fehlern mehr lernen kann als aus Erfolgen und warum dem so ist. Beim Brückenbau. Es gibt wenig bis gar keinen Grund anzunehmen, dass es bei Software anders ist. Darum müssen wir jedem dankbar sein, der uns mit einer Analyse von Software-Fehlern mit signifikanten Auswirkungen beschenkt. Nancy Leveson ('Safeware') hat ein ganzes Buch dem Therac-25 Fall gewidmet, der auch in diesem Buch besprochen wird. Peterson ist kein Software-Täter, ich schätze ihn als Mathematiker ein, wegen der Genauigkeit, mit der er den Fällen nachgeht und zum Wesen des Problems vordringt. Und uns die Chance bietet zu überlegen, ob in unserem Umfeld so was auch passieren könnte und wenn ja, welche Konsequenzen es haben würde und ob es nicht gut wäre, für Vorkehrungen zu sorgen. Es klingt nach Risikomanagement, vermutlich ist es auch. Wenn es seinen einmaligen Charakter verliert, wird es zur Prozessverbesserung.

Das Buch ist geeignet für Vielreisende, die einzelnen Essays bereichern eine langweilige Reisestrecke und vielleicht bleibt noch Zeit, über das Gelesene bis zum Dösen nachzudenken.

Karol Frühauf, Juli 2009

by Karl E. Wiegers, Addison-Wesley Professional, 2002, 256 pp., ISBN 0-201-73485-0, US$39.99

A Guide on Inspections and Other Review Techniques

I was eager to read Peer Reviews in Software for three reasons: first, to see if it confirmed my experience; second, to learn something new; and third, to steal ideas for better presentation of the topic in my teaching. But judging the book on the basis of my expectations would be unfair. It deserves to be measured against Karl Wiegers’ goal. In his own words, “the principal goal of this book is to help you effectively perform appropriate reviews of deliverables that people in your organization create.” It’s primarily intended for people who want to participate in reviews and people who should encourage reviews in their organizations. The book completely satisfies the expectations it creates. It is well organized, sticks to the topic, and provides all the information the reader needs, all in easy-to-understand language. The book isn’t only about software quality, it’s also a piece of quality work.

Wiegers

1992, Hal F. Rosenbluth, Diane McFerrin Peters
Quill William Morrow, New York, 1992, ISBN 0-688-13246-4

Wer soll denn als erster kommen, wenn nicht die Mitarbeiter?

Das Buch erzählt in einer einfachen Sprache eine Vielzahl von Geschichten aus dem Rosenbluth Reisebüro, ein Paradebeispiel für Dienstleistung und ein Dienstleistungsunternehmen par excellence. Es ist erfrischend, ein Buch über Qualitätsmanagement in Reinkultur zu lesen ohne ein einziges Mal über Business Excellence, TQM oder ISO 9000 und daraus abgeleiteten Phrasen, Floskeln und Buzzwords zu stolpern. Ach, tat es gut, darüber zu lesen, wie man sich um Neueintritte kümmern kann, wie man überhaupt Mitarbeiter auswählen kann, wie man Informatik als Werkzeug einsetzen kann oder wie man eine Unternehmenskultur aktiv kreieren und hegen kann.

Rosenbluth

1999, Tom DeMarco, Timothy Lister

Remakes im Trend

Sollten Sie zu der raren Sorte Menschen gehören, die Peopleware noch nicht gelesen hat, muss ich sie vor dem Genuss diese Buches warnen: Es besteht Suchtgefahr. Aber es gibt viel gesundheitsschädigenderen

Suchtmittel als dieses. Warum sollten Sie sich der Suchtgefahr aussetzen? Vielleicht, weil Sie nach eingehender Begründung für das Unbehagen suchen, das Sie am Software-Arbeitsplatz haben? Weil Sie wissen wollen, warum es falsch ist, was Sie am Tun und Handeln Ihrer Manager als falsch ansehen? Oder eine Bestätigung haben wollen, dass Sie das Recht haben, ungestört arbeiten zu können und auf die persönliche Gestaltung ihres Arbeitsplatzes. Nicht im Namen der Rose, sondern der Produktivität und Qualität. Gründe genug, das Buch zu lesen, treten Sie dem Peopleware-Club bei.

DeMarco-Weinberg

Silver Anniversary Edition
1998, Gerald M. Weinberg

Guter alter Wein braucht keine neuen Schläuche

Bei der Aufmachung des Buches hat sich der Verlag mehr um Authentizität als Schönheit bemüht. Schade. Dies trübt ein wenig den Lesegenuss dieses Kultbuchs meiner Generation. Und die nachfolgende(n) täte(n) gut daran, die Ratschläge zu beherzigen, denen meine nur zugestimmt hat.

1999, Richard S. Schifman, Yvonne Heinrich, Günther Heinrich

Qualität von Multimedia und ihrer Produktion

Das Buch ist mehr über Multimedia als über Projektmanagement. Ich habe viele Hinweise erhalten aber mir keine Übersicht verschaffen können. Daraus folgt, dass das Buch für Personen nützlich ist, die eine Übersicht haben aber mit den Details nicht fertig werden.

Schifmann

1999, Oliver Merx (Hrsg.)

Die Qualität liegt im Auge des Lesers

Das Buch ist nicht geeignet für Personen, die ein Kochrezept suchen, wie sie fehlerfrei erfolgreiche Multimedia-Anwendungen produzieren können. Ich habe viele Ordnungskriterien, Klassifizierungen, Merkmale, Handlungsanweisungen gefunden. Sie sind nicht konsistent und ergeben kein abgerundetes Bild. Sie sind wertvolle Mosaiksteine, geeignet mein Multimedia-Weltbild abzurunden. Ist man bereit dies zu tun, ist das Buch ein nützliches Nachschlagewerk.

Frank P. Ginac, Prentice Hall PTR, Upper Saddle River, NJ 07458, 1998, 141 pp., ISBN 0-13-571464-8
September 1999

A right but incomplete introduction

This handy and easy-to-read book intends to present software quality assurance with the customer as the focus. This is certainly a laudable effort (and a difficult job). The few selected topics covered by the book are on an introductory level. They are all handled correctly; what is there is right. What is not right is that too much is missing for a comprehensive approach.

The author identifies upper management as the primary audience of his book. If its members are not hampered by some knowledge of software engineering and quality management they will find the book a good reading, e.g. on a flight to a customer. The book has the most value for management or quality professionals who have not yet mastered the communication with software professionals, although they ought to. They find here an introductory text for some areas of software quality but unfortunately no hints that some pieces of the puzzle are missing and where to find them.

Ginac

Robert L. Glass: Prentice Hall PTR, Upper Saddle River, NJ 07458, 1998, 259 pp., ISBN 0-13-673443-X
March 1999

Software Runaways - Projects to Learn from

„There seems to be a much more indelible lesson to be learned from failures than from successes.“ is one of the first sentences in the preface of the book. Robert L. Glass collected more than a dozen stories about software projects which failed with an echo in the public.

A software runaway is „a project that goes out of control primarily because of the difficulty of building the software needed by the system“. Glass’ definition of ‘out of control’ is really out of control – project consumed twice its allotted estimated time or more and consumed twice its estimated cost or more and the product could not meet the (functional, reliability) requirements. It is this high standard which prevented him from including more war stories.

„Perhaps because software is a product built from no physical resources, a product constructed purely out of intellect, it is especially devastating to the psyche when it fails.“ It is even more devastating that it is an accepted behavior, it is considered to be business as usual that projects or activities within a project don’t meet the targets. ‘O.k. you did not keep the deadline – when do you think you’ll accomplish the task?’ That’s it. No search for reasons, no consequences, no learning on either side. This type of culture inevitably leads to runaways.

Glass

1997, Christian Horn, Immo O. Kerner (Hrsg.)
Fachbuchverlag Leipzig im Carl Hanser Verlag München Wien, 1997, ISBN 3-446-18699-9

Praktische Informatik für ungeübte Studenten

Das gesamte Werk verspricht ein wertvolles Lehr- und Lernmittel für Fachschulstudenten zu werden. Im vorliegenden Band finden sie eine gute Übersicht über Programmiersprachen; alle heute praxisrelevanten Programmier-Paradigmen sind vertreten. Zum Selbststudium würden wir das Werk nicht empfehlen; das tun auch die Autoren nicht.

Horn

1996, Johann Blieberger, Johann Klasek, Alexander Redlein, Gerhard-Helge Schildt
Springer Wien New York, 1996, ISBN 3-211-82860-5

Informatik fällt nicht vom Himmel

Wir haben nur wenige faktische Fehler in den Kapiteln Algorithmen und Boolsche Algebra entdeckt. Das Buch ist sorgfältig verfasst.
Wenn wir uns vorstellen, in einer sechsstündigen Vorlesung zu sitzen, in welcher in einem Semester das ganze Buch durchgepaukt wird ... Wäre etwas weniger vielleicht mehr?

Blieberger

1997, Tom DeMarco
Dorset House Publishing, New York, 1997, ISBN 0-932633-39-0

Software-Management als Krimiroman

Am Anfang war ich hin (weiterlesen) und her (aufgeben) gerissen. Das Buch beginnt nicht mit dem Knall. Langsam, zum Teil holprig und plakativ wird die Geschichte aufgebaut. Weil ich Tom DeMarco und sein bisheriges Werk kenne, riss mich meine Neugier hin. Zum Glück. Sobald er auf dem heimischen Boden ist (ich meine Software Engineering, nicht Morovia), gewinnt die Geschichte an Fahrt, die Dialoge fliessen wie von selbst und es entstehen Bilder des Projektalltags. Eines Projektalltags, den wir erträglicher gestalten können, wenn wir uns von diesem Buch inspirieren lassen.

DeMarco