Requirements Engineering PDF

SOFTWARE ENGINEERING 1 Themenblock 2: Requirements Engineering HHN | Medizinische Informatik Dipl.-Inform. Med. Martin Wiesner AGENDA ADAPTIERT NACH MATERIAL VON PROF. DR. A. REICHENBACH 1. Funktionale und nicht-funktionale Anforderungen 2. Prozesse des Requirements-Engineerings > Erhebung...

SOFTWARE ENGINEERING 1 Themenblock 2: Requirements Engineering HHN | Medizinische Informatik Dipl.-Inform. Med. Martin Wiesner AGENDA ADAPTIERT NACH MATERIAL VON PROF. DR. A. REICHENBACH 1. Funktionale und nicht-funktionale Anforderungen 2. Prozesse des Requirements-Engineerings > Erhebung und Spezifikation der Anforderungen > Validierung der Anforderungen > Anforderungsmanagement HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 2 LERNZIELE DER VERANSTALTUNG 1. Konzepte von Benutzer- und Systemanforderung verstehen und wissen, warum diese Anforderungen in verschiedenen Darstellungsarten ausgedrückt werden sollten. 2. Unterschiede zwischen funktionalen und nicht-funktionalen Anforderungen verstehen. 3. Prinzipielle Aktivitäten des Requirements Engineering (RE) sowie die Zusammenhänge der Aktivitäten verstehen. 4. Verstehen, wie Anforderungen in einer Gesamtspezifikation (Lasten- und Pflichtenheft) organisiert werden können. 5. Wissen, warum Anforderungsmanagement notwendig ist und wie es die anderen Aufgaben des RE unterstützt. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 3 REQUIREMENTS ENGINEERING Anforderungen an ein System umfassen die Beschreibung dessen, was das System leisten soll: > die Dienste, die es zur Verfügung stellt > Die Einschränkungen seiner Funktionsweise Anforderungen spiegeln den Bedarf des Kunden nach einem System wider, das einem bestimmten Zweck dient. Requirements Engineering beinhaltet die Unterprozesse der Erhebung, Analyse, Dokumentation und Überprüfung von Anforderungen. Anmerkung: Im deutschen Sprachraum ist für den Gesamtprozess des „Requirements Engineering“ auch der Begriff „Anforderungsanalyse“ gebräuchlich. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 4 WAS GENAU IST EINE ANFORDERUNG? Kann alles sein von abstrakten Aussagen über einen Service oder eine Randbedingung bis hin zu detailierten mathematisch beschriebenen funktionalen Spezifikationen. Anforderungen können unterschiedliche Funktionen haben > Dienen als Grundlage für eine Ausschreibung und müssen daher Interpretationsspielräume bieten (Lastenheft / Anforderungsspezifikation). > Dienen als Grundlage für einen Vertrag und müssen daher sehr fein detailiert sein (Pflichtenheft / Fachspezifikation). => Je nachdem mit wem man redet, kann also der Begriff „Anforderungen“ eine andere Bedeutung haben! => Man sollte eine klare Trennung (und Benennung) zwischen diesen verschiedenen Ebenen vornehmen! HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 5 ARTEN VON ANFORDERUNGEN Benutzeranforderungen > Anforderungen aus Benutzersicht. Das können Aussagen in natürlicher Sprache und evtl Diagramme der System-funktionalitäten und Randbedingungen sein. Systemanforderungen > Anforderungen aus Systemsicht. Ein strukturiertes Dokument mit detailierten Auflistungen von Funktionen, Services und Randbedingungen. Sowohl Lasten- als auch Pflichtenheft können beide Arten von Anforderungen enthalten. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 6 BENUTZER- UND SYSTEMANFORDERUNGEN BSP MENTCARE User requirements definition 1. The Mentcare system shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. System requirements specification Nummerierung wichtig 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. 1.2 The system shall generate the report for printing after 17.30 on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g. 10mg, 20mg, etc) separate reports shall be created for each dose unit. 1.5 Access to drug cost reports shall be restricted to authorized users as listed on a management access control list. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 7 LESER DER ANFORDERUNGSDOKUMENTE Verschiedene Ebenen von Anforderungen sind nützlich, da sie Informationen über das System an verschiedene Zielgruppen vermitteln. Client managers System end-users User Client engineers requirements Contractor managers System architects System end-users System Client engineers requirements System architects Software developers HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 8 „STAKEHOLDER“ EINES SYSTEMS Jegliche Person oder Organisation, die in irgendeiner Weise etwas mit dem System zu tun hat (Interessensvertreter). Arten von Stakeholdern > Endbenutzer > Betreiber des Systems, z.B. IT-Abteilung > Besitzer des Systems, z.B. eine bestimmte Fachabteilung > Externe Interessenten HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 9 STAKEHOLDER DES MENTCARE SYSTEMS 1. Patienten: ihre Informationen werden gespeichert 2. Ärzte: zuständig für die Diagnose und Behandlung der Patienten 3. Pflegekräfte: koordinieren die Arzttermine und verabreichen einige der Behandlungen 4. Rezeptionskräfte: vereinbaren die Patiententermine 5. IT-Abteilung: verantwortlich für Installation und Wartung des Systems 6. Medizinischer Ethik-Beauftragter: muß sicherstellen, dass das System die entsprechenden ethischen Richtlinien in der Patientenpflege einhält. 7. Manager der Kliniken und Praxen: bekommen Management Reports 8. Medizinisches Archivierungspersonal: stellen die Datenhaltung und – archivierung gemäß rechtlicher Richtlinien sicher. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 10 ANFORDERUNGEN BEI AGILEN METHODEN Anhänger agiler Methoden lehnen detailierte Systemanforderungen ab sie verschwenden nur Zeit, da sich die Anforderungen so schnell ändern => Dokumentation der Anforderungen immer veraltet. Bei agilen Methoden setzt man inkrementelles Requirements Engineering ein und arbeitet mit „User Stories“. Ist bei Geschäftsanwendungen umsetzbar, aber nicht bei kritischen Systemen oder paralleler Entwicklung. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 11 FUNKTIONALE UND NICHT-FUNKTIONALE ANFORDERUNGEN Funktionale Anforderungen > Aussagen über die Services, die ein System erbringen soll, wie das System auf bestimmte Eingaben reagieren soll und wie es sich in bestimmten Situationen verhalten soll. > Kann explizit enthalten, was das System nicht machen soll. Nicht-funktionale Anforderungen > Bedingungen, die die Funktionen erfüllen müssen wie zB Zeitbegrenzungen, Einhaltung von Standards etc > Sind oft auf das Gesamtsystem und nicht auf einzelne Funktionen bezogen. Domainanforderungen > Bedingungen die sich aus dem Geschäftsumfeld ergeben. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 12 FUNKTIONALE UND NICHT-FUNKTIONALE ANFORDERUNGEN Der Unterschied ist in der Praxis nicht immer ganz so klar wie es in der Theorie erscheint! Anforderungen sind oft nicht unabhängig voneinander, sondern schränken andere Anforderungen ein oder erzeugen andere Anforderungen. Systemanforderungen spezifizieren nicht nur Dienste und Funktionen des Systems, sondern auch notwendige Funktionalität, damit die Dienste und Funktionen ordnungsgemäß ausgeliefert werden können. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 13 FUNKTIONALE ANFORDERUNGEN Beschreiben Funktionalitäten oder Services des Systems Hängen von der Art der Software ab, sowie von den erwarteten Benutzern und dem Einsatzort Funktionale Benutzeranforderungen können allgemein gehaltene Aussagen darüber sein, was das System machen soll. Funktionale Systemanforderungen sollen die Services des Systems sowie seine Einbettung in bestehende Systeme und Strukturen detailiert ausführen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 14 FUNKTIONALE ANFORDERUNGEN AN MENTCARE BEISPIELE 1. Ein Benutzer soll die Listen aller Arzttermine aller Ambulanzen durchsuchen können. 2. Das System soll jeden Tag für jede Ambulanz eine Liste von Patienten erstellen, die an dem Tag einen Termin haben. 3. Jeder Benutzer des Systems soll eindeutig mit seiner 8-stelligen Mitarbeiternummer identifiziert werden. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 15 UNGENAUIGKEITEN IN DEN ANFORDERUNGEN Wenn funktionale Anforderungen nicht präzise formuliert sind entstehen Probleme! 1. Schwammige oder mehrdeutige Formulierungen können uU von Entwickler*innen und Benutzer*innen unterschiedlich interpretiert werden. 2. Entwickler*in interpretiert eine (nicht eindeutige) Anforderung idR so, dass jene einfach umzusetzen ist – das ist nicht unbedingt das, was sich der Kunde vorgestellt hat. => Aufwändige Überarbeitung HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 16 VOLLSTÄNDIGKEIT UND KONSISTENZ VON ANFORDERUNGEN Prinzipiell sollten Anforderungen vollständig & konsistent sein. Vollständig > Sie sollten die Beschreibung sämtlicher benötigter Funktionalitäten beinhalten. Konsistent > Es sollten keine Konflikte oder Widersprüchlichkeiten in den Beschreibungen auftreten. In der Realität ist das jedoch aufgrund der Komplexität der Umgebung und des Systems oft unmöglich. Unterschiedliche Stakeholder haben ggf widersprüchliche Anforderungen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 19 NICHT-FUNKTIONALE ANFORDERUNGEN Definieren Beschränkungen der durch das System angebotenen Dienste und Funktionen zB Zuverlässigkeit, Antwortzeiten oder Speicherbedarf. Prozessanforderungen können zB eine bestimmte IDE, Programmiersprache oder Entwicklungsmethode verlangen. Nicht-funktionale Anforderungen sind oft relevanter als einzelne funktionale Anforderungen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 20 NICHT-FUNKTIONALE ANFORDERUNGEN Benutzer können sehr kreativ werden, wenn ihre funktionale Anforderung nicht 100% erfüllt wird... HHN | Medizinische Informatik - SWE 1 | [email protected] NICHT-FUNKTIONALE ANFORDERUNGEN Wird jedoch eine nicht-funktionale Anforderung nicht erfüllt, ist ggf das gesamte System unbrauchbar! > Bsp Anforderung an Zuverlässigkeit HHN | Medizinische Informatik - SWE 1 | [email protected] NICHT-FUNKTIONALE ANFORDERUNGEN BEISPIEL: VERFÜGBARKEIT Kernfrage: Wie kritisch ist es, wenn das System einmal ausfällt? Mit entsprechend zuverlässigen Komponenten muss gearbeitet werden, entsprechend robust muss die Software entwickelt sein. Weiterhin: Gibt es Zeiten, zu denen das System nicht verfügbar sein muss (in der denen zB Wartung uä gemacht werden kann), zB WE Verfügbarkeit = (Gesamtzeit - Ausfallzeit) / Gesamtzeit Bsp 1: 99% Verfügbarkeit, nur Werktage: max. 31,2h/Jahr Ausfall, 5640h für Wartung Das sei ein Produktionssystem für 500 Arbeiter (Mindestlohn): 132.600€ Verlust/Jahr Bsp 2: 99,99% Verfügbarkeit bei 24/7: max. 52,56min/Jahr Ausfall, keine Zeit für Wartung. Das sei Amazon mit 107Mrd US$ Umsatz/Jahr: 10,7Mio US$ Verlust (in Maximale Dauer eines einzelnen Ausfalls > Fähigkeit, über einen gegebenen Zeitraum hinweg korrekt zu arbeiten > Robustheit gegen Fehlbedienung, Sabotage und höhere Gewalt > Wie lange dauert es, bis das System eine spezielle Aktion ausgeführt hat > Mittlere Dauer der Wiederherstellung nach einem Ausfall > Mittlere Betriebszeit zwischen zwei auftretenden Fehlern ohne Reparaturzeit Hochverfügbarkeitssysteme > arbeiten mit redundanten Komponenten, zB Stromversorgung, RAID, Server Spiegelung (Cold- und Hot-Standby), Failover-Clustern etc > haben logistische Anforderungen wie vorbeugende Wartung, qualifizierte Fehlermeldungen und schnelle Kommunikation etc HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 24  Nicht-funktionale Anforderungen IMPLEMENTIERUNG NICHT-FUNKTIONALER ANFORDERUNGEN Nicht-funktionale Anforderungen können die Gesamtarchitektur des Systems betreffen und nicht nur einzelne Komponenten. > zB muß ein System wegen Performanzanforderungen ggf so organisiert werden, dass die einzelnen Komponenten untereinander so wenig wie möglich kommunizieren. Eine einzige nicht-funktionale Anforderung wie zB eine Sicherheitsanforderung kann eine Reihe funktionaler Anforderungen nach sich ziehen. > Sie können auch andere Anforderungen beschneiden. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 25 ARTEN NICHT-FUNKTIONALER ANFORDERUNGEN unterscheiden können HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 26  Arten nicht-funktionaler Anforderungen KLASSIFIZIERUNG NICHT-FUNKTIONALER ANFORDERUNGEN Produktanforderungen > Anforderungen, die spezifizieren, auf welche Art und Weise das System arbeiten muss, zB Performanz, Zuverlässigkeit Unternehmensanforderungen > Anforderungen, die eine Konsequenz der Unternehmensstruktur sind, zB Prozess-Standards, die eingehalten werden müssen, Anforderungen an die Entwicklungsumgebung Externe Anforderungen > Anforderungen aufgrund von Faktoren, die mit dem System und der Entwicklung an sich nichts zu tun haben, zB gesetzliche Auflagen HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 27 KLASSIFIZIERUNG NF-ANFORDERUNGEN BSP: MENTCARE Produktanforderungen > Das Mentcare System soll für alle ambulanten Sprechstunden während normaler Arbeitszeiten (Mon-Fri, 8:30-17:30 Uhr) verfügbar sein. Während der Arbeitszeiten darf das System pro Tag nicht länger als 5 Sekunden ausfallen. Unternehmensanforderungen > Benutzer von Mentcare sollen sich mit ihrem Benutzerausweis von der Gesundheitsbehörde authentifizieren. Externe Anforderungen > Die Ermöglichung des Zugriffs auf Patientendaten soll gemäß den Anforderungen der nationalen Gesetze restriktiert sein. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 28 ZIELE UND ANFORDERUNGEN Nicht-funktionale Anforderungen können ggf nicht präzise festgelegt werden. Und unpräzise Anforderungen können schwer umgesetzt und verifiziert werden. Ziel > Ein allgemein gefasster Wunsch des Benutzers wie „leicht zu bedienen“ Verifizierbare nicht-funktionale Anforderung > Eine Beschreibung mit einer Metrik, die objektiv getestet werden kann. Ziele sind oft hilfreich für Entwickler, da sie die Handlungsziele der Benutzer verdeutlichen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 29 ANFORDERUNGEN AN DIE GEBRAUCHSTAUGLICHKEIT „Das System sollte vom medizinischen Personal leicht zu bedienen sein und so aufgebaut sein, dass Fehler minimiert werden.“ => typisches Systemziel für Manager „Medizinisches Personal sollte nach einer 4-stündigen Schulung sämtliche Systemfunktionen benutzen können. Nach diesem Training soll die durchschnittliche Fehleranzahl pro Stunde Benutzung durch einen erfahrenen Benutzer nicht mehr als 2 betragen.“ => testbare nicht-funktionale Anforderung HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 30 METRIKEN FÜR DIE SPEZIFIKATION NICHT- FUNKTIONALER ANFORDERUNGEN Eigenschaft Metrik Geschwindigkeit Ausgeführte Transaktionen / sec Antwortzeit auf Benutzer / Ereignis Größe M/G/T/PBytes Anzahl von Prozessoren,... Leicht bedienbar Schulungszeit Anzahl von Aufrufen der Hilfe-Funktion Zuverlässigkeit Auftrittswahrscheinlichkeit von Fehlern Verfügbarkeit Robustheit Zeit für Re-Start nach Systemfehler (Wahrscheinlichkeit von Datenverlust bei Systemfehler) Portierbarkeit Anzahl unterstützter Plattformen HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 31 NICHT-FUNKTIONALE ANFORDERUNGEN Nicht-funktionale Anforderungen stehen oft mit funktionalen Anforderungen in Konflikt oder hängen zusammen. > Benutzer von Mentcare sollen sich mit ihrem Benutzerausweis von der Gesundheitsbehörde authentifizieren. > => es muss ein Kartelesegerät an jedem PC installiert werden > Für mobile Geräte von Ärzten muss es eine andere Lösung geben, da dort idR kein Kartenlesegerät installiert ist. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 32  DISKUSSION Wie kann man den Überblick über die Abhängigkeiten zwischen funktionalen und nicht-funktionalen Anforderungen behalten? Nummerierung, Priorisierung HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 33 PROZESSE DES REQUIREMENTS ENGINEERING Requirements Engineering erfordert mehr als nur die Anwendung von Methoden. Erhebung der Anforderungen ist eine am Menschen orientierte Aktivität! (siehe auch: Software Ergonomie) HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 34 PROZESSE DES REQUIREMENTS ENGINEERING Die Prozesse für Requirements Engineering unterscheiden sich stark nach dem Anwendungsfeld, den beteiligten Leuten und der Organisation, die die Anforderungen erhebt. Es gibt 4 generische Aktivitäten, die alle Requirements Engineering Prozesse gemeinsam haben > Erhebung der Anforderungen (requirements elicitation) > Analyse der Anforderungen (requirements analysis) > Validierung der Anforderungen (requirements validation) > Anforderungsmanagement (requirements management) In der Praxis ist Requirements Engineering eine interative Aktivität, in der diese Prozesse verzahnt sind. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 35 PROZESSE DES REQUIREMENTS ENGINEERING Oft noch vorgeschaltet: Durchführbarkeitsstudie Beantwortung von 3 Leitfragen > Leistet das System einen Beitrag zur Verwirklichung der Gesamtziele des Unternehmens? > Kann das System unter Benutzung der derzeitigen Technologie und innerhalb von Kosten- und Zeitbeschränkungen realisiert werden? > Kann das System mit anderen eingesetzten Systemen zusammenarbeiten? HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 36 EIN SPIRALMODELL DES RE-PROZESSES Requirements specification System requirements specification and modeling User requirements specification Business requirements specification Start Feasibility System study Requirements req. Requirements elicitation elicitation User validation requirements elicitation Prototyping Reviews System requirements document HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 37 ERHEBUNG UND ANALYSE DER ANFORDERUNGEN Softwareentwickler arbeiten eng mit der ganzen Bandbreite an Stakeholdern zusammen, um das Geschäftsumfeld kennenzulernen, die benötigten Funktionalitäten zu verstehen, benötigte Performanz und Hardwareeinschränkungen herauszufinden, angeschlossene Systeme zu analysieren etc Besteht aus den Stufen > Entdecken und sammeln der Anforderungen > Klassifizierung und Organisation der Anforderungen > Priorisierung und Verhandlung der Anforderungen > Spezifikation der Anforderungen HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 38 ERHEBUNG UND ANALYSE DER ANFORDERUNGEN Iterative Vorgehensweise bei der Anforderungserhebung und -analyse Verbesserung des Verständnisses der Anforderungen mit jedem Schritt Der Zyklus endet, wenn die Gesamt- 1. Requirements discovery spezifikation vollständig ist. 4. Requirements 2. Requirements specification classification and organization 3. Requirements prioritization and negotiation HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 39 ERHEBUNG UND ANALYSE VON ANFORDERUNGEN Entdecken und Sammeln der Anforderungen > Interaktionen mit den Stakeholdern, um ihre Anforderungen zu entdecken und zu sammeln, auch die Domain Anforderungen. Klassifizierung und Organisation der Anforderungen > Anforderungen in kohärenten Gruppen organisieren. Priorisierung und Verhandlung der Anforderungen > Priorisierung und Auflösung von Konflikten. Spezifikation der Anforderungen > Dokumentation der Anforderungen als Eingabe für die nächste Spirale. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 40 HERAUSFORDERUNGEN BEI DER ANFORDERUNGSERHEBUNG 1. Stakeholder wissen oft nicht so präzise, was sie wirklich wollen und drücken Anforderungen in ihrer eigenen Fachsprache aus. 2. Verschiedene Stakeholder haben möglicherweise miteinander in Konflikt stehende Anforderungen. 3. Es werden ggf unrealistische Anforderungen gestellt, da nicht abschätzbar ist, was machbar ist und was nicht. 4. Politische Faktoren in der Organisation können die Systemanforderungen beeinflussen. 5. Neue Anforderungen ergeben sich während des Analyse Prozesses. Es können neue Stakeholder dazukommen und das Geschäftsfeld kann sich ändern. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 41 ENTDECKEN UND SAMMELN DER ANFORDERUNGEN Der Prozess, bei dem Informationen über das benötigte sowie bestehende Systeme gesammelt werden, um aus diesen die Benutzer- und Systemanforderungen herauszuarbeiten. > Gespräche mit allen Stakeholdern – von Managern bis hin zu externen Prüfern. Ein System hat für gewöhnlich eine ganze Bandbreite an Stakeholdern. > Zudem: Lesen von Dokumentation und Informationen über die Spezifikation ähnlicher Systeme. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 42 ENTDECKEN UND SAMMELN DER ANFORDERUNGEN Unterschiedliche Quellen der Anforderungen (Projektbeteiligte, Anwendungsgebiete, Systeme) können als Perspektiven (Viewpoints) auf das System dargestellt werden. Jeder Viewpoint stellt eine Untermenge der Systemanforderungen dar, beleuchtet das Problem auf eine andere Art und Weise. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 43 ENTDECKEN UND SAMMELN DER ANFORDERUNGEN Es gibt eine Reihe von Werkzeugen, die für das Entdecken und Sammeln von Anforderungen nützlich sein kann > Interviews > User Stories und Szenarios > Storyboard > Ethnographie Live Beobachtung HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 44 INTERVIEWS Formale oder informale Interviews mit den Stakeholdern sind Bestandteil der meisten RE-Prozesse. Fragen zum aktuellen und dem neu zu entwicklenden System. Arten von Interviews > Geschlossene Interviews auf der Basis eines Fragenkatalogs. > Offene Interviews, in denen verschiedene Aspekte des Systems mit den Stakeholdern sondiert werden. Effektives Interviewen > Seien Sie aufgeschlossen, vermeiden Sie eine eigene vorgefertigte Meinung über die Anforderungen und hören Sie den Stakeholdern zu. > Halten Sie die Diskussion am Laufen indem Sie zB offene Fragen stellen, einen Anforderungsvorschlag diskutieren oder zusammen an einem Prototyp arbeiten. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 45 INTERVIEWS IN DER PRAXIS Sind meist eine Mischung aus geschlossenem und offenem Interview. Durch Interviews bekommt man einen guten Überblick, wie die Stakeholder arbeiten und wie sie das System benutzen könnten. Personen reden idR gerne über ihre Arbeit und sind meist glücklich, wenn sie gehört werden, um ein System zu verbessern. Gespäche über das System müssen ggf. angestoßen werden durch das Vorschlagen von Anforderungen, anstatt einfach zu fragen was gewünscht wird. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 46 PROBLEME MIT INTERVIEWS Spezialisierte Anwender können eine fachspezifische Sprache benutzen, die ein Requirements-Engineer uU nicht versteht. Mit Interviews kommt man schwer an Domain-Anforderungen heran. > Requirements Engineers verstehen uU nicht die Terminologie des Geschäftsfelds. > Manche Gegebenheiten in einem Geschäftsumfeld sind so selbstverständlich für Leute die sich in diesem Umfeld bewegen, so dass diese nicht erwähnt werden. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 47 USER STORIES UND SZENARIOS Wirklichkeitsnahe Beispiele, wie das System benutzt werden kann. Detailierte Beschreibung, wie ein System für eine bestimmte Aufgabe benutzt werden kann. Da sie auf praktischen Situationen basieren, können sich die zukünftigen Benutzer damit identifizieren und die Story in Bezug auf ihre Situation kommentieren. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 48 USER STORY FÜR MENTCARE „Anna ist eine 45 Jahre alte Krankenschwester. Sie arbeitet in der psychiatrischen Klinik und ist dort seit 5 Jahren in Leitungsposition. Ihrer Verantwortung untersteht es, dass die Behandlungszimmer für den nächsten Tag für die diensthabenden Ärzte vorbereitet werden. Sie hat gerade ihren letzten Patienten versorgt und hat nun noch 20 Minuten Zeit, bis sie nach Hause gehen muss. Anna hält ihre ID-Karte an den Kartenleser des Mentcare PCs und kommt so nach einigen Sekunden auf ihren personalisierten Anfangsbildschirm des Systems.“ [...] Das Szenario geht nun noch weiter mit einer detailierten Beschreibung von Annas Interaktion mit Mentcare. Nicht-Funktionale Anforderungen: -Man muss sich identifizieren (ID Karte) -Schnelligkeit -immer abrufbar HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 49 SZENARIO Strukturierte Form einer User Story Können als Text geschrieben und durch Diagramme, Screenshots etc unterstützt werden Ein Szenario sollte beinhalten > Eine Beschreibung der Ausgangssituation > Eine Beschreibung der normalen Abläufe > Eine Beschreibung was schieflaufen kann > Informationen über weitere parallel ablaufende Aktivitäten > Eine Beschreibung der Endsituation HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 50 BEISPIELSZENARIO FÜR MENTCARE HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 51 BEISPIELSZENARIO FÜR MENTCARE HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 52 STORYBOARDS Visualisierung einer Story In den 1920er Jahren in Hollywood erfunden Geschichte mit detailierten Bildern Wird va im Bereich Mensch-Computer-Interaktion angewendet HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 53 STORYBOARDS HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 54 ENTDECKEN UND SAMMELN DER ANFORDERUNGEN Szenarios, User Stories und Storyboards sind effektive Verfahren zum Ermittlen der Anforderungen von Projektbeteiligten, die direkt mit dem System interagieren. Weniger gut geeignet für > Ermitteln von Beschränkungen > Geschäftliche und nicht-funktionale Anforderungen > Bestimmen von fachlichen Anforderungen HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 56 ETHNOGRAPHY Ein Sozialwissenschaftler verbringt eine ganze Menge Zeit damit, Leute zu beobachten und zu analysieren, was diese wirklich machen. Zukünftige Benutzer müssen nicht erklären, was sie machen- Sie müssen ihre Arbeit nicht in Worte fassen. Wichtige soziale und organisatorische Faktoren können ggf beobachtet werden. Ethnographische Studien zeigen, dass Arbeitsabläufe meist wesentlich komplexer sind als einfach Systemmodelle. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 57 FOKUSSIERTE ETHNOGRAPHIE Kombiniert Ethnography mit Prototyping Entwicklung des Prototyps resultiert in Fragen, welche die ethnographische Analyse fokussieren Ethnographic Debriefing Focused analysis meetings ethnography Prototype evaluation Generic system System development protoyping HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 58 ANWENDUNGSBEREICH VON ETHNOGRAPHIE Wenn man Anforderungen auf Basis realer Arbeitsprozesse erheben möchte und nicht auf Basis definierter theoretischer Arbeitsprozesse. Mit Ethnographie können effektiv bestehende Prozesse analysiert werden, aber es können keine Verbesserungen identifiziert werden, die dem System hinzugefügt werden sollen. > Möglicherweise werden Praktiken beobachtet, die einmal sinnvoll waren, die jedoch inzwischen nicht mehr relevant sind. Ethnographie ist auch weniger gut geeignet für die Erhebung von Anforderungen des Unternehmens. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 59  QUESTIONS & ANSWERS Zeit für Ihre Fragen HHN | Medizinische Informatik - SWE 1 | [email protected] | 60 SPEZIFIKATION SPEZIFIKATION DER ANFORDERUNGEN Schriftliche Fixierung der Benutzer- und Systemanforderungen in einer Gesamtspezifikation (software requirements document). Die Gesamtspezifikation beinhaltet > Benutzeranforderungen müssen von Endbenutzern und Kunden ohne technischen Hintergrund verständlich sein. > Systemanforderungen sind detaillierter und enthalten mehr techn. Informationen. Die Spezifikation soll den Entwurf nicht vorwegnehmen! > Es geht darum, was das System machen soll und nicht wie. > Diese Trennung kann in der Praxis ggf nicht ganz aufrecht erhalten werden. zB muss man ggf eine Systemarchitektur entwerfen, um die Anforderungen zu strukturieren. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 62 SPEZIFIKATION DER ANFORDERUNGEN Die Gesamtspezifikation spielt bei der Vergabe von Projekten nach extern eine zentrale Rolle. Oft Aufteilung in > Lastenheft „Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“ (DIN 69901-5) Was will der Kunde? > Pflichtenheft „Vom Auftragnehmer erarbeitetes Realisierungsvorhaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts.“ (DIN 69901-5) Was wollen wir dem Kunden erstellen? Alles zusammen bildet die Vertragsgrundlage. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 63 SPEZIFIKATION DER ANFORDERUNGEN Generell gilt: Der Detailierungsgrad der Gesamtspezifikation hängt ab von > der Art des zu entwicklenden Systems > dem verwendeten Entwicklungsprozess Detailierte Anforderungen bei > Kritischen Systemen > Externer Entwicklung Weniger detailierte Anforderungen bei > Iterativem Ansatz > Interner Entwicklung => Mehrdeutigkeiten können ggf während der Entwicklung noch geklärt werden HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 64 SPEZIFIKATION DER ANFORDERUNGEN Die Gesamtspezifikation wird von verschiedenen Leuten gelesen Von denen, die... >... die SW bezahlen >... die Entwicklung planen >... die SW entwickeln >... die SW benutzen >... die SW testen >... die SW warten >... HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 65 DIE GESAMTSPEZIFIKATION Es gibt einen IEEE-Standard für die Gesamtspezifikation > Sehr allgemein > Kann auf die spezielle Anwendung angepasst werden HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 66 DIE GESAMTSPEZIFIKATION ALLGEMEINE STRUKTUR 1/3 Vorwort > Sollte die erwartete Leserschaft des Dokuments festlegen und eine Versionshistorie beschreiben, die eine Begründung einer neuen Version, sowie eine Zusammenfassung über Änderungen zur letzten Version beinhalten sollte. Einleitung > Sollte die Notwendigkeit des Systems beschreiben. Es sollte kurz die Systemfunktionen darlegen und erklären, wie es mit anderen Systemen zusammenarbeiten wird. Außerdem soll erläutert weren, wie das System mit den gesamtwirtschaftlichen oder strategischen Zielen des Unternehmens übereinstimmt, das die Software in Auftrag gibt. Glossar > Sollte die im Dokument verwendeten technischen Fachbegriffe festlegen. Dabei sollten Sie keine Erfahrung oder Fachwissen beim Leser voraussetzen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 67 DIE GESAMTSPEZIFIKATION ALLGEMEINE STRUKTUR 2/3 Definition der Benutzeranforderungen > Beschreibt die Dienste, die für den Benutzer bereitgestellt werden. Die nicht-funktionalen Anforderungen sollten hier ebenfalls beschrieben werden. Diese Beschreibung kann natürliche Sprache, Diagramme oder andere für Kunden verständliche Notationen benutzen. Produkt- und Entwicklungsstandards, die befolgt werden müssen, sollten ebenfalls festgelegt werden. Systemarchitektur > Sollte einen groben Überblick über die erwartete Systemarchitektur geben, der die Verteilung der Funktionen auf die Systemmodule zeigt. Wiederverwendete Komponenten sollten gekennzeichnet werden. Spezifikation der Systemanforderungen > Sollte die funktionalen und nicht-funktionalen Anforderungen genauer beschreiben. Ggf können auch weitere Einzelheiten zu den nicht-funktionalen Anforderungen hinzugefügt werden. Schnittstellen zu anderen Systemen können definiert werden. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 68 DIE GESAMTSPEZIFIKATION ALLGEMEINE STRUKTUR 3/3 Systemmodelle > Hier können graphische Systemmodelle enthalten sein, um die Beziehungen zwischen den Systemkomponenten und dem System und seiner Umgebung aufzuzeigen. Bsp für Modelle sind Objekt-, Datenfluss- und semantische Datenmodelle. Systemevolution > Sollte die grundlegenden Voraussetzungen, auf denen das System basiert, und jede erwartete Veränderung aufgrund der Hardwareentwicklung, Veränderungen der Benutzeranforderungen etc beschreiben. Für Systementwickler nützlich, da dieser Abschnitt helfen kann, Entwurfsentscheidungen zu vermeiden, die voraussichtliche Änderungen in der Zukunft am System beschränken würden. Anhänge > Genauere Information mit Bezug zur Anwendung, zB Hardware- & Datenbankbeschreibungen. Index > Ggf mehrere Indices, zB Schlagwörter, Abbildungen, Funktionen,... HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 69 DIE GESAMTSPEZIFIKATION Enthaltene Information hängt von der zu entwickelnden SW ab > Evolutionärer Prozess Auslassen einiger Kapitel Schwerpunkt liegt auf Benutzeranforderungen und übergreifenden nicht-funktionalen Anforderungen Urteilsvermögen der Entwickler ist gefragt > Großes Systemprojekt Hard- und Software arbeiten zusammen Notwendigkeit, die Anforderungen detailliert zu spezifizieren Gesamt- spezifikation wird sehr umfangreich > Diverse Inhaltsverzeichnisse bzw Indices HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 70 UND WIE WIRD DIE GESAMTSPEZIFIKATION NUN AUFGESCHRIEBEN? Benutzeranforderungen > idR in natürlicher Sprache, angereichert um geeignete Diagramme oder Tabellen Systemanforderungen > Natürliche Sprache möglich, aber auch andere Notationen, die auf Formularen, graphischen oder mathematischen Systemmodellen basieren HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 71 NOTATIONEN FÜR DIE SYSTEMANFORDERUNG (1/2) Sätze in natürlicher Sprache > Die Anforderungen werden als durchnummerierte Sätze in natürlicher Sprache aufgeschrieben. Jeder Satz sollte eine Anforderung ausdrücken. Strukturierte natürliche Sprache > Die Anforderungen werden in natürlicher Sprache in ein Standardformular oder eine Vorlage geschrieben. Jedes Feld liefert Informationen über einen Aspekt der Anforderung. Sprachen zur Entwurfsbeschreibung > Nutzung einer Sprache ähnlich einer Programmiersprache, aber mit eher abstrakten Funktionen zur Spezifikation der Anforderungen durch Definition eines funktionsfähigen Modells des Systems. Selten eingesetzt, kann aber va für die Spezifikation von Schnittstellen sehr nützlich sein. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 72 NOTATIONEN FÜR DIE SYSTEMANFORDERUNG (2/2) Graphische Notationen > Graphische Modelle, ergänzt durch Textvermerke, werden zur Definition der funktionalen Anforderungen am System verwendet. Anwendungsfälle (use cases) und Sequenzdiagramme der UML (Unified Modeling Language) sind weit verbreitet. Mathematische Spezifikationen > Notationen, die auf einem mathematischen Konzept aufbauen, wie zB endliche Zustandsautomaten oder Mengen. Diese eindeutigen Spezifikationen können zwar die Mehrdeutigkeiten in Gesamtsystemspezifikationen reduzieren, jedoch verstehen die meisten Kunden diese formalen Spezifikationen nicht. Sie können nicht überprüfen, ob diese Spezifikation ihren Wünschen entspricht und sind daher abgeneigt, sie als Vertragsinhalt zum System zu akzeptieren. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 73 SPEZIFIKATION IN NATÜRLICHER SPRACHE Positiv > Ausdrucksstark => wird vom Kunden und > Intuitiv Endbenutzer verstanden J > Universell Negativ > Vage und mehrdeutig Sehr präzise zu beschreiben ist schwierig und liest sich auch schwer > Bedeutung hängt ggf vom Hintergrund des Lesers ab > Funktionale und nicht-funkt. Anforderungen werden gern vermischt > Verschieden Anforderungen werden uU nicht scharf getrennt HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 74 SPEZIFIKATION IN NATÜRLICHER SPRACHE TIPPS 1. Entwickeln Sie ein Standardformat und stellen Sie sicher, dass alle Anforderungsdefinitionen diesem Format entsprechen. => Minimierung des Risikos von Versäumnissen und leichtere Überprüfung der Anforderungen. 2. Jede Anforderung in einem einzigen Satz ausdrücken. 3. Einheitliche Sprache verwenden. Ua auch: Verbindliche Anforderung: „muss“; opt. Anforderung: „sollte“ 4. Farbliches Hervorheben von Schlüsselworten und –sätzen. 5. Vermeiden Sie Computer-Jargon, Abkürzungen und Akronyme. 6. Jede Anforderung sollte durch eine Begründung gestützt sein. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 75 SPEZIFIKATION IN NATÜRLICHER SPRACHE BSP INSULINPUMPE 1. Das System muss alle 10 Minuten den Blutzuckerspiegel messen und falls nötig Insulin ausgeben. (Der Blutzuckerspiegel ändert sich relativ langsam, deswegen sind häufigere Messungen unnötig; seltenere Messungen könnte hingegen zu einem hohen Blutzuckerspiegel führen.) 2. Das System muss jede Minute einen Selbsttest ausführen. Die dabei zu testenden Bedingungen und damit verbundenen Aktionen sind in Tabelle 1 festgelegt. (Ein Selbsttest kann Hardware- und Softwareprobleme aufdecken und den Benutzer warnen, dass ggf der normale Betrieb nicht möglich ist.) HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 76 SPEZIFIKATION IN STRUKTURIERTER SPRACHE Stukturierte Sprache bietet die Möglichkeit, die Freiheit des Autors einzuschränken, um so eine standardisierte Form der Anforderungsspezifikation zu erhalten. Ausdruck und Verständlichkeit bleiben erhalten Verwendung von Spezifikationsvorlagen HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 77 SPEZIFIKATION IN STRUKTURIERTER SPRACHE IN EINEM STANDARDFORMULAR ENTHALTENE INFORMATIONEN Beschreibung der spezifizierten Funktion oder Entität Beschreibung der Eingabedaten und deren Herkunft Beschreibung ihrer Ausgaben und deren Ziel Informationen über die Hinweise, die für die Berechnung oder für andere benutzte Entitäten im System benötigt werden Beschreibung der vorzunehmenden Aktion Für funktionale Methoden: > Vorbedingung: muss erfüllt sein, bevor die Funktion ausgeführt wird > Nachbedingung: ist erfüllt, nachdem die Funktion ausgeführt wurde Beschreibung der Seiteneffekte der Funktion (falls vorhanden) HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 78 SPEZIFIKATION IN STRUKTURIERTER SPRACHE BSP INSULINPUMPE Insulinpumpe/Steuerungssoftware/SRS/3.3.2 Funktion Berechne Insulindosis: Sicherer Zuckerspiegel Beschreibung Berechnet die auszugebende Insulindosis, wenn sich der zurzeit gemessene Zuckerspiegel in der sicheren Zone zwischen 3 und 7 Einheiten bewegt. Eingaben Aktuelle Zuckermessung (r2), vorhergehende 2 Messungen (r0 und r1) Quelle Aktuelle Messung vom Sensor. Andere Messungen aus dem Speicher. Ausgaben CompDose – die auszugebende Insulindosis Ziel Hauptsteuerungsschleife Aktion CompDose ist null (=0), wenn der Zuckerspiegel stabil ist oder fällt oder wenn der Spiegel zwar steigt, aber die Steigungsrate fällt. Wenn der Spiegel und die Steigungsrate ansteigt wird CompDose berechnet, indem die Differenz zwischen r2 und r1 durch 4 geteilt und das Ergebnis gerundet wird. Wenn das Ergebnis auf null gerundet wird, wird CompDose auf die Minimaldosis gesetzt. Benötigt Zwei vorhergehende Messungen, sodass die Änderungsrate des Zuckerspiegels berechnet werden kann. Vorbedingung Der Insulintank enthält mindestens die zulässige maximale Einzeldosis Insulin. Nachbedingung R0 wird durch r1 ersetzt und r1 anschließend durch r2 Seiteneffekte keine HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 79 SPEZIFIKATION IN STRUKTURIERTER SPRACHE Zwingt zu einer relativ vollständigen Spezifikation. Weniger Mehrdeutigkeiten als bei natürlicher Sprache. Manchmal dennoch schwierig Anforderungen klar und eindeutig zu schreiben falls komplexere Berechnungen anzugeben sind, zB Berechnung der Insulindosis Lösungen: 1. Zusätzliche Informationen mittels Tabellen, graphischen Modellen oder mathematischen Formeln 2. Tabellen > Nützlich falls es mehrere Alternativen und Aktionen gibt HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 80 SPEZIFIKATION IN STRUKTURIERTER SPRACHE BSP INSULINPUMPE Tabelle für Berechnung der Insulindosis Bedingung Vorgang Zuckerspiegel fällt (r2 < r1) CompDose = 0 Zuckerspiegel stabil (r2 = r1) CompDose = 0 Zuckerspiegel steigt, Steigungsrate sinkt CompDose = 0 ((r2-r1) < (r1-r0)) Zuckerspiegel steigt, Steigungsrate ist stabil CompDose = runden ((r2-r1)/4) oder steigt ((r2 > r1) & ((r2-r1) ≥ (r1-r0))) Falls Ergebnis = 0 dann CompDose = MinimumDose HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 81 SPEZIFIKATION IN GRAPHISCHER NOTATION Für die graphische Notation sind die Diagramme der UML gebräuchlich. Beschreiben das System aus verschiedenen Perspektiven. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 82 SPEZIFIKATION IN GRAPHISCHER NOTATION Für die Spezifikation der (Benutzer)interaktionen mit dem System auf höchster Ebene werden Anwendungsfälle (use cases) verwendet. Anwendungsfälle sind ähnlich zu Szenarios. Ein Anwendungsfall benennt im einfachsten Fall > die beteiligten Akteure > die Art der Interaktion Anreicherung mit zusätzlichen Informationen zur Beschreibung der Interaktion mit dem System > Textuelle Beschreibung, strukturiert oder unstrukturiert > Weitere graphische Modelle, zB Sequenz- oder Aktivitätsdiagramme HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 83 SPEZIFIKATION IN GRAPHISCHER NOTATION ANWENDUNGSFÄLLE Anwendungsfälle werde mit Hilfe eines übergeordneten Anwendungsfalldiagrammes dokumentiert. Die Menge der Anwendungsfälle repräsentiert alle möglichen Interaktionen, die in den Systemanforderungen beschrieben sein sollen => Vollständigkeit (!) Elemente: 1. Akteure können Personen oder andere Systeme sein 2. Jeder Anwendungsfall repräsentiert einen Interaktionstyp 3. Linien verbinden die Akteure mit den Anwendungsfällen > Optional: Pfeilspitzen – von wem wird die Interaktion initiiert HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 84 SPEZIFIKATION IN GRAPHISCHER NOTATION ANWENDUNGSFALLDIAGRAMM FÜR MENTCARE HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 85 SPEZIFIKATION IN GRAPHISCHER NOTATION ANWENDUNGSFÄLLE Anwendungsfalldiagramme stellen die individuellen Wechselwirkungen zwischen dem System und seinen Benutzern oder anderen Systemen dar. Jeder Anwendungsfall sollte mit (strukturierter) natürlicher Sprache ergänzt werden. Anwendungsfalldiagramme lassen sich mit anderen Modellen der UML verknüpfen => Beschreibung des Systems aus vielen Perspektiven. UML-Diagramme der Anforderungsspezifikation lassen sich unkompliziert in Entwurfsmodelle weiterentwickeln. Hinweis: Vorlage zur Strukturierung eines Anwendungsfalles im ILIAS. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 86 SPEZIFIKATION IN GRAPHISCHER NOTATION ANWENDUNGSFALLDIAGRAMM FÜR MENTCARE Kurze Beschreibung des Anwendungsfalls „ärztliche Beratung einleiten“ > Bei der Einleitung einer ärztlichen Behandlung können zwei oder mehr Ärzte, die in verschiedenen Büros arbeiten, gleichzeitig denselben Datensatz sehen. Ein Arzt eröffnet die Sitzung, indem er die einzubeziehenden Ärzte aus einem Drop-Down Menü auswählt, welches alle Ärzte enthält die gerade online sind. Die elektronische Krankenakte wird dann auf dem Bildschirm angezeigt, aber nur der Arzt, der die Beratung eröffnet hat, kann den Datensatz verändern. Außerdem wird ein Chatfenster für Nachrichten erzeugt, um die Koordination der Aktionen zu unterstützen. Es wird davon ausgegangen, dass Sprachkommunikation separat genutzt werden kann. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 87 ANWENDUNGSFALL ÜBUNG ONLINE-SHOP Erstellen Sie ein Anwendungsfalldiagramm für einen (einfachen!) Online-Shop > Welche Akteure gibt es? > Welche Interaktionstypen (Anwendungsfälle) gibt es? > Beschreiben sie jeden Anwendungsfall kurz HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 88 REQUIRMENTS ENGINEERING Jetzt sind die Anforderungen erhoben... Die Gesamtspezifikation ist fertig J Tief durchatmen! Und nun? HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 89 VALIDIERUNG DER ANFORDERUNGEN Überprüfung, ob die Anforderungen wirklich das System definieren, das der Kunde benötigt und erwartet. Analyse und Validierung der Anforderungen stellen sich überschneidende Aktivitäten dar. Zur Erinnerung: > 60% der Fehler entstehen während des Requirements Engineering. > Einen Fehler erst nach der Implementierung zu finden ist 100x teurer als ihn während des Requirements Engineerings zu finden. > Nachträgliche Veränderung der Anforderungen bedeutet, dass Entwurf und Implementierung verändert werden müssen und dann das System noch einmal getestet werden muss. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 90 VALIDIERUNG DER ANFORDERUNGEN PRÜFARTEN Gültigkeitsprüfung > Stellt das System wirklich die Funktionen zur Verfügung, die den Bedarf der Benutzer abdecken? Sind alle abgeleiteten Anforderungen enthalten? Konsistenzprüfung > Stehen verschiedene Anforderungen miteinander in Widerspruch? Vollständigkeitsprüfung > Sind wirklich alle benötigten Funktionalitäten und Bedingungen abgedeckt? Realisierbarkeitsprüfung > Kann das System nach dem aktuellen Stand der Technik umgesetzt werden? Ist das System innerhalb der vorgegebenen Zeit und der geplanten Kosten realisierbar? Verifizierbarkeitsprüfung > Sind die Anforderungen überprüfbar? Können sie eindeutig getestet werden? HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 91 VALIDIERUNG DER ANFORDERUNGEN VALIDIERUNGSTECHNIKEN Review der Anforderungen > Die Anforderungen werden systematisch durch ein Team von Gutachtern analysiert, die auf Fehler und Inkonsistenzen prüfen. Prototyping > Endnutzer können mit einem Prototyp (funktionsfähiges Modell des Systems) experimentieren, um zu prüfen, ob es den tatsächlichen Anforderungen entspricht. Generierung von Testfällen > Umsetzung der Anforderungen in Testfälle, um die Testbarkeit der Anforderungen festzustellen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 92 VALIDIERUNG DER ANFORDERUNGEN REVIEW DER ANFORDERUNGEN 1. Während des des gesamten Requirements Engineering Prozesses sollten regelmäßige Reviews durchgeführt werden. 2. Sowohl Kunde / Benutzer als auch Auftragnehmer / Entwickler sollten in diese Reviews eingebunden sein. 3. Reviews können formell sein (inkl Dokumentation) oder informell. Gute Kommunikation zwischen Entwicklern, Kunde und Benutzern ist essentiell, um Probleme frühzeitig zu entdecken bzw gar nicht erst aufkommen zu lassen! HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 93 VALIDIERUNG DER ANFORDERUNGEN PRÜFFRAGEN FÜR DAS REVIEW 1. Ist jede Anforderung realistisch testbar? 2. Ist jede Anforderung vollständig verstanden worden? 3. Ist der Ursprung / das Ziel jeder Anforderung klar? 4. Kann jede Anforderung geändert werden, ohne dass andere Anforderungen davon stark betroffen sind? HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 94 VALIDIERUNG DER ANFORDERUNGEN Es ist schwierig zu zeigen, dass eine bestimmte Menge an Anforderungen tatsächlich alle Bedürfnisse der Benutzer erfüllt. Benutzer müssen sich die Software im Betrieb vorstellen... Es ist somit (fast) unmöglich, alle Fehler innerhalb der Validierung zu finden.... but it‘s worth trying! J HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 95 ANFORDERUNGSMANAGEMENT Anforderungen an Softwaresysteme ändern sich ständig => Anforderungen sind (immer) unvollständig Verständnis der Projektbeteiligten ändert sich während des Softwareprozesses => Systemanforderungen müssen sich ebenfalls weiterentwickeln. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 96 ANFORDERUNGSMANAGEMENT Nach der Systeminstallation und regelmäßigen Benutzung entstehen neue Bedürfnisse und Anderungswünsche => neue Anforderungen. Benutzer und Systemkunden können nur schwer voraussehen, welche Auswirkungen das neue System auf ihre Geschäftsprozesse haben wird. Außerdem... HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 97 ANFORDERUNGEMANAGEMENT Änderung des wirtschaftlichen und technischen Umfelds > Neue Hardware > Kopplung von Systemen, zB Datenaustausch > Neue Gesetze und Regelungen Systemkunden („zahlen“) ≠ Endnutzer (nutzen das System) > Anforderungen wurden (oft) aufgrund wirtschaftlicher Randbedingungen festgelegt > Nach Auslieferung festgestellt, dass Anf. der Endnutzer (zu) wenig berücksichtigt Große Systeme haben idR vielfältige Benutzergruppen => verschiedene Anforderungen & Prioritäten > Widersprüche, Konflikte => Endgültige Anforderungen sind ggf ein Kompromiss, ggf Veränderung des Schwerpunktes bei den Anforderungen HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 98 ANFORDERUNGSMANAGEMENT Anforderungsmanagement ist der Prozess des Verstehens und Kontrollierens von Anforderungen. Individuelle Anforderungen werden überwacht. Die Verbindungen voneinander abhängiger Anforderungen wird im Überblick behalten, so dass Auswirkungen von Anforderungs- änderungen abgeschätzt werden können. Implementierung eines formalen Prozesses für Anforderungsänderungen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 99 ANFORDERUNGSMANAGEMENT PLANUNG DES ANFORDERUNGSMANAGEMENTS Wichtige erste Etappe des Anforderungsmanagements Es muss über folgende Punkte entschieden werden > Anforderungsidentifikation: Jede Anforderung müss durch ein Kürzel (ID) eindeutig identifizierbar sein. Vereinfacht Querverweise und sie zur Nachvollziehbarkeit identifiziert werden können. > Ablauf des Änderungsmanagements: Menge an Aufgaben, die die Auswirkungen und Kosten der Änderung einschätzen. > Richtlinien zur Nachvollziehbarkeit: Legen fest, welche Beziehungen zwischen den Anforderungen und Anforderungen und dem Systementwurf erfasst werden sollen. > Unterstützung durch Werkzeuge: Anforderungsmanagement umfasst den Umgang mit großen Daten. Spezielle Werkzeuge für das Anforderungsmanagement, Tabellenkalkulation oder einfache Datenbanksysteme können unterstützen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 100 ANFORDERUNGSMANAGEMENT PLANUNG DES ANFORDERUNGSMANAGEMENTS Anforderungsmanagement benötigt eine automatisierte Unterstützung. Softwarewerkzeuge zur Unterstützung sollten bereits während der Planungsphase ausgewählt werden. An der HHN für Anforderungsmanagement verwendet: Jira von Atlassian, vgl. auch agile Software Engineering > ist integriert mit Confluence => Diskussionsforum und Dokumentablage > und Bitbucket => skalierbare, verteile Versionskontrolle >... werden Sie in den Software Laboren verwenden HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 101 ANFORDERUNGSMANAGEMENT PLANUNG DES ANFORDERUNGSMANAGEMENTS Diese Punkte sollten durch Werkzeuge unterstützt werden > Anforderungsspeicher: Anforderungen sollten in einem sicher verwaltet und aufbewahrt werden, zu dem jeder* gemäß Rolle Zugriff(srechte) hat. > Änderungsmanagement: Vereinfachung durch Unterstützung von Werkzeugen. > Nachvollziehbarkeitsmanagement: Werkzeugunterstützung ermöglicht, dass verwandte bzw abhängige Anforderungen erkannt und verfolgt werden können. Bei kleinen Systemen sind spezialisierte Werkzeuge möglicherweise nicht erforderlich. > Anforderungsmanagement kann durch Textverarbeitung, Tabellenkalkulationssysteme oder Datenbanken unterstützt werden. Bei großen Systemen ist ein spezialisertes Werkzeug erforderlich. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 102 ANFORDERUNGSMANAGEMENT ANFORDERUNGSÄNDERUNGSMANAGEMENT Ist für alle Anforderungen zuständig, die nach der Genehmigung der Gesamtspezifikation vorgeschagen werden. Abwägen, ob die Vorteile der Implementierung der neuen Anforderungen die ddaurch entstehenden Kosten rechtfertigen. Formales Verfahren > Alle Änderungsvorschläge werden gleich behandelt > Änderungen am Gesamtsystem erfolgen kontrolliert HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 103 ANFORDERUNGSMANAGEMENT ANFORDERUNGSÄNDERUNGSMANAGEMENT Problemanalyse und Änderungsspezifikation > Prozess beginnt bei einem a) bei den Anforderungen erkannten Problem oder b) bestimmten Änderungsvorschlag. Prüfung auf Validität => genauer Änderungsvorschlag oder Rücknahme der Änderungsanfrage Änderungsanalyse und Aufwandsschätzung > Bewertung der Auswirkungen der vorgeschlagenen Änderung inkl Abhängigkeiten => Kostenschätzung der Änderung an Spezifikation, Entwurf und Implementierung => Entscheidung über Anforderungsänderung Implementierung der Änderung > Durchführung der Modifikation HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 104 ANFORDERUNGSMANAGEMENT Praxiserfahrung > Implementierung einer Anforderungsänderung dringend erforderlich. > Oft wird erst das System geändert mit der Absicht, die Änderung in die Gesamtspezifikation noch einzupflegen... > Gesamtspezifikation wird nicht angepasst > Spezifikation wird inkonsistent... => System und Spezifikation driften auseinander... HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 105  QUESTIONS & ANSWERS Zeit für Ihre Fragen HHN | Medizinische Informatik - SWE 1 | [email protected] | 106 ZUSAMMENFASSUNG Anforderungen an ein Softwaresystem legen fest, was das System leisten soll; zudem sie definieren Einschränkungen seiner Funktion und Implementierung. Funktionale Anforderungen sind Aufstellungen der Dienste, die das System bereitstellen soll oder Beschreibungen, wie Berechnungen durchgeführt werden müssen. Nicht-funktionale Anforderungen schränken häufig das zu entwickelnde System und das dafür verwendete Entwicklungsverfahren ein. Dabei kann es sich um Produkt- oder, Unternehmensanforderungen und externe Anforderungen handeln. Sie beziehen sich oft auf das System als Ganzes. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 107 ZUSAMMENFASSUNG Die Gesamtspezifikation ist die vereinbarte Aufstellung der Systemanforderungen. Sie sollte so aufgebaut sein, dass sie sowohl vom Systemkunden als auch von Softwareentwicklern verstanden werden kann. Der Prozess des Requirements Engineering umfasst eine Durchführbarkeitsstudie, die Anforderungserhebung und –analyse, die Anforderungsspezifikation sowie die Anforderungsvalidierung und das Anforderungsmanagement. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 108 ZUSAMMENFASSUNG Die Anforderungserhebung und –analyse ist ein sich wiederholender Prozess, der als Spirale von Aktivitäten dargestellt werden kann: Anforderungssammlung, Klassifizierung und Organisation von Anforderungen, Auflösung von Konflikten und Dokumentation von Anforderungen. Die Validierung der Anforderungen ist der Prozess, in dem die Anforderungen auf Gültigkeit, Konsistenz, Vollständigkeit, Realisierbarkeit und Verifizierbarkeit überprüft werden. Wirtschaftliche, organisatorische und technische Änderungen führen unweigerlich zu Änderungen der Anforderungen für ein Softwaresystem. Das Anforderungsmanagement umfasst das Verwalten und die Steuerung dieser Änderungen. HHN | Medizinische Informatik - SWE 1 | [email protected] Seite 109  KONTAKT Martin Wiesner Fakultät für Informatik | Medizinische Informatik Heilbronn University Max-Planck-Str. 39 74081 Heilbronn X (aka Twitter): @mawiesne Phone: +49 7131 504 6947 Mail: [email protected] Web: http://www.mi.hs-heilbronn.de/ HHN | Medizinische Informatik - SWE 1 | [email protected] | 110