Autor: Thomas Batt, MicroConsult GmbH<\/p>\n
Anforderungen zu erfassen und zu verwalten ist ein wesentlicher Schl\u00fcssel zu erfolgreichen Projekten. Egal ob im klassischen oder agilen Prozessumfeld – professionelles Requirements Engineering und Management f\u00fcr Embedded- und Echtzeitsysteme verk\u00fcrzt Ihre Projektlaufzeiten und spart Entwicklungs- sowie Wartungskosten ein. Stellen Sie sich dieser Herausforderung!<\/strong><\/p>\n Vor dem Hintergrund meiner beruflichen Erfahrungen sowie der Durchf\u00fchrung von vielen Seminaren und Coachings zum Thema Requirements Engineering und Management ist die dem Beitrag zugrunde liegende Checkliste entstanden (s.\u00a0PDF<\/a>, Bild 1).<\/p>\n Die Checkliste soll Ihnen zeigen, was Sie zum Thema Anforderungen in Ihrem Unternehmen einf\u00fchren, durchf\u00fchren und optimieren k\u00f6nnen. Sie ist gleicherma\u00dfen eine Fundgrube wertvoller Tipps aus der Praxis.<\/p>\n Der folgende Beitrag greift alle Themenpunkte der Checkliste der Reihe nach auf und beleuchtet den Hintergrund dazu. Wichtig f\u00fcr das Verst\u00e4ndnis: Wo der Begriff „System“ verwendet ist, kann dieser durch andere Dom\u00e4nen wie beispielsweise Embedded-Software oder -Hardware ersetzt werden.<\/p>\n Die Requirements Engineering und Management Checkliste zusammen mit der dazugeh\u00f6rigen Dokumentation dazu haben wir unter [1] f\u00fcr Sie zum Download bereitgestellt.<\/p>\n Grenzen Sie gedanklich, schriftlich und organisatorisch Anforderungen von deren Umsetzung ab. Anforderungen meinen das WAS und die Umsetzung das WIE. Nur in wenigen begr\u00fcndbaren F\u00e4llen enthalten Anforderungen kein WIE.<\/p>\n Grenzen Sie das anzufordernde System gegen dessen Kontext ab, um die externen Schnittstellen und damit die zugeh\u00f6rigen Anforderungen zu identifizieren.<\/p>\n (s.\u00a0PDF<\/a>, Bild 2)<\/p>\n Als grafische Notation dazu eignet sich f\u00fcr eine Kontextsicht das Use-Case Diagramm aus der UML (Unified Modeling Language) bzw. aus der SysML (Systems Modeling Language) [5].<\/p>\n Die Basis f\u00fcr alles weitere in der Entwicklung und im Test sind die Anforderungen. Sie sollten diese textuell erfassen und ggf. mit anderen Darstellungsformen wie Grafiken und Diagrammen erg\u00e4nzen. Eine alternative Notationsm\u00f6glichkeit, mit der Sie die textuelle Anforderungserfassung komplett ersetzen k\u00f6nnen, ist bis heute (2017) nicht erfunden.<\/p>\n Verwenden Sie Anforderungstemplates [8], um bereits beim Schreiben der Anforderungen einen sehr hohen Qualit\u00e4tslevel der Anforderung zu erreichen.<\/p>\n Anforderungstemplate f\u00fcr selbstst\u00e4ndige Systemaktivit\u00e4t:<\/p>\n [Wann?] [Unter welcher Bedingung?] MUSS | SOLLTE DAS SYSTEM Anforderungstemplate f\u00fcr interaktive Systemaktivit\u00e4t:<\/p>\n [Wann?] [Unter welcher Bedingung?] MUSS | SOLLTE<\/em>\u00a0DAS SYSTEM <wem?> DIE M\u00d6GLICHKEIT BIETEN, <Objekt und Erg\u00e4nzung des Objektes> <Prozesswort im Infinitiv>.<\/em><\/p>\n Anforderungstemplate f\u00fcr potentielle Systemaktivit\u00e4t:<\/p>\n [Wann?] [Unter welcher Bedingung?] MUSS | SOLLTE DAS SYSTEM F\u00c4HIG SEIN, Um die Qualit\u00e4t der Anforderungen nochmals zu steigern, wenden Sie erg\u00e4nzend zu den Anforderungstemplates die nat\u00fcrlichsprachlichen Methode [8] an. Dadurch erreichen Sie eine R\u00fccktransformation der beim Wissensausdruck entstehenden Tilgungen, Generalisierungen und Verzerrung.<\/p>\n Jede Anforderung muss die folgenden Qualit\u00e4tsmerkmale erf\u00fcllen: vollst\u00e4ndig, korrekt, verstehbar, notwendig, konsistent, verfolgbar, machbar, Verbindlichkeit klassifiziert, testbar und [optional] atomar.<\/p>\n Machen Sie sich dieser Anforderungskategorien bewusst:<\/p>\n Produktanforderungen: Projektanforderungen: Plattformanforderungen: Machen Sie sich dieser Anforderungsarten bewusst:<\/p>\n Funktionale Anforderungen: Nichtfunktionale Anforderungen: Zusicherungen als Anforderungen: Beschreiben Sie nicht nur funktionale Anforderungen, sondern auch deren Qualit\u00e4ten und genauso wie die Qualit\u00e4ten f\u00fcr das gesamte System.<\/p>\n Quantisieren Sie abstrakte Qualit\u00e4tsmerkmale wie beispielsweise Wiederverwendbarkeit. „Die Embedded-Software muss wiederverwendbar sein.“ -> „Die Embedded-Software muss mit dem Grad 4 wiederverwendbar sein.“ Dabei m\u00fcssen Sie die verschiedenen Grade einmalig spezifizieren. Daraus geht hervor, was die Embedded-Software erf\u00fcllen muss.<\/p>\n Bei konkreten Qualit\u00e4tsmerkmalen, wie beispielsweise dem Leistungsverbrauch eines Systems, k\u00f6nnen Sie direkt den Wert mit Einheit setzen.<\/p>\n In der oben beschriebenen Gradspezifikation beschreiben Sie zusammen mit dem Testteam auch die Testbarkeit \/ Nachweisbarkeit f\u00fcr die Erf\u00fcllung des (abstrakten) Qualit\u00e4tsmerkmals.<\/p>\n Bei konkreten Qualit\u00e4tsmerkmalen, wie beispielsweise dem Leistungsverbrauch eines Systems, ist die Testbarkeit \/ Nachweisbarkeit meist klar.<\/p>\n Standards und Normen enthalten nicht immer direkt die Anforderungen f\u00fcr das Produkt. Vielmehr lassen die Texte h\u00e4ufig einen gewissen Interpretationsspielraum zu. Umso wichtiger ist es, dass Sie einmalig aus den f\u00fcr Ihre Produkte g\u00fcltigen Standards und Normen die konkreten Anforderungstexte ableiten und diese gemeinsam mit den Beratungsstellen der zertifizierenden Organisationen vor der Umsetzung abstimmen.<\/p>\n Wenn Sie in den Anforderungstexten Substantive, Verben, Adjektive oder Abk\u00fcrzungen verwenden, die bei Stakeholdern nicht gepr\u00e4gt sind, m\u00fcssen Sie diese Begriffe in einem Glossar erkl\u00e4ren. F\u00fchren Sie ein einziges Glossar anstelle mehrerer verschiedener f\u00fcr das gesamte Projekt \u00e8 Vermeiden von Redundanz und Inkonsistenz<\/p>\n F\u00fchren Sie Requirements Engineering und Management nicht nur f\u00fcr Kunden- und Systemanforderungen ein, sondern f\u00fcr alle Entwicklungsdom\u00e4nen, z.B. Subsysteme, Hardware, Embedded-Software, Software, Konstruktion, usw.<\/p>\n (s.\u00a0PDF<\/a>, Bild 3)<\/p>\n Egal ob Sie traditionelle [3] oder agile [4] Prozesse leben, definieren Sie eindeutige Workflows mit genau benannten Aktivit\u00e4ten, deren ein- und ausgehenden Artefakten und deren verantwortlichen Rollen.<\/p>\n Insbesondere bei der Unternehmenseinf\u00fchrung von Requirements Engineering und Management in Pilotprojekten ist es wichtig, ein gemeinsames Verst\u00e4ndnis sowie ein hohes Ma\u00df an Motivation, Wissen und Zustimmung unter den Beteiligten zu schaffen. Zweifler involvieren Sie punktuell, z.B. in Engineering Meetings.<\/p>\n Aus den gesammelten Erfahrungen mit den Vorg\u00e4ngerprodukten leiten Sie Anforderungen f\u00fcr das neue Produkt ab.<\/p>\n Stakeholder sind Personen und Institutionen, die ein berechtigtes Interesse an dem neuen Produkt haben. Nicht nur der Produktmanager sollte sich intensiv \u00fcber potentielle Stakeholder Gedanken machen, sondern auch die Anforderungsverantwortlichen nachfolgender Entwicklungsebenen.<\/p>\n W\u00e4hlen Sie aus den identifizierten Stakeholder-Gruppen einzelne Repr\u00e4sentanten aus und dokumentieren Sie Ihre Auswahl.<\/p>\n Vereinbaren Sie mit den ausgew\u00e4hlten Stakeholder-Repr\u00e4sentanten Interviewtermine und befragen Sie sie zu den von Ihnen vorbereiteten Anforderungsthemen. Lernen und \u00fcben Sie dazu Interviewtechniken. Hierzu profitieren Sie von Kenntnissen \u00fcber NLP (Neuro-Linguistisches Programmieren) [7].<\/p>\n Leiten Sie aus den Interviewergebnissen konkrete Anforderungen ab.<\/p>\n Stimmen Sie die aus den Interviewergebnissen abgeleiteten Anforderungen in einer n\u00e4chsten Iteration mit den Stakeholdern ab.<\/p>\n Modellieren Sie im Rahmen der Analyse die Anforderungen. So werden Inkonsistenzen und Unvollst\u00e4ndigkeiten entdeckt, und ein verbessertes Themenverst\u00e4ndnis wird erlangt. Dabei entwickeln Sie neben der Kontextsicht Funktionale-Anforderungssichten, interaktive und generische Verhaltenssichten. Als Notation dazu sei nochmals auf die UML \/ SysML [5] verwiesen. Um noch weitere Anforderungen aufzudecken, f\u00fchren Sie auf Basis der entstandenen Sichten eine Fehleranalyse durch.<\/p>\n Mithilfe von Toolunterst\u00fctzung und entsprechender Vorbereitung f\u00fchren Sie das Anforderungsmodell aus und simulieren so die Anforderungen. Mittels der Simulationsergebnisse verbessern Sie die Anforderungsqualit\u00e4ten.<\/p>\n Ein Anforderungsqualit\u00e4tsmerkmal ist die Machbarkeit der Anforderung. Wenn nicht einmal der Fachspezialist die Machbarkeit absch\u00e4tzen kann, m\u00fcssen Sie eine Machbarkeitsstudie (Feasibility Study) beauftragen. Damit entscheiden Sie die Machbarkeit.<\/p>\n Mittels des vom Prototypen-Team erstellten Prototyps erhalten Sie eine konkrete Aussage \u00fcber die Machbarkeit der Anforderung. Den Wegwerf-Prototyp entsorgen Sie, den evolution\u00e4ren Prototyp lassen Sie ins Produkt einflie\u00dfen. Vereinbaren Sie vor der Prototypenerstellung dessen Art und halten Sie das Ergebnis schriftlich fest. Beachten Sie, dass ein Wegwerf-Prototyp niemals zu einem evolution\u00e4ren Prototyp mutieren darf!<\/p>\n F\u00fchren Sie mit ausgew\u00e4hlten Stakeholdern Reviews der textuellen und der modellierten Anforderungen durch. Mit den Review-Ergebnissen verbessern Sie die Anforderungsqualit\u00e4ten.<\/p>\n Funktionalszenarien: Analysieren Sie mit \u201ePapier und Bleistift\u201c oder toolgest\u00fctzt mit der UML \/ SysML Notation [5] typische und untypische funktionale Abl\u00e4ufe gegen die Schnittstellen des Systems. Basis dazu ist der aktuelle Kenntnisstand \u00fcber das System. Pr\u00fcfen Sie dabei die Konsistenz und Vollst\u00e4ndigkeit der Anforderungen zu den Abl\u00e4ufen. Als nebenl\u00e4ufigen Nutzen k\u00f6nnen Sie diese Funktionalszenarien auch als Testszenarien gegen die externen Schnittstellen (Systemtest) einsetzen.<\/p>\n Qualit\u00e4tsszenarien: Analysieren Sie, welche realistischen und konkreten Szenarien sich f\u00fcr (abstrakte) Qualit\u00e4tsmerkmale f\u00fcr das System ergeben. Beispielsweise resultieren aus dem abstrakten Qualit\u00e4tsmerkmal Portabilit\u00e4t in der Embedded-Software mehrere Dimensionen: Portierbarkeit bezogen auf Hardware, Betriebssystem, Kommunikation, Middleware. F\u00fcr alle relevanten Dimensionen arbeiten Sie realistische Szenarien aus, z.B. Hardware-Portierung von Mikrocontroller A zu Mikrocontroller B, und nehmen diese als Anforderung mit auf.<\/p>\n Gleichen Sie kontinuierlich die Umsetzung mit den Anforderungen ab. Im Fehlerfall korrigieren Sie die Anforderungen. Bei Anforderungs\u00e4nderungen pr\u00fcfen Sie die Umsetzung. Allersp\u00e4testens am Projektende sollte das System exakt die Umsetzung der Anforderungen widerspiegeln \u2013 nicht mehr und nicht weniger.<\/p>\n Das Testteam stattet jede Anforderung mit mindestens einem Test-Case aus. Durch die personelle Trennung (vier-Augen-Prinzip) ergeben sich positive R\u00fcckwirkungen auf die Anforderungsqualit\u00e4ten. Mit dem sp\u00e4teren Ausf\u00fchren des Test-Cases weist der Tester nach, dass die Anforderung im System umgesetzt ist. Es existiert keine Anforderung ohne Test-Case. In Umkehrschluss entf\u00e4llt jede Anforderung ohne Test-Case.<\/p>\n Die Projektleitung f\u00fchrt w\u00e4hrend des gesamten Projektes ein Risiko-Tracking-Dokument, in das die Projektbeteiligten die identifizierten Risiken eintragen.<\/p>\n (s.\u00a0PDF<\/a>, Bild 4)<\/p>\n Damit Sie die Eintrittswahrscheinlichkeit P und das Schadensausma\u00df S nicht nach Bauchgef\u00fchl angeben, m\u00fcssen Sie f\u00fcr P und S konkrete Werte und Einheiten definieren.<\/p>\n W\u00e4hrend der Entwicklung \u00e4ndern sich aus verschiedensten Gr\u00fcnden immer wieder Anforderungen, bzw. neue kommen hinzu und bestehende entfallen. Hierzu sollten Sie einen Ablauf definieren, in dem ein Team die Konsequenzen der \u00c4nderung bewertet (Impact-Analyse) und final \u00fcber die \u00c4nderung entscheidet. F\u00e4llt die Entscheidung gegen die \u00c4nderung, sollten Sie die Anforderung f\u00fcr das Folgeprodukt speichern.<\/p>\n Sorgen Sie daf\u00fcr, dass Sie die gleichen Fehler (in der Anforderungserhebung) nicht mehrfach machen \u00e8 Lessons learned.<\/p>\n Jedes neue Projekt bietet die Chance, den Prozess und was dazugeh\u00f6rt kontinuierlich zu verbessern. Notieren Sie sich die Optimierungspunkte w\u00e4hrend des Projektes (Projekttagebuch) und adaptieren Sie den Prozess vor dem n\u00e4chsten Projekt.<\/strong><\/p>\n Insbesondere in Unternehmen, in denen Sie immer gleiche oder \u00e4hnliche Produkte entwickeln, bietet sich die Wiederverwendung von Anforderungen an. Dabei ist eine M\u00f6glichkeit der Minimal-Plattformgedanke: die f\u00fcr alle Produkte gleichen Anforderungen als Plattformanforderungen zu separieren und im individuellen Produktanforderungsset zu referenzieren. Eine Alternative dazu ist der Maximal-Plattformgedanke. In der Maximalplattform sind alle Anforderungen f\u00fcr alle Produkte enthalten. F\u00fcr neue Produkte referenzieren Sie die entsprechend g\u00fcltigen und versionierten Anforderungen.<\/p>\n Auch im Kontext der Anforderungswiederverwendung k\u00f6nnen Sie Anforderungstext mit Variablen und Einheiten besetzen, deren Werte Sie produktindividuell in deren Parameterlisten anpassen, z.B. die maximale Leistungsaufnahme Pmax<\/sub>\u00a0im Watt.<\/p>\n Statten Sie Anforderungen mit Eigenschaften aus, von denen Sie einen Nutzen haben. Manchmal ist weniger mehr. Neben der einzigartigen ID (z.B. REQ-EMB-SW_000001) zur Identifikation und Referenzierung, sollte jede Anforderung auch einen Status (z.B. in Bearbeitung \/ freigegeben \/ umgesetzt \/ getestet) besitzen. Alle Eigenschaften m\u00fcssen Sie pflegen, sonst haben diese keinen Nutzen.<\/p>\n (s.\u00a0PDF<\/a>, Bild 5a und 5b)<\/p>\n Die Version als Eigenschaft der Anforderung erlaubt es Ihnen, die Entstehung nachzuverfolgen und Anforderungen zuk\u00fcnftig evolution\u00e4r weiterzuentwickeln.<\/p>\n Zu einem definierten Zeitpunkt im Projektablauf halten Sie die aktuelle Reife der Anforderungen zur weiteren Umsetzung fest.<\/p>\n In denen f\u00fcr sicherheitskritische (Safety) Systeme g\u00fcltigen Standards ist die bidirektionale Traceability (Verlinkung) zwischen Anforderungen \u00fcber die Umsetzung bis hin zum Test-Case meist gefordert. Dies \u00fcber verschiedene Entwicklungsdom\u00e4nen und deren unterschiedliche Tools zu schaffen ist dabei die wesentliche Herausforderung \u00e8 Toolintegration, Standards wie ReqIF [5] und STEP [7].<\/p>\n Stelle Sie f\u00fcr die Artefakte im Prozess Templates bereit. Damit erreichen Sie, dass die gleichen Artefakt-Typen (z. B. Requirements Specification) immer gleich aussehen und erh\u00f6hen so das Verst\u00e4ndnis. Durch die vorgegebenen Inhalte \u00fcbersehen Sie keine Punkte, die zu bearbeiten sind. F\u00fcr viele Artefakt-Typen gibt es heute bereits Standards.<\/p>\n Grunds\u00e4tzlich m\u00fcssen Sie bei Tools die Entscheidung zwischen rein textverarbeitenden oder datenbankorientierten Tools treffen. Die Komplexit\u00e4t Ihrer Produkte wird weiterhin steigen. Je mehr Anforderungen und andere Artefakte Sie managen m\u00fcssen, desto besser unterst\u00fctzen Sie dabei datenbankorientierte Tools.<\/p>\n Es gibt nicht das beste Tool am Markt. Es gibt h\u00f6chstens das Tool am Markt, das Ihren Bedarf bzw. Ihre Toolanforderungen am besten erf\u00fcllt. Denken Sie bei der Toolauswahl an die folgende Reihenfolge: erst der Mensch, dann die Methode und dann das Tool! Die Toolauswahl sollte keine firmenpolitische Entscheidung sein.<\/p>\n Integrieren und testen Sie das ausgew\u00e4hlte Tool vor Projektbeginn. Um einer m\u00f6glichen Toolablehnung durch die Anwender entgegenzuwirken, sollten diese vor der Toolnutzung eine Toolschulung erhalten.<\/p>\n Etablieren Sie das Tool \u00fcber mehrere Abteilungen hinweg. Auch hier ist ein kontinuierlicher Lern- und Verbesserungsprozess zu leben.<\/p>\n Bei jedem einzelnen Checklisten-Punkt m\u00fcssen Sie f\u00fcr sich den dazugeh\u00f6rigen Nutzen im Verh\u00e4ltnis zum Umsetzungsaufwand abw\u00e4gen. Die besten Punkte f\u00fcr Sie sind die mit hohem Nutzen bei kleinem Umsetzungsaufwand.<\/p>\n [1]\u00a0MicroConsult Download f\u00fcr diesen Beitrag – komplett und aktuell<\/a><\/p>\n [2]\u00a0\u00a0MicroConsult Trainings<\/strong><\/a>:<\/p>\n [3]\u00a0V-Modell<\/a><\/p>\n [4]\u00a0Agiles Manifest<\/a><\/p>\n [5]\u00a0Object Management Group (OMG)<\/a><\/p>\n [6]\u00a0STEP (Standard for the Exchange of Product Model Data) ISO 10303<\/a><\/p>\n [7]\u00a0Neuro-Linguistisches Programmieren<\/a><\/p>\n [8]\u00a0Fachliteratur:Requirements Engineering und Management<\/a> Dipl.-Ing. (FH) Thomas Batt ist geb\u00fcrtiger Freiburger. Nach seiner Ausbildung als Radio- und Fernsehtechniker studierte er Nachrichtentechnik in Offenburg. Seit 1994 arbeitet er kontinuierlich in verschiedenen Branchen und Rollen im Bereich Embedded-\/Real-Time Systementwicklung. 1999 wechselte Thomas Batt zur MicroConsult GmbH. Dort verantwortet er heute als zertifizierter Trainer und Coach die Themenbereiche Systems \/Software Engineering f\u00fcr Embedded-\/Real-Time-Systeme sowie Entwicklungsprozess-Beratung.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Requirements \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Requirements\/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nRequirements Engineering – Anforderungen identifizieren, dokumentieren und verwalten<\/h2>\n
Anforderungen (WAS) von Umsetzung (WIE) trennen<\/h3>\n
Anforderungskontext identifizieren und darstellen<\/h3>\n
Anforderungen textuell erfassen<\/h3>\n
Anforderungstemplates anwenden<\/h3>\n
\n<Objekt und Erg\u00e4nzung des Objektes> <Prozesswort im Infinitiv>.<\/em><\/p>\n
\n<Objekt und Erg\u00e4nzung des Objektes> <Prozesswort im Infinitiv>.<\/em><\/p>\nNat\u00fcrlichsprachliche Methode anwenden<\/h3>\n
Anforderungsqualit\u00e4tsmerkmale definieren und ber\u00fccksichtigen<\/h3>\n
Produkt-, Projekt- und Plattformanforderungen differenzieren<\/h3>\n
\n<\/em>Anforderungen, die Leistungsmerkmale, F\u00e4higkeiten und Eigenschaften des aktuell zu entwickelnden Produktes beschreiben<\/p>\n
\n<\/em>Von der Projektleitung kommende Anforderungen, beispielsweise Zeiten, Kosten, Lieferumfang und Logistik<\/p>\n
\n<\/em>Anforderungen, die f\u00fcr mehrere Produkte bzw. f\u00fcr diese Produktgruppe immer g\u00fcltig sind -> Wiederverwendbarkeit von Anforderungen<\/p>\nFunktional, nichtfunktional und Zusicherung differenzieren<\/h3>\n
\n<\/em>Nach au\u00dfen hin sichtbare \/ beobachtbare Funktionalit\u00e4ten<\/p>\n
\n<\/em>Qualit\u00e4ten, Qualit\u00e4tsmerkmale einzelner funktionaler Anforderungen oder des gesamten Systems<\/p>\n
\n<\/em>Standards, Normen, Prozesse, technische Zusicherungen, Projektanforderungen<\/p>\nQualit\u00e4tsanforderungen definieren und erfassen<\/h3>\n
(Abstrakte) Qualit\u00e4tsmerkmale quantisieren<\/h3>\n
(Abstrakte) Qualit\u00e4tsmerkmale testbar \/ nachweisbar gestalten<\/h3>\n
Aus Standards g\u00fcltige Requirements ableiten<\/h3>\n
Anforderungsglossar als Teil des Projektglossars pflegen<\/h3>\n
Prozess, Vorgehen, Methode<\/h2>\n
Anforderungen auf allen Entwicklungsebenen etablieren<\/h3>\n
Workflows, Aktivit\u00e4ten, Artefakte und Rollen definieren<\/h3>\n
Verst\u00e4ndnis und Commitment zu Anforderungen schaffen<\/h3>\n
Ist-Zustand der bisherigen Produkte analysieren<\/h3>\n
Stakeholder identifizieren und analysieren<\/h3>\n
Stakeholder ausw\u00e4hlen und dokumentieren<\/h3>\n
Stakeholder-Interviews durchf\u00fchren<\/h3>\n
Anforderungen aus Interview-Ergebnissen ableiten<\/h3>\n
Anforderungen mit Auftraggeber \/ Stakeholdern abstimmen<\/h3>\n
Anforderungen analysieren, modellieren<\/strong><\/h3>\n
Anforderungen simulieren, ausf\u00fchren<\/h3>\n
Anforderungsmachbarkeit pr\u00fcfen<\/h3>\n
Prototyp (Wegwerf- oder evolution\u00e4r) erstellen<\/h3>\n
QA: Reviews durchf\u00fchren<\/h3>\n
QA: Funktionalszenarien und Qualit\u00e4tsszenarien ausf\u00fchren<\/h3>\n
Konsistenz zwischen Anforderungen und Umsetzung gew\u00e4hrleisten<\/h3>\n
Abnahmekriterium \/ Test-Case f\u00fcr jede Anforderung entwickeln<\/h3>\n
Kontinuierliches, proaktives Risikomanagement etablieren<\/h3>\n
\u00c4nderungsprozess f\u00fcr Anforderungen etablieren<\/h3>\n
Aus Fehlern lernen<\/h3>\n
Prozess, Vorgehen, Methode und Tooling kontinuierlich verbessern<\/h3>\n
Requirements Management – Anforderungen verwalten, verfolgen und verlinken<\/h2>\n
Anforderungen wiederverwenden<\/h3>\n
Anforderungen parametrieren<\/h3>\n
Anforderungseigenschaften (Properties \/ Attribute) definieren<\/h3>\n
Versionierung von Anforderungen etablieren<\/h3>\n
Baselining \/ Releases f\u00fcr Anforderungen etablieren<\/h3>\n
Bidirektionale Traceability \u00fcber alle Entwicklungsschritte etablieren<\/h3>\n
Templates f\u00fcr Artefakte bereitstellen<\/h3>\n
Requirements Management Tools<\/h2>\n
Text vers. Application\/Product Life Cycle (A\/PLM) Tools evaluieren<\/h3>\n
Tool anforderungsbasierend ausw\u00e4hlen<\/h3>\n
Tool integrieren, testen und schulen<\/h3>\n
Tool in t\u00e4glicher Arbeit etablieren<\/h3>\n
Res\u00fcmee<\/h2>\n
Referenzierte und weiterf\u00fchrende Links<\/h2>\n
\n
\nSOPHIST GmbH, HANSER Verlag, Print-ISBN: 978-3-446-43893-4, E-Book-ISBN: 978-3-446-44313-6<\/p>\nAutor:<\/h2>\n
\nRequirements – MicroConsult Trainings & Coachings<\/h2>\n
\nRequirements – Fachwissen<\/h2>\n