Diskussion:Anforderungsmanagement

Definition fehlt

Es steht geschrieben "Diese Definition trägt den Erkenntnissen aus der Vergangenheit Rechnung [...]." in Absatz 3 von Haupt-Absatz 1. Dvor steht aber nur eine Eingliederung, nicht aber eine Definition. Es müsste stehen (BSP): "Anforderungsmanagment ist die Tätigkeit eines Unternehmers, Anforderungen eines vom Kunden nachgefragten Produkts auf seine [???] zu prüfen.", wobei an [???] das Wissensobjekt treten würde, das ihr hier zu referenzieren vergessen habt. (nicht signierter Beitrag von 94.221.81.127 (Diskussion) 11:19, 25. Dez. 2012 (CET))

Anforderungsmanagement in der Praxis

In der Praxis wird heute ein Anforderungsmanagement so eingesetzt, dass es ein Pflichtenheft praktisch ersetzt. Vom Auftraggeber gibt es weiterhin ein Lastenheft, das der Auftragnehmer und Entwickler umsetzt, jetzt statt in ein Pflichtenheft in einen Satz von Einzel-Anforderungen. Wie beim Lastenheft-Pflichtenheft-Mechanismus muss diese Formulierung der Anforderungen vom Auftraggeber abgenommen werden, bevor die eigentliche Entwicklungsarbeit startet. Die Überwachung des Fortgangs erfolgt individuell für die einzelnen Anforderungen. Der Unterschied zum hergebrachten Lastenheft-Pflichtenheft-Mechanismus besteht vor allem darin, dass Anforderungen tendenziell in kleinere Einheiten aufgespalten werden, so dass eine Tendenz zum „Mikromanagement“ entsteht.

Ich möchte nicht gleich sagen dass es falsch ist, aber auf jeden Fall unsauber formuliert. Anforderungsmanagement ist ein Prozess und kein Enddokument. Pflichtetheft, oder wie man es nennt, ist in der Regel ein vertragliches Dokument, mit mehr als nur den fachlichen Anforderungen. Anforderungsmanagement kann und wird sowohl vor/ wie auch nach der Ausschreibung durchgeführt, manchmal durch einen dritten Partner. Den Satz über die Tendenz zum Mikromanagement verstehe ich nicht.-- Avron 16:28, 26. Jul. 2008 (CEST)

Ich gehe einen Schritt weiter: Der Satz ist falsch. Erstens mag das eine "Privatmeinung" sein, für die kein Beleg erbracht wurde. Zudem widerspricht sich der Satz eigentlich selbst. Und schließlich ist es egal, wie die Detailspezifikation benamst wird. Den generellen Anspruch, den der Satz erhebt, kann er obendrein nicht im geringsten erfüllen. Mag sein, dass die beschriebene Methodik dort oder da mal angewandt worden ist (Beispiele Fehlen), aber "gängige Praxis" ist das definitiv nicht. -- ~ğħŵ ₫ 20:15, 27. Jul. 2008 (CEST)

Hab die schon etwas angepasste Version gelöscht. Für eine gängige Praxis im Anforderungsmanagement kann es wohl keine Quelle geben... dementsprechend hat es allerdings auch nichts im Artikel verloren.--Ma-Lik ? +/- 22:39, 27. Jul. 2008 (CEST)

Also das war ein Versuch der Schilderung, wie ich es auf der Arbeit bei einem großen Automobilzulieferer erlebt habe. Teilweise arbeiten die noch mit Lastenheft/Pflichtenheft, in anderen Bereichen wird auf Lastenheft/Requirements umgestellt. Das ist dort Praxis, aber wohl nicht öffentlich zitierbar, eine schriftliche Quelle muss ich schuldig bleiben. Man arbeitet dabei mit der Datenbank DOORS (siehe Telelogic). Die Sache mit dem "Mikromanagement" betrifft eine dort ständig lauernde Streitfrage, wie detailliert die Requirements heruntergebrochen werden. Wenn sie zu kleinteilig formuliert werden, wird das "Mikromanagement" (als Vorwurf) genannt, wird es zu allgemein formuliert, kommt es zum Vorwurf Schwammigkeit. --PeterFrankfurt 02:08, 2. Aug. 2008 (CEST)

