Anforderungsmanagement - anschaulich und praxisnah

Dieses Video gibt einen bildhaften und verständlichen Einstieg ins Anforderungsmanagement. Dazu wird zunächst das fehleranfällige dokumentenbasierte Anforderungsmanagement erläutert und welche Nachteile dieses mit sich bringt. Im Gegensatz dazu wird anschließend das datenbankbasierte Anforderungsmanagement erklärt und dessen zentrale Konzepte verdeutlicht. So wird aufgezeigt, welches enorme Potenzial diese im Gegensatz zum eingangs gezeigten dokumentenbasierten Anforderungsmanagement mitbringen.
Das Video ist der Auftakt zu einer Videoreihe, die anschließend thematisiert, wie die hier gezeigten Konzepte von modernen Anforderungsmanagement-Tool wie Doors umgesetzt werden.

[@andreholtkotte8079]

Sehr verständlich erklärt, top!

[@DigitizedProcesses]

Vielen Dank. Bei Fragen, immer gern raus damit😀

[@Rire_Noir]

super erklärt, echt vielen Dank

[@Hakkalakka]

Super erklärt! 👌Danke sehr!!👍👍👍

[@akoyaemedion]

Sehr zu empfehlendes Video. Es ist noch gar nicht lange her, als viele Unternehmen das Anforderungsmanagement für eher unnötig gehalten haben. Meiner Meinung nach ist Anforderungsmanagement besonders notwendig da: a) Anforderungen nicht statisch sind, sondern sich stetig ändern. b) Es viele Schnittstellen zu anderen Disziplinen gibt (Architektur, Implementierung, Verifikation) die abgestimmt werden müssen. Um ein effektives Anforderungsmanagement zu erreichen ist neben einem modernen datenbankbasierten Tool (wie DOORS NG) eine explizite Festlegung des Datenmodells/Typensystems und der RequirementsManagement-Prozeduren (z.B. die Behandlung von "Obsolete" Requirements, das Review von geänderten Requirements oder das Erstellen von Baselines) erforderlich.

[@DigitizedProcesses]

Dem ist nichts hinzuzufügen👍 Ich habe vor, noch einige von den Themen, die du angesprochen hast, in folgenden Videos zu vertiefen. Danke für deine Kommentare.

[@IdlewiseYTTest]

@6:38 Ich habe grosse Probleme damit, wie Sie die Zusammenführung zweier Anforderungen höherer Ebene zu einer einzigen niedrigeren Ebene darstellen. Eine Anforderung beschreibt ein „Problem“: Hier werden zwei Probleme zu einem kombiniert. Was soll das bringen? Zum einen wird es schwierig zu testen sein! Wenn nun die beiden Anforderungen dasselbe Problem beschreiben, bedeutet dies, dass die Aufteilung auf der Ebene darüber falsch ist und die Aufteilung dort erfolgen sollte, und so weiter. Sie sollten NIEMALS zwei Anforderungen zusammenführen, da dies die Hierarchie und Herkunft zerstört, insbesondere wenn wir uns mit Varianten- und Konfigurationsmanagement, Versionierung, Änderungssätzen usw. befassen.

[@accountname1651]

Wie stehen denn die Anforderungen in Beziehung zueinander? Wie kommen die einzelnen Mitarbeiter denn zu den Informationen, dass sie relevant sind für den Motor?

[@DigitizedProcesses]

Die Anforderungen sind miteinander verlinkt. Egal welche Anforderung man sich ansieht, man sieht auch die jenigen Anforderungen, die die Grundlage für die betrachtete Anforderung sind und die Anforderungen die auf Grund der betrachteten Anforderung abgeleitet worden . Desweiteren wird jede Anforderung auch mit dem entsprechenden System (Baugruppe, Teil etc.) verlinkt. Man kann sich daher auch alle Anforderungen anzeigen lassen, die mit einer Baugruppe oder eben dem Motor verlinkt sind. In folgenden dem Video habe ich das an einem Beispiel verdeutlicht: kzbin.info/www/bejne/f6LWcoSLhq-afMk

