"Who in their right mind would ever need more than 640K of RAM?"
(dt.: "Welcher vernünftige Mensch würde jemals mehr als 640K RAM benötigen?")
(Bill Gates, Microsoft Gründer, 1981)

Technische Anforderungen

Die technischen Anforderungen gehören zu den wesentlichen nichtfunktionalen Anforderungen (engl.: non functional requirements, NFR) und werden genauso wie die funktionalen Anforderungen vom Kunden gestellt. Dabei ist auf Grenzwerte und Plausibilitäten genauso zu achten wie auf Leistungsanforderungen (engl.: performance requirements, PR), z.B. Übertragungsraten von Standorten oder Antwortzeiten einer Datenbank. Ein beliebtes Thema ist sicherlich auch die Ausfalltoleranz: Hier wird schnell leichtsinnig eine Verfügbarkeit von 99,999% gefordert, ohne darüber nachzudenken, was das eigentlich wirklich bedeutet und welche immensen Kosten es aufwirft. In der Praxis bleiben davon oft nur noch geforderte 99,0% über (bei beispielsweise 250 Arbeitstagen im Jahr also immerhin noch 2,5 Ausfalltage). Die Technologieplattform (Soft- und Hardware) wird also an dieser Stelle genauso festgelegt wie das Testsystem und das Lieferverfahren, also das technische Deployment über das Testsystem ins Echtsystem.

Die technischen Anforderungen führen in der Regel auch zu den Systemanforderungen, die jeder von den Produktkartons her kennt. Wenn Ihr Produkt nicht in so einem Karton landet, ist es dennoch für den Support und das Administrationsteam wichtig, diese Systemanforderungen zu kennen und bei der Installation bzw. bei Problemen zu prüfen.

Natürlich sollte der Anbieter auch bei den technischen Anforderungen dem Kunden mit Rat und Tat zur Seite stehen, aber er sollte auf keinen Fall den Kunden zu einer Technologie überreden, nur weil er diese selbst am besten beherrscht. In der Regel hat der Kunde auch bereits hohe Investitionen in der technischen Infrastruktur gebunden, so dass die Flexibilität hier heutzutage eher gering ist. Früher wurde noch gefragt: "Welchen PC sollen wir uns denn am besten für das Programm kaufen?" Heute legt die IT-Abteilung des Hauses sofort die IP-Adresse des zu verwendenden Datenbankservers auf den Tisch.

Ein professioneller Softwareentwickler sollte heute auch in der Lage sein auf die Betriebssystem-Neigungen des Kunden einzugehen und die momentan so beliebte Religions-Diskussion um Linux/UNIX/Windows oder Sun-ONE/BEA/IBM-Websphere oder J2EE/.NET sachlich zu führen! Gleiches gilt für die Diskussion um Open Source und kommerzielle Software, die auch immer etwas einer Diskussion um Kirche und Staat gleicht. Vor allem mit Prognosen für die Zukunft sollte man dem Kunden gegenüber immer vorsichtig sein, wie der Spruch oben auf dieser Seite und oben auf der Folgeseite zeigt. Derlei Diskussionen und Prognosen gehören vielleicht doch eher an den Entwicklerstammtisch.

T-Shirt

Da ist die Diskussion um den Einsatz einer komponentenorientierten Architektur zur Unterstützung eines EAI-Ansatzes schon viel sinnvoller. Diese Diskussion werden Sie als Anbieter bei größeren Kunden wahrscheinlich auch nicht mit der Fachabteilung, sondern mit der zentralen IT-Abteilung führen, aber die Fachabteilung von der Notwendigkeit der Diskussion erst mal überzeugen müssen (oft muss die Fachabteilung den Kontakt herstellen). Diese Diskussion mit der IT-Abteilung kann auch durchaus etwas länger ausfallen, falls es noch gar kein Konzept für einen EAI-Ansatz gibt - und dies ist leider immer noch die Regel.

Oft werden technische Anforderungen auch von der Revisionsabteilung oder vom Betriebsrat gestellt, wenn es beispielsweise darum geht, personenbezogene Daten zu schützen, Mitarbeitertätigkeiten zu protokollieren oder Unternehmensgeheimnisse zu speichern. Aufgrund der historischen Entwicklungen der IT in den Unternehmen sind die technischen Anforderungen manchmal auch äußerst skurril, aber in der Regel gibt es auf Nachfrage tatsächlich eine - auf gewisse Art - plausible Erklärung dafür.

Gerade in den ersten Gesprächen spielen die technischen Anforderungen eigentlich keine Bedeutung: werden sie genannt, sollten sie natürlich aufgenommen werden, ansonsten sollten sie aber erstmal ignoriert werden. So können Sie als Analytiker vermeiden, dass die Diskussion vom "was" zum "wie" abdriftet. Die technische Diskussion ist für Softwareentwickler oft greifbarer und daher einfacher als die fachliche, aber die fachliche ist die weitaus wichtigere. Als Auftraggeber können Sie dies durchaus als Erkennungsmerkmal für die Projekterfahrung Ihres Anbieters nutzen!

Beispiele

Die strategische Plattform für Applikationen im Unternehmen ist der Sun ONE Application Server 7.0 auf Solaris 8 mit Oracle 8.1.6. Als Client wird der Microsoft Internet Explorer eingesetzt. Die SAP-Schnittstelle ist mit dem SAP-Java-Connector zu realisieren, während bei der Anbindung an das Dokumenten-Management-System der vorhandene Web-Service zu nutzen ist.

Die Software ist mit Microsoft Visual Basic 6 zu entwickeln und muss auf dem Citrix Terminal Server lauffähig sein. Die Daten sind auf einem Microsoft SQL-Server 2000 zu speichern.

Dauert die Erstellung des Reports länger als 3 Minuten, so ist dieser automatisiert jede Nacht als PDF-Dokument zu erstellen, damit er den Anwendern jederzeit zur Verfügung steht.

Die ...-Daten sind ausschließlich über Stored Procedures zu speichern und es dürfen keinerlei Rechte auf die Tabellen für Anwender vergeben werden; alle Tätigkeiten der Prozeduren auf den Tabellen sind per Trigger zu protokollieren und die Protokolltabellen müssen jede Nacht automatisiert an ... übermittelt und geleert werden.

Die Daten in der Tabelle ... sind mit einem Algorithmus und Kennwortmechanismus zu verschlüsseln, die noch zur Verfügung gestellt werden.

Die Authentifizierung der Anwender soll von Windows übernommen werden, die Autorisierung über eine unternehmenszentrale Datenbanktabelle gesteuert werden.

Die Schnittstelle zum Chipkartenleser der Versichertenkarten muss unterstützt werden.

Die Applikation darf die CPU zu keiner Zeit um mehr als 80% belasten, um Zeiten für Hintergrundtasks frei zu halten.

Einige Anwendungsfälle müssen für die Class-A-Kunden im Internet erreichbar sein. Dazu ist ein möglichst einfacher aber sicherer Authentifizierungsmechanismus zu integrieren. (Hier ist sicher mindestens eine weitere Diskussion zwischen Technikern beider Seiten erforderlich, um das zunächst offensichtlich sehr hohe Abschätzungsrisiko aus der Anforderung los zu werden. Die Ergebnisse dieser Sitzung müssen im Protokoll möglichst auch für Nicht-Techniker nachvollziehbar festgehalten werden, weil an den späteren Streits über die Kosten die Techniker nicht mehr dabei sein werden. Ferner ist zu klären, welche Anwendungsfälle betroffen sind, damit auch "von außen" ein vollständiger Eindruck der Software entsteht und keine Links vor die Wand laufen.)

in Barcelona