Ich kann dem zustimmen: Requirements (in welchem Format auch immer) ersetzen zunehmend klassische Lasten- und Pflichtenhefte (Idealbild ist eine durchgängige Anforderungsmodellierung angefangen bei den strategischen Unternehmenszielen bis hinunter auf die Detailanforderungen; insbesondere im Automotive-Sektor). Das diese Strategie gängige Praxis ist, dürfte niemand in Frage stellen, der in dem Bereich unterwegs ist.

Zum Thema Wording: man sollte viellecht besser von Requirements-Baselines sprechen, welche die Pflichtenhefte ersetzen. Damit ist klar, dass ein definierter Datenstand gemeint ist. Ob es sich um einen DOORS-Export, eine RIF-Datei oder ein Word-Dokument handelt, ist damit letztendlich egal.

Zur Erklärung von "Mikromanagement": das Risiko beim AM ist, dass zu detaillierte Anforderungen entstehen. Damit entsteht gewaltiger Overhead in der Verwaltung der Detailanforderungen. Die große Kunst des AM ist den richtigen Detaillierungsgrad zu finden! Zu grobe Requirements sind meist lückenhaft, zu detaillierte Requirements erzeuge Overhead und bergen das Risiko, Umsetzungsdetails implizit vorwegzunehmen. --Prjmgr72 21:17, 20. Jan. 2009 (CET)

Ich finde hier werden verschiedene Dinge miteinander verwechselt. Anforderungsmanagement ist ein Prozese wie man zu Anforderungen kommt. Anforderungsmanagement-Tools helfen dabei. Lasten-/Pflichtenheft ist Laut DIN ein Vorgehen, wie Ausschreibungen im Idealfall laufen sollten. Im englischen kommt man mit diesen Begriffen nicht klar. Da der Softwaresektor aber englischsprachich geprägt ist, führt das immer wieder zu missverständnissen. Die Frage ist vielmehr was unter "klassische bzw. moderne Lasten- und Pflichtenhefte" zu verstehen ist?

Dem Mikromanagement stimme ich zu.-- Avron 22:09, 20. Jan. 2009 (CET)

Jetzt wird es akademisch, aber offenbar scheint das Verständnis der Materie hier tatsächlich nicht weit gediegen zu sein.

Anforderungsmanagement ist kein Prozess; die Anforderungserhebung ist der Prozess/die Methodik, um Anforderungen zu gewinnen. Anforderungsmanagement ist die Verwaltung der Anforderungen im Rahmen des Engineering-Prozesses (vielleicht hätte wirklich mal jemand den Text meines Weblinks lesen sollen, anstatt ihn von vornherein wegen angeblich zu großer Logo-Dimensionen zu disqualifizieren).

Lasten- und Pflichtenhefte sind zudem kein Vorgehen, sondern Artefakte. Das Vorgehen besteht bestenfalls darin, zu definierten Zeitpunkten entsprechende Dokumente zu erstellen. Und das Lasten-/Pflichtenhefte im Bereich des Softwaresektors etwas unklar sind, liegt daran, dass bei der SW-Entwicklung oft andere Methodiken und Artefakte eingesetzt werden. Allerdings geht es hier konkret ja auch um Systems Engineering, nicht Software Engineering.

Also nochmal zum Mitdenken: es gibt einen Engineering-Prozess gepaart mit einem Vorgehen. Dieser Prozess erzeugt Artefakte (in unserem Fall Lasten- & Pflichtenheft). Diese Artefakte dienen als Grundlage für weitere Prozesse.

Was sich nun ändert ist, dass anstelle der Artefakte Lasten-/Pflichtenhefte mit Requirements-Baselines gearbeitet wird. Vorteil: Traceability und Konsistenz entlang des gesamten Prozesses, sowie automatische Gap-Analyse.

Ich hoffe, ihr erspart mir, auch noch eine Einführung in das RM im Softwareengineering geben zu müssen... --Prjmgr72 22:46, 20. Jan. 2009 (CET)

...aber offenbar scheint das Verständnis der Materie hier tatsächlich nicht weit gediegen zu sein und Ich hoffe, ihr erspart mir, auch noch eine Einführung in das RM im Softwareengineering geben zu müssen. Für einen "Neuling" hast du ganz schön viel Selbstvertrauen. Anderseits können man das als Überheblichkeit auslegen. Deswegen rate ich dir einen anderen Diskussionstil zu benutzen. Gerade das Thema Anforderungsmanagement ist so vielschichtig, da postulieren viele Beteiligten gerne ihre eigenen Weissheiten. Eine "Wahrheit" in diesem Thema gibt es nicht.

Lastenheft und Pflichtenheft sind Artefakte. Jedoch werden die beiden Dokumente nicht einfach so, sondern im Verbund eingesetzt. Das Lastenheft erstellt der Auftraggeben, das Pflichtenheft der Auftragnehmer. Soviel zu Theorie der DIN. Ich weiß, in der Praxis läut es oft anders.

Ich war allerdings nicht ganz korrekt. Anforderungsmanagement bedeutet natürlich nicht nur die Anforderungserhebung. Management bedeutet "Führung". So ist auch die Aufgabe des Anforderungsmanagement die aufgenemmenen Anforderungen auf Sinnhaftigkeit, Effizienz und Durchführbarkeit auf Grund endlicher Ressourcen zu prüfen.--Avron 08:37, 21. Jan. 2009 (CET)

Wieso verweist das "Änderungsmanagement" auf das "Veränderungsmanagement". Das sind m.E. nach zwei verschiedene Dinge.

Abschnitt "Anwendung"

Hallo,

m.E. bezieht sich der Absatz "Anwendung" auf die Anforderungen selbst, nicht das Anforderungs-Management. Der Absatz sollte daher raus, statt dessen nochmal ein Verweis auf Anforderungserhebung, wo die Qualitätskriterien an Anforderungen detalliert aufgeführt sind.

Was meint Ihr? --Prjmgr72 09:52, 15. Jan. 2009 (CET)

Die Überschrift ist auf jeden Fall verwirrend. Wahrscheinlich ist es in Anforderungserhebung besser aufgehoben.-- Avron 21:23, 21. Jan. 2009 (CET)

Warum meine Bearbeitung entfernt?

Hallo Jpp,

Du hast eine Bearbeitung von mir (ein Link auf ein Whitepaper/Übersichtsartikel RE, RM, ALM) gelöscht -- was passt Dir an dem Link nicht?

Es handelt sich dabei um einen guten, knapppen Übersichtsartikel, in dem die Themen RE, RM und ALM kurz dargestellt und abgegrenzt werden. Aus meiner Sicht extrem hilfreich; in der Projektpraxis trifft man ständig auf Begriffschaos und Konfusionen. Noch schlimmer wird es, wenn man mit Marketing/Sales irgendwelcher Toolhersteller zu tun bekommt...

Ich musste auch schon in Projekten darunter leiden, dass die Themen alle in einen Topf geworfen wurden. --Prjmgr72 08:06, 17. Jan. 2009 (CET)

Der Link ist etwas dünn für so große Werbelogos...-- Avron 10:32, 17. Jan. 2009 (CET)

Wie ich schon in meinem Bearbeitungskommentar schrieb: Die verlinkte Seite sieht für mich so aus als solle sie primär das publizierende Unternehmen bekannt machen. Der Inhalt ist eher banal. Wenn du die Begriffe besser voneinander abgrenzen möchtest, warum beteiligst du dich nicht an der Verbesserung des Inhalts unserer Artikel, statt nur lieblos einen Link hinein zu klatschen? --j ?! 16:25, 18. Jan. 2009 (CET)

Wie groß dürfen denn Firmelogos maximal sein? :-D

Was die Verbesserung des Inhaltes angeht, versuche ich es ja; aber offenbar scheint es hier wichtiger zu sein, potentielle Werbung zu verhindern, als an der Ausgestaltung des Artikels zu arbeiten (siehe beispielsweise 'Abschnitt "Anwendung"').

Vermutlich habe ich ich das Wiki-Prinzip einfach noch nicht ganz verinnerlicht; es ist also okay, einfach Beiträge anderer nach eigenem Ermessen zu löschen... Das macht die Sache natürlich deutlich entspannter... --Prjmgr72 15:49, 19. Jan. 2009 (CET)

Was genau ist jetzt dein Problem? Dein inhaltlicher Beitrag steht doch noch drin. --j ?! 20:27, 19. Jan. 2009 (CET)

Wie denn jetzt? Ich dachte, meine Beiträge beschränken sich auf "lieblos hineingeklatschte Links", die dann offenbar liebevoll von - wie es aussieht - selbsternannten Experten entfernt werden müssen. --Prjmgr72 20:48, 20. Jan. 2009 (CET)

Am 18. Januar hatte ich noch nicht bemerkt, dass du neben dem Link auch inhaltlich beigetragen hattest, weil das in zwei unterschiedlichen Bearbeitungen passierte. Sorry dafür. Es bleibt aber die Frage offen, in welchen Punkten die von dir verlinkte Webseite über den Artikel hinausgeht. --j ?! 17:13, 23. Jan. 2009 (CET)

Abgrenzung Produktmanagement

Wie ist Anforderungsmanagement in der Produktentwicklung einzugliedern. Ich sehe hier Berührungspunkte bzw. Überschneidungen zum Produktmanagement. Könnte man diese Begriffe voneinander abgrenzen. Was ist Aufgabe des Produktmanagements, was ist Aufgabe des Anforderungsmanagements und wo sind die Schnittstellen zwischen den beiden? Oder habe ich da etwas grundlegend falsch verstanden? --Silverchecker301 15:57, 13. Jan. 2012 (CET)

Das Anforderungsmanagement geht zum größten Teil dem Projektmanagement voraus, es findet vorwiegend in der Vorbereitungsphase statt, muss aber natürlich in der Realität ggf. später noch diverse Nachanpassungen und Nachbesserungen durchlaufen. Im Idealfall sollte es abgeschlossen sein, wenn dadurch die benötigten Ressourcen eindeutig klar sind und das Projektmanangement diese allokieren und überwachen kann. In der Realität läuft es dann aber parallel weiter mit. - Da könnte man auch im Artikel etwas erwähnen (das Wort Projekt kommt ja erst zur Artikelhälfte in einem Nebensatz vor, hui). Und bei PM entsprechend was zum RM. --PeterFrankfurt 02:03, 14. Jan. 2012 (CET)

Gut, das ist aber eher die Abgrenzung zum Projektmanagement, nicht zum Produktmanagement. Wo ist die Trennlinie zwischen Produktmanagement und Anforderungsmanagement. Meine Interpretation ist: Produktmanagement ist Marktanalyse, Konzeption, Marketeinführung, Marketing, Vertrieb. Anforderungsmanagement ist Erhebung und Verfolgung von Anforderungen. Hier sehe ich eine Überschneidung: Die Konzeption (Produktmanagement) und die Erhebung (Anforderungsmanagement) sind für mich fast deckungsgleich. --Silverchecker301 14:13, 16. Mar. 2012 (CET)

Das kann man aber auch anders sehen: In diesen Teilschritten des Produktmanagements fehlt bei Dir ja die komplette Produktion, incl. ihrer Vorbereitungsphase, die eben (nach der Marktanalyse) die Anforderungen formuliert, die dann in einen Entwicklungsprozess münden, der im Rahmen des PM überwacht wird und schließlich in die ihrerseits zu überwachende Produktion des abgesegneten Produkts mündet. Demnach wäre das Anforderungsmanagement eher als einer von vielen Teilschritten im Rahmen des Produktmanagements zu betrachten. --PeterFrankfurt (Diskussion) 01:50, 17. Mär. 2012 (CET)

Das Produktmanagement formuliert die Anforderungen, die im Anforderugnsmanagement verwaltet werden. Yotwen (Diskussion) 16:41, 17. Mär. 2012 (CET)

Das kenne ich aber ganz anders. Wo ich zuletzt (als Leihkraft bei einem großen Automobilzulieferer) gearbeitet habe, gab es für das Anforderungsmanagement eine eigene Abteilung, die direkt und selbstständig nach dem Lastenheft des Auftraggebers (plus ggf. in direktem Kontakt mit diesem) arbeitete. Das Produktmanagement bot dazu nur den rein organisatorischen Rahmen, gab aber keinerlei Anweisungen in der Sache. - Aber solche Praxisdetails können natürlich von Firma zu Firma differieren. --PeterFrankfurt (Diskussion) 02:21, 18. Mär. 2012 (CET)

Jetzt verstehe ich nicht, wo der Unterschied sein soll. Das Produktmanagement soll doch das Produkt managen: Marktauftritt, Segment, Zielsetzungen usw. Daraus resultieren Anforderungen, sagen wir mal "Mehr PS/Watt verbrauchter Energie", "schlanker, länger, breiter", ... Diese Anforderungen sind Teilziele des Produktmanagements. Je nach Grösse verwalte ich diese Anforderungen im PM oder im Anforderungsmanagement - Die Aufgabe bleibt aber Anforderungsmanagement. Die Kunst ist üblicherweise, die Balance zwischen beiden Aufgaben zu treffen - Wer hauptsächlich in AM abrutscht verliert seine Vision und wer zu viel PM macht erreicht nichts - Hier ist nicht mehr gleich besser, sondern die Balance unterscheidet Gewinner von Verlierern. Yotwen (Diskussion) 10:47, 18. Mär. 2012 (CET)

Wie gesagt, das war eine eigene Abteilung, die sich auf das AM konzentrierte. Das übergeordnete PM (ganz andere Leute) hielt sich da im Tagesgeschäft raus. - Und wie gesagt, das kann sich gut von Kanton zu Kanton unterscheiden, und wir dürfen nicht eine einzelne von vielen existierenden Implementierungen fälschlicherweise wie die einzig existierende oder einzig wahre präsentieren. --01:50, 19. Mär. 2012 (CET)

Das ist doch alles eine Frage was man als "Projekt" definiert. In manchen Unternehmensteilen z. B. Entwicklungsabteilungen ist das Anforderungsmanagement tägliches Geschäft und kann über den üblichen Geschäftsprozess innerhalb des Produktmanagements abgewickelt werden. Ein Projekt ist der Definition nach etwas Einmaliges. An sich unterscheidet sich das Anforderungsmangement in der Linie wohl nicht vom AM in Projekt.--Avron (Diskussion) 09:06, 19. Mär. 2012 (CET)

Abgrenzung Anforderungsmanagement VS Requirement Engineering

Moin, nach mehrtägiger Recherche in div. Lit, bin ich zu dem Punkt gekommen dass das Anforderungsmanagement eigentlich für den Teilprozess der Anforderungsverwaltung steht. Also nach(!) der Anforderungserhebung und -dokumentation steht. Meiner Meinung nach, sogar erst nach vollständiger Spezifikation der jeweiligen Anforderung (vgl Rupp 2009: Detailierungslevel). Gerade im vergl. zur engl.sprachigen Literatur wird das Req.Man. als (letzter) Teilprozess des Req.Eng. verstanden. Die Begrifflichkeit Anf.Man. auch zur Übersetzung von Req.Eng. zu verwenden, halte ich für ein Kuckucksei, dass uns noch lange Zeit verfolgen wird indem es Missverständnisse erzeugt. Gibts hierzu gegeläufige oder beständigende Meinungen? PS. Ich komme eigentlich aus dem Bereicht benutzerzentrierter Softwareentwicklung und setzte mich seit mehrern Woche mit Req.Eng. im Zusammenhang mit neuen beruflichen Aufgaben auseinander --Albin (Diskussion) 14:32, 13. Aug. 2014 (CEST)

Da es scheinbar keine weiteren Meinungen zu gibt, würde ich die entsprechenden Abschnitte demnächst bearbeiten. Insgesamt würde ich für "Requirement Engineering" den deutschen Begriff "Anforderungsentwicklung" verwenden, auch wenn ich damit nicht ganz zufrieden bin (Engineering ist ja doch was anderes). Aber die sonst typischen Begriffe wie Anforderungsdesign, -konstruktion oder -gestaltung wecken meiner Meinung nach die falschen Assoziationen. --Albin (Diskussion) 09:37, 19. Aug. 2014 (CEST)

Requirements-Management ist definitiv Teil von Requirements-Engineering (RE). Das umfassende IREB Handbuch "CPRE Advanced Level Requirements Management - Handbook" (siehe Referenzen oder https://www.ireb.org/en/downloads/#cpre-advanced-level-requirements-management-handbook) schreibt "Wir definieren RM als Teil des RE. RE ist also umfassender." Anforderungsentwicklung finde ich auch gut.--LS (Diskussion) 14:04, 16. Aug. 2019 (CEST)

Abschnitt Zertifizierungen, Konferenzen, Journale etc.?

Ich denke diese Themen könnten die Seite bereichern. Ich kenne einiges dazu und könnte beitragen...--LS (Diskussion) 14:13, 16. Aug. 2019 (CEST)