{"id":14,"date":"2011-06-21T12:49:35","date_gmt":"2011-06-21T10:49:35","guid":{"rendered":"https:\/\/sgaul.de\/?p=14"},"modified":"2012-12-02T22:05:56","modified_gmt":"2012-12-02T21:05:56","slug":"anforderungen-systematisch-analysieren","status":"publish","type":"post","link":"https:\/\/sgaul.de\/2011\/06\/21\/anforderungen-systematisch-analysieren\/","title":{"rendered":"Anforderungen systematisch analysieren"},"content":{"rendered":"<p>Ein wesentlicher Teil der Softwareentwicklung ist die <strong>Anforderungsanalyse<\/strong>. Dieses Feld, oft auch gern beim englischen Namen \u201e<strong>Requirements Engineering<\/strong>\u201c genannt, wird oft als l\u00e4stig und unn\u00fctz zeitaufwendig empfunden. Auch wenn man es kaum glauben mag, aber eine der h\u00e4ufigsten Ursachen f\u00fcr qualitativ unzureichende Software ist eine unvollst\u00e4ndige Analyse der Anforderungen sowie unzureichende Einbeziehung der Nutzer (vgl. [Chaos-Studie 1995]).<!--more--><\/p>\n<p>Anforderungen vollst\u00e4ndig und korrekt zu dokumentieren hat aber auch weitere Zwecke:<\/p>\n<ul>\n<li>Dokumente k\u00f6nnen als <strong>Vertragsbestandteil zwischen Dienstleistern und Kunden<\/strong> dienen<\/li>\n<li>erm\u00f6glicht eine zuverl\u00e4ssigere <strong>Einsch\u00e4tzung des Entwicklungsaufwandes<\/strong><\/li>\n<li>Entwickler haben eine genaue und vollst\u00e4ndige <strong>Liste der umzusetzenden Funktionen<\/strong><\/li>\n<li>Softwaretester haben realit\u00e4tsnahe <strong>Qualit\u00e4tsvorgaben<\/strong><\/li>\n<\/ul>\n<h2>Kategorisierung von Anforderungen<\/h2>\n<p>Betrachten wir \u00fcbliche Anforderungen genauer, gibt es vor allem zwei Kategorien, die auffallen: \u201eDer Administrator soll neue Nutzer hinzuf\u00fcgen k\u00f6nnen.\u201c bezeichnet klar, was das Programm k\u00f6nnen soll. Hier haben wir eine konkrete Forderung, die der Entwickler umsetzen und abhaken kann. Dem gegen\u00fcber stehen weniger klare Forderungen wie \u201eAuch ungeschultes Personal soll die Software effizient einsetzen k\u00f6nnen.\u201c Hier steht der Entwickler vor einem Problem, da sich die Anforderung nicht eindeutig pr\u00fcfen l\u00e4sst. Zur Vereinfachung wird daher oft versucht, messbare Parameter in solche Formulierungen einzubringen: \u201eUngeschultes Personal soll innerhalb von drei Minuten einen neuen Nutzer anlegen k\u00f6nnen.\u201c<\/p>\n<p>Genannte Unterteilung ist auch in der Literatur sehr \u00fcblich und wird oft folgenderma\u00dfen benannt:<\/p>\n<dl>\n<dt>Funktionale Anforderungen<\/dt>\n<dd>Die Anforderung beschreibt, was das Produkt tun soll (eine bestimmte Produktfunktion).<\/dd>\n<dt>Nichtfunktionale Anforderungen<\/dt>\n<dd>Die Anforderung beschreibt eine Eigenschaft des Produktes oder einer bestimmten Funktion.<\/dd>\n<\/dl>\n<p>Ob Vertragsdetails wie die Entwicklungszeit eine nichtfunktionale Anforderung darstellen ist strittig. Meist werden sie jedoch nicht dazu gez\u00e4hlt.<\/p>\n<h2>Was es zu erfassen gilt<\/h2>\n<p>Wie und in welchem Umfang Anforderungen dokumentiert werden sollten ist unterschiedlich. Um jedoch nichts wichtiges zu vergessen, bietet sich eine vollst\u00e4ndige Liste \u00fcblicher Fakten an, die \u00fcber Produkte erhoben werden k\u00f6nnen.<\/p>\n<p>Eine Empfehlung des Aufbaus eines Dokuments zur Erfassung von Anforderungen gibt der <strong>Standard IEEE 830-199<\/strong>:<\/p>\n<blockquote>\n<h3>Table of Contents<\/h3>\n<ol>\n<li>Introduction\n<ol>\n<li>Purpose<\/li>\n<li>Scope<\/li>\n<li>Definitions, acronyms, and abbreviations<\/li>\n<li>References<\/li>\n<li>Overview<\/li>\n<\/ol>\n<\/li>\n<li>Overall description\n<ol>\n<li>Product perspective<\/li>\n<li>Product functions<\/li>\n<li>User characteristics<\/li>\n<li>Constraints<\/li>\n<li>Assumptions and dependencies<\/li>\n<\/ol>\n<\/li>\n<li>Specific requirements<\/li>\n<li>Appendix<\/li>\n<\/ol>\n<p class=\"cite\">aus [IEEE 830-199]<\/p>\n<\/blockquote>\n<h2>Die Vorgehensweise<\/h2>\n<p>Ist man sich nicht klar, wie man zu den gew\u00fcnschten Ergebnissen kommen kann, ist eine systematische Vorgehensweise empfehlenswert (vgl. [Pfleeger 2001]):<\/p>\n<table>\n<tbody>\n<tr>\n<td>1.<\/td>\n<td class=\"important\">Problemanalyse<\/td>\n<td style=\"vertical-align: middle;\" rowspan=\"3\"><strong>Anforderungsgewinnung<\/strong> (Requirements Definition)<\/td>\n<\/tr>\n<tr>\n<td>2.<\/td>\n<td class=\"important\">Problembeschreibung<\/td>\n<\/tr>\n<tr>\n<td>3.<\/td>\n<td class=\"important\">Prototyping, Testen<\/td>\n<\/tr>\n<tr class=\"separated\">\n<td>4.<\/td>\n<td class=\"important\">Dokumentation, Validierung<\/td>\n<td><strong>Anforderungsspezifikation<\/strong> (Software Requirements Specification, SRS)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>In den benannten Phasen wird im wesentlichen folgendes getan:<\/p>\n<ol>\n<li>Was soll das Endprodukt leisten? Wer soll es nutzen oder ist anderweitig betroffen und sollte daher befragt werden?<\/li>\n<li>Hier erfolgt eine konkrete Auflistung der Probleme durch die <em>betroffenen Kunden<\/em> (von einem Produkt betroffene Menschen werden auch \u201e<strong>Stakeholder<\/strong>\u201c genannt). Dies entspricht einer Liste an Produktfunktionen und -eigenschaften und entspricht somit dem <strong>Lastenheft<\/strong>.<\/li>\n<li>Die Entwickler m\u00fcssen pr\u00fcfen, inwieweit die Anforderungen umsetzbar sind.<\/li>\n<li>Die gesammelten Erkenntnisse werden dokumentiert und \u00fcberpr\u00fcft. Dies ergibt ein f\u00fcr Vertr\u00e4ge oft ma\u00dfgebliches <strong>Pflichtenheft<\/strong>, in dem der Entwickler konkret aufz\u00e4hlt, welche Leistungen erbracht werden sollen.<\/li>\n<\/ol>\n<h2>Qualit\u00e4tsanspr\u00fcche<\/h2>\n<p>Eine erfolgreiche Anforderungsanalyse sollte im wesentlichen drei Eigenschaften erf\u00fcllen (vgl. [Jarke 1995]). W\u00e4hrend und vor allem nach der Fertigstellung der Dokumente, sollte man sich einige Fragen stellen:<\/p>\n<ul>\n<li>Ist die <strong>Spezifikation<\/strong> wirklich <strong>vollst\u00e4ndig<\/strong>?<\/li>\n<li>Sind die <strong>Anforderungen formal<\/strong> dargestellt und somit allgemein verst\u00e4ndlich?<\/li>\n<li>Habe ich auch wirklich umgesetzt, was der Kunde von mir wollte? Habe ich die <strong>Kundensicht<\/strong> beachtet?<\/li>\n<\/ul>\n<p>Kann man jede dieser Fragen mit einem ehrlichen ja beantworten, sollte einer erfolgreichen Umsetzung nun nichts mehr im Weg stehen.<\/p>\n<section class=\"source\">\n<h2>Quellen<\/h2>\n<dl>\n<dt>[Chaos-Studie 1995]<\/dt>\n<dd>The Standish Group: \u201eThe Standish Group Report\u201c, 1995<\/dd>\n<dt>[Pfleeger 2001]<\/dt>\n<dd>Shari Lawrence Pfleeger: \u201eSoftware Engineering\u201c, 2001<\/dd>\n<dt>[IEEE 830-199]<\/dt>\n<dd>IEEE-SA Standards Board: \u201eIEEE Recommended Practice for Software Requirements Speci\ufb01cation\u201c, 1998<\/dd>\n<dt>[Jarke 1995]<\/dt>\n<dd>Matthias Jarke, Klaus Pohl, Ralf D\u00f6mges, Stephan Jacobs, Hans W. Nissen: \u201eRequirements Information Management: The NATURE Approach\u201c, 1995<\/dd>\n<\/dl>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Ein wesentlicher Teil der Softwareentwicklung ist die Anforderungsanalyse. Dieses Feld, oft auch gern beim englischen Namen \u201eRequirements Engineering\u201c genannt, wird oft als l\u00e4stig und unn\u00fctz zeitaufwendig empfunden. Auch wenn man es kaum glauben mag, aber eine der h\u00e4ufigsten Ursachen f\u00fcr qualitativ unzureichende Software ist eine unvollst\u00e4ndige Analyse der Anforderungen sowie unzureichende Einbeziehung der Nutzer (vgl.&hellip; <a class=\"more-link\" href=\"https:\/\/sgaul.de\/2011\/06\/21\/anforderungen-systematisch-analysieren\/\"><span class=\"screen-reader-text\">Anforderungen systematisch analysieren<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":58,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[91],"tags":[10,11],"_links":{"self":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts\/14"}],"collection":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/comments?post=14"}],"version-history":[{"count":61,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts\/14\/revisions"}],"predecessor-version":[{"id":1783,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts\/14\/revisions\/1783"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/media\/58"}],"wp:attachment":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/media?parent=14"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/categories?post=14"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/tags?post=14"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}