Free ebooks ==> www.Ebook777.com www.Ebook777.com Free ebooks ==> www.Ebook777.com Karl Scharbert Requirements Analysis realisieren www.Ebook777.com Aus dem Bereich IT erfolgreich gestalten Grundkurs JAVA von Dietmar Abls Grundkurs MySQL und PHP von Marlin PoUakowski Ole Kunlt der ProgTammlerun, mitC++ von Martin Aupperle Rechner.rehhektur von Paul Herrmann Grundkurs Vert.itte Sy., me von GOnther Bengel Erfol,relche Datenbankanwendunc mItSQL3 von Jarg Fritze und JOrgen Marsch WI I ••• LAN In der Praxis von Peter Klau Exehan,e Server von Thomas Joos Termln.lnrver mit Cltrtx Metafnme XP von Thomas Joos W.~.I.rt Syatemlnte",ltlon von Harry Marsh Sneed und Stephan S Sneed IT-ProJekte trukturiert all,leren von Ralph Brugger CM HErmlt Methode von Heinrich Roltmann Visual anle NET mit Mett.ocle von Heirlrich Rottmann Warum lu.prechnet NET? von Heinrich Rottmann W.~Procnmml.runl von Oral Avcl, Ralph Trittmann und Werner Mellis Proflkurs PHP-Nuke von Jens Ferner Proflku~ Ecllp von Gottfried Wolmeringer www.vieweg-it.de Pl'Oflku~ ABAP"' von Patrick Theobald SAP R/3- Kommunlkatlon mit RFC und Visual Basic von Patrick Theobald ProJektmana,ement de, SW-Entwlcldune von Werner Mellis Praxis des rr-Rechts von Horst Speichert IT-5lchert.elt - Make or Buy von Marco Kleiner, Lucas MUlier und Mario Kohler Manacement Software-Entwlcklun, von Carl Steinweg Untemehmenswettes Datenmanapment von Rolf Dippold, Andreas Meier, Walter Schnider und Klaus Schwinn Mehr rr-5lchert.elt durch Pen-Tests von Enno Rey, Michael Thumann und Dominick Baier IT-5lchert.ett mit System von Klaus-Rainer Mulier IT-Rlslko Manacement mit System von Hans-Peter Konigs Six Sipain der SW-Entwlcklunc von Thomas Michael Fehlmann Netzarchttektur- Kompass fUr die Reallslerune von Thomas Spitz, Markus Bliimle und Holger Wiedel SIP - Die Technlk von Andreas Kanbach Der IT s.c:urity Manapr von Heinrich Kersten und Gerhard Klett Requirements Analysis reallsleren von Karl Scharbert Karl Scharbert Requirements Analysis realisieren Praktischer Leitfaden fur die Anforderungsanalyse bei IT-Projekten Kundenanforderungen erfragen, verstehen und spezifizieren Mit einem Geleitwort von Theo Saleck und 51 Abbildungen Springer Fachmedien Wiesbaden GmbH ~ vleweg Free ebooks ==> www.Ebook777.com Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet uber abrufbar Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten waren und daher von jedermann benutzt werden durfen Hochste inhaltliche und technische Qualitat unserer Produkte ist unser Ziel Bei der Produktion und Auslieferung unserer Biicher wollen wir die Umwelt schonen: Dieses Buch ist auf saurefreiem und chlorfrei gebleichtem Papier gedruckt Die EinschweiBfolie besteht aus Polyathylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen Auflage November 2005 Alle Rechte vorbehalten © Springer Fachmedien Wiesbaden 2005 Urspriinglich erschienen bei Friedr Vieweg & Sohn Verlag/GWV Fachverlage Gmbh, Wiesbaden 2005 Lektorat: Dr Reinald Klockenbusch / Andrea BroBler Der Vieweg-Verlag ist ein Unternehmen von Springer Science+Business Media www.vieweg-it.d e Das Werk einschlieBlich aller seiner Teile ist urheberrechtlich geschutzt Jede Verwertung auBerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulassig und strafbar Das gilt insbesondere fur Vervielfaltigungen, Ubersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen Konzeption und Layout des Umschlags: Ulrike Weigel, www.CorporateDesignGroup.de Umschlagbild: Nina Faber de.sign, Wiesbaden Druck- und buchbinderische Verarbeitung: MercedesDruck, Berlin ISBN 978-3-8348-0001-5 DOI 10.1007/978-3-663-11302-7 ISBN 978-3-663-11302-7 (eBook) www.Ebook777.com Vorwort Die Themen von IT-Buchern sind techniklastig In Buchhandlungen kann man die Literatur zu Programmiersprachen, Betriebssystemen und Standardsoftware nach Regalmetern bemessen Daneben findet man einige Kilogramm Netzwerktechnik, Internet und UML Dann gibt es noch eine kleine, leicht zu ubersehende Ecke zu Projektmanagement und eine mit Lehrbuchern Die Requirements Analysis, das Aufnehmen, Strukturieren und IT-taugliche Darstellen der Kundenanforderungen, kommt regelmafSig zu kurz Dies ist umso bedenklicher, als ein nicht geringer Anteil der Entwicklungskosten fur Software fur die Feststellung der Kundenwunsche verbraucht wird Das Thema ist fUr die technisch orientierte Welt der IT auch nur schwer fassbar, denn man geht dabei als Analytiker mit Menschen urn, die nichts von der IT verstehen Dieses Buch stellt einen Briickenschlag zwischen Fachabteilung und IT-Team her Softwareentwickler verlangen nach konkreten Vorgaben Diese fallen nicht vom Himmel Sie mussen erfragt, verstanden und strukturiert werden Das Buch richtet sich in erster Linie an Analytiker und Projektleiter aus der IT sowie an ITSpezialisten, die mit einer Requirements Analysis fUr die Softwareentwicklung befasst sind Es kann aber auch von Fachanwendern benutzt werden, die bei der Erstellung von Fachkonzepten mitwirken sollen Studenten und Auszubildende finden Anregungen zu Themen, die sie in ihrer Ausbildung bestenfalls streifen In den Texten finden sich viele Beispiele, damit stets ein Bezug zur Geschaftswelt hergestellt werden kann Die verfremdeten Praxisbeispiele im grauen Kasten sind aIle passiert Entstanden ist dieses Buch aus der Praxis Die urspriingliche Textfassung war auf einer Website, in das Buch flossen Leserkommentare mit ein Sie finden bei www.karlscharbert.de jetzt Material, fUr das in diesem Buch kein Platz mehr war Leserkomrnentare sind willkommen, so dass die Leserschaft ihre Erfahrungen zum wechselseitigen Vorteil einbringen kann Fur ihre Mithilfe bei der Entstehung dieses Buches will ich mich besonders bedanken bei Sonja Cradock, Eva G6del, Ulrich Haag, Dr Edgar Haimerl, Theo Saleck, Christian Stilz, Ulrich Vogt, Volker Wegert und bei meinem Lektor Dr Reinald Klockenbusch rch betrachte dieses Buch dann als einen Erfolg, wenn auch nur ein einziges Entwicklungsprojekt besser lauft, der Kostenrahmen nicht gesprengt wird, der Zeitplan eingehalten wird und die Entwickler abends und am Wochenende zu Hause sein k6nnen Munchen, im September 2005 Karl Scharbert V Geleitwort Wir leben aile unter demselben Himmel, aber wir haben nicht aile denselben Horizont Dieser Ausspruch von Konrad Adenauer trifft ein seit Jahrzehnten bestehendes zentrales Problem der Informationsverarbeitung Die beteiligten Gruppen, mogen es nun Kaufleute, Organisatoren, Techniker oder Sachbearbeiter sein, leben in ihren unterschiedlichen Welten und reden mit viel Engagement aneinander vorbei Wenn dann die unvermeidlichen Probleme eintreten und Projekte scheitern, wird gerne auf den vermeintlich "beschrankten Horizont" des jeweils anderen gewettert Viel hilfreicher ist, den Horizont des anderen nicht zu bewerten, sondem anzuerkennen und die unterschiedlichen Welten durch gemeinsames Bemiihen zu verbinden Leider wird dieses Thema seit Jahrzehnten durch Revierabgrenzungen tabu isiert In diesem Buch werden Methoden und Verfahren aus der Praxis vorgestellt, die es ermoglichen, ein "gemeinsames Bemiihen" auch zum Erfolg kommen zu lassen Die "Requirements Analysis", also die Analyse und das gemeinsame Begreifen der Anforderungen des Auftraggebers, auch als Auftragsklarung zu verstehen, nimmt hier Schritt fUr Schritt praktikable Gestalt an Das Verstehen und das Verankem im Bewusstsein wird durch die zahlreichen Beispiele aus der Praxis wesentlich gefordert Der Verfasser versteht es, Systematiken, das Verstandnis dafiir und die Anwendungsmoglichkeiten so zu verkniipfen, dass dieses Buch yom Praktiker als detaillierte Anleitung verwendet werden kann Hierbei werden die Horizonte so miteinander verbunden, dass in die Projektarbeit doch noch ein StUck klaren Himmels hineinscheinen kann Ein Buch fUr den Praktiker, der die Tatsache der unterschiedlichen Horizonte erkannt und anerkannt hat und nun in die Realisierung der "Requirements Analysis" einsteigen will Theo Saleck im September 2005 VII Inhaltsverzeichnis Einfuhrung 1.1 1.2 1.3 1.4 1.5 1.6 Prozessmodelle 11 2.1 2.2 2.2 2.3 2.4 2.5 2.6 Die Analysephase in der Softwareentwicklung 11 Entwicklung auf Zuruf 13 Wasserfallmodell 15 Inkrementelles Modell 18 Evolutionares Modell 19 Nebenlaufiges Modell 20 Prozessmodelle in der Praxis 23 Istanalyse 27 3.1 3.2 Definition 27 Wann ist eine Istanalyse notwendig? 28 3.3 Was ist aufzunehmen? 28 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 3.5 3.5.1 3.5.2 3.5.3 3.6 Fur wen ist dieses Buch? Ein Beispiel Wie soll dieses Buch gelesen werden? Begrifflichkeit und EVA Der Analytikerberuf Wohin geht die Reise? Was findet man vor? 28 Vorhandene IT-Systeme 29 Manuelle Verfahren 31 Halbautomatische Verfahren 36 Rollen 39 Wer wird befragt? 39 Reihenfolge 41 Stepwise Refinement 41 Teilprozesse 42 Aktivitiiten 44 Bewegte Ziele 45 Die Anforderungsanalyse 47 IX 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 Was wird analysiert? 47 Wann ist eine Anforderungsanalyse notwendig? 47 Istanalyse und Anforderungsanalyse 48 Was ist aufzunehmen? 50 Produktzielgruppenspezifische Befragung und Risiken 53 Fachanwender 56 Timing 59 Tiicken 61 4.8.1 4.8.2 4.8.3 4.8.4 4.8.5 4.8.6 Fehlende Festlegung 61 Hohe Abstraktheit 62 Interessenskonflikte 63 Desinteresse 65 Ungenauigkeit 66 Bewegte Ziele 68 Der Weg zum Anforderungsdokument 71 5.1 5.2 5.3 Voruberlegungen 71 Hohe Sicht auf Projektebene 73 Vorarbeiten 73 Teambildung und Rolle des Analytikers 73 Vereinbarung von Regeln 75 5.3.1 5.3.2 5.4 Elf Schritte zum Anforderungsdokument 76 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.4.8 5.4.9 5.4.10 5.4.11 5.5 Definition der Benutzeroberfhche 89 Interaktion mit dem Fachanwender 91 6.1 6.1.1 x Anwendungsfallpakete und Randbedingungen 76 Erfassung der Geschaftslogik 78 Quantifizierung 80 Review und Teilabnahme 81 Priorisierung 81 Detaildatenanalyse 83 Vorgangsdefinition, Story Board und Verarbeitungsschritte 84 Konflikte auf IT-Ebene identifizieren 86 Review und vorlaufige Abnahme 87 Abschatzung und Entwicklungsplanung 88 Abnahme 89 Meetings 91 Einftihrung 91 Free ebooks ==> www.Ebook777.com 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 Vorbereitung 92 Agenda 93 Personliche Vorbereitung 93 Durchfiihrung 94 Aufgaben des Vorsitzenden und des Moderators 95 Nachbearbeitung 95 Interview 95 Workshop 99 Informelle Treffen 101 Spontane Interaktion 102 Beobachtung des Fachanwenders 102 Mitarbeit beim Fachanwender 104 Fragebogen und schriftlichen Umfrage 106 E-Mail 107 Telefongesprach 110 Arbeitspakete 110 Fragetechniken 111 6.12.1 6.12.2 6.12.3 6.12.4 6.12.5 6.12.6 6.12.7 6.12.8 6.13 Eskalation 124 6.13.1 6.13.2 6.13.3 Allgemeines 111 Entspannung der Situation 113 Erzahlen lassen 114 Kontextfreiheit 116 Die Ja-Nein-Frage 117 Vollstandigkeit 119 Korrektheit 121 Implizite Annahmen 122 Ein Standardvorgehen 124 Eskalation verstehen 126 Eskalationswege 127 Daten, Bildschirmformulare, AbHiufe 129 7.1 7.2 7.2.1 7.2.2 7.2.3 7.3 7.3.1 Daten 129 Bildschirmformulare 131 Allgemeines 131 Entwurf und Darstellung von Bildschirmformularen 132 Wichtige Bildschirme1emente 134 Ablaufe 137 Was kann einem Fachanwender zugemutet werden? 137 XI www.Ebook777.com Inha/t eines Anforderungsdokuments 12 12.11 Verlisslichkeit Aussagen tiber Konsequenzen aus Abstiirzen, Fehlererkennung, Wiederaufsetzen und Schutz vor VerfaIschungen der Daten gewinnen an Wichtigkeit, je genauer ein System (jm Sinne des Konflikts Robustheit vs Genauigkeit) arbeiten muss und je teurer ein Ausfall wird Betriebsunterbrechungen wegen Wartungsarbeiten und andere geplante Ausfalle geharen in das SLA, die zugrunde liegenden fachlichen Anforderungen (z B keine Betriebsunterbrechungen in StoB- und Kernarbeitszeiten) ins Anforderungsdokument Das Beispiel zeigt, das Fehlertoleranz und Robustheit eine Fruge der ITProzessge taltung sein kann , denn e in Gescha ftsprozess wie die er mus ieh nieht mit Druekem ohne Papier befassen 1m Rahmen eine erwaltungworgang \ ird owohl ein Statu, fUr einen Daten 'alZ gespeiehert als auch zeitgleich ein ,chreiben ausgedruckt Er I, als bei einem Drucker das Papier ausgeht und der Dmck fehlsehHigl, kommt man hinter eine ystemschwach: Ocr usdruck la 'st skh nicht wiederholen, da da ' Kennz ichen bcreits gespcichert iSl und cler organg nur als Ganzes magHeh ist und nkht wiederholt werden kann 1m konkreten Fall war nerfahrenheit aller Projektbeteiligten di rsa he In der Foigeversion wurden die beiden Proze se talUS selze n" und chreiben au 'drucken" getrennl II II Der Analytiker bewegt sich bei der Definition von Anforderungen zur Ausfallsicherhe it oder den Konsequenzen aus Absttirzen in einer Grauzone I d R kann der Analytiker lediglich die Wichtigkeit der Daten klassifizieren und zusammen mit den Fachanwendern eine Kostenschatzung fUr einen Totalausfall abgeben und dann Forderungen dahingehend fixieren, wie lange ein Ausfall tolerierbar ist Ggf werden, abhangig von diesen Aussagen, Konventionalstrafen vereinbart Mit cler Entwicklung benutzerspezifischer Software haben solche Anforderungen nur wenig zu tun, im Betrieb miissen sie aber dennoch berucksichtigt werden 12.12 Sicherheitsanforderungen Die Verarbeitung sensibler Daten, an erster Stelle personenbezogener Daten, erfordert besondere SicherheitsmaBnahmen, die z T gesetzlich geregeIt sind Der Analytiker konsuItiert dazu die Hausjuristen Bei anderen sensiblen Daten (z B wesentliche Geschaftsdaten oder Betriebsgeheimnisse) kann die Fachabteilung selbst Auskunft geben Sicherheitsanforderungen k6nnen verschli.isseIte Dbertragung von Daten oder auch besondere Forderungen zum Schutz der Hardware umfassen Die Ausarbeitung dieser Forderungen ist i d R keine einfache Angelegenheit und staBt haufig an Verstandnisgrenzen So bekam einmal ein Manager ohne jeden ITHintergrund mit, dass Administratoren Zugriff auf aile Systeme eines Rechners haben Er wollte dies verbieten 224 12.13 Gesetzliche Forderungen und Regelungen icherhc it ist folgendes Beispiel: Ein Abteilungsleiter veriangt pauschal, da niemand Zugriff auf b timmt Dat n hab n durfe Die Ruckfrage des Analytiker , wozu dann die Daten g speichert wDrden, wird zunach t nicht ver tanden Der Analytiker muss notigenfalls die Grundlagen d er Da tenverarbeitung vermitteln Jedoch ware es weitaus gu nstiger, wenn die Anspr chpartner ausreichende IT-Kompetenz mitbringen 12.13 Gesetzliche Forderungen und Regelungen Gemeint ist vor allem das Bundesdatenschutzgesetz bzw die Landesdatenschutzgesetze, die bei der Verarbeitung personenbezogener Daten zu beachten sind Z B sind manche Verfahren genehmigungspflichtig, andere nur anzeigepflichtig beim Datenschutzbeauftragten des jeweiligen Bundeslandes Dies zu regeln ist Aufgabe des betrieblichen Datenschutzbeauftragten Da die Mitarbeiter in Fachabteilungen normalerweise keinerlei Sensibilitat fur gesetzliche Forderungen haben, wird der betriebliche Datenschutzbeauftragte so gut wie immer ubergangen Meist wird er erst in einer fortgeschrittenen Projektphase vom Analytiker oder Projektleiter mehr oder weniger zufallig und manchmal sogar gegen den Willen der Fachabteilung in Kenntnis gesetzt Auswirkungen auf den Entwicklungsprozess bestehen grundsatzlich, u a da nachgewiesen werden muss, wer welche Daten wann geandert hat Ebenfalls muss nachgewiesen werden konnen, welche Daten wann an wen weitergegeben worden sind Eine Protokollierungsfunktion muss bei der Verarbeitung personenbezogener Daten grundsatzlich vorgesehen werden Die konkreten Erfordernisse mussen zunachst mit dem betrieblichen Datenschutzbeauftragten abgestimmt und dann in der Anforderungsanalyse beachtet werden Der Gesetzgeber fordert auch besondere Maftnahmen zum Schutz der Daten vor Verfalschung oder Missbrauch Die Aufgabe des Analytikers kann in diesem Fall sein, neben den IT-Prozessen manuelle Geschaftsprozesse bis hin zu Arbeitsanweisungen zu definieren Zu beachten ist §202a StGB, der eine Bestrafung fUr das Ausspahen von Daten nur dann vorsieht, wenn die Daten "gegen unberechtigten Zugriff besonders gesichert" sind Sehr viele Sicherungsmechanismen konnen ohne weiteres selbst von einem Schuler der Mittelstufe ausgehebelt werden, von einer besonderen Sicherung kann deshalb haufig nur schwerlich die Rede sein Vielmehr ist von Nachlassigkeit beim Hersteller und Betreiber der Software auszugehen Ein Beispiel flir den besonder mgang mit Dat n: Eine Behorde, die per onenb zogen Daten verarbeitet, protokolliert bi auf Attributebene mit, welche Mitarbeiter wei he Daten wann andern uBerdem gilt eine Arbeitsanwei ung, da nul' rot marki rte Datentrager zur Speicherung solcher Daten verwendet werden dur~ n Weit rhin ist festgelegt, 225 Inhalt eines Anfordernngsdokuments 12 das oateien mit umfangreich n tammdaten ammlungen, die regelmaBig aus dem Verwaltung b rich (der kein Verbindung zum Internet hat) in inen offentlichen Bereich ub rtrag n werden, nur PGP-verschlUsselt auf die Reise gehen Man hatte sich mehnnals ausfUh rl ich Yom zustand igen Datenschutzbeauftragten des Landes beraten lassen Der Leiter der Behorde harte ausdruckl ich geauBert, dass er sei nen ame n nicht in iner Ze itung wiederzufi nden wunscht, weil auf Daten un befugt zugegriff n werden kon ne Gegen technische Pannen und Sicherheitslucken kann der Analytiker nicht viel machen Seine Aufgabe besteht vor allem in der Klassifikation der Sensibilitat der Daten Gemeinsam mit Juristen, Technikern und Fachanwendern kann er dann Arbeitsanweisungen erarbeiten, die zum Schutz der Daten beitragen Auf die Einhaltung dieser Arbeitsanweisungen hat er keinen Einfluss mehr Es obliegt dem technischen IT-Personal, geeignete besondere Sicherungsmechanismen zu definieren und zu implementieren Die Konsultation eines Sicherheitsexperten wie im Beispiel kann im Einzelfall angezeigt sein 12.14 Benutzerrollen Zu definieren ist, wer welche Zugrlffsrechte hat, wer also welche Oaten eingeben, andern oder loschen, und wer welche Vorgange auslosen kann Die Regelung der Rechte kann auf Ebene ganzer Datenobjekte, einzelner Attribute, aber auch auf Basis von Funktionalitaten und Prozessen geregelt werden So mag z B rein datenbanktechnisch jeder Anwender jeden Datensatz loschen konnen, da auf Ebene der Datenbank keine Benutzerrollen mit den zugehorigen Rechten definiert werden In der Anwendung kann die Loschfunktion dafur nicht von jedem Benutzer erreicht werden 12.15 Wartbarkeit und Weiterentwicklung Ein Unternehmen samt seinen Geschaftsprozessen ist nicht in Stein gemeiBeit Definiert werden muss daher, an welchen Stellen mit welcher Wahrscheinlichkeit sich die Geschaftslogik andern kann Das Geschaft verandert sich und somit auch die Anforderungen an das IT-System Da ein leicht wartbares und weiterentwickelbares System stets teurer, manchmal sogar sehr viel teurer ist, als ein System, das man nur einmal schreibt, einige Zeit benutzt und dann wegwirft, durfen klare Vorgaben nicht fehlen Zu spezifizieren ist auch die Dauer des geplanten Einsatzes ystemdesign, Archite ktur und Werkzeuge wa r n im Beispiel sic her anclers gewah lt word n, w nn vo rher d ie Lebensda uer des ystems bekannt gewesen wa re Mein erstes Projekt war die Um teHung iner Abteilung auf IT, eine ClipperLosung lint r DO Wir gingen damals, im Jahr 1989, cia von au , class nach 226 12.16 Entwicklungsbeginn vor Spezijikationsende spate tens funf Jahren ein neues ystem eingefuhrt werden wiirde Das System wurde jedoch kontinuierlich weiterentwickelt 2005 war noch immer nicht in icht, wann das System abgelost wird In den gegebenen Rahmenbedingungen ist nichts falsch gemacht worden Werden klare Forderungen zur Wartbarkeit und Weiterentwicklung unterlassen, so kann dies ein teurer SpaB werden Jeder Auftragnehmer wird die Entwicklungskosten fur sich selbst stets so niedrig wie moglich halten Am einfachsten ist dies, wenn die Geschaftslogik wie im nachsten Beispiel hart im Programm eincodiert ist Die Konsequenz ist, dass die Wartungskosten explodieren konnen Ein Extrembeispiel fU r schlechte Wartbarkeit, verursacht von einem Berufseinsteiger: Ein Modul wird erweitert Dabei geht es darum, dass auf einer Bildschirmseite Spalten mit Informationen angezeigt werden, die auf 12 Spalten erweitert werden mussen Es stellt sich heraus, dass der Autor des Programms konsequent die Zahl in den Code geschrieben hat, anstatt einmalig eine Konstante zu definieren Man spricht dabei in der IT von magic numbers (magischen Zahlen), die fest im Code stehen und von denen nicht klar ist, was sie eigentIich bedeuten Es dauert mehrere Tage, den Code zu uberarbeiten Weitere vier Wochen werden bewilligt, urn den Code des Produkts insgesamt etwas wartungsfreundlicher zu machen Ohne qualifiziertes Personal- lasst sich nicht viel machen Dokumentationsund Codingstandards, die die Verwendung von magic numbers verbieten, waren hilfreich gewesen 12.16 Entwicklungsbeginn vor Spezifikationsende Falls fUr das Projekt ein Prozessmodell gewahlt worden ist, das vor Beginn der technischen Arbeiten ein vollstandig abgenommenes Anforderungsdokument vorsieht, gibt es zur Verschiebung des Liefertermins bei Verzogerung nur die Alternative, mit einer noch nicht vollstandigen Spezifikation die Entwicklung zu beginnen Dadurch wird das Prozessmodell durchbrochen Fehlende und unvollstandige Prozesse sind zu dokumentieren Auf Teilabnahmen muss das IT-Team jedoch beharren, da sonst jede Entwicklung als Eigenmachtigkeit des Auftragnehmers betrachtet werden muss Dadurch kann keine Pflicht des Auftraggebers hergeleitet werden, dafur zu bezahlen Die Teilabnahmen sollten weit genug gehen, damit ein Teilsystem fixiert werden kann, das fur sich bereits vom Kunden abgenommen und als Teilprojekt realisiert werden kann Es ist muBig festzustellen, dass normale Fachanwender so gut wie nie die strikt planende Vorgehensweise von IT-Spezialisten kennen Terminverzogerungen im Rahmen der Spezifikationsphase werden beinahe ausnahmslos yom Auftraggeber verursacht und sind Gegenstand einer Reihe von IT-Witzen In den wenigen verbleibenden Fallen 227 12 Inbalt eines Anforderungsdokuments liegen Personalengpasse beim Auftragnehmer vor oder der Analytiker ist nicht verfiigbar Manchmal ist der Analytiker nicht kompetent genug und seine Spezifikation fallt fortwahrend bei den technischen Reviews durch Besteht von Projektbeginn an Terminenge, so sollte es gar nicht soweit kommen, dass eine unvollstandige Spezifikation abgegeben wird Statt dessen ist ein nichtlineares Prozessmodell ein Losungsansatz Lassen sich implementierbare abgenommene Prozessketten identifizieren, kann mit deren Entwicklung begonnen werden Dem Kunden muss nachdriicklich kommuniziert werden, dass Anderungen an bereits implementierten Prozessen, die infolge der noch verschwommenen Anforderungen notwendig werden konnten, zu weiteren Verzogerungen fiihren werden Der Analytiker kann dem Entwicklerteam helfen, indem er mogliche Varianten der noch nicht spezifizierten Prozesse aufzeigt So werden die Entwickler von den kommenden Ereignissen nicht iiberrascht, und sie konnen ihren Code einigerma8en flexibel halten 12.17 Projektspezifische Regelungen und Anforderungen Jedes Projekt hat seine eigenen spezifischen Regelungen und Anforderungen, die sich nicht pauschal mit einer Dokumentenvorlage oder Checkliste abdecken lassen Ein mogliches Beispiel ist die Forderung nach der Wiederverwendbarkeit einzelner Komponenten der Systemarchitektur 12.18 Testfiille Testfalle konnen Teil der Anforderungsanalyse sein Sie werden jedoch normalerweise erst nach Abschluss der Anforderungsanalyse aus den Anwendungsfallen abgeleitet und in einem eigenen Dokument gepflegt Der Analytiker ist nicht per se fUr die Testplanung oder auch nur fiir die Erarbeitung von Testfallen zustandig Aber er unterstiitzt normalerweise das Testteam bei der Erstellung des Abnahmetests In kleinen Projekten iibernimmt er oft die Rolle des Testers nebenbei Testfalle lassen sich in Positivtests und Negativtests unterscheiden Der Positivtest priift den regularen Systemdurchlauf mit allen giiltigen Sonderfallen, der Negativtest Ausnahmen und Alternativen Der Negativtest wird oft als "Provokation" bezeichnet Es gibt verschiedene Moglichkeiten, Tests aufzubauen und darzustellen Prinzipiell ist das Testszenario dem erwarteten und gemessenen Ergebnis gegeniiber zu stellen Wenn man einen Anwendungsfall zu Grunde legt, dann konnen die zugehorigen Testszenarien parallel dazu geschrieben werden Autbau und Angaben erfolgen sinngema8 zum Anwendungsfall Tests sind zu nummerieren, und der zugehorige Anwendungsfall ist zu referenzieren Besteht das Produkt einen bestimmten Testfall nicht, so ist der Test zu reproduzieren und so an die Entwickler zu melden, dass sie ihn selbst nochmals nachvollziehen konnen Nimmt man den Anwendungsfall aus 228 12.18 Testfalle 12.7.5, in dem auch die im Testfall angegebenen Formulare und Dialoge kurz erklart sind, so kbnnten einige TestfaUe wie folgt aussehen Test: T - Login Zugehorlger Anwendungsfall: UC 1.01 Voraussetzungen: Benutzer "test" mit Passwort "testpw" angelegt Positivtest: T 1.01 Der Anwender wahlt das Loginformular, tippt die korrekten Daten fi.ir Benutzer "test" ein und klickt auf den Button Login Der Benutzer ist angemeldet Der Security-Counter ist O Negativtest: T 1.02 - Syntaxfehler im Benutzername Der Anwender wahlt das Loginformular und tippt den Benutzernamen "t%" und das Passwort "test12" ein und klickt auf den Button Login Die Dialogbox D 1.1 erscheint Der Anwender klickt dort auf OK Das Loginformular ist wieder aktiv Diese Darstellungsform ist gut, wenn unterschiedliche Ablaufe einmalig gepri.ift werden In dieser Form hat sie allerdings den Nachteil, dass man bestenfalls auf einem Ausdruck einen Haken dran machen kann Man soUte eine tabellarische Form wahlen, in der bereits eine Spalte zum Aushaken vorgesehen wird 1m konkreten Beispiel geht es immer wieder urn Loginversuche mit verschiedenen Benutzernamen und Kennworten, die die verschiedenen Alternativen und Ausnahmen des Anwendungsfalls aus 12.7.5 abpri.ifen sollen Ahnliche Testfalle kbnnen wie in Tab 12.1 zusammengefasst werden Tab 12.1 - Testszenarien zum Anwendungsfall aus 12.7.5, wo auch die Formulare erklart sind Nr Szenario User Pw erwartet ok Login korrekt, wiederhole mit Leerzeichen vor und nach dem Benutzernamen test testpw F.H 1.01, Security-Counter wieder / 2.x Syntaxfehler im Benutzername oder Passwort 2.1 Benutzer syntaktisch falsch, Passwort syntaktisch richtig t%6 zzz123 D 1.1 erscheint fail 2.2 Benutzer syntaktisch falsch, Passwort syntaktisch falsch &L a b dito fail 229 12 Inhalt eines Anfordernngsdokuments 2.3 Benutzer syntaktisch richtig aber unbekannt, Passwort syntaktisch falsch Testxxx (12345 dito /' 2.4 Benutzer bekannt, Passwort syntaktisch falsch test $$hhhh dito, SecurityCounter unverandert /' 2.5 Benutzer bekannt, kein Passwort eingegeben test "leer" dito, SecurityCounter unverandert /' 2.6 Benutzer nicht eingegeben, kein Passwort eingegeben "leer" "leer" dito, SecurityCounter unverandert /' 2.7 Benutzername bekannt, Passwort zu lang test iiiiiiiiiiiiiiiiiiii dito, SecurityCounter unverandert /' Benutzer bekannt, Passwort syntaktisch richtig, aber falsche Passwort test Ttt123 F 1.1, SecurityCounter hochgezahlt /' 4.x Fehlanmeldunjilen, Security-Counter 4.1 Fehlanmeldungen, dann ein korrekter Login wie bei test zzz123, zzz123, testpw F 1.1, F 1.1, F-H 1.01, Security-Counter wieder /' 4.2 Fehlanmeldungen, dann ein korrekter Login wie bei test zzz123, zzz123, zzz123, testpw F 1.1, F 1.1, F 1.1, F 1.1 /' 5.x Ausnahmen 5.1 Login-Versuch, wenn Datenbank online test testpw F 1000 /' 5.2 Security-Counter = -1 test testpw F 1000 /' 5.3 Hinterlegtes Passwort = null test testpw F 1000 fail Bei genauerer Betrachtung k6nnte man noch einige andere Testszenarien entwerfen z B k6nnten aIle Testfalle mit Leerzeichen vor und hinter dem Benutzernamen 230 12.18 Testfiille wiederholt werden Man muss dabei gesunden Menschenverstand walten lassen und entscheiden, ob wirklich alle Szenarien oder nur einige Stichproben auf diese Weise durchgegangen werden sollen Weiterhin k6nnen Ausnahmen konstruiert werden, die nicht im Anwendungsfall definiert sind, z B ein in der Datenbank hinterlegtes zu kurzes, zu langes oder syntaktisch falsches Passwort Bei der Konstruktion der Testfalle fallt auf, dass die Fehlerformulare bzw der Dialog D 1.1 in ahnlichen Fallen benutzt wird Man muss im Story Board nachschlagen, ob sie parametrisiert sind und somit aussagekraftige Meldungen erzeugen - Es ist nicht ungew6hnlich, dass wahrend der Testplanung oder Programmierung Schwachen in schlechten Anforderungsdokumenten aufgedeckt werden So wurde auch die LangenprUfung des Benutzernamens und Passworts erst wahrend des Schreibens der Testfalle als fehlender Ablaufschritt im Anwendungsfall aufgedeckt Der Anwendungsfall in 12.7.5 wurde deshalb nochmals uberarbeitet Eine Anwendung kann in den seltensten Fallen pur als Black Box auf vernunftige Weise getestet werden 1m Beispiel muss man in der Datenbank nachschauen k6nnen, was im Security-Counter steht Fur Ausnahmen mussen auch bestimmte Werte manuell in die Datenbank eingetragen werden k6nnen Derartige Forderungen muss der Tester rechtzeitig vor Testbeginn dem Projektleiter mitteilen Tests von Dialogsystemen sind mit viel Handarbeit verbunden Die Szenarien werden abgetippt und mussen mit jeder neuen Produktversion wiederholt werden Urn dies zu vereinfachen, gibt es Produkte, die automatisierte Tests unterstutzen Dabei werden die Tastatureingaben aufgezeichnet und bei der Testwiederholung automatisch eingespielt Vorsicht: Besteht eine Abhangigkeit des Tests yom Systemdatum, so muss dies beim Regressionstest beachtet werden Ahnlich wie Tests gegen Anwendungsfalle sind Lasttests gegen die spezifizierten Mengengeruste vorzubereiten Dabei ist der technische Aufwand aber meist gr6Ber als der organisatorische Eine Lastsimulation zu fordern ist einfach, die technische Infrastruktur bereit zu stellen nicht Urn Dberraschungen wahrend der Produktion zu vermeiden, sollten nicht nur die spezifizierten Mengen getestet werden, sondern man sollte die Grenzen des Systems feststellen Schnittstellen zu Fremdsystemen mussen ebenfalls gepruft werden Dies fallt in den Systemtest und somit in den Aufgabenbereich von Architekt, Designer oder Entwickler Wurde im Anforderungsdokument jedoch ein fur den Anwender sichtbares Systemverhalten spezifiziert, so wird dieser Test zumindest teilweise dem Abnahmetest zugeordnet K6nnen die Datenmengen an den Schnittstellen zu kritischen Systemlaufzeiten fUhren, so sollen auch hier Lasttests gefahren werden Wenn durch die gebaute Anwendung im Laufe der Zeit groBe Datenmengen aufgebaut werden, so ist auch projiziert auf die geplante Lebensdauer des Systems eine Prufung vorzusehen Dazu werden entsprechende Datenbestande wie im nachfolgenden Beispiel generiert, und die davon abhangigen Systemfunktionalitaten werden getestet Man sollte sich vor Testbeginn den Kopf daruber zerbrechen, was man tun 231 12 Inha/t eines Anfordenmgsdokuments wird, wenn der Test fehlschlagen sollte 1m Nachhinein eine Datenbank samt darauf aufsetzender Anwendung anzupassen, kann aufwandig werden In diesem Beispiel wurden lllglich einige tausend Datensatze dem Datenbestand hinzu gefUgt 1m Umfeld des Reporting ' einer Bank werden wglich mehr re Excelsh ets angeliefert Urn das Reporting zu verbe 'sem, wird eine M cce s Datenbank aufgebau{, in die die heets importierl werd n Die Daten werden aufgedraselt und so angepasst, dass das Reporting deutli h detailli ner Daten Hefem kann Die fachlichen Anforderungen werden auf nhieb erfilllt m zu prtifen, ob diese Lasung auch langfri tig tr,lgHihig ist, werden mehrer hunderttausend Datensatze gen riert, so da die Datenbe tande einen mfang err ich n, d rca elrei Jahre nach Produktionsbeginn geg ben ein wird Da, Laufz itv rhalt n ist nach wie vor akzeptabel, und der Te'ter cham, da, da y tem noch einj e Jahr Ian er arbeiten kann Da Vorgehen war den zu rwart nden Entwicklungen angeme ·en Baht t man, das im Laufe 'olcher Zeitraum auch die Hardware chneller wird, ist abzusehen, da s di e Lasung th r tisch un ndlich einsetzbar ist In der Praxis kannen frtiher oeler 'pat r alte Datenb stande gela cht werden Man kann in den seltensten Fallen a//e maglichen Fehler simulieren Wesentlich beim Testen ist, dass man so viele Faile wie maglich abdeckt Auch Testszenarien unterliegen einer Review-Prozedur Tests sind essenziell fUr hohe Produktqualitat Ehrgeiz des Testers sollte es sein, das zu testende Produkt zu zerstoren ]eder Test kann aber nur gegen bekannte Anforderungen stattfinden Ein Test kann niemals besser als das zugrunde Iiegende Anforderungsdokument sein Ihre Initiative ist gefragt! 232 13 13.1 Anhang Glossar Anonyme / nicht anonyme Software: Bei anonymen Produkten ist der Endanwender nicht persbnlich bekannt und kann nicht befragt werde Solche Produkte werden fur den Massenmarkt entwickelt Nicht anonyme Produkte sind spezifische Entwicklungen fUr kleine Benutzergruppen Der Endanwender ist bekannt und kann befragt werden Change Request / Feature Request: Ein Antrag auf Anderung bzw Einfuhrung eines neuen Features CMS: Content Management System, ein System, mit dem die Inhalte von CHTML-) Oberflachen verwaltet werden kbnnen, die zur Laufzeit dynamisch aufgebaut werden Domane: Problembereich ERM / ER-Model / Entity Relationship Model: Ein Modell einer relationalen Datenbank, in dem alle Tabellen und Beziehungen zwischen den Tabellen dargestellt wird Finiter Automat: Eine EinfUhrung tiber Zustandsautomaten findet sich bei [Balzert1), S 316 ff oder bei www.wikipedia.de Gap Analysis: Analyse der Differenz zwischen zwei Zustanden Z B findet vor einer kundenspezifischen Anpassung eines Systems eine Analyse der Differenz zwischen dem aktuellen und dem gewtinschten Leistungsumfang des Systems statt ITIL: IT Infrastructure Library Eine aus GroBbritannien stammende "best practice" fUr IT-Infrastrukturbetrieb np-vollstandig: Die Komplexitatstheorie unterteilt durch Automaten zu bearbeitende Probleme in Klassen Dabei werden auch Aussagen tiber die Rechenzeit bei steigender Datenmenge gemacht Bei np-vollstandigen Problemen steigt die Rechenzeit rasch ins Astronomische Eine Darstellung findet sich bei www.wikipedia.de 233 13 Anbang Refactoring: Die notwendigen Anpassungen des Programmcodes, wenn ein Produkt erweitert wird Bei iterativen Prozessmodellen wird dies bewusst in Kauf genommen Review: Priifung, meist eines Dokuments, auf Vollstandigkeit und Korrektheit SLA / Service Level Agreement: Vereinbarung iiber zu liefernde Services rund urn Hard- und Software Z B kann gefordert sein, dass Server redundant und in unterschiedlichen Brandabschnitten installiert werden Time to first / last byte: Zeit vom Eintreffen einer Anfrage, bis der Server das erste / letzte Byte der Antwort verschickt hat 13.2 Literaturverzeichnis [Balzertl] Balzert, Helmut: Lehrbuch der Software-Technik: Software-Entwicklung Aufiage, Spektrum Akademischer Verlag, Berlin, 2000 ISBN 3-8274-0480-0 [Balzert2] Balzert, Helmut: Lehrbuch der Software-Technik: Softare-Management, Software-Qualitatssicherung, Unternehmensmodellierung Spektrum Akademischer Verlag, Berlin, Aufiage, 2000 ISBN 3-8274-0065-1 [Fowlerl] Fowler, Martin: Patterns fiir Enterprise Application-Architekturen mitpVerlag, Bonn, Aufiage, 2003 ISBN 3-8266-1378-3 [Fowler2] Fowler, Martin; Cott, Kendall: UML konzentriert Addison-Wesley, Miinchen, Aufiage, 2000 ISBN 3-8273-1617-0 [Fuchsl] Fuchs, Emmerich; Fuchs, Karl Herrmann; Hauri, Christian H.: RequirementsEngineering in IT Vieweg-Verlag, Wiesbaden, Aufiage, 2002 ISBN 3-528-05756-4 [Ruppl] Rupp, Chris: Requirements-Engineering und -Management Carl Hanser Verlag, Miinchen Wien, Aufiage, 2004 ISBN 3-446-22877-2 [Saleckl] Saleck, Theo: Auftragsklarung in IT-Projekten Vieweg-Verlag, Wiesbaden, Aufiage, 2003 ISBN 3-528-05803-X [Thallerl] Thaller, Georg Erwin: ISO 9001, Software-Entwicklung in der Praxis Verlang Heinz Heise, Hannover, Aufiage, 2000 ISBN 3-88229-181-8 Antwort zur Frage von S 202: Laut Sprachberatung des Dudens heiBt es bei mathematischen Ausdriicken prinzipiell ist: Sieben und runf ist dreizehn Das andert aber nichts daran, dass + = 12 richtig ist Diese Fangfrage funktioniert sowohl miindlich als auch schriftlich in mehr als drei Viertel der Falle, auch die Sprachberatung ist darauf herein gefallen Nachdem der Fokus auf die Formulierung gelenkt wurde, wird der Inhalt nicht beachtet Bei Anforderungsanalysen fiihrt dies regelmaBig zu Desastern 1m Text habe ich einige Zeilen wirres Zeug vorangeschickt, urn vom Inhalt abzulenken Dasselbe passiert regelmaBig in Interaktionen und halb fertigen Dokumenten 234 Sachwortverzeichnis Analytiker Berufsbild, notwendige Kompetenzen 7-9 Risiken bei Personalauswahl 197 Risiken in seinem Verantwortungsbereich 196 Rolle in der Softwareentwicklung Siebe Kapite! Prozessmodelle und Projektleiter 74, 90, 125, 223 Anforderungsanalyse 47-70 Abschatzung der Dauer 49 Aufspuren logischer Fehler 45, 113, 119, 122, 182-185, 185 Definition Entwicklungsbeginn vor Spezifikationsende 227 gesunder Spezifikationsverlauf 192 Konsensfindung 54, 100 Notwendigkeit 11,47 Prozessschnittstellen 29, 60 Teil der Softwareentwicklung Siebe Prozessmodell ungesunder Spezifikationsverlauf 193 Vergleich Istanalyse 48, 56, 59, 95 Zie! 47 Anforderungsdokument absichtliche Fehler fUr QM 186 Fehler, kontextuelle 185 Fehler,logische 182-185 Inhalt 203-232 Qualitatscheckliste 173 Uberseher des Fachanwenders finden 185 Anwendungsfall 76, 176, 213, 216-221 Behorde Siebe offentlicher Dienst Benutzeroberflache 131-137 Ergonomie 90 Benutzerrechte / -rolle Siebe Rolle Beobachtung des Fachanwenders 102-104 Fachanwender wird nicht konkret 63 verdeckte Vorgiinge 186 zum Erziiblen animieren 114 Beobachtungsinterview Siebe Beobachtung des Fachanwenders Besprechung Siebe Meeting Betriebsblindheit 99, 105, 122, 175, 197 bewegte Ziele bei Anforderungsanalyse 33,68,200 bei Istanalyse 45 und norrnale Anderungen 73 Bildschirrnforrnular Siebe Benutzeroberflache Budget 12,13,23,75,83,112,133,198 -uberwachung 24 und erwartete Nutzerzahl bei Internetanwendung 212 zu implementierende Features 81 zuknappes 80,88,89,161,193 Datenanalyse 83, 129, 149-162 bei EVA statistische Auffalligkeiten in Datenbestanden 31 Datenrnengen Siebe quantitative Angaben Datenmodell 149-162, 222 Istanalyse von Altsystemen 30 Verstandnis von Fachanwendern 36, 65 Datenquelle 6, 221 Datenschutz 132, 225 Datensenke 6, 221 Analyse vor Datenquelle 44, 59 Auswirkung von Anderungen am Prozessoutput 60 235 manuelle Nachbearbeitung von Systemoutput 69 Entscheidungstabelle 146 ERM / Entity Relationship Model Siebe Datenmodell Eskalation 124-128 als letztes Mittel 61, 126 unzureiehender Arbeitsergebnisse 189, 190 EVA Anwendungsfall 216 bei der Anforderungsanalyse 50,83 Prozesse und Aktivitaten 44, 97 Suche logischer Fehler 184 Fachanwender Begriffsdefinition einfugen in ein Prozessmodell 12 Erwartungshaltung 11, 16, 19,22,44, 55, 60, 65, 77, 99, 103, 138, 169 in der Anforderungsanalyse 56, 137-140 kann Prozessbeschreibungen nieht nachvollziehen 57 Kommunikationsverbot 41, 53 macht ungenaue Angaben 61-70, 122 Mitarbeit 178 Mitwirkungspflicht 48 ohne IT-Kompetenz 30, 44, 51, 138, 146 Dberseher finden 185 Unterschied Informatiker 8, 56, 151, 157 weiB nieht, was er will Siebe Willensfindungsprozess wird nieht konkret 62 Wissenstrager 31,40,45,46 Feldstudie Siebe Beobachtung des Fachanwenders Flussdiagramm 142 Fragebogen 106-107 Fragetechnik 111-124 Ja-Nein-Frage 117 236 Korrektheit von Anforderungen 121 nach impliziten Annahmen 122 Vollstandigkeit von Anforderungen 119 zum Erzahlen animieren 114 Geschaftslogik/-regeln 8, 31, 78-80, 80, 122, 186, 216, 226 ableiten aus Beispielsammlungen 35 Ausdifferenzierung von Details 85 nachlassige Definition 84 Geschaftsprozess Siebe Prozess und Geschaftslogik implizite Annahme 122 Input Siebe Datenquelle Internetanwendung Auswirkung der Oberflachengestaltung auf die Analyse 133 Browserversion als Anforderung 223 erwartete Nutzerzahl 212 personenbezogene Daten 132 Systemantwortszeitverhalten 213 Interview 95-99 bei Istanalyse mit Fuhrungspersonal 35 Beobachtungs- 102 Fachanwender wird nicht konkret 62 mit unterschiedlichen Fachanwendern zum selben Thema 57 Szenarien, in denen ein Workshop besser ist 99 zum Erzahlen animieren 114 Istanalyse 27-46 Abschatzung der Dauer 49 Basis fUr Anforderungsanalyse 28, 50 eingesetzter Offiee-Produkte 36-39 Evaluierung fUr Prognose der Anforderungsanalysequalitat 191 Konsensfindung 100 manuelle Verfahren 31-36 Mitarbeit beim Fachanwender als letztes Mittel 104 ohne Unterstutzung 49 scheitert 28 Free ebooks ==> www.Ebook777.com schrittweise Verfeinerung 41 Vergleich Anforderungsanalyse 48,56, 59, 95 von Altsystemen 29 Komplexitatstheorie 167, 233 Kontext 116 LOsungsneutralitat 78,111,129,150,175, 196 Meeting 91-95 Mengengeriist Siebe quantitative Angaben Mission Statement 73, 76, 77, 209 Mitarbeit beim Fachanwender 104-106 bei Istanalyse 35 verdeckte Vorgiinge 186 affentlicher Dienst 17, 31, 33, 46 Office-Lasung als Hilfe bei bewegten Zielen 69 Istaufnahme 36 Output Siebe Datensenke Projektleiter abgeschlossene Versionen des Anforderungsdokuments 22 bewegte Ziele 68, 70 Budget und Termine 23 Eskalation am Projektleiter vorbei 128 Fachanwender dreht sich im Kreis 58 und Analytiker Siebe Analytiker und Projektleiter Untersttitzung der Analyse 4, 19, 48, 55, 62, 66, 75, 81, 84, 90, 109, 133, 141, 163, 166, 214 von ihm ausgehende Risiken 198, 201 Prosa 140 Prototyp 16, 56,85, 124, 134, 163-170 ftir Usability-Test 104 Messung intuitiver Bedienbarkeit 178 Prozess 215-221 Abhangigkeit Datenmenge 80 Aktivitaten 44 Analysereihenfolge 60 Anforderungsanalyse 47-70 Aufsptiren logischer Fehler 182-185 Beispiel 41 Beschreibungsformen filr Ablaufe 137148 Definition bei EVA -details, Analyse 59, 72 -details, Ansprechpartner 40 Fachanwendersicht 44 Fragetechnik implizite Annahmen 122 Fragetechnik Korrektheit 121 Fragetechnik Vollstandigkeit 120 Gestaltung/Optimierung 7,63 Historie 28 Istanalyse 27-46 Konsensfindung bei Analyse 100 manuell 31-36,38,85 manueller 225 mit Office-Produkten 36-39 neu erfundener, Test 48 Priorisierung durch Fachabteilung 81 prototypische Darstellung Siebe Prototyp Randbedingungen andem sich 58,194 Review Siebe Review Rollen im 39 -schnittstellen Siebe Anforderungsanalyse: Prozessschnittstellen schrittweise Verfeinerung 51 Sicherheit tiber korrekte Beschreibung 105 Sichtweise Fachanwender vs Informatiker 56, 103 -teile, Verlagerung 65 Teilprozess 42 und Benutzeroberflache 90, 131, 133, 165, 214 unzureichend beschrieben 17,80,113, 191 verborgener 31, 45, 106, 122 verloren gegangenes Know-how 31, 39 237 www.Ebook777.com Free ebooks ==> www.Ebook777.com Prozessmodell 11-26 in der Praxis 23 SW-Entwicklung ohne 13 Pseudocode 144 Qualitiit 10, 15,48, 171-194 bei Office-LQsungen 36, 37 bei Prototypen 167 btirokratisches Qualitatsmanagement 16, 148 eines Interviews 97 im Anforderungsdokument 101, 104, 171-194 im Fachbereich 53 Qualitatshandbuch 35 Qualitatsmanager - Befragung bei Istanalyse 40 Qualitatsmanager in kleinen Unternehmen 40 unzureichendes Qualitatsmanagement 12, 26, 55 von Eingangsdaten 64 quantitative Angaben 47,48,80, 130, 168, 175, 211, 213, 218, 221, 233 Rechte Siebe Rolle Releasemanager Befragung bei Istanalyse 40 in kleinen Unternehmen 40 Requirements Analysis Siebe Anforderungsanalyse Review 81,87,173,180,182,188 Rolle 29,39,50,51,226 Schuld Suche nach Schuldigen 10, 107, 113, 126 -zuweisungen 24, 58, 189 Sollanalyse Siebe Anforderungsanalyse Stakeholder 5, Siebe Fachanwender Story Board 85, 89, 131, 132, 213-215 mange1hafte Priifung 124, 170 strukturiertes Deutsch 141 System muss auf dem Papier funktionieren 7, 35, 51, 79, 80, 138, 142 Ausnahme 168 Systemarchaologie Siebe Istanalyse von Altsystemen Test 12, 228-232 Entwicklung ohne Prozessmodell 14 Fehlermenge in getesteter Software 209 gegen Anforderungen 76, 173 in verschiedenen Projektphasen 17 Office-Losungen 36 Planung auf Basis der Istanalyse 48 Prototyp ftir Usability-Test 104, 166 Qualitat hineintesten 173 schematisierte Testplanung 217 Testbarkeit von Anforderungen 16, 116, 118, 174, 176, 196, 203 Testplanung schematisierbar 140 unmoglich ohne Anforderungen 47 unzureichender, ftihrt zu Qualitatsmangeln 55 U~L 148, 203, 214, 216, 221 Vorgehensmodell Siebe Prozessmodell Weiterentwicklung Ansprechpartner finden 208 eines Prototyps 166 eines Systems 20, 23, 29, 226 Eingriff in 22 Parallelisierung 20 Willensfindungsprozess 13, 20, 21, 23, 25, 28, 55, 73, 76, 78, 165, 192, 194 Workshop 99-100 bei Istanalyse mit Ftihrungspersonal 35 dem Interview vorziehen 57 238 www.Ebook777.com ... s.c:urity Manapr von Heinrich Kersten und Gerhard Klett Requirements Analysis reallsleren von Karl Scharbert Karl Scharbert Requirements Analysis realisieren Praktischer Leitfaden fur die Anforderungsanalyse... 1m Umfeld der Requirements Analysis herrscht eine babylonische Sprachverwirrung Die deutsche Sprache kennt keine eindeutige und verbindliche Dbersetzung des Begriffs Requirements Analysis In dies... Illusion hin, dass Sie nur damit eine perfekte Analyse realisieren konnen Holen Sie sich Verstarkung! 1.4 Begrifflichkeit und EVA Die Requirements Analysis hat die Aufnahme der Anforderungen an ein