Der Artikel ist bei Oldenbourg als PDF erhältlich.

1. Einleitung

Das konkrete Vorgehen und der gewählte Methodeneinsatz im Usability- bzw. Requirements-Engineering hängen von verschiedenen Kontexten ab. Dies zeigte sich schon auf der UPA-Session „Usability Professionals und Requirements Engineering – Erfahrungen und Trends“ auf der Mensch und Computer 2003 in Stuttgart (Beck et. al. 2003). Dort wurden sehr unterschiedliche Erfahrungen präsentiert, je nachdem ob eine Individualentwicklung oder eine Produktentwicklung im Fokus stand. Verschiedene Widersprüche ließen sich erst auflösen, nachdem die Art der Entwicklung explizit gemacht wurde. Zum Beispiel ist es für die meisten Individualsoftwareprojekte kein Problem die Teilnehmer für eine Fokusgruppe zu finden. Für die Entwicklung von Produktsoftware kann dies eine aufwändig zu planende Aktivität sein. Andererseits wird bei Individualsoftwareprojekten meist auf klassische Fokusgruppen verzichtet, da in der Regel feste Ansprechpartner aus Fachabteilungen abgestellt werden, die in der Konzeptphase intensiv mitarbeiten. Fokusgruppen werden hier zum Beispiel dafür genutzt, um die Ergebnisse der Projektgruppe zu verifizieren („Arbeiten alle Abteilungen so?“).

Auf der Mensch und Computer 2004 haben wir daraufhin in einem Workshop die Unterschiede im konkreten Usability- und Requirements-Engineering in unterschiedlichen Kontexten erarbeitet. Die Thesenpapiere dieses Workshops und das Ergebnis der Diskussion bilden die Basis für diesen Beitrag (Strauß et. al. 2004).

1.1 Ziel des Workshops

Die Veranstaltung wurde als offener Workshop mit 3 Vorträgen zu den unterschiedlichen Software-Arten durchgeführt. Es wurden Thesen zur Requirements-Analyse vorgestellt und in der Diskussion verfeinert. Schwerpunkt war der Erfahrungsaustausch zur praktischen Umsetzbarkeit von Spezifikationstechniken und Usability-Methoden und eine darauf aufbauende kontextbezogene Bewertung.

1.2 Begriffsklärung

Wir erläutern hier kurz die wichtigsten Unterschiede zwischen Individualsoftware und Produktsoftware.

1.2.1 Produktsoftware

Produktsoftware wird ohne einen konkreten Auftrag für den Markt entwickelt. Die konkreten Anwender und Benutzer einer Produktsoftware kaufen das fertige Produkt und setzen es in ihrem Betrieb ein. Typische Beispiele für Produktsoftware sind Betriebssysteme, Office-Pakete, SAP R3, usw. Das Synonym „Standardsoftware“ deutet darauf hin, dass die unterstützten Prozesse, Aufgaben und Funktionen standardisierbar sind. Produktsoftware zeichnet sich in ihrer Reinform durch folgende Punkte aus:

• Die späteren Benutzer sind zum Entwicklungszeitpunkt nicht bekannt.
• Der Leistungsumfang der Software – evtl. auch nur bestimmte Features oder Funktionen, die die Konkurrenz schon bereitstellt – kann für den einzelnen Käufer entscheidend sein.
• Die Nutzung der Software und die zu unterstützenden Prozesse können beliebig weit von den bei der Softwareerstellung intendierten Prozessen abweichen.
• Die Software wird in vielen verschiedenen Installationen betrieben und es befinden sich unterschiedliche Versionen auf dem Markt.
• Die Software wird oft nachträglich an Kundenbedürfnisse angepasst.

1.2.2 Individualsoftware

Individualsoftware zeichnet sich dadurch aus, dass sie im Kundenauftrag entwickelt wird. In der Reinform entwickelt ein Auftragnehmer eine Software im Auftrag eines Kunden, der dieser bei sich im Hause einsetzt. Individualsoftware zeichnet sich durch folgende Punkte aus:

• Der Anwender und insbesondere die späteren Benutzer stehen fest und können über Repräsentanten in das Entwicklungsprojekt eingebunden werden.
• Der Leistungsumfang der Software wird durch ein Pflichtenheft (bzw. Anforderungsdokument, Grobspezifikation o. ä.) definiert.
• Die Software ist langlebig und unterstützt die individuellen Kernprozesse des Kunden optimal und verfügt – vor allem bei den betrieblichen Informationssystemen – über vielfältige Schnittstellen zu anderen Systemen des Kunden.
• Die Software wird oft nur einmal installiert und nachträglich nicht mehr verändert. Updates sind nur selten erforderlich.

Typisches Beispiel für eine (betriebliche) Individualsoftware ist die Auftragsabwicklung für PKW-Bestellungen, die aus Auftragseinbuchung, Baubarkeitsprüfung des Fahrzeugs, Austausch der Daten mit dem produzierenden Werk, Distribution zum Auslieferungsort und der Fakturierung des Fahrzeugs besteht.

2. Anforderungsermittlung bei Produktsoftware

Die hier vorgestellten Methoden und Prozesse rund um das Requirements-Engineerung bei Produktsoftware gründen sich auf die Erfahrungen, die die Autoren bei der Entwicklung von Enterprise Content Management Systemen (Livelink ECM der Open Text Corporation) und Office-Software (OpenOffice.org/StarOffice von Sun Microsystems) gewonnen haben.

2.1 Erhebung der Anforderungen

Im Gegensatz zu Individualsoftware ist für die Entwicklung einer Produktsoftware die genaue Kenntnis des Absatzmarktes von zentraler Bedeutung.

Die Anforderungen dafür stammen aus zahlreichen Informationskanälen. Externe Quellen sind beispielsweise Befragungen von Bestandskunden oder Partnern, Marktrecherchen oder Wettbewerbsvergleiche. Intern werden Feature-Requirements u. a. von den Abteilungen Sales, Services oder Support eingebracht.

Die Vorgehensmethoden lassen sich in subjektiv und objektiv klassifizieren.

2.1.1 Subjektive Methoden

Subjektive Methoden beziehen sich unmittelbar auf die Beurteilungen und Einschätzungen der Benutzer. Bei Sun nennt sich dieser Teil des Requirements-Engineering „Voice of the Customer“. Mittels Online-Fragebögen werden mehrere hundert Kunden befragt, wie sie die aktuelle Software bewerten und welche Funktionen sie sich für die nächste Version wünschen. Durch den Open Source Ansatz bei OpenOffice.org werden solch Fragebögen auch auf der Community-Website eingesetzt. Die Zahl der Antworten ist dabei ungleich größer und beträgt bei der letzten Umfrage mehr als 200.000. Eine dritte Fragebogenvariante betrifft die Usability-Studien im Labor. Über den SUS-Fragebogen kann man neben den objektiven Daten subjektive Einschätzungen der Testperson über die vorliegende Software erheben.

Die Marketing-Gruppe führt des weiteren Interviews beim Kunden und Diskussionen in Fokusgruppen, die zusätzlich dabei helfen sollen die Erwartungen des Kunden zu ermitteln.

Neben den schon erwähnten internen Quellen für Feature Requests formuliert die Open Source Community ihre Wünsche auch ganz explizit als Request for Enhancements (RFEs) und legt diese selbstständig mittels Web-Formular im Task-Tracking-System ab.

Bei Open Text werden zahlreiche User Research Aktivitäten durch das User Experience Team durchgeführt und User Communities geben regelmäßig Feedback über derzeitige und zukünftig gewünschte Entwicklungen und Erfordernisse. Daneben wird durch vielfach genutzte Feedback-Kanäle und Umfragen z.B. des Support direktes Endbenutzer- und Kundenfeedback eingesammelt.

2.1.2 Objektive Methoden

Menschen sind sich nicht immer – oder sogar nur selten – darüber bewusst, was und warum sie etwas tun. Umso schwerer fällt es ihnen auch, sich von emotionalen Einflüssen frei zu machen und eine Situation richtig einzuschätzen (Vroon 1993). Objektive Methoden setzen nun anstelle der Bewertungen des Benutzers die Beobachtung. Kundenbesuche (Site Visits) haben das Potential bis dato unbekannte Arbeitsabläufe zu entdecken, da die User Experience Experten den Benutzer im Kontext seiner alltäglichen Arbeitsumgebung begleiten (Job Shadowing).

Eine weitere wichtige objektive Methode ist das Usability-Testing. In einer Laborsituation werden Benutzer an das eigene Produkt, das der Konkurrenz oder an einen Prototypen gesetzt, um damit eine gegebene Reihe von Aufgaben zu bearbeiten. Ein Prototyp muss dabei nicht immer ein Computerprogramm sein. Mit Papier-Prototypen lassen sich sehr kostengünstig verschiedene Designalternativen ausprobieren (Snyder 2003). Wenn die Produktentwicklung allerdings schon etwas vorangeschritten ist, oder wenn man sich nicht mehr im ersten Produktzyklus befindet, können Benutzertests auch direkt in produktiven Umgebungen bei Kunden durchgeführt werden.

2.1.3 Bewertung der Methoden

Den einen typischen Benutzer von Produktsoftware gibt es nicht. Man hat sich also immer der Frage zu stellen, inwiefern die Benutzer, von denen man Daten erhoben hat, repräsentativ für die Zielgruppe der Software sind. Bei gezielten Fragebogenaktionen hat man dieses Problem gut unter Kontrolle; aus einem Adresspool werden bestimmte Kunden ausgewählt und um ihre Mithilfe gebeten. Bei offenen Fragebögen auf Websites ist nie klar, wer diese ausfüllt. Genau wie bei den RFEs bleibt zu vermuten, dass eine aktive Minderheit eine schweigende Mehrheit überstimmen könnte. Positiv ist aber anzumerken, dass Fragebögen sowohl im Stichprobenumfang, als auch in globaler Hinsicht gut skalieren. Bei allen anderen Methoden ist es sehr aufwändig, Requirements und Usability-Probleme einer internationalen Benutzergruppe zu ermitteln.

Bei direktem Benutzer- oder Kundenfeedback ist darauf zu achten, welche Rolle die Befragten haben. Hier kann der Unterschied zwischen einem Kunden, der die Software für eine größere Firma kaufen soll, und dem Mitarbeiter, der tagtäglich mit der Software arbeitet, sehr erheblich sein.

Alle subjektiven Methoden haben gemeinsam den Nachteil, dass sie nur eine vermittelte Sichtweise abbilden. Dennoch bieten sich hier sinnvolle Möglichkeiten der Requirements-Analyse, insbesondere wenn man seinen Gesprächspartnern im wortwörtlichen Sinne zuhört. Mark Federman führt das sehr schön anlässlich der Customer Relationship Management Conference aus (Federman 2001). Das natürliche Gespräch zwischen Anwender und Requirements-Engineer birgt in seinen Nuancen wichtige Einsichten für die Gestaltung der Software.

2.2 Von den Anforderungen zum Produkt

Für die Entwicklung von Produktsoftware konsolidiert, kategorisiert und priorisiert das Produktmanagement zu Beginn der Spezifikationsphase alle vorliegenden Requirements und erarbeitet eine Gesamt-Produkt-Roadmap, die mehrere sukzessive Versionsprojekte umfasst. Wie die Erfassung erfolgt die Verwaltung der Requirements mittels einer Datenbank mit Webfrontend. Mit Hilfe einer Priorisierungsmatrix werden Kriterien wie z.B. quantitativer bzw. qualitativer Customer Benefit, strategische Bedeutung für das Gesamtproduktfolio und Usability-Aspekte abgefragt. Daraus entsteht die endgültige Fassung in Form eines Version Proposal. Die Entwicklungsabteilung prüft die technischen Realisierungsmöglichkeiten der darin enthaltenen Funktionsanforderungen und spezifiziert deren Umsetzung unter Berücksichtigung des Zeitrahmens in einer Version Specification, die bei Open Text nach dem Muster des Volère-Template ausgearbeitet wird.

Dem folgt in der Implementierungsphase die Ausarbeitung eines detaillierten GUI-Konzepts. Benutzertests und Expert Walk-Throughs werden Projekt begleitend durchgeführt, um festgestellte Usability-Schwächen und Abweichungen von den erhobenen Anforderungen noch vor Fertigstellung der Version korrigieren zu können. Bei Updates werden oft nur Konzepte für wenige neue Dialoge oder Dialogerweiterungen benötigt. Der Fokus verlagert sich hier hin zur Evaluation von Benutzerprofilen (ggf. Personas) und Nutzungskontexten.

Kurze Versionszyklen ermöglichen ein flexibles, iteratives Vorgehen. Bild 1 zeigt eine schematische Darstellung eines Versionsprojekts.

Bild 1: Versionsprojekt im Rahmen einer Produktplanung

3. Anforderungsermittlung bei Individualsoftware

Die in diesem Abschnitt beschriebenen Erfahrungen beziehen sich auf betriebliche Informationssysteme, die von sd&m als Individualsoftware konzipiert und implementiert werden. Hierzu gehört die oben schon genannte Auftragsabwicklung für PKWs von Daimler Chrysler oder auch im Bereich Tourismus ein System zur Verwaltung von Unterbringungen (Zimmer, Appartements, Schiffskabinen, Hotels einer Rundreise, …) mit ihren Stammdaten bei Thomas Cook (mit Zuordnung zur Einkaufssicht und Katalogsicht). Typischerweise sind die Projekte zwischen 5 und 50 Bearbeiterjahre groß. Die Entwicklung von Individualsoftware erfolgt in aller Regel in den Phasen Spezifikation (Fachkonzept), Konstruktion (DV-Konzept / technisches Design), Realisierung, System-Test & Integration, sowie Inbetriebnahme & Rollout. Diese Phasen werden üblicherweise jeweils für ein Release durchgeführt. Vorgelagert gibt es Studien und Grobkonzepte, die ein Thema ganzheitlich betrachten oder Strategien konkretisieren und geeignete Projekte mit einem oder mehreren Stufen definieren (Krug et. al. 2002, Kretschmer et. al. 2002).

3.1 Anforderungsermittlung als Teil der Spezifikation

Die bei Produktsoftware übliche iterative Ermittlung, Verfeinerung und Priorisierung der Anforderungen ist hier theoretisch nicht nötig, da die Anforderungen mit der Definition der zu unterstützenden Prozesse und Aufgaben fest stehen sollten. Da der Kunde bei der Anforderungsermittlung auch „ausreichend“ zur Verfügung steht, ist es nahe liegend, die Anforderungen zu Beginn des Projekts vollständig zu ermitteln. In Individualsoftware-Projekten tauchen jedoch folgende Schwierigkeiten in der Anforderungsermittlung auf, die solch ein Vorgehen verhindern:

• Anforderungen sind nicht widerspruchsfrei, so dass die Ermittlung konsistenter Anforderungen eine besondere Herausforderung ist.
• Durch die Einbindung in existierende Abläufe und die Anbindung an viele Nachbarsysteme entstehen viele detaillierte Vorgaben an das System.
• Die Benutzer haben Schwierigkeiten Anforderungen zu formulieren bzw. Anforderungen zu validieren.
• Anforderungen ändern sich, da die zu unterstützenden Prozesse – bzw. allgemein: die Umwelt – sich ändert.
• Die zu unterstützenden Prozesse sind in aller Regel im Unternehmen schon lange etabliert. Das Wissen über die entsprechenden Anforderungen an das System ist aber über Abteilungen verteilt. Neue mit dem System eingeführte Prozesse bzw. Funktionen führen zu neuen Anforderungen, die vorab nicht oder schlecht vorhergesehen werden können.

Eine vollständige Anforderungsanalyse als eigenständige Phase wird aus diesen Gründen selten durchgeführt. Stattdessen wird die Anforderungsanalyse mit der Spezifikationsphase verwoben. In einer frühen Phase, häufig noch vor der Spezifikation, muss aber die zu erbringende Leistung für den internen oder externen Auftragnehmer definiert werden. Am Anfang der Spezifikation – bei komplexen oder unklaren Themen ggf. in einer Vorabstudie oder einem Grobkonzept – steht die Festlegung einer kurzen Anforderungs-, Leistungsausgrenzungs- und Prämissenliste („ALP-Listen“) im Vordergrund. In typischerweise je 5-25 Punkten wird vor allem den Umfang des Systems als Basis für eine Beauftragung durch den Kunden definiert. Die hier festgehaltenen Anforderungen beschreiben also eher, was das System unterstützen soll und nicht, wie das System genau funktioniert.

Die detaillierten Anforderungen werden nur implizit dokumentiert, indem die Spezifikation des Systems entsprechend erweitert wird. Dies hat zwei wichtige Vorteile: Zum einen werden inkonsistente Anforderungen viel früher und einfacher erkannt, da sie direkt in das entstehende Daten-, GUI- oder Funktionsmodell integriert werden. Zum anderen können Spezifikationsdokumente – insb. die Beschreibung von Abläufen bzw. Dialogen – von den Benutzern einfacher verstanden und auf Korrektheit und Vollständigkeit geprüft werden.

Bild 2 verdeutlicht die zeitliche Verschränkung von Anforderungsermittlung und Spezifikationsphase. Nach den ALP-Listen werden zuerst die Anwendungsfälle identifiziert, aber dann parallel zu Benutzerschnittstelle und Datenmodell spezifiziert und verfeinert. Geschäftsprozessanalyse und -modellierung sind optionale Aktivitäten. Zu beachten ist, dass die Anforderungsanalyse nicht direkt mit der Erstellung der ALP-Dokumente endet. Zur Spezifikationstechnik von sd&m siehe auch (Krug et. al. 2002, Strauß 2003).

Bild 2: Zeitlicher Aufriss in der Spezifikation, die einzelnen Elemente einer Spezifikation werden nicht sukzessive sondern parallel erstellt.

3.1.1 Dokumentation von Anforderungen

Eine etablierte Requirements-Dokumentation, wie zum Beispiel die Volère Snowcards, wird bei der Erstellung von Individualsoftware selten genutzt. Bei Volère werden Anforderungen einzeln als Snowcard mit Begründung, Messkriterium für die Umsetzung, Klassifikation und Anforderer beschrieben. Dies führt bei den üblichen Projektgrößen zu mehr als Hundert, ggf. auch mehr als Tausend Anforderungen, die dokumentiert und verwaltet werden müssen.

Probleme bei diesem Verfahren sind der hohe Dokumentationsaufwand und vor allem die Unübersichtlichkeit: Bei diesem Vorgehen können Anforderungskonflikte bei der Analyse nur schwer entdeckt werden, da die einzelnen Anforderungen unverbunden nebeneinander stehen. Viele fachliche Konflikte ergeben sich bei Individualsoftwareprojekten aber erst aus einer Kombination von mehreren Anforderungen (aus verschiedenen Abteilungen). Benutzer haben zudem Schwierigkeiten, die Auswirkungen von einzelnen Anforderungen abzuschätzen und können Anforderungen auch schlecht priorisieren. Insbesondere entstehen so schnell viele so genannte „goldene Henkel“ Anforderungen, die für sich genommen durchaus sinnvoll sein können, sich aber nicht gut ins Gesamtsystem integrieren.

