{"id":836,"date":"2013-02-02T22:32:29","date_gmt":"2013-02-02T21:32:29","guid":{"rendered":"http:\/\/www.capri-soft.de\/blog\/?p=836"},"modified":"2013-02-04T14:56:58","modified_gmt":"2013-02-04T13:56:58","slug":"requirements-engineering","status":"publish","type":"post","link":"https:\/\/www.capri-soft.de\/blog\/?p=836","title":{"rendered":"Requirements Engineering"},"content":{"rendered":"<h1>Vorwort und Quellen<\/h1>\n<p>Dieser Artikel entstand im Rahmen meiner IREB-Zertifizierung zum <em>Certified Professional for Requirements Engineering <\/em>und beinhaltet eine verdichtete, pr\u00fcfungsrelevante Zusammenfassung und Ausschnitte des IREB-Werkes &#8222;<em>Basiswissen &#8211; Requirements Engineering<\/em>&#8220; von Rupp \/ Pohl.<\/p>\n<h1>Grundlagen<\/h1>\n<h2>Gr\u00fcnde f\u00fcr Requirements Engineering<\/h2>\n<ul>\n<li>Budget\u00fcberschreitung<\/li>\n<li>v\u00f6lliges Scheitern eines Projektes<\/li>\n<li>60 Prozent der Fehler in der Entwicklung sind aufgrund mangelnder Anforderungen<\/li>\n<li>Fehler, die bereits in den Anforderungen entstehen, verursachen bei zunehmendem\u00a0 Projektfortschritt h\u00f6here Kosten und sollte m\u00f6glichst fr\u00fch beseitigt werden.<\/li>\n<li>Symptome bei mangelhaftem RE sind fehlende und unklare Anforderungen<\/li>\n<\/ul>\n<p>Gr\u00fcnde f\u00fcr mangelhaftes Requirements Engineering<\/p>\n<ul>\n<li>Die Stakeholder denken, dass <strong>vieles selbstverst\u00e4ndlich<\/strong> ist<\/li>\n<li><strong>Kommunikationsprobleme und Konflikte<\/strong> aufgrund von unterschiedlichem Wissen und unterschiedlichen Erfahrungen<\/li>\n<li><strong>Projektdruck<\/strong>: Der Auftraggeben will m\u00f6glichst schnell ein sichtbares Ergebnis pr\u00e4sentiert bekommen<\/li>\n<\/ul>\n<h2>Die vier Hauptt\u00e4tigkeiten des RE<\/h2>\n<ol>\n<li>Anforderungen erheben<\/li>\n<li>Anforderungen dokumentieren<\/li>\n<li>Anforderungen abstimmen und pr\u00fcfen<\/li>\n<li>Anforderungen verwalten<\/li>\n<\/ol>\n<h2>Die Rolle der Kommunikation im RE<\/h2>\n<p>Das Verwenden von nat\u00fcrlicher Sprache ist das wichtigste Hilfsmittel im Requirements Engineering. Das Kommunikationsmedium (also ob eine Anforderung schriftlich oder m\u00fcndlich erfasst wird) spielt ebenfalls eine gro\u00dfe Rolle. Es muss eine gemeinsame Begriffswelt zwischen Entwicklung und Realit\u00e4t geschaffen werden und Unklarheiten m\u00f6glichst besieitigt werden.<\/p>\n<h2>Eigenschaften eines Requirements Engineeers<\/h2>\n<ul>\n<li>Selbstbewusstsein<\/li>\n<li>Empathie<\/li>\n<li>Analytisches Denken<\/li>\n<li>\u00dcberzeugungsf\u00e4higkeit<\/li>\n<li>Konfliktl\u00f6sungsf\u00e4higkeit<\/li>\n<li>Moderationsf\u00e4higkeit<\/li>\n<li>Kommunikationsf\u00e4higkeit<\/li>\n<\/ul>\n<h2>Drei Arten von Anforderungen<\/h2>\n<ul>\n<li>Funktionale Anforderungen<\/li>\n<li>Qualit\u00e4tsanforderungen<\/li>\n<li>Randbedingungen<\/li>\n<\/ul>\n<h2>Rolle der Qualit\u00e4tsanforderungen<\/h2>\n<p>Qualit\u00e4tsanforderungen m\u00fcssen dokumentiert werden. Folgende Aspekte sind insbesondere zu beachten:<\/p>\n<ul>\n<li>Detailierung der Funktionalit\u00e4t (z.B. Sicherheit\/Genauigkeit einer Berechnung)<\/li>\n<li>Zuverl\u00e4ssigkeit<\/li>\n<li>Benutzbarkeit<\/li>\n<li>Effizienz<\/li>\n<li>\u00c4nderbarkeit<\/li>\n<li>\u00dcbertragbarkeit<\/li>\n<\/ul>\n<h1>System und Systemkontext abgrenzen<\/h1>\n<p><a href=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/systemkontextgrenze.png?ssl=1\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" data-attachment-id=\"878\" data-permalink=\"https:\/\/www.capri-soft.de\/blog\/?attachment_id=878\" data-orig-file=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/systemkontextgrenze.png?fit=681%2C391&amp;ssl=1\" data-orig-size=\"681,391\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;}\" data-image-title=\"systemkontextgrenze\" data-image-description=\"\" data-image-caption=\"\" data-large-file=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/systemkontextgrenze.png?fit=474%2C272&amp;ssl=1\" class=\"alignnone size-full wp-image-878\" alt=\"systemkontextgrenze\" src=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/systemkontextgrenze.png?resize=474%2C290&#038;ssl=1\" width=\"474\" height=\"290\" \/><\/a><\/p>\n<h2>Ursprung und Rechtfertigung von Anforderungen<\/h2>\n<p>Die Quelle aller Anforderungen liegt \u00fcblicherweise im Systemkontext. Zu den m\u00f6glichen Aspekten im Systemkontext geh\u00f6ren u.a.<\/p>\n<ul>\n<li>Personen<\/li>\n<li>Systeme im Betrieb<\/li>\n<li>Prozesse<\/li>\n<li>Ereignisse<\/li>\n<li>Dokumente<\/li>\n<\/ul>\n<p>Die Systemgrenze ist h\u00e4ufig erst gegen Ende des RE Prozesses eindeutig festgelegt, und hat w\u00e4hrend dieser Zeit eine Grauzone (beweglich).<\/p>\n<h1>Anforderungen ermitteln<\/h1>\n<h2>Arten von Anforderungsquellen<\/h2>\n<ul>\n<li>Stakeholder (Kunden, Marketing, Servicetechniker, Entwickler&#8230;)<\/li>\n<li>Dokumente (rechtliche Vorschriften Normen&#8230;)<\/li>\n<li>Systeme (Vorbild ist ein Fremsystem als Input)<\/li>\n<li>Prozesse (?)<\/li>\n<li>Ereignisse (?)<\/li>\n<\/ul>\n<h2>Bedeutung von Anforderungsquellen<\/h2>\n<p>Die Hauptaufgabe des Requirements Engineering ist das Ermitteln von Anforderungen an ein geplantes System. Die Anforderungen werden aus unteschiedlichen Anforderungsquellen gesammelt.<\/p>\n<h2>Probleme bei unber\u00fccksichtigten Anforderungsquellen<\/h2>\n<p>Sollte es vorkommen, dass bestimmte Anforderungsquellen nicht ber\u00fccksichtigt werden, kann sich dieser Zustand mit negativen Folgen auf den gesamten Projektverlauf auswirken.<\/p>\n<h2>Dokumentation der Anforderungsquelle &#8222;Stakeholder&#8220;<\/h2>\n<p>Die Dokumentation der Stakeholder sollte mindestens die folgenden Informationen enthalten:<\/p>\n<ul>\n<li>Nachname, Vorname<\/li>\n<li>Funktion \/ Rolle \/ Aufgabe<\/li>\n<li>Kontaktdaten<\/li>\n<li>Verf\u00fcgbarkeit w\u00e4hrend der Projektlaufzeit\n<ul>\n<li>zeitlich (07:40h bis 17:00h)<\/li>\n<li>r\u00e4umlich (Werk 1 Geb\u00e4ude 2)<\/li>\n<\/ul>\n<\/li>\n<li>Relevanz des Stakeholders<\/li>\n<li>Ziele und Interessen bezogen auf das Projekt<\/li>\n<\/ul>\n<h2>Umgang mit Stakeholdern<\/h2>\n<p>M\u00fcndliche oder schriftlich wird eine Stakeholdervereinbarung festgehalten, in der die Stakeholder Rechte und Pflichten festgelegt sind.<\/p>\n<p>Beispiele:<\/p>\n<ul>\n<li><strong>Stakeholder Rechte<\/strong>: Weisungsbefugnisse, Verantwortungsbereiche<\/li>\n<li><strong>Stakeholder Pflichten<\/strong>: Aufgaben<\/li>\n<\/ul>\n<h2>KANO-Modell<\/h2>\n<p style=\"text-align: center;\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" title=\"KANO-Modell\" alt=\"\" src=\"http:\/\/upload.wikimedia.org\/wikipedia\/de\/5\/5e\/Kano_Modell_allgemein.png\" width=\"592\" height=\"480\" \/><\/p>\n<h3>Bedeutung<\/h3>\n<p>KANO stellt in einem 2-Dimensionalen Koordinatensystem gegen\u00fcber, wie sich der Realisierungsgrad einer Anforderung auf die Zufriedenheit des Stakeholders auswirkt und stellt dabei fest, dass es 3 Klassen gibt.<\/p>\n<h3>Inhalt<\/h3>\n<p>Das KANO-Modell kategorisiert, wie sich eine Anforderung auf die Zufriedenheit der Stakeholder aus\u00fcbt, in 3 Klassen:<\/p>\n<ul>\n<li>Basisfaktoren<\/li>\n<li>Leistungsfaktoren<\/li>\n<li>Begeisterungsfaktoren<\/li>\n<\/ul>\n<p><strong>Begeisterungsfaktoren <\/strong>sind z.B. Produktmerkmale, die komplett innovativ sind und vom Kunden mit Begeisterung aufgenommen werden. Der Kunde selbst hatte urspr\u00fcnglich nicht den Anspruch an das Produkt (z.B. Bilder per WhatsApp verschicken mit dem SmartPhone).<\/p>\n<p><strong>Leistungsfaktoren <\/strong>erwartet der Kunde grunds\u00e4tzlich von dem Produkt wenn er es kauft. Die Liste der Leisungfaktoren hat der Kunde pr\u00e4sent und kann direkt aufz\u00e4hlen was er erwartet.<\/p>\n<p><strong>Basisfaktoren <\/strong>sieht der Kunde als selbstverst\u00e4ndlich und als nicht nennenswert an. Sollten diese Merkmale aber nicht vorhanden sein, wird der Kunde sehr unzufrieden sein. Aus diesem Grund nennt er nicht unbeding, dass er diese Produkt-Eigenschaft haben m\u00f6chte.<\/p>\n<p>Im Laufe der Zeit werden Begeisterungsfaktoren zu Leistungsfaktoren und Leistungsfaktoren zu Basisfaktoren.<\/p>\n<p><strong>Bsp: Die Anforderung SMS VERSENDEN<\/strong><\/p>\n<p>In der damaligen Zeit war das Versenden von SMS ein High-Tec Feature, welches durch die modernen Handys m\u00f6glich wurde<strong> (Begeisterungsfaktor)<\/strong><\/p>\n<p>Nachdem die Handys mittlerweile jedes Kinderzimmer erreicht hatten, wurde das Schreiben von SMS zu einer nicht mehr wegzudenkenden Leistung der modernen Ger\u00e4te\u00a0 <strong>(Leistungsfaktor)<\/strong>. Jeder befragte \u00e4u\u00dferte die Forderung &#8222;Ich muss SMS schreiben k\u00f6nnen!&#8220;.<\/p>\n<p>Die heutige Smartphone Generation benutzt SMS nur noch in den seltensten F\u00e4llen, da Apps wie &#8222;WhatsApp&#8220;, welche sogar Bilder und Ton versenden k\u00f6nnen und das Nutzen von Multiuserchats erm\u00f6glichen. Es wird keiner mehr explizit erw\u00e4hnen, das er SMS versenden m\u00f6chte. W\u00e4re ein Smartphone nicht dazu in der Lage SMS zu versenden oder zu empfangen, w\u00fcrde dies aber zu extremer Unzufriedenheit beim Kunden f\u00fchren <strong>(Basisfaktor)<\/strong>.<\/p>\n<h3>Anwendung<\/h3>\n<p>F\u00fcr die Auswahl der zu verwendenden Ermittlungstechniken wird u.a. auch die Betrachtung des KANO Modells genutzt.<\/p>\n<h2>Ermittlungstechniken<\/h2>\n<h3>Bedeutsame Ermittlungstechniken von Anforderungen<\/h3>\n<ol>\n<li>Befragungstechniken\n<ol>\n<li>Interview<\/li>\n<li>Fragebogen<\/li>\n<\/ol>\n<\/li>\n<li>Kreativit\u00e4tstechniken (Begeisterungsfaktoren nach KANO)\n<ol>\n<li>Brainstorming<\/li>\n<li>Brainstorming paradox<\/li>\n<li>Perspektivwechsel<\/li>\n<li>Analogietechnik<\/li>\n<\/ol>\n<\/li>\n<li>dokumentenzentrierte Techniken (Basisfaktoren nach KANO)\n<ol>\n<li>Systemarch\u00e4ologie<\/li>\n<li>Perspektivenbasiertes Lesen<\/li>\n<li>Wiederverwendung von Anforderungen<\/li>\n<\/ol>\n<\/li>\n<li>Beobachtungstechniken\n<ol>\n<li>Feldbeobachtung<\/li>\n<li>Apprenticing<\/li>\n<\/ol>\n<\/li>\n<li>unterst\u00fctzende Techniken\n<ol>\n<li>Mind Mapping<\/li>\n<li>Workshops<\/li>\n<li>CRC-Karten<\/li>\n<li>Audio- und Videoaufzeichnung<\/li>\n<li>Use-Case-Modellierung<\/li>\n<li>Protoyping<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<h3>Einflussfaktoren f\u00fcr die Wahl der Ermittlungstechnik<\/h3>\n<ul>\n<li>Risikofaktoren<\/li>\n<li>menschliche Einfl\u00fcsse<\/li>\n<li>organisatorische Einfl\u00fcsse<\/li>\n<li>fachlich-inhaltliche Einfl\u00fcsse<\/li>\n<li>angestrebter Detailierungsgrad der Anforderung<\/li>\n<\/ul>\n<p>Der Einsatz geeigneter Ermittlungstechniken kann projektentscheidend sein. Die besten Ergebnisse werden durch Kombination verschiedener Ermittlungstechniken erzielt.<\/p>\n<h1>Dokumentation von Anforderungen<\/h1>\n<h2>Dokumentationstechnik<\/h2>\n<p>Als Dokumentationstechnik bezeichnet man jegliche Arten der Darstellung von Anforderungen<\/p>\n<h2>Wozu dokumentieren?<\/h2>\n<p>Die Dokumentation nimmt bei der Kommunikation eine zielgerichtete, unterst\u00fctzende Funktion ein.<\/p>\n<ul>\n<li>Anforderungen sind langlebig<\/li>\n<li>Anforderungen sind rechtlich relevant<\/li>\n<li>Anforderungen sollten allen zug\u00e4nglich sein<\/li>\n<\/ul>\n<h2>Funktionale Anforderungen<\/h2>\n<h3>3 Perspektiven<\/h3>\n<p>\u00dcblicherweise umfassen Anforderungsdokumente mindestens die folgenden drei Perspektiven eines Systems<\/p>\n<ul>\n<li>Strukturperspektive<\/li>\n<li>Verhaltensperspektive<\/li>\n<li>Funktionsperspektive<\/li>\n<\/ul>\n<h3>Effektiv einsetzbare Formen der Dokumentation<\/h3>\n<ul>\n<li>Nat\u00fcrlichsprachige Anforderungsdokumentation<\/li>\n<li>Anforderungsmodelle wie Use-Case-Diagramme, Klassendiagramme, Aktivit\u00e4tsdiagramme, Zustandsdiagramme<\/li>\n<li>Mischformen von Anforderungsdokumentationen<\/li>\n<\/ul>\n<h2>Vor- und Nachteile f\u00fcr Anforderungsdokumentation in nat\u00fcrlicher Sprache<\/h2>\n<ul>\n<li>Vorteile<\/li>\n<li>f\u00fcr alle Beteiligten verst\u00e4ndlich<\/li>\n<li>f\u00fcr Anforderungen jeglicher Art geeignet<\/li>\n<li>f\u00fcr alle drei Perspektiven geeignet<\/li>\n<li>zwingend notwendig um Komplexit\u00e4t von Anforderungen zu erfassen<\/li>\n<li>Nachteile<\/li>\n<li>oftmal zweideutig da nicht formal<\/li>\n<li>Transofrmationseffekte<\/li>\n<li>Vermischung der Perspektiven m\u00f6glich<\/li>\n<\/ul>\n<h2>Modellbasierte Dokumentationsformen von Anforderungen<\/h2>\n<ul>\n<li>Use-Case-Diagramme<\/li>\n<li>Klassendiagramme<\/li>\n<li>Aktivit\u00e4tsdiagramme<\/li>\n<li>Zustandsdiagramme<\/li>\n<li>&#8230;<\/li>\n<\/ul>\n<h2>Vorteile von standardisierter Dokumentenstruktur<\/h2>\n<p>Nimmt man vorgefertigte Dokumentenstrukturen, hat man die Gewissheit, dass es sich zumeist um vollst\u00e4ndige, flexible praxiserprobte Strukturierungen handelt. Zumeist erleichtert es die Verwendung des Anforderungdokumentes in sp\u00e4teren Entwicklungst\u00e4tigkeiten \/ Projektphasen (Definition von Testf\u00e4llen&#8230;).<\/p>\n<h2>Eine verbreitete standardisierte Dokumentenstruktur<\/h2>\n<p>Eine verbreitete Referenzstruktur f\u00fcr Anforderungsdokumente ist IEEE 830-1998 (Referenzstruktur f\u00fcr &#8222;Software Requirements Specification&#8220; (SRS).<\/p>\n<h2>Wichtige Punkte einer angepassten Standardstruktur<\/h2>\n<p>Referenzstrukturen k\u00f6nnen f\u00fcr gew\u00f6hnlich nicht 1:1 \u00fcbernommen werden, da sie an<\/p>\n<ul>\n<li>dom\u00e4nenspezifische<\/li>\n<li>projektspezifische<\/li>\n<li>unternehmenspezifische<\/li>\n<\/ul>\n<p>Gegebenheiten angepasst werde m\u00fcssen.<\/p>\n<h2>Aufgaben, die auf Anforderungsdokumenten aufbauen<\/h2>\n<p>Im Laufe des Projektes dienen Anforderungsdokumente als Grundlage f\u00fcr diverse Aufgaben.<\/p>\n<ul>\n<li>Planung<\/li>\n<li>Architekturentwurf<\/li>\n<li>Implementierung<\/li>\n<li>Test<\/li>\n<li>\u00c4nderungsmanagement<\/li>\n<li>Systemnutzung und Systemwartung<\/li>\n<li>Vertragsmanagement<\/li>\n<\/ul>\n<h2>Qualit\u00e4tskriterien f\u00fcr Anforderungsdokumente<\/h2>\n<p>Da Anforderungsdokumente eine Grundlage f\u00fcr alle weiteren Entwicklungsschritte bilden, muss das Dokument bestimmten Qualit\u00e4tskriterien gen\u00fcgen.<\/p>\n<ul>\n<li>Eindeutigkeit und Konsistenz<\/li>\n<li>Klare Struktur<\/li>\n<li>Modifzierbarkeit und Erweiterbarkeit<\/li>\n<li>Vollst\u00e4ndigkeit<\/li>\n<li>Verfolgbarkeit<\/li>\n<\/ul>\n<h2>Qualit\u00e4tskriterien f\u00fcr Anforderungen<\/h2>\n<ul>\n<li>Abgestimmt<\/li>\n<li>Bewertet<\/li>\n<li>Eindeutig<\/li>\n<li>G\u00fcltig und aktuell<\/li>\n<li>Korrekt<\/li>\n<li>Konsistent<\/li>\n<li>Pr\u00fcfbar<\/li>\n<li>Realisierbar<\/li>\n<li>Verfolgbar<\/li>\n<li>Vollst\u00e4ndig<\/li>\n<li>Verst\u00e4ndlich<\/li>\n<\/ul>\n<h2>Die zwei wichtigsten Stilregeln f\u00fcr Anforderungen<\/h2>\n<ol>\n<li>kurze S\u00e4tze und Abs\u00e4tze<\/li>\n<li>nur eine Anforderung pro Satz formulieren<\/li>\n<\/ol>\n<h2>Bedeutung eines Glossars<\/h2>\n<p>Ein Glossar ist eine Sammlung von Begriffsdefintionen f\u00fcr das RE.<\/p>\n<h2>Inhalte eines Glossars<\/h2>\n<ul>\n<li>Kontextspezifische Fachbegriffe<\/li>\n<li>Abk\u00fcrzungen und Akronyme<\/li>\n<li>Allt\u00e4gliche Begriffe, die im gegebenen Kontext eine spezifische Bedeutung haben<\/li>\n<li>Synonyme (Mehrere Worte haben eine Bedeutung)<\/li>\n<li>Homonyme (Ein Wort hat mehrere Bedeutungen)<\/li>\n<\/ul>\n<h2>Probleme die ohne Glossar auftreten<\/h2>\n<p>Eine h\u00e4ufige Ursache von Konflikten, die im RE auftritt, liegt im unterschiedlichen Begriffsverst\u00e4ndnis der beteiligten Personen. Um diese Probleme zu vermeiden, ist es notwendig, dass alle relevanten Begriffe in einem Glossar definiert sind.<\/p>\n<h2>Regeln f\u00fcr den Umgang mit dem Glossar<\/h2>\n<ul>\n<li>Das Glossar muss zentral verwaltet werden<\/li>\n<li>Es m\u00fcssen Verantwortlichkeiten zur Glossarpflege definiert werden<\/li>\n<li>Das Glossar muss projektbegleitend gepflegt werden<\/li>\n<li>Das Glossar muss allgemein zug\u00e4nglich sein<\/li>\n<li>Das Glossar muss verbindlich verwendet werden<\/li>\n<li>Die Herkunft der Begriffe sollte im Glossar enthalten sein<\/li>\n<li>Das Glossar muss mit den Stakeholdern abgestimmt sein<\/li>\n<li>Die Eintr\u00e4ge des Glossars m\u00fcssen eine einheitliche Struktur aufwesen<\/li>\n<\/ul>\n<p>Es ist vorteilhaft, m\u00f6glichst fr\u00fchzeitig mit der Erstellung des Glossars anzufangen. Dadurch reduziert sich der sp\u00e4tere Angleichungsaufwand.<\/p>\n<h1>Nat\u00fcrlichsprachige Dokumentation von Anforderungen<\/h1>\n<h2>5 Transformationsprozesse bei der Wahrnehmung und Darstellung von nat\u00fcrlicher Sprache<\/h2>\n<p>Nat\u00fcrliche Sprache ist oft mehrdeutig und kann unterschiedlich interpretiert werden. Die 5 Transformationsprozesse gehorchen gewissen Regeln, welche man nutzen kann um herauszufinden, was der Autor einer Anforderung wirklich gemeint hat.<\/p>\n<ol>\n<li>Nominalisierung<\/li>\n<li>Substantive ohne Bezugsindex<\/li>\n<li>Universalquantoren<\/li>\n<li>Unvollst\u00e4ndig spezifierte Bedingungen<\/li>\n<li>Unvollst\u00e4ndig spezifierte Prozessw\u00f6rter<\/li>\n<\/ol>\n<h2>5 Schritte zur Formulierung von Anforderungen mittels einer Satzschablone<\/h2>\n<p>Satzschablonen dienen der Reduzierung sprachlicher Effekte w\u00e4hrend der Anforderungsformulierung. Der Autor wird effektiv dabei unterst\u00fctzt, qualitativ hochwertige Anforderungen zu erstellen.<\/p>\n<p>Um mit einer Satzschablone Anforderungen zu formulieren, h\u00e4lt man die folgenden Schritte ein:<\/p>\n<ol>\n<li>Festlegen der rechtlichen Verbindlichkeit\n<ol>\n<li>Verben\n<ol>\n<li>muss\/shall (Pflicht)\n<ol>\n<li>Rechtlich verbindlich<\/li>\n<li>muss erf\u00fcllt sein, sonst kann die Abnahme verweigert werden<\/li>\n<\/ol>\n<\/li>\n<li>sollte\/should (Wunsch: Nice-To-Have)\n<ol>\n<li>W\u00e4re sch\u00f6n wenn&#8230;<\/li>\n<li>Stakeholder besteht nicht drauf<\/li>\n<\/ol>\n<\/li>\n<li>wird\/will (Absicht)\n<ol>\n<li>Pl\u00e4ne f\u00fcr die Zukunft<\/li>\n<li>System zukunftssicher konzipieren<\/li>\n<\/ol>\n<\/li>\n<li>kann\/can (Vorschlag)<\/li>\n<li>Kommentare<\/li>\n<\/ol>\n<\/li>\n<li>Auch Einsatz eines Attributes m\u00f6glich\n<ol>\n<li>Z.B. in Doors kann jedem Objekt\/Jeder Anforderung ein Attribut zugewiesen werden<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<li>Benennen des Kerns der Forderung<\/li>\n<li>Charakterisieren der Aktivit\u00e4t des Systems<\/li>\n<li>Objekte einf\u00fcgen<\/li>\n<li>Formulieren von logischen und zeitlichen Bedingungen<\/li>\n<\/ol>\n<p>Satzschablonen sollten optional sein und lediglich als Hilfsmittel dargestellt dienen, da sich so die besten Erfolge erzielen lassen.<\/p>\n<h1>Anforderungen modellbasiert dokumentieren<\/h1>\n<h2>Definition Modell<\/h2>\n<p>Ein Modell ist ein abstrahiertes Abbild einer existierenden Realit\u00e4t oder Vorbild einer zu schaffenden Realit\u00e4t.<\/p>\n<h2>3 Eigenschaften von Modellen<\/h2>\n<p>Durch die Verwendung von Modellen erreicht man ein verbessertes und schnelleres Auffassen von Sachverhalten und deren Zusammenh\u00e4ngen.<\/p>\n<ol>\n<li>Abbildungseigenschaft: Modelle bilden eine Realit\u00e4t ab<\/li>\n<li>Verk\u00fcrzende Eigenschaft: Modelle verk\u00fcrzen die abgebildete Realit\u00e4t<\/li>\n<li>Pragmatische Eigenschaft: Modelle werden f\u00fcr eine spezifische Verwendung konzipiert<\/li>\n<\/ol>\n<h2>2 Definitionselemente von konzeptuelle Modelle<\/h2>\n<p>Beschreiben die abzubildende Realit\u00e4t durch eine Menge grafischer Elemente. Zur Modellierung werden konzeptuelle Modellierungssprachen eingesetzt, die \u00fcber deren<\/p>\n<ul>\n<li>Syntax (das sind die Modellierungselemente wie Use Case, Aktion&#8230;. und deren g\u00fcltige Kombinationen)<\/li>\n<li>Semantik (Bedeutung der Modellierungselemente)<\/li>\n<\/ul>\n<p>definiert werden.<\/p>\n<h2>Vorteile von Anforderungsmodellen<\/h2>\n<ul>\n<li>Bildhaft dargestellte Informationen k\u00f6nnen schneller erfasst werden und pr\u00e4gen sich schneller ins Ged\u00e4chtnis ein<\/li>\n<li>Es kann eine bestimmte Perspektive auf Anforderungen modelliert werden<\/li>\n<li>Es k\u00f6nnen zweckm\u00e4\u00dfige Abstraktionen der Realit\u00e4t durch die Definition der Modellierungssprache festgelegt werden<\/li>\n<\/ul>\n<p>Eine Kombination von nat\u00fcrlicher Sprache und Anforderungsmodellen vereinigt die Vorteile beider Dokumentationsarten<\/p>\n<h2>Die Bedeutung von Zielen im Requirements Engineering<\/h2>\n<p>Ein Ziel ist die intentionale Beschreibung eines von Stakeholdern gew\u00fcnschten charakteristischen Merkmals des zu entwickelnden Systems, bzw. des zu entwickelnden Entwicklungsprojektes.<\/p>\n<h2>Dokumentationsformen von Zielen<\/h2>\n<p>Ziele k\u00f6nnen nat\u00fcrlichsprachig als auch in Form von Modellen dokumentiert werden. Als wesentlichen Bestandteil beim Formulieren von Zielen werden sogenannte <em>Dekompositionsbeziehung<\/em> f\u00fcr die Definition \u00fcber- und untergeordneter Ziele verwendet.<\/p>\n<h2>Zwei Arten von Zieldekomposition<\/h2>\n<ol>\n<li>UND-Dekompoisiton (alle Teilzile m\u00fcssen erf\u00fcllt sein, um das \u00fcbergeordnete Ziel zu erf\u00fcllen)<\/li>\n<li>ODER-Dekomposition (mindestens ein Teilziel muss erf\u00fcllt sein, um das \u00fcbergeordnete Ziel zu erf\u00fcllen)<\/li>\n<\/ol>\n<h2>Modellierung von Zielbeziehungen in Und-Oder-B\u00e4umen<\/h2>\n<p><a href=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/undoder.png?ssl=1\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" data-attachment-id=\"856\" data-permalink=\"https:\/\/www.capri-soft.de\/blog\/?attachment_id=856\" data-orig-file=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/undoder.png?fit=392%2C234&amp;ssl=1\" data-orig-size=\"392,234\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;}\" data-image-title=\"undoder\" data-image-description=\"\" data-image-caption=\"\" data-large-file=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/undoder.png?fit=392%2C234&amp;ssl=1\" class=\"alignnone size-full wp-image-856\" alt=\"undoder\" src=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/undoder.png?resize=392%2C234&#038;ssl=1\" width=\"392\" height=\"234\" srcset=\"https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/undoder.png?w=392&amp;ssl=1 392w, https:\/\/i0.wp.com\/www.capri-soft.de\/blog\/wp-content\/uploads\/2013\/02\/undoder.png?resize=300%2C179&amp;ssl=1 300w\" sizes=\"auto, (max-width: 392px) 100vw, 392px\" \/><\/a><\/p>\n<h2>Einsatzziele von Use Cases<\/h2>\n<p>Ziel von Use Cases ist, Funktionalit\u00e4ten eines geplanten oder existierenden Systems aus einer Nutzungssicht auf das System zu untersuchen und dokumenterien zu k\u00f6nnen.<\/p>\n<h2>Dokumentationstechniken von Use Cases<\/h2>\n<ul>\n<li>Use Case Diagramme<\/li>\n<li>Use Case Spezifikationen<\/li>\n<\/ul>\n<h2>Vorteile von Use Case Diagrammen<\/h2>\n<ul>\n<li>leicht verst\u00e4ndlich<\/li>\n<li>Dokumentation des Systemkontextes<\/li>\n<li>Funktionen<\/li>\n<\/ul>\n<h2>Modellierung von Use Case Diagrammen<\/h2>\n<p>Use Cases bestehen aus<\/p>\n<ul>\n<li>Akteuren (die M\u00e4nnchen)<\/li>\n<li>der Systemgrenze (hier Bibliothekssystem)<\/li>\n<li>Use Cases (die Elipsen)<\/li>\n<li>verschiedenen Typen von Modellierungselemten (extend \/ include)\n<ul>\n<li>&lt;&lt;include&gt;&gt; zeigt auf einen Anwendungsfall, der vom ausgehenden einbezogen wird. Dies wird h\u00e4ufig zwecks Wiederverwendung eines Use Cases gemacht<\/li>\n<li>&lt;&lt;extend&gt;&gt; ist eine optional bedingte Erweiterung eines Use Cases. Der Pfeil zeigt vom erweiternden Use Case auf den abstrakten. Im Beispiel unten w\u00e4re das wie das derive, was &#8222;Katalog durchsuchen&#8220; konkretisiert.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" class=\"alignnone\" alt=\"\" src=\"https:\/\/i0.wp.com\/www.ronny-schattauer.de\/blog\/wp-content\/uploads\/2008\/11\/bibliotheksusecase.png?resize=474%2C263\" width=\"474\" height=\"263\" \/><\/p>\n<p>Anmerkung: Die Pfeilbezeichnung &#8222;derive&#8220;\u00a0 ist keine Standardspezifikation von UML Use Cases und sollte hier durch &lt;&lt;EXTEND&gt;&gt; oder &lt;&lt;INCLUDE&gt;&gt; ersetzt werden. Die Pfeillinien sollten gestrichelt sein.<\/p>\n<h2>Spezifikation von Use Cases<\/h2>\n<p>Als Erg\u00e4nzung f\u00fcr die Use Case Diagramme werden Use Case-Spezifikationen genutzt, um die wesentlichen Eigenschaften einzelner Use Cases zu beschreiben. F\u00fcr jeden festgehaltenen Use Case wird separat eine vorgegebene Schablone ausgef\u00fcllt.<\/p>\n<p>Die Abschnitte der Schablone<\/p>\n<ul>\n<li>eindeutiger Bezeichner des Use Case (z.B. Katalog einfach durchsuchen)<\/li>\n<li>Name des Use Cases<\/li>\n<li>Beschreibung des Use Case<\/li>\n<li>ausl\u00f6sendes Ereignis<\/li>\n<li>Akteure<\/li>\n<li>Ergebnis<\/li>\n<li>Vor- und Nachbedingungen<\/li>\n<li>Verschiedene Arten von Szenarien\n<ul>\n<li>Beschreiben exemplarische Ereignisfolgen, die zur erfolgreichen Ausf\u00fchrung des Use Case f\u00fchren (Hauptszenarien und Alternativszenarien) oder explizit beschreiben, wie innerhalb der Ausf\u00fchrung des Use Case auf Ausnahmesituationen rreagiert werden soll (Ausnahmeszenarien).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2>Drei Perspektiven auf die Anforderungen<\/h2>\n<p>Anforderungen werden im Rahmen der modellbasierten Dokumentation in drei \u00fcberlappenden Modellierungsperspektiven modelliert<\/p>\n<ol>\n<li>Strukturperspektive\n<ol>\n<li>Entity Relationship Diagram<\/li>\n<li>UML Klassendiagramm<\/li>\n<\/ol>\n<\/li>\n<li>Funktionsperspektive\n<ol>\n<li>Datenflussdiagramme<\/li>\n<li>UML Aktivit\u00e4tsdiagramme<\/li>\n<\/ol>\n<\/li>\n<li>Verhaltensperspektive\n<ol>\n<li>endliche Automaten<\/li>\n<li>Statecharts<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<h2>Fokus der Strukturperspektive auf Anforderungen<\/h2>\n<ul>\n<li>Struktur von Daten<\/li>\n<li>Nutzungs- und Abh\u00e4ngigkeitsbeziehungen im Systemkontext<\/li>\n<\/ul>\n<h2>ER-Diagramme<\/h2>\n<p>Traditionell wird die Strukturperspektive durch ER Diagramme modelliert, die aus 3 Beziehungen bestehen:<\/p>\n<ol>\n<li>Entit\u00e4tstypen (Rechtecke)<\/li>\n<li>Beziehungstypen (Linien)\n<ol>\n<li>.. enthalten Kardinalit\u00e4ten (unten 1 oder N\/M, bzw. *), die die H\u00e4ufigkeit der Instanz in der Beziehung zeigen\n<ol>\n<li>Ein Angestellter leitet mehrere Projekte<\/li>\n<li>EIn Projekt wird nur von einem Angestelltem geleitet<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<li>Attribute (Elipsen)<\/li>\n<\/ol>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone\" alt=\"\" src=\"http:\/\/upload.wikimedia.org\/wikipedia\/de\/thumb\/a\/ab\/Er-diagramm.svg\/300px-Er-diagramm.svg.png\" width=\"399\" height=\"320\" \/><\/p>\n<h2>UML-Klassendiagramme<\/h2>\n<p>Ein weiterer verbreiteter Ansatz um Anforderungen in der Strukturperspektive zu modellieren, ist das Verwenden von UML Klassendiagrammen.<\/p>\n<p>H\u00e4ufig verwendete Modellelemente von UML Klassendiagrammen sind<\/p>\n<ul>\n<li>Klassen<\/li>\n<li>Assoziationen (mit Multiplizit\u00e4ten und Rollen)<\/li>\n<li>Aggregations- und Kompositionsbeziehungen<\/li>\n<li>Generalisierungsbeziehungen<\/li>\n<\/ul>\n<p><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" class=\"alignnone\" alt=\"\" src=\"https:\/\/i0.wp.com\/ifgivor.uni-muenster.de\/vorlesungen\/Geoinformatik\/kap\/kap4\/uml_Wetterstation_1.gif?resize=474%2C398\" width=\"474\" height=\"398\" \/><\/p>\n<h2>Fokus der Funktionsperspektive auf Anforderungen<\/h2>\n<ul>\n<li>Verarbeitung von Eingabedaten aus der Umgebung<\/li>\n<li>Ausgabedaten f\u00fcr die Umgebung<\/li>\n<\/ul>\n<h2>Konzeptuelle Modelle in der Funktionsperspektive<\/h2>\n<ol>\n<li>Datenflussdiagramme<\/li>\n<li>UML Aktivit\u00e4tsdiagramme<\/li>\n<\/ol>\n<h2>Datenflussdiagramme (Synonym: Kontextdiagramme)<\/h2>\n<ul>\n<li>Prozesse (Unten das System)<\/li>\n<li>Datenfl\u00fcsse (die Pfeile sind betitelt, im Kontext muss es sich nicht ausschlie\u00dflich um Daten handeln die flie\u00dfen, es kann auch etwas physikalisches flie\u00dfen)<\/li>\n<li>Datenspeicher (im RE eher un\u00fcblich, da man hier den Kontext beschreiben m\u00f6chte, aber unten w\u00e4re es die Datenbank mit Strich oben, Strich unten)<\/li>\n<li>Termintatoren (Rechtecke &#8211; unten der Customer i.d.R. Quellen und Senken)<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone\" alt=\"\" src=\"http:\/\/upload.wikimedia.org\/wikipedia\/commons\/c\/c8\/DataFlowDiagram_Example.png\" width=\"478\" height=\"77\" \/><\/p>\n<p>Da die Datenflussdiagramme genutzt werden um den Systemkontext zu beschreiben oder eine Kontextabgrenzung vorzunehmen, werden Speicher i.d.R. nicht verwendet da diese technischer Natur sind und sich eher innerhalb des Systems befinden (dies bezieht sich nur\u00a0 auf Kontextabgrenzungen im Requirements Engineering).<\/p>\n<h3>Nachteile Datenflussdiagramme<\/h3>\n<p>Datenflussdiagramme zeigen nicht, unter welchen Bedingungen welche Prozesse ausgef\u00fchrt werden. Sie eignen sich eher um mit Hilfe der Terminatoren Ein- und Ausgabeparameter im Systemkontext zu dokumentieren.<\/p>\n<p>Um den Kontrollfluss (also den Programm-Verlauf\/Ablauf) zu erfassen, m\u00fcssen Datenflussdiagramme um eine Minispefizikation erweitert werden. Der Kontrollfluss kann durch Aktivit\u00e4tsdiagramme modelliert werden.<\/p>\n<h2>UML-Aktivit\u00e4tsdiagramme<\/h2>\n<p>Bestehen aus folgenden Elementen:<\/p>\n<ul>\n<li>Aktion (Rechteck mit abgerundeten Ecken)<\/li>\n<li>Start- und Endknoten<\/li>\n<li>Kontrollfluss (Pfeil)<\/li>\n<li>Objektfluss (Rechteck &#8211; zumeist nach einer Aktion und beschreibt den Zustand [z.B. Zielort ERMITTELT] als Ergebnis der vorigen Aktion)<\/li>\n<li>Entscheidungsknoten (Raute mit ausgehenden Pfeilen)<\/li>\n<li>Zusammenf\u00fchrung alternativer Kontrollfl\u00fcsse (Raute mit eingehenden Pfeilen)<\/li>\n<li>Fork (horizontaler dicker Balken auf den ein Kontrollfluss eingeht und mehrere wegflie\u00dfen &#8211; Beginn von Parallelit\u00e4t\/Nebenl\u00e4ufigkeit)<\/li>\n<li>Join (horizontaler docker Balken auf den mehrere Kontrollfl\u00fcsse eingehen und einer wegflie\u00dft &#8211; Ende von Parallelit\u00e4t \/ Nebenl\u00e4ufigkeit)<\/li>\n<li>Hierarchisierungselemente<\/li>\n<\/ul>\n<h2>Fokus der Verhaltensperspektive von Anforderungen<\/h2>\n<p>Der Fokus liegt auf der Modellierung der Zust\u00e4nde, in denen sich ein System befinden kann und die \u00dcberg\u00e4nge zwischen Zust\u00e4nden (Transitions)<\/p>\n<h2>UML-Zustandsdiagramme<\/h2>\n<ul>\n<li>Zustand (Rechteck mit abgerundeten Ecken)<\/li>\n<li>Start- und Endzustand (schwarzer Punkt und schwarzer Punkt mit Ring)<\/li>\n<li>Zustands\u00fcbergang (Pfeil mit Beschriftung des Ereignisses\/der Aktion die zum \u00dcbergang f\u00fchrt)<\/li>\n<li>Nebenl\u00e4ufigkeit<\/li>\n<\/ul>\n<h1>Anforderungen pr\u00fcfen und abstimmen<\/h1>\n<h2>Bedeutung der \u00dcberpr\u00fcfung von Anforderungen<\/h2>\n<p>Es wird gepr\u00fcft ob Anforderungen festgelegten Qualit\u00e4tskrieterien (z.B. Korrektheit oder Vollst\u00e4ndigkeit) gen\u00fcgen. Fehler in den Anforderungen sollten m\u00f6glichst fr\u00fchzeitig erkannt und behoben werden. Der Aufwand zur Behebung eines Fehlers, der in den Anforderungen gemacht wurde, ist wesentlich h\u00f6her je sp\u00e4ter er entdeckt wird. Das liegt daran, dass der Fehler in den Anforderungen Auswirkungen auf alle Artefakte des Systems haben kann (z.B. Systemarchitektur, Implementierung der Testf\u00e4lle&#8230;.)<\/p>\n<h2>Bedeutung von (Stakeholder) Konflikten bzgl. Anforderungen<\/h2>\n<h3>Auswirkung<\/h3>\n<p>Konflikte, die nicht beseitigt wurden, k\u00f6nnen dazu f\u00fchren, dass Anforderungen einer Stakeholdergruppe nicht umgesetzt werden k\u00f6nnen bzw. dass das System nicht oder unzureichend akzeptiert und genutzt wird.<\/p>\n<h3>Ziele der Abstimmung<\/h3>\n<p>Unter den relevanten Stakeholder muss ein gemeinsames und \u00fcberinstimmendes Verst\u00e4ndnis hinsichtlich der Anforderungen an das zu entwickelnde System erarbeitet werden.<\/p>\n<h2>Drei Qualit\u00e4tsaspekte f\u00fcr Anforderungen<\/h2>\n<ol>\n<li>Inhalt<\/li>\n<li>Dokumentation<\/li>\n<li>Abgestimmtheit<\/li>\n<\/ol>\n<h2>Pr\u00fcfkriterien f\u00fcr die Qualit\u00e4tsaspekte<\/h2>\n<h3>8 Pr\u00fcfkriterien f\u00fcr Inhalt<\/h3>\n<ol>\n<li>Vollst\u00e4ndigkeit des Anforderungsdokumentes<\/li>\n<li>Vollst\u00e4ndigkeit der einzelnen Anforderungen<\/li>\n<li>Verfolgbarkeit<\/li>\n<li>Korrektheit \/ Ad\u00e4quatheit<\/li>\n<li>Konsistenz<\/li>\n<li>Keine vorzeitige Entwurfsentscheidungen<\/li>\n<li>\u00dcberpr\u00fcfbarkeit<\/li>\n<li>Notwendigekeit<\/li>\n<\/ol>\n<h3>5 Pr\u00fcfkriterien f\u00fcr Dokumentation<\/h3>\n<ol>\n<li>Konformit\u00e4t zum Dokumentationsformat<\/li>\n<li>Konfirmit\u00e4t zur Dokumentenstruktur<\/li>\n<li>Verst\u00e4ndlichkeit<\/li>\n<li>Eindeutigkeit<\/li>\n<li>Konformit\u00e4t mit Dokumentationsregeln<\/li>\n<\/ol>\n<h3>3 Pr\u00fcfkriterien f\u00fcr Abgestimmtheit<\/h3>\n<ol>\n<li>Abstimmung<\/li>\n<li>Abstimmung nach \u00c4nderung<\/li>\n<li>Konflikte aufgel\u00f6st<\/li>\n<\/ol>\n<h2>Sechs Prinzipien der Pr\u00fcfung von Anforderungen<\/h2>\n<p>Um m\u00f6glichst viele Fehler in den Anforderungen zu identifieren, werden die folgenden Prinzipien eingehalten<\/p>\n<ol>\n<li>Beteiligung der richtigen Stakeholder<\/li>\n<li>Trennung von Fehlersuche und Fehlerkorrektur<\/li>\n<li>Pr\u00fcfung aus unterschiedlichen Sichten<\/li>\n<li>Geeigner Wechsel der Dokumentationsform<\/li>\n<li>Konstruktion von Entwicklungsartefakten, die auf Anforderungen beruhen<\/li>\n<li>Wiederholte Pr\u00fcfung<\/li>\n<\/ol>\n<h2>Techniken zur Pr\u00fcfung von Anforderungen<\/h2>\n<ul>\n<li>Stellungnahme<\/li>\n<li>Inspektion<\/li>\n<li>Walkthrough<\/li>\n<\/ul>\n<p>W\u00e4hrenddessen kommen weitere Techniken zum Einsatz<\/p>\n<ul>\n<li>Perspektivenbasiertes Lesen<\/li>\n<li>Pr\u00fcfung von Prototypen<\/li>\n<li>Einsatz von Checklisten<\/li>\n<\/ul>\n<h2>Pr\u00fcftechniken Stellungnahme, Inspektion, Walkthrough, Perspektivbasiertes Lesen, Pr\u00fcfung durch Prototypen, Einsatz von Checklisten<\/h2>\n<h2>Aufgaben in der Abstimmung von Anforderungen<\/h2>\n<ul>\n<li>Konfliktidentifikation<\/li>\n<li>Konfliktanalyse<\/li>\n<li>Konfliktaufl\u00f6sung<\/li>\n<li>Dokumentation von Konfliktl\u00f6sungen<\/li>\n<\/ul>\n<h2>Arten von Konflikten bez\u00fcglich Anforderungen<\/h2>\n<ul>\n<li>Sachkonflikt<\/li>\n<li>Interessenkonflikt<\/li>\n<li>Wertekonflikt<\/li>\n<li>Beziehungskonflikt<\/li>\n<li>Strukturkonflikt<\/li>\n<\/ul>\n<h2>Verschiedene Konfliktl\u00f6sungstechniken<\/h2>\n<ul>\n<li>Einigung<\/li>\n<li>Kompromiss<\/li>\n<li>Abstimmung<\/li>\n<li>Variantenbildung<\/li>\n<li>Ober-Sticht-Unter<\/li>\n<li>Consider-All-Facts<\/li>\n<li>Plus-Minus-Interesting<\/li>\n<li>Entscheidungsmatrix<\/li>\n<\/ul>\n<h2>Dokumentation der Konfliktl\u00f6sung<\/h2>\n<p>Nach der Konfliktl\u00f6sung sollte eine Dokumentation dar\u00fcber stattfinden, wie der Konflikt gel\u00f6st wurde und die Gr\u00fcnde die f\u00fcr die daraus resultierende Entscheidung resultieren.<\/p>\n<h1>Anforderungen verwalten<\/h1>\n<h2>Definition von Attributierungsschemata<\/h2>\n<p>Um die Attributstruktur f\u00fcr eine Anforderung (z.B. in Doors ein Objekt mit mehreren Spalten) festzulegen, werden Attributierungsschemata verwendet. Attributierungsschemata werden entweder tabellarisch oder in Form von eines Informationsmodells defniert.<\/p>\n<h2>Zweck von Attributierungsschemata<\/h2>\n<p>Zweck von Attributen ist es, dass die Anforderungen \u00fcber den gesamten Lebenszyklus des Systems verwaltet werden k\u00f6nnen.<\/p>\n<h2>Wichtige Attributtypen f\u00fcr Anforderungen<\/h2>\n<ul>\n<li>Identifikator (z.B. die erste Spalte eines Moduls in Doors)<\/li>\n<li>Name<\/li>\n<li>Beschreibung<\/li>\n<li>Quelle<\/li>\n<li>Stabilit\u00e4t<\/li>\n<li>Kritikalit\u00e4t<\/li>\n<li>Priorit\u00e4t<\/li>\n<\/ul>\n<p>Auch die &#8222;rechtliche Verbindlichkeit&#8220; kann anhand eines Attributes als zus\u00e4tzliche Information zur Anforderung gespeichert werden.<\/p>\n<h2>Sichten auf Anforderungen<\/h2>\n<p>Sichten dienen der Reduktion von Anforderungskomplexit\u00e4t ist ein reduzierter Zugriff bzw. ein Filtern von Anforderungen in Abh\u00e4ngigkeit der Verwendung notwendig. Hierf\u00fcr werden Sichten auf die Daten verwendet (z.B. in Doors Views).<\/p>\n<ul>\n<li><strong>Selektive Sichten:<\/strong> Darstellung einer Teilmenge der Attributwerte \u00fcber definierte Selektionskriterien<\/li>\n<li><strong>Verdichtende Sichten<\/strong>: Darstellung verdichteter Informationen zu den \u00fcber definierte Anforderungen ausgew\u00e4hlten Selektionskriterien<\/li>\n<\/ul>\n<h2>Vorgehen zur Priorisierung von Anforderungen<\/h2>\n<ul>\n<li>Bestimmung der Ziele und Randbedingungen der Priorisierung<\/li>\n<li>Bestimmung der Priorisierungskriterien<\/li>\n<li>Bestimmung der relevanten Stakeholder<\/li>\n<li>Auswahl der zu priorisierenden Artefakte<\/li>\n<\/ul>\n<h2>Techniken zur Priorisierung von Anforderungen<\/h2>\n<ul>\n<li>Ranking und Top-Ten-Technik<\/li>\n<li>Ein-Kriterium-Klassifikation<\/li>\n<li>Kano-Klassifikation<\/li>\n<li>Wiegers&#8217;sche Priorisierungsmatrix<\/li>\n<\/ul>\n<h2>Nutzen der Verfolgbarkeit von Anforderungen<\/h2>\n<ul>\n<li>Vereinfachung der Nachweisbarkeit<\/li>\n<li>Identifikation von unn\u00f6tigen Eigenschaften im System<\/li>\n<li>Identifikation von unn\u00f6tigen Anforderungen<\/li>\n<li>Unterst\u00fctzung der Auswirkungsanalyse<\/li>\n<li>Unterst\u00fctzung der Wiederverwendung<\/li>\n<li>Unterst\u00fctzung der Festlegung der Zurechenbarkeit<\/li>\n<li>Unterst\u00fctzung der Wartung und Pflege<\/li>\n<\/ul>\n<h2>Klassen von Verfolgbarkeitsbeziehungen<\/h2>\n<ul>\n<li>Pre-Requirement-Specification-Traceability<\/li>\n<li>Post-Requirements-Specification-Traceability<\/li>\n<li>Traceability zwischen Anforderungen<\/li>\n<\/ul>\n<h2>Repr\u00e4sentationsformen von Verfolgbarkeitsbeziehungen<\/h2>\n<ul>\n<li>Textuelle Refernzen und Hyperlinks<\/li>\n<li>Verfolgbarkeitsmatrizen<\/li>\n<li>Verfolgbarkeitsgraphen<\/li>\n<\/ul>\n<h2>Versionierung von Anforderungen<\/h2>\n<p>Es wird erm\u00f6glicht verschiedene Entwicklungsst\u00e4nde und Anforderungsdokumente verf\u00fcgbar zu halten. Die Versionsnummer einer Anforderungs besitzt dabei mindestens zwei Bestandteile<\/p>\n<ol>\n<li>Version<\/li>\n<li>Inkrement<\/li>\n<\/ol>\n<p>Version 2.1 (&lt;- Inkrement ist 1)<\/p>\n<h2>Bildung von Anforderungskonfigurationen<\/h2>\n<p>Anforderungskonfigurationen fassen eine definierte Menge logisch zusammengeh\u00f6render Anforderungen zusammen. Jede Anforderung ist maximal in einer Version in der Anforderungskonfiguration enthalten.<\/p>\n<h2>Bildung von Anforderungsbasislinien<\/h2>\n<p>Die Bildung von Anforderungskonfigurationen wird entlang zweier Domensionen definiert:<\/p>\n<ul>\n<li>Produktdimension: die einzelenen Anforderungen der Anforderungsbasis<\/li>\n<li>Versionsdimension: die verschiedenen Versionsst\u00e4nde einer Anforderung<\/li>\n<\/ul>\n<h2>Bedeutung von Anforderungs\u00e4nderungen<\/h2>\n<p>\u00dcber den gesamten Lebenszyklus eines Systems \u00e4ndern sich Anforderungen. Diese \u00c4nderungen werden in einem systematischen \u00c4nderungsmanagementprozess verwaltet.<\/p>\n<h2>Aufgaben und Vertreter des Change-Control-Board<\/h2>\n<p>In einem \u00c4nderungsmanagementprozess ist das Change-Control-Board f\u00fcr die Bearbeitung eingehender \u00c4nderungsantr\u00e4ge verantwortlich. Die Aufgaben des Change-COntrol-Boards sind<\/p>\n<ul>\n<li>Klassifikation eingehender \u00c4nderungsantr\u00e4ge<\/li>\n<li>Bestimmung des Aufwands einer \u00c4nderung<\/li>\n<li>Beurteilung der \u00c4nderungsantr\u00e4ge hinsichtlich Aufwand\/Nutzen<\/li>\n<li>Definition neuer Anforderugnen auf Basis eingehender \u00c4nderungsantr\u00e4ge<\/li>\n<li>Entscheidung \u00fcber Annahme oder Ablehnung eines \u00c4nderungsantrags<\/li>\n<li>Priorisierung der angenommenen \u00c4nderungsantr\u00e4ge<\/li>\n<li>Zuordnung der \u00c4nderungen zu \u00c4nderungsprojekten<\/li>\n<\/ul>\n<h2>Aufbau eines \u00c4nderungsantrages f\u00fcr Anforderungen<\/h2>\n<ul>\n<li>Identifikator des \u00c4nderungsantrages<\/li>\n<li>Titel des \u00c4nderungsantrages<\/li>\n<li>Beschreibung der notwendigen \u00c4nderung<\/li>\n<li>Begr\u00fcndung f\u00fcr die Notwendigkeit der \u00c4nderung<\/li>\n<li>Datum der Beantragung<\/li>\n<li>Antragsteller<\/li>\n<li>Priori\u00e4t der \u00c4nderung aus Sicht des Antragstellers<\/li>\n<\/ul>\n<h2>3 Klassen von \u00c4nderungsantr\u00e4gen<\/h2>\n<ol>\n<li>Korrektive \u00c4nderungen<\/li>\n<li>Adaptive \u00c4nderungen<\/li>\n<li>Ausnahme\u00e4nderungen<\/li>\n<\/ol>\n<h2>Vorgehen zur Bearbeitung von \u00c4nderungsantr\u00e4gen<\/h2>\n<ul>\n<li>Auswirkungsanalyse und Beurteilung des \u00c4nderungsantrages<\/li>\n<li>Priorisierung der Anforderugns\u00e4nderung<\/li>\n<li>Zuordnung der \u00c4nderung zu einem \u00c4nderungsprojekt<\/li>\n<li>Kommunikation der Annahme\/Ablehnung des \u00c4nderungsantrages<\/li>\n<\/ul>\n<h1>Werkzeugunterst\u00fctzung<\/h1>\n<h2>Acht Eigenschaften eines Requirements Management Werkeugs<\/h2>\n<ul>\n<li>Verschiedene Informationen verwalten<\/li>\n<li>Logische Beziehungen zwischen Informationen verwalten<\/li>\n<li>Jedes Artefakt eindeutig identifierzieren<\/li>\n<li>Informationen flexibel und sicher zug\u00e4nglich machen<\/li>\n<li>Sichten auf die Informationen unterst\u00fctzen<\/li>\n<li>Informationen organisieren\n<ul>\n<li>Attributierung<\/li>\n<li>Hierarchiebildung<\/li>\n<\/ul>\n<\/li>\n<li>Berichte \u00fcber Infromationen erstellen<\/li>\n<li>Dokumente aus den Informationen generieren<\/li>\n<\/ul>\n<p>Spezielle Tools f\u00fcr das Requirements Engineering sind IBM Doors oder Polarion.<\/p>\n<h2>F\u00fcnf Gesichtspunkte bei der Einf\u00fchrung von Requirements Engineering Werkzeugen<\/h2>\n<ul>\n<li>Ben\u00f6tigte Ressourcen planen<\/li>\n<li>Risiken durch Pilotprojekte umgehen<\/li>\n<li>Evaluierung anhand von definierten Kriterien<\/li>\n<li>\u00dcber Lizenzkosten hinausgehende Kosten ber\u00fccksichtigen<\/li>\n<li>Benutzer schulen<\/li>\n<\/ul>\n<h2>Sieben Sichten auf Requiremtns Engineering Werkzeuge<\/h2>\n<ul>\n<li>Projektsicht (z.B. Unterst\u00fctzung der Projektplanung)<\/li>\n<li>Benutzersicht (insbesondere Bedienung)<\/li>\n<li>Produktsicht (Funktionalit\u00e4t)<\/li>\n<li>Prozesssicht (methodische Unterst\u00fctzung)<\/li>\n<li>Anbietersicht (z.B. Service des Anbieters)<\/li>\n<li>Technische Sicht (z.B. Interoperabilit\u00e4t, Skalierbarkeit)<\/li>\n<li>Betriebswirtschaftliche Sicht (Kosten)<\/li>\n<\/ul>\n<p>F\u00fcr jede Sicht sind klare Kriterien zu definieren.<\/p>\n<iframe src=\"http:\/\/www.facebook.com\/plugins\/like.php?href=https%3A%2F%2Fwww.capri-soft.de%2Fblog%2F%3Fp%3D836&amp;layout=standard&amp;show_faces=true&amp;width=450&amp;action=like&amp;colorscheme=light\" scrolling=\"no\" frameborder=\"0\" allowTransparency=\"true\" style=\"border:none; overflow:hidden; width:450px;margin-top:5px;\"><\/iframe>","protected":false},"excerpt":{"rendered":"<p>Vorwort und Quellen Dieser Artikel entstand im Rahmen meiner IREB-Zertifizierung zum Certified Professional for Requirements Engineering und beinhaltet eine verdichtete, pr\u00fcfungsrelevante Zusammenfassung und Ausschnitte des IREB-Werkes &#8222;Basiswissen &#8211; Requirements Engineering&#8220; von Rupp \/ Pohl. Grundlagen Gr\u00fcnde f\u00fcr Requirements Engineering Budget\u00fcberschreitung v\u00f6lliges Scheitern eines Projektes 60 Prozent der Fehler in der Entwicklung sind aufgrund mangelnder Anforderungen &hellip; <a href=\"https:\/\/www.capri-soft.de\/blog\/?p=836\" class=\"more-link\"><span class=\"screen-reader-text\">Requirements Engineering<\/span> weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1],"tags":[],"class_list":["post-836","post","type-post","status-publish","format-standard","hentry","category-allgemein"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p4yGeN-du","jetpack_likes_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=836"}],"version-history":[{"count":43,"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/836\/revisions"}],"predecessor-version":[{"id":839,"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/836\/revisions\/839"}],"wp:attachment":[{"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=836"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.capri-soft.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}