[@JL-ci8zv]

Wie sinnvoll wäre es im Anforderungsmanagement, die Anforderungen in jeweilige Klassen/ Unterkategorien einzuteilen?

[@DigitizedProcesses]

Sehr sinnvoll. Gerade wenn man bedenkt, das große Projekte schnell eine vierstellige Anzahl von Anforderungen haben. So kann man Sie nach Fachbereichen unterteilen oder jenachdem wie einfach bzw. schwierig die Anforderungen unsetzbar sind, man kann sie preorisieren oder auch die Unterteilung in funktionale und nicht-funktionale Anforderungen ist üblich.

[@JL-ci8zv]

@@DigitizedProcesses Vielen Dank für die Antwort! Gibt es grundsätzliche Kriterien, anhand derer beurteilt werden kann, ob eine bestimmte Unterteilung der Anforderungen sinnvoll ist? Oder ist dies eher von Anwendungsfall zu Anwendungsfall unterschiedlich?

[@DigitizedProcesses]

Naja ich würde sagen: so wenige wie möglich und so viele wie nötig. Ich unter teile meist in Kundenanforderungen, interne Anforderungen und Anforderungen für das Pflichtenheft. Ich würde für jede dieser Anforderungen eine Verantwortliche Stelle aus der Projektorganisation zuweisen, ein System/Baugruppe aus dem Systemaufbruch zuweisen und einen Testfall zuweisen. Jeder Kundenanforderung würde ich zusätzlich eine Compliance zuweisen. Alles Weitere ist Anwendungsbezogen, um beispielsweise seine Prozesse umsetzen und überwachen zu können. Wenn du detaillierte Fragen hast, können wir gern telefonieren.

[@hajoist]

Machen die Änderungen nicht das Änderungsmanagement?

[@DigitizedProcesses]

Vielen Dank für die interessante Frage. Mit Änderungsmanagement bzw. Changemanagement werden in der Regel zwei Dinge bezeichnet: 1. Das Überführen eines Unternehmensteils in veränderte Prozesse/Technologien (z.B.: Vorbehalte der Belegschaft gegen ein neu eingeführtes ERP-System abbauen etc.) 2. Der Umgang mit Änderungen und dessen Auswirkungen auf andere Artefakte in einem Projekt (z.B.: geänderte Kundenanforderung, Norm, Technischer Zeichnung, Kosten usw.) Deine Frage zielt auf Zweiteres ab. In diesem Bezug ist Änderungsmanagement eine quschnittliche Disziplin wie z.B. Konfigurationsmanagement. Sprich: Egal ob man Projekt-, Anforderungs-, Design-, Qualitätsmanagement usw. betrachtet. Alle müssen mit solchen Änderungen umgehen können. Bei der einen Disziplin mit Änderungen an CAD-Modellen, bei den anderen mit Änderungen an einem Projektplan, einem Testplan oder eben der Änderung an einer Anforderung - eben entlang des gesamten Produktlebenszykluses (PLZ) Da die Anforderungen aber ganz zu Beginn des PLZ stehen, spielt das Anforderungsmanagement im Umgang mit Änderungen eine besondere Rolle. Schließlich sollten ausgehend von den Anforderungen alle Artefakte der anderen Disziplinen verlinkt sein. Sprich an den Anforderungen hängen Systemkomponenten und Tests, an diesen hängen Arbeitspakete, Bestellungen, Arbeitspläne, Stücklisten etc. Oder anders gesagt, egal was sich ändert - Anforderungen sind meistens direkt oder indirekt davon betroffen. Ich hoffe, das war verständlich. Ansonsten einfach Fragen (-: Beste Grüße, Robert.

[@hajoist]

@@DigitizedProcesses danke für die ausführliche Antwort! :)

[@DigitizedProcesses]

Immer gern. Wenn du zufrieden bist, lass gern ein Abo da (-:

[@hajoist]

@@DigitizedProcesses mach ich doch glatt :) Vielen dank für die Mühe der Antwort. Ich weiß das zu schätzen!

[@DigitizedProcesses]

Vielen Dank (-: