Autor: Thomas Batt, MicroConsult GmbH<\/em><\/p>\n Anforderungen zu erfassen und zu verwalten ist ein wesentlicher Schl\u00fcssel zum Projekterfolg. Die Embedded-Software-Funktionalit\u00e4t in Anforderungen zu beschreiben ist einfacher als die Qualit\u00e4tsmerkmale. Dennoch sind die Qualit\u00e4tsmerkmale zu erfassen, da sie sich am Ende NICHT hineintesten lassen. Je abstrakter die Qualit\u00e4tsmerkmale sind, desto aufwendiger ist deren Erfassung. Mit genau dieser Herausforderung besch\u00e4ftigt sich dieser Beitrag.<\/strong><\/p>\n Anforderungen sind in funktionale Anforderungen, Zusicherungen als Anforderungen und nichtfunktionale Anforderungen unterteilbar.<\/p>\n Funktionale Anforderungen beschreiben die nach au\u00dfen hin sichtbaren Funktionalit\u00e4ten der Embedded-Software. Beispiel f\u00fcr eine funktionale Anforderung: Zusicherungen (Constraints) sind allgemeine, globale Zusicherungen, die f\u00fcr das Produkt und\/oder f\u00fcr die Produktentwicklung gelten. Auch die Projektrandbedingungen geh\u00f6ren zu den Zusicherungen.<\/p>\n Unterarten von Zusicherungsanforderungen:<\/strong><\/p>\n Beispiel einer technischen Zusicherung als Anforderung: Mit dieser Gliederung reduzieren sich die nichtfunktionalen Anforderungen auf Qualit\u00e4tsmerkmale.\u00a0Qualit\u00e4tsmerkmale<\/strong>\u00a0lassen sich differenzieren in:<\/p>\n Dieses Bewusstsein und Verst\u00e4ndnis \u00fcber Qualit\u00e4tsanforderungen sollte bei allen Mitarbeitern aus den Unternehmensbereichen Vertrieb, Marketing, Produktmanagement, Projektmanagement, Entwicklung, Test und Produktion vorhanden sein.<\/p>\n Schaffen Sie es, einen Formel-1-Rennwagen so zu realisieren, dass er als Drei-Liter-Auto und zum Containertransport geeignet ist?<\/p>\n Zu Software-Qualit\u00e4tsmerkmalen sowie deren Spezifikation und Test existieren die folgenden\u00a0Standards<\/strong>:<\/p>\n Dieser Standard ist abgel\u00f6st durch:<\/p>\n Siehe Bild 1 (PDF<\/a>): Exemplarische \u00dcbersicht zu Qualit\u00e4ts- und Subqualit\u00e4tsmerkmalen<\/em><\/p>\n Bitte beachten Sie dazu immer die f\u00fcr Ihre Branche und Produkte g\u00fcltigen Standards.<\/p>\n Siehe Bild 2-1 (PDF<\/a>): Erfassungsmethode f\u00fcr Qualit\u00e4tsanforderungen (1. Teil)<\/em><\/p>\n Abstraktes Qualit\u00e4tsmerkmal festlegen:<\/strong><\/p>\n Zu jedem Qualit\u00e4tsmerkmal formuliert der Anforderungsanalyst\u00a0erschlie\u00dfende Fragen<\/strong>\u00a0und zu jedem Subqualit\u00e4tsmerkmal weiterf\u00fchrende Fragen. Daraus ergeben sich zun\u00e4chst abstrakte Anforderungen. Er kann in der Datenbank pr\u00fcfen, ob das Qualit\u00e4tsmerkmal bereits quantisiert ist. Wenn ja, kann der Anforderungsanalyst direkt die konkrete Anforderung formulieren.<\/p>\n Qualit\u00e4tsmerkmal bereits in der Datenbank erfasst?<\/strong><\/p>\n Falls das Qualit\u00e4tsmerkmal bereits in vorherigen Produkten spezifiziert wurde, k\u00f6nnen der Anforderungsanalyst direkt die konkrete Anforderung und das Testteam den konkreten Test-Case formulieren.<\/p>\n Quantisierung 1 (Referenzteil f\u00fcr Produkt) festlegen:<\/strong><\/p>\n Der Anforderungsanalyst erarbeitet zusammen mit Fachexperten ein Quantisierungsschema f\u00fcr das Qualit\u00e4tsmerkmal.<\/p>\n Kriterien f\u00fcr die Umsetzung ableiten:<\/strong><\/p>\n Aus dem Quantisierungsschema leiten sich Kriterien und Fakten f\u00fcr die Umsetzung der Anforderung ab.<\/p>\n Siehe Bild 2-2 (PDF<\/a>): Erfassungsmethode f\u00fcr Qualit\u00e4tsanforderungen (2. Teil)<\/em><\/p>\n Kriterien f\u00fcr den Test ableiten:<\/strong><\/p>\n Aus dem Quantisierungsschema leiten sich Kriterien und Fakten f\u00fcr die Verifikation der Anforderung ab.<\/p>\n Quantisierung 2 (Regelungsteil) f\u00fcr Projekt festlegen:<\/strong><\/p>\n Viele Quantisierungsschemata erlauben dem Anforderungsanalysten eine projektspezifische Anpassung von Werten und oder Zusammenh\u00e4ngen.<\/p>\n Konservierung zur Wiederverwendung:<\/strong><\/p>\n Neu entwickelte Quantisierungsschemata zu Qualit\u00e4tsmerkmalen pflegt der Anforderungsanalyst zur Wiederverwendung in die Datenbank ein.<\/p>\n Konkrete Anforderung mit Test-Case erfassen:<\/strong><\/p>\n Auf Basis der bereits vorhandenen abstrakten Anforderung zusammen mit dem Quantisierungsschema f\u00fcr das betrachtete Qualit\u00e4tsmerkmal erfasst der Anforderungsanalyst eine umsetzbare und nachweisbare Anforderung. Aus der Anforderung leitet das Testteam den passenden Test-Case ab.<\/p>\n Siehe Bild 3 (PDF<\/a>): Datenbankaufbau f\u00fcr Qualit\u00e4tsanforderungen<\/em><\/p>\n Die Referenzdatenbank ist m\u00f6glichst generisch zu halten, damit sie den stetig wachsenden und immer wieder wechselnden Anforderungen aus Theorie und Praxis gerecht wird.<\/p>\n Allgemeiner Teil:<\/strong><\/p>\n Referenzbeispiel:<\/strong><\/p>\n F\u00fcr die in der Datenbank enthaltenen L\u00f6sungen werden Referenzbeispiele erstellt. Zu jedem Referenzbeispiel geh\u00f6ren ein Referenzteil und ein Regelungsteil.<\/p>\n Referenzteil:<\/strong><\/p>\n Der Referenzteil beinhaltet Kenngr\u00f6\u00dfen und m\u00f6gliche Wertebereiche zu Berechnung der entsprechenden Submerkmale.<\/p>\n Regelungsteil:<\/strong><\/p>\n Im Regelungsteil wird der L\u00f6sungsweg zur konkreten L\u00f6sung anhand von Beispielen beschrieben. Am Ende des Regelungsteils kann die konkrete Anforderung f\u00fcr das entsprechende Merkmal stehen.<\/p>\n Siehe Bild 4 (PDF<\/a>): (Abstraktes) Qualit\u00e4tsmerkmal festlegen<\/em><\/p>\n Das Qualit\u00e4tsmerkmal „\u00e4nderbar“ ist in diesem Beispiel auf die Software eines Kaffeevollautomaten angewandt, l\u00e4sst sich aber auf beliebige Produkte \u00fcbertragen.<\/p>\n Bezogen auf Bild 1 gelten f\u00fcr das Qualit\u00e4tsmerkmal \u00c4nderbarkeit die Subqualit\u00e4tsmerkmale Analysierbarkeit, Modifizierbarkeit, Stabilit\u00e4t und Pr\u00fcfbarkeit.<\/p>\n Zu jedem Qualit\u00e4tsmerkmal formuliert der Anforderungsanalyst\u00a0erschlie\u00dfende Fragen:<\/strong><\/p>\n \u00c4nderbarkeit<\/em><\/strong><\/p>\n Wollen Sie Kenngr\u00f6\u00dfen zu den Merkmalen definieren, die sich auf den Aufwand beziehen, der zur Durchf\u00fchrung vorgegebener \u00c4nderungen des zu entwickelnden Systems notwendig sind?<\/p>\n Zu jedem Subqualit\u00e4tsmerkmal formuliert der Anforderungsanalyst\u00a0weiterf\u00fchrende Fragen<\/strong>:<\/p>\n Analysierbarkeit<\/em><\/strong><\/p>\n Wollen Sie Kenngr\u00f6\u00dfen f\u00fcr die Merkmale definieren, die sich auf den Aufwand beziehen, um M\u00e4ngel oder Ursachen von einem Versagen des zu erstellenden Systems zu diagnostizieren oder um \u00e4nderungsbed\u00fcrftige Teile zu bestimmen?<\/p>\n Modifizierbarkeit<\/em><\/strong><\/p>\n Wollen Sie Kenngr\u00f6\u00dfen f\u00fcr die Merkmale definieren, die sich auf den Aufwand beziehen, der zur Ausf\u00fchrung von Verbesserungen, zur Fehlerbeseitigung oder zur Anpassung an Umgebungsver\u00e4nderungen notwendig ist?<\/p>\n Stabilit\u00e4t<\/em><\/strong><\/p>\n Wollen Sie Kenngr\u00f6\u00dfen f\u00fcr die Merkmale definieren, die sich auf den Aufwand beziehen, der zur Pr\u00fcfung der ge\u00e4nderten Hardware\/Software\/… notwendig ist?<\/p>\n Pr\u00fcfbarkeit<\/em><\/strong><\/p>\n Wollen Sie Kenngr\u00f6\u00dfen f\u00fcr die Merkmale definieren, die sich auf den Aufwand beziehen, der zur Pr\u00fcfung der ge\u00e4nderten Hardware\/Software\/… notwendig ist.<\/p>\n Siehe Bild 5-1 (PDF<\/a>): Quantisierung 1 (Referenzteil f\u00fcr Produkt) festlegen: Softwaremetriken<\/em><\/p>\n Das folgende Beispiel basiert auf einer Ver\u00f6ffentlichung der DSF Deutsche Flugsicherung GmbH und Brandenburg Technische Universit\u00e4t Cottbus:\u00a0„Pieper: Definition von Software-Qualit\u00e4tsmerkmalen\u201c<\/em>\u00a0und\u00a0\u201eBennicke, D\u00f6rr: New Metric Application“.<\/em><\/p>\n Die oben dargestellten Metriken sind ein Beispiel f\u00fcr einen Auszug aus der Referenzdatenbank zum Qualit\u00e4tsmerkmal\u00a0\u00c4nderbarkeit<\/strong>. Die Metriken und Grenzwerte k\u00f6nnen zur Bestimmung der Subqualit\u00e4tsmerkmale\u00a0Analysierbarkeit, Modifizierbarkeit, Stabilit\u00e4t<\/strong>\u00a0und\u00a0Pr\u00fcfbarkeit<\/strong>\u00a0herangezogen werden.<\/p>\n Siehe Bild 5-2 (PDF<\/a>): Quantisierung 1 (Referenzteil f\u00fcr Produkt) festlegen: Zuordnung und Gewichtung<\/em><\/p>\n Nach Bestimmung der\u00a0Metriken<\/strong>\u00a0m\u00fcssen diese den Submerkmalen\u00a0zugeordnet<\/strong>\u00a0werden:<\/p>\nBeitrag – Embedded Software Engineering Kongress 2018<\/h3>\n
Qualit\u00e4tsanforderungen und deren Mythen<\/h2>\n
Funktionale Anforderungen<\/h3>\n
\nDie Kaffeevollautomat-Software muss f\u00e4hig sein, sich zu aktualisieren.<\/em><\/p>\nZusicherungen als Anforderungen<\/h3>\n
\n
\nTechnische Zusicherungen sind Anforderungen, die technische Vorgaben zur Realisierung festlegen, z.B. Bestimmung der Programmiersprache oder des Prozessors.<\/li>\n
\nProjektbezogene Zusicherungen sind Anforderungen, die sich auf das gesamte Projekt beziehen, z.B. Einhaltung von g\u00fcltigen Standards, Kosten (f\u00fcr Entwicklung, Produktion) und Daten, die sich in den Projektpl\u00e4nen widerspiegeln.<\/li>\n
\nLieferungsbezogene Zusicherungen sind Anforderungen, die sich auf die Systemlieferung beziehen, z.B. Lieferumfang, Liefervarianten, Lieferzeiten und Liefermengen.<\/li>\n
\nRechtliche und vertragliche Zusicherungen sind Anforderungen, die die Abwicklung der Entwicklung betreffen, z.B. Kosten, Termin der Fertigstellung, Zahlungsmeilensteine, Vertragsstrafen, Umgang mit neuen Anforderungen, Umgang mit Anforderungs\u00e4nderungen und Eskalationspfade.<\/li>\n
\n<\/strong>Prozessbezogene Zusicherungen sind Anforderungen bez\u00fcglich des Entwicklungsprozesses (Vorgehensmodell), z.B. die Entwicklung muss basierend auf dem V-Modell XT durchgef\u00fchrt werden.<\/li>\n<\/ul>\n
\nDie Kaffeevollautomat-Software muss mit der UML (Unified Modeling Language) modelliert sein.<\/em><\/p>\nNichtfunktionale Anforderungen<\/h3>\n
\n
\n>\u00a0konkretes Qualit\u00e4tsmerkmal<\/strong><\/li>\n<\/ul>\n\n
\n>abstraktes Qualit\u00e4tsmerkmal<\/strong><\/li>\n<\/ul>\nFakten zu Qualit\u00e4t<\/h2>\n
\n
\n
\n
Erfassungsmethode f\u00fcr Qualit\u00e4tsanforderungen<\/h2>\n
\n
Erfassungsbeispiel<\/h2>\n