3.1.2 Priorisierung von Anforderungen bei Individualsoftware

Im Abschnitt 2 zur Produktsoftware haben wir die detaillierte Ermittlung und Priorisierung von Anforderungen beschrieben. Diese komplexe Ermittlung und Priorisierung von Anforderungen kennen wir bei der Individualsoftwareerstellung in der Form nicht. Die Identifikation der Anforderungen ist in der Regel einfacher, die Priorisierung von Anforderungen erfolgt meist in einer frühen Phase der Projektinitialisierung, bei der der Projektumfang festgelegt und das Projekt zumeist in funktionale Stufen eingeteilt wird und weniger wichtige Komponenten häufig in spätere Stufen verschoben werden (ggf. werden diese „Nice to Have“ Teile auch mehrfach verschoben). Problematisch ist stattdessen vor allem die Konsolidierung der Anforderungen, bei der Inkonsistenzen sowie Anforderungslücken eliminiert werden.

3.2 Probleme und Risiken

Die bei Individualsoftware vereinfachte Verwaltung von Anforderungen zugunsten einer frühzeitigen Spezifikation birgt auch verschiedene Risiken. Die wichtigsten Probleme und Risiken und die typischen Gegenmaßnahmen stellen wir kurz dar.

3.2.1 Instabil definierter Systemumfang und unbekannte Anforderungen

Ist der Systemumfang nicht klar abgestimmt, kann sich die Spezifikationsphase in die Länge ziehen (ungeplante Themen enthalten oder Schleifen drehen). Die Definitionen von (Kern-)Anforderungen, Leistungsausgrenzungen und Prämissen (ALP) kann helfen, die Systemgrenzen besser zu definieren. Bei einem neuen Projektteam – erstes Projekt zu diesem fachlichen Gebiet bzw. diesem Kunden – werden Themen trotzdem häufig unterschätzt. Hier ist es wichtig, sich nicht vorab auf eine verbindliche Planung oder eine Beauftragung über alle Phasen einzulassen.

3.2.2 Fehlendes Requirements-Tracing

Anforderungen werden häufig abgelehnt oder modifiziert, weil sie nicht umsetzbar sind oder im Konflikt zu anderen Anforderungen stehen. In einer Spezifikation werden solche abgelehnten Anforderungen in der Regel nicht beschrieben, oder es fehlt die Begründung für die Ablehnung. Dies kann dann bei größeren Spezifikationsteams und bei Fluktuationen im Team zum Problem werden.

4. Unterschiede zwischen Produktsoftware und Individualsoftware

4.1.1 Iterative vs. einmalige Anforderungsermittlung

Bei Produktsoftware verläuft die Requirements-Analyse iterativ. Fehler können leichter korrigiert und neue Anforderungen schneller berücksichtigt werden. Da eine Kontinuität der Projektteams gewährleistet ist, müssen einmal eingeführte Usability-Prinzipien nicht für jede Version neu erarbeitet werden, sondern bleiben erhalten.

Bei einer Individualsoftware-Entwicklung ist eine iterative Anforderungsermittlung beschränkt auf Korrekturen. Diese können nötig sein, weil Anforderungen übersehen worden sind, sich parallel die Umwelt geändert hat oder mit der neuen Software Arbeitsprozesse geändert worden sind, die in der Software noch nicht berücksichtigt wurden.

4.1.2 Unterschiedliche Dokumentationstechniken

Um in großen, über mehrere Standorte verteilten, internationalen Teams über einen längeren Zeitraum hinweg Entwicklungsprojekte durchführen zu können, bedarf es bei der Dokumentation der Anforderungen eines standardisierten Verfahrens, wie es beispielsweise das Volère Template darstellt. Solche Projekte finden sich eher im Bereich der Produktsoftware, als Individual-Entwicklungen. Komplexe Anforderungskonflikte, wie sie bei Anforderungsanalyse für Individualsoftware häufig auftreten, werden durch Reviews von Spezifikationsmodellen (Datenmodell, Funktionsmodell, usw.) aufgedeckt und zusammen mit dem Fachbereich aufgelöst.

4.1.3 Szenarienbasierte vs. benutzerzentrierte Entwicklung

Während bei Individualsoftware Nutzer in der Regel schon frühzeitig einbezogen werden können, sind bei Produktsoftware konkrete Nutzungskontexte nicht immer eindeutig vorhersagbar. Oft basiert die Entwicklung der Benutzungsschnittstellen auf Szenarien, die möglichst durch konkrete Persona-Beschreibungen ergänzt werden. Bei dieser Vorgehensweise muss die Umsetzung möglichst frühzeitig überprüft und verifiziert werden. Dazu bieten sich Beta-Kunden an, die schon in der Testphase miteinbezogen werden können. Da die Produkte darüber hinaus oft branchen- oder fachübergreifend eingesetzt werden, gibt es – selbst wenn einige Nutzungskontexte durch Szenarien vorausgesetzt werden können – große Unterschiede in der Benutzbarkeit im jeweiligen Kontext.

4.1.4 Stark divergierender Einsatz von objektiven Methoden

Objektive (beobachtende) Methoden werden in der Produktsoftware-Entwicklung oft und in allen Projektphasen eingesetzt. Erkenntnisse gehen direkt in die laufende und zukünftige Produktentwicklung ein.

• In frühen Projektphasen werden z.B. einfache Papierprototypen für die Entwicklung von Interface-Konzepten und für erste Design-Studien verwendet.
• High-end Prototypen mit (simulierter) Funktionalität können sehr effektiv für Usability Tests eingesetzt werden.
• Nach Abschluss eines Versionszyklus können mit Hilfe von User Interviews einerseits die Szenarien kennen gelernt bzw. verifiziert, auf der anderen Seite durch Job Shadowing eindrucksvolle Erkenntnisse gesammelt werden, wie ein Benutzer tatsächlich mit dem Produkt arbeitet.

Bei Individualsoftware beschränkt sich die Nutzung objektiver Methoden in der Regel auf das Evaluieren des Designs durch

• Prototypen; häufig bei technischen Fragestellungen.
• Mockups (Papier-Prototypen); für die Überprüfung der Gebrauchstauglichkeit sowie der Vollständigkeit. Sind alle nötigen Informationen und Funktionen vorhanden?
• Szenarien-Walkthroughs (Schreibtischtests); für die Prüfung von komplexen Funktionen. Hierbei werden mehrere Funktionen durchgespielt und die Veränderung der Daten geprüft (Konsistenz, Vollständigkeit).

4.1.5 Erhöhte Anforderungen durch Customizing-Möglichkeiten bei Produktsoftware

Eine Produktsoftware muss nicht notwendigerweise so eingesetzt werden, wie sie aus der Verpackung kommt. Im Gegenteil, oft wird sie noch massiv an Kundenbedürfnisse angepasst. Das bedeutet, dass eine zentrale Produkteigenschaft die Customizing-Fähigkeit ist. Dies bedeutet eine erhöhte Herausforderung für die Entwicklung. Ebenso steigen damit aber auch die Anforderungen bezüglich der Usability erheblich. Es gilt, einen möglichst guten Standard in der Benutzerführung und eine flexible Benutzungsschnittstelle anzubieten, damit die Software in den unterschiedlichsten Nutzungskontexten benutzungsfreundlich bleibt.

5. Zusammenfassung

Das Vorgehen in der Requirements-Phase kann sich für eine Produktsoftware grundlegend vom Vorgehen bei Individualsoftware unterscheiden. Anforderungen zu Produktsoftware werden von User Experience, Marketingabteilung und Sales beim Kunden bzw. Benutzer erhoben. Priorisierung, Prüfung auf Umsetzbarkeit und Qualitätssicherung erfolgen bei der Definition der zu planenden Version. Da außerdem die konkreten Nutzungskontexte teilweise nur schwer ermittelt werden können, hat dies Auswirkungen auf die Techniken zur Verwaltung und Dokumentation der Anforderungen.

Demgegenüber werden Anforderungen zu Individualsoftware direkt weiterverarbeitet. Indem sie in eine Spezifikation integriert oder abgelehnt/ausgegrenzt werden, erfolgt direkt eine Qualitätssicherung (bzgl. fachlicher Umsetzbarkeit) und Priorisierung. Eine Dokumentation von zurückgestellten Anforderungen ist in der Praxis sehr unterschiedlich geregelt und ist hauptsächlich davon abhängig, ob eine entsprechende Weiterentwicklung vorgesehen ist.

Es ist zu vermuten, dass eine weitergehende Anforderungsermittlung und insb. -verwaltung für Individualsoftware nur für mehrstufige bzw. unscharfe Projektkontexte Vorteile bringt. Diese sollte sich aber auf die saubere Abgrenzung des Systemkontextes beschränken. Ansonsten ist hier die übliche integrierte Anforderungsermittlung im Rahmen einer Spezifikationserstellung vorzuziehen, da die Benutzer ein Spezifikationsbestandteile – einen Dialog, eine Funktion, oder einen Ablauf – einfacher verstehen und validieren können, als viele nebeneinander stehenden Anforderungen.

6. Literatur

• Beck, A.: Usability Professionals und Requirements Engineering – Erfahrungen und Trends. In: Usability Professionals 2003. Stuttgart: German Chapter der Usability Professionals' Association. 29-33.
• Federman, M.: Listening to the Voice of the Customer. University of Toronto, 2001. www.mcluhan.utoronto.ca/VoiceoftheCustomer.pdf (Letzter Zugriff: 15.01.2006).
• Kretschmer, D., Krug, W., Stutz, C. Siedersleben, J.: Analysis beyond UML. In: Proceedings of the RE'02: IEEE Joint International Requirements Engineering Conference 2002, 215.
• Krug, W., Siedersleben, J: Bausteine zur Spezifikation. In: (Hrsg. Siedersleben J.), Softwaretechnik, Hanser, 2002.
• Nielsen, J.: Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier. In: Cost-Justifying Usability (Hrsg. Bias, R. G., Mayhew, D. J.). Academic Press, 1994.
• Robertson, J. und S.: Mastering the Requirements Process. London: Addison-Wesley, 1999.
• Snyder, C.: Paper Prototyping. Morgan Kaufmann, 2003.
• Strauß, F.: Requirements-Analyse und GUI-Design. In: Usability Professionals 2003. (Hrsg. M. Peissner & K. Röse). Stuttgart: German Chapter der Usability Professionals' Association. 49-53.
• Strauß, F., Kowallik, P., Müller-Prove, M.: Requirements-Engineering im Spannungsfeld von Individual- und Produktsoftware. www.mprove.de/script/04/muc/ (Letzter Zugriff: 15.01.2006).
• Volère Template: www.systemsguild.com/GuildSite/Robs/Template.html (Letzter Zugriff: 15.1.2006).
• Vroon, P.: Drei Hirne im Kopf – Warum wir nicht können, wie wir wollen. Zürich: Kreuz, 1993.

7. Autoren

à propos

• Requirements- und Usability-Engineering für Standard-Software: Beispiel StarOffice / OpenOffice.org, Mensch und Computer 2004
• User Experience und Requirements-Engineering für Software-Projekte, IM (3)2005
• Drei Hirne im Kopf. Ein Radio-Feature von Mechthild Müser