ZA221 - 11 Kriterien die Dein Werkzeug für Anforderungsmanagement erfüllen sollte

02.07.2024 50 Minuten



Zusammenfassung

In dieser Episode des Zukunftsarchitekten Podcasts wird ausführlich besprochen, welche Kriterien bei der Auswahl eines Anforderungsmanagement-Tools entscheidend sind. Ziel ist es, eine fundierte und objektive Auswahl zu treffen, die den spezifischen Bedürfnissen eines Projektes gerecht wird.

Bewertungskriterien für RM-Werkzeuge:

1. Anforderungen editieren:
– Dokumentation und Bearbeitung von Anforderungen, inklusive Attributierung und Anhänge.
– Frei konfigurierbare Metadaten und automatisierte Prozesse zur Verwaltung der Anforderungen.

2. Traceability:
– Aufbau und Verwaltung der Rückverfolgbarkeit von Anforderungen über den gesamten Projektlebenszyklus und ggf. darüber hinaus.
– Verlinkung von Anforderungen mit Tests, Änderungsanträgen und anderen relevanten Projektdokumenten.

3. Kommunikation:
– Unterstützung für E-Mail-Benachrichtigungen und Reviews.
– Flexibel konfigurierbare Workflows, um die Anforderungen an die spezifischen Projektbedürfnisse anzupassen.

4. Konfigurations- und Änderungsmanagement:
– Nachverfolgbarkeit aller Änderungen an Anforderungen.
– Unterstützung für Baselines und die Verwaltung von Änderungen durch Änderungsanträge.

5. Sichtenbildung:
– Möglichkeit zur Filterung und Darstellung von Anforderungen für verschiedene Nutzergruppen.
– Unterstützung für kumulierte Ansichten und Suchfunktionen.

6. Import / Export:
– Funktionen zum Import und Export von Anforderungen aus und in andere Tools, z.B. über Word- oder Excel-Dokumente.
– Unterstützung für Roundtrip-Engineering mit Office-Programmen.

7. Reporting:
– Umfangreiche Berichtsoptionen zur Darstellung des Fortschritts bei der Anforderungsdokumentation und -umsetzung.
– Unterstützung für Release- und Iterationsplanung.

8. Administrative Sicht:
– Benutzerverwaltung, z.B. Integration in Active Directory oder LDAP.
– Unterstützung für Datenmigration und einfache Installation sowie Wartung des Tools.

9. Testmanagement Sicht:
– Erstellung und Verwaltung von Testfällen, deren Parametrisierung und Verknüpfung mit Anforderungen.
– Unterstützung für Test-Sets und die Dokumentation von Testversionen.

10. Lizenzmodell & Kosten & Support:
– Bewertung der Kostenstrukturen, einschließlich Lizenzkosten und jährlicher Wartungsgebühren.
– Betrachtung der Verbreitung und des Supports der Tool-Anbieter.

11. Erweiterte Funktionen:
– Unterstützung für Offline-Bearbeitung und Cloud-basierte Nutzung.
– Integration von Glossaren und speziellen Austauschformaten, wie OSLC oder RIF.

Weiteres Vorgehen:

1. Bewertungsmethodik auswählen:
– Eine geeignete Methodik zur Bewertung der Tools festlegen.

2. Kriterien aufstellen und Bewertungsmetrik festlegen:
– Für jedes Kriterium eine Bewertungsmatrix entwickeln und ggf. Demos der Tools durchführen lassen.

3. Objektiv bewerten:
– Eine fundierte und nachvollziehbare Bewertung der Tools durchführen, um die beste Wahl für das spezifische Projekt zu treffen.

Zusammenfassung:

Vor der Auswahl eines Anforderungsmanagement-Tools sollte eine detaillierte Liste von Kriterien erstellt werden. Es ist wichtig, diese Kriterien objektiv zu bewerten und die Auswahlmethodik sorgfältig zu dokumentieren, um eine fundierte und nachvollziehbare Entscheidung treffen zu können. Dies hilft nicht nur bei der aktuellen Tool-Auswahl, sondern kann auch zukünftige Diskussionen und Überprüfungen unterstützen.

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

Die Bewertungskriterien: Kriterienkatalog in der SE-Online-Bibliothek (Registrierung per Email notwendig)

 

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

 

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA220 - Was ist Dein System? Erkennen, was ist drinnen und was ist draußen

25.06.2024 25 Minuten



Zusammenfassung

In dieser Episode des Zukunftsarchitekten geht es um die Bedeutung einer klaren Systemabgrenzung zu Beginn eines Projekts. Ich erläutere, warum es wichtig ist, mit einer klaren Systemabgrenzung zu starten und wie du dabei vorgehen kannst, um eine akzeptierte Darstellung deines Systems zu erhalten.

Eine Systemabgrenzung hilft dir, Einblicke in die Einbettung deines Systems zu gewinnen und Informationen über externe und interne Systemelemente zu erhalten. Durch die Diskussion über diese Elemente und die Identifizierung von Akteuren, die das System nutzen oder bedienen, könnt ihr im Projektteam ein gemeinsames Verständnis aufbauen und Missverständnisse frühzeitig klären.

Durch die Systemabgrenzung kannst du auch eine Stakeholderliste erstellen und Anwendungsfälle identifizieren, die das System unterstützen soll. Darüber hinaus können vorhandene interne Elemente überprüft werden, ob sie für das aktuelle Projekt wiederverwendet werden können, was Zeit und Ressourcen spart.

Die erlangten Informationen aus der Systemabgrenzung können auch für das Schnittstellenmanagement genutzt werden. Ein gut verwaltetes Schnittstellenmanagement hilft dabei, Probleme bei der Integration des Systems in die reale Umgebung zu vermeiden und die Kommunikation mit externen Systemen zu erleichtern.

Für die Umsetzung einer Systemabgrenzung empfehle ich, leichtgewichtig mit einem Flipchart oder einem Whiteboard zu beginnen und später digitale Tools wie PowerPoint oder Visio zu nutzen. Die kontinuierliche Pflege des Systemkontexts hilft dabei, langfristig einen Mehrwert aus der Arbeit zu generieren.

Zum Abschluss gebe ich drei Tipps: Beginne leichtgewichtig, sorge für ein einheitliches Verständnis im Team und pflege den Systemkontext kontinuierlich. Falls du an Systemkontext-Plakaten interessiert bist, kannst du diese auf meiner Webseite erwerben. Ich danke dir fürs Zuhören und wünsche dir einen hohen Wirkungsgrad bei deinen Projekten. Tschüss und bis zum nächsten Mal beim Zukunftsarchitekten, dem Systems Engineering Podcast.

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

SysML der OMG: https://www.omgsysml.org/

Buch zur Methode CONSENS und ein Anwendungsbeispiel: https://www.systemsengineeringmastermind.de/portfolio-item/einfache-modellierung-der-systemarchitektur-mit-consens/

System-Footprint: https://www.systemsengineeringmastermind.de/portfolio-item/system-footprint/

Systemabgrenzung Plakat: https://www.digistore24.com/product/558269 mit dem Rabatt-Code ZAP220.

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA213 - Richtiges Einordnen von Normenanforderungen

09.01.2024 20 Minuten



Zusammenfassung

Bist du unsicher, wie du Anforderungen aus Normen korrekt kategorisieren sollst? In unserer kommenden Episode tauchen wir tief in dieses Thema ein, um dir Klarheit zu verschaffen!

In dieser Episode wirst du erfahren:

  1. Korrekte Kategorisierung von Normenanforderungen: Wie werden Anforderungen aus Normen richtig eingeordnet? Wir beleuchten beispielsweise, ob die aktive Entladung eines HV-Systems eine Einschränkung ist oder als funktionale Anforderung definiert werden kann.
  2. Aufteilung von Normenanforderungen: Wie weit müssen Normen-Anforderungen aufgeschlüsselt werden, um sie sinnvoll zu handhaben? Wir nehmen dabei spezifische Normen wie LV123 genauer unter die Lupe und diskutieren, ob sie detailliert aufgedröselt oder allgemein nur referenziert werden sollten.
  3. Definition von DTCs auf Systemebene: Brauchst du eine genaue Festlegung von Prioritäten, Verlernzählern usw. bei der Definition von Diagnose-Fehlercodes auf Systemebene? Oder geschieht dies erst auf einer späteren Abstraktionsebene? Wir klären, welche Herangehensweise hier am effektivsten ist.

Verpasse diese Episode nicht, um deine Kenntnisse zu erweitern und deine Herangehensweise an Normenanforderungen zu verbessern!

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA211 - Wie werden Anforderungen in Subsysteme zerlegt?

31.10.2023 28 Minuten



Zusammenfassung

In dieser Episode des Zukunftsarchitekten-Podcasts geht es darum, wie du Anforderungen in Subsysteme aufteilen kannst und welche Vorteile dies für dein Projektmanagement hat. Du wirst verstehen, dass es wichtig ist, die Anforderungen von Kunden und dem Markt zu kennen, um erfolgreich Produkte verkaufen zu können. Neben den Systemanforderungen gibt es auch auf Unternehmensebene spezifische Anforderungen an Software, Elektronik, Elektrik und andere Bereiche. Du musst diese Anforderungen aufteilen, um die Umsetzung durch die entsprechenden Teams zu ermöglichen und Arbeitspakete zu bilden.

Teile die Anforderungen in funktionale Elemente auf, um ihnen bestimmte Funktionen zuzuweisen. Dadurch kannst du die Anforderungen genauer planen und die entsprechenden Attribute und Metadaten festlegen. Eine bewährte Methode ist die Dreiteilung, bei der du die Anforderungen grob und auf einer High-Level-Ebene aufschreibst, dann die Funktionen bestimmst, die mit diesen Anforderungen erfüllt werden müssen, und schließlich eine logische Aufteilung des Systems vornimmst. Nutze den morphologischen Kasten, um verschiedene Möglichkeiten zur Erfüllung der Funktionen zu betrachten und Varianten zu bilden, die später bewertet werden können. Dadurch kannst du die Anforderungen strukturiert aufteilen und besser verfolgen, welche bereits umgesetzt sind und welche noch bewertet werden müssen.

Bei der Architekturbewertung kannst du verschiedene Kriterien wie Preis oder Entwicklungsgeschwindigkeit betrachten. Nachdem du deine Auswahl aus dem morphologischen Kasten getroffen hast, überführst du deine funktionale Architektur in eine logische Architektur und weist dort die einzelnen Elemente zu. Es kann sein, dass beim Einbau der Elemente in das Produkt weitere Anforderungen auftauchen, die zuvor nicht berücksichtigt wurden. Diese Anforderungen werden ebenfalls dokumentiert und den logischen Elementen zugewiesen.

Auf der physikalischen Ebene betrachtest du die mechanischen Bauteile, Elektronik und Software, die auf dem System läuft. Auch Software betrachtest du als physikalisches Element, da sie auf dieser Ebene besser einzuordnen ist und oft ein eigenes Software-Team vorhanden ist. Bei den physikalischen Elementen schaust du zunächst, welche bereits im Unternehmen vorhanden sind und wiederverwendet werden können. Falls dies nicht der Fall ist, guckst du, was mit kleinen Änderungen wiederverwendet werden kann. Im schlimmsten Fall entsteht ein neues Teilprodukt oder eine Bausteinvariante. Im besten Fall kann ein Baustein sowohl im alten als auch im neuen System verwendet werden. Es spart Zeit, vorhandene Bausteine wiederverwendet, solange die Änderungen akzeptabel sind. Es besteht auch die Möglichkeit, Zukaufteile wie Widerstände oder Embedded-Systeme wie Arduino oder Raspberry Pi zu verwenden. Diese müssen jedoch auch Industrie-Tauglichkeit, EMV, etc. erfüllen. Du kannst sie entweder direkt zukaufen oder bei der eigenen Entwicklung oder einem externen Entwicklungsunternehmen beauftragen.

Es entstehen weitere Anforderungen, wenn du physikalische Elemente gestaltest, die deinen logischen und funktionalen Architekturen entsprechen. Zum Beispiel benötigst du für die Erhitzung eines Gartengrills einen Brenner. Die Implementierung eines solchen Brenners erfordert spezifische Schnittstellen wie ein Ventil zum Regulieren des Gaseinlasses. Hier musst du dir überlegen, welche Anforderungen sich aus dem Einsatz dieses Ventils ergeben, wie beispielsweise der Durchmesser und die Anschlussgeometrie. Auch die Luftzufuhr und der Abgasschutz müssen berücksichtigt werden. Indem du dein System dekomponierst und Entscheidungen triffst, kannst du die erforderlichen Anforderungen filtern und ihnen Traceability und Informationen zuordnen.

 

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA202 - Anforderungen für das A-Muster machen wir nicht

17.01.2023 34 Minuten



Zusammenfassung

In regelmäßigen Abstände höre ich in den Entwicklungsprojekten, wie über die Anforderungserhebung diskutiert wird. Und vor allem, wann diese doch scheinbar lästigen Arbeiten durchgeführt werden sollen. Daher möchte ich diese Episode nutzen, um die zu klären, warum Entwicklungsteams glauben, keine Anforderungen für das A-Muster erheben zu müssen? Darauf folgend wird es Konsequenzen für das zu entwickelnde Produkt geben. Welches das sind, beschreibe ich im Mittelteil der Episode.
Um einen reibungslosen Ablauf des Entwicklungsprojekts zu realisieren, gibt es Vorgehen, die ich im letzten Teil beschreibe. Diese sind kein Dogma, aber dennoch gute Ansätze, die in den einschlägigen Standard der Systementwicklung aufgenommen sind.

 

Der Zukunftsarchitekten-Podcast auf den Streaming-Platformen:

–> Google Podcasts

–> Apple Podcasts

–> Amazon Music

–> Spotify

 

Episodenplanung

–> zur Planung der Episoden und Deinem Voting

 

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

 

Du kannst Dir in meinem Online-Kalender gerne einen Termin buchen: https://kalender.bjoernschorre.de

 

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA195 - Erfahrungsbericht - Zwei Erkenntnisse eines Startups mit Lastenheften

17.05.2022 50 Minuten



Zusammenfassung

Dieser Erfahrungsbericht aus der Sicht eines Kunden zeigt auf, wie eine Lastenheft im Projektalltag doch das Leben vereinfachen kann. Rene Meye erläutert, in welchem Umfeld er mit seinem Unternehmen unterwegs ist und wie ihm dort das Lastenheft – welches mithilfe meiner Dienstleistung erstellt wurde – extrem weitergeholfen hat. Er zeigt aber auch auf, wo es evtl. nicht sinnvoll diesen Service zu nutzen. Sei gespannt und höre rein.

Hinweise und Links aus der Episode:

 

Mein Buch ist da: Erfolgreich Lastenhefte schreiben – Eine Schritt-für-Schritt-Anleitung für den Mittelstand

On Air in dieser Episode

avatar
Björn Schorre
avatar
René Meye

ZA193 - 5 Tipps um bessere Anforderungen zu erhalten

19.04.2022 35 Minuten



Zusammenfassung

Diese Episode beschäftigt sich mit Möglichkeiten, gute Anforderungen für Dein Projekt zu erhalten, sodass Du bessere Produkte für den Markt und einzelne Kunden entwickeln kannst und damit weniger Risiko bei der Projektabwicklung hast.

 

Wenn Du Fragen hast oder Anregungen, kannst Du mich gerne über die Emailadresse hoererfrage@zukunftsarchitekten-podcast.de anschreiben.

 

Hinweise und Links aus der Episode:

 

Mein Buch ist da: Erfolgreich Lastenhefte schreiben – Eine Schritt-für-Schritt-Anleitung für den Mittelstand

On Air in dieser Episode

avatar
Björn Schorre

ZA191 - Muss auf ein Lastenheft ein Pflichtenheft folgen?

22.03.2022 42 Minuten



Zusammenfassung

In dieser Episode geht es darum zu klären,

  • Warum ein bewertes Lastenheft kein Pflichtrenheft ersetzt und
  • Warum ein Pflichtenheft und eine System-Architektur sinnvolle Arbeitsergebnisse in der Systementwicklung sind.

 

Wenn Du Fragen hast oder Anregungen, kannst Du mich gerne über die Emailadresse hoererfrage@zukunftsarchitekten-podcast.de anschreiben.

 

Hinweise und Links aus der Episode:

On Air in dieser Episode

avatar
Björn Schorre

ZA175 - Lastenhefte erstellen als Serivce

29.09.2021 31 Minuten



Zusammenfassung

Die Herausforderungen in den Projekte sind vielfältig. Zu kämpfen hat das Team am Ende meistenes mit den Auswirkungen, die ganz zu Anfang eines Projektes getroffen werden – oder eben nicht getroffen wurden.

Das Resultat ist dann, dass das Projekt aus dem Ruder läuft. Immer wieder werden Anforderungen geändert oder neue kommen hinzu.
Die geplante Zeit bis zur Markteinführung wird nicht eingehalten. Gründe hierfür sind, dass die Fertigstellung von Subsystemen verschoben wird. Und zusätzlich kann der Ferigstellungsgrad der Subsysteme nicht kontrolliert werden.
Bei den Integrationen der Subsysteme zu einem Gesamtsystem laufen Test schief. D.h., dass einige Teile der Entwicklungsarbeiten nochmal durchgeführt werden müssen und dadurch auch die Tests wiederholt werden.

Wie Du dagegen angehen kannst, beschreibe ich Dir in dieser Podcast-Episode.

Mein Service hilft Dir dabei, die Anforderungen des Kunden innerhalb von zwei Wochen zu Papier zu bringen: https://lastenhefterstellen.de/vorgehen-lhe

 

Hinweise und Links aus der Episode:

On Air in dieser Episode

avatar
Björn Schorre

Drei Kriterien, um die Qualität eines Lastenheftes sicherzustellen

Wenn ich Projekte begleite, kommt früher oder später folgende Frage auf: „Woran erkenne ich, ob ich mit meinen Requirements fertig bin?“

Es ist immer schwierig, geistige Leistung – und Requirements sind die Ergebnisse geistiger Arbeit – zu bewerten, und gerade bei den eigenen Arbeiten tun wir uns oft schwer.

Die meisten unter uns haben diese Erfahrungen mit selbstgeschriebenen Texten gemacht: Irgendwann sehen wir unsere Fehler einfach nicht mehr. Und leider schleichen sich aus diesem Grund auch schnell Fehler in die Requirements-Dokumente ein.

Damit das nicht passiert, nutze ich in der Praxis drei einfache Checks, die mir enorm weiterhelfen:

1) Testebene

Wenn ich Requirements beschreibe, ist es meine Aufgabe als Systemingenieur, bei jedem Requirement auch für die Testebene eine Empfehlung abzugeben. Fällt es mir schwer, nur eine Ebene anzugeben, und habe ich stattdessen mehrere Möglichkeiten, die ich auswählen kann, ist das Requirement sehr wahrscheinlich nicht gut beschrieben.

Als Konsequenz ändere ich also das Requirement, formuliere es detaillierter, teile es auf, schreibe es um – bis ich sicher nur eine Testebene empfehlen kann. Das hilft gleichzeitig auch dem Testkollegen, denn so kann er seine Tests frühzeitig entwerfen und die Abdeckung nachweisen.

2) Linkabdeckung

Im zweiten Schritt nutze ich den Filter meines Requirements-Management-Werkzeuges und schaue, ob es in meinem Dokument irgendwelche Requirements gibt, die keinen Link zu übergeordneten Anforderungen besitzen. Wenn mir der Filter Einträge dieser Art anzeigt, ziehe ich diese Links nach.

Anschließend prüfe ich mit einem weiteren Filter, ob es übergeordnete Anforderungen gibt, die keinen Link zu meinem Dokument haben. Wenn mir der Filter Einträge dieser Art anzeigt, prüfe ich, ob ich noch etwas in meinem Dokument vergessen habe, und erstelle entsprechende Anforderungen auf meiner Ebene (und verlinke diese natürlich!).

3) Reviews

Ich gebe meine Arbeitsergebnisse regelmäßig anderen Kollegen mit der Bitte, mir mit einem Peer-Review ein kurzes Feedback zu geben. Anschließend arbeite ich die Ergebnisse ein und lade zu einem formalen Review.

In dieser Review-Session übernehme ich alle Auffälligkeiten in ein Review-Protokoll und gewichte gemeinsam mit den Teilnehmern die Schwere der Auffälligkeiten. Wenn ich keine „Major“-Punkte und nicht mehr als zehn „Minor“-Punkte habe, ist die Reife der Requirements nach dem aktuellen Wissensstand gut genug. Ansonsten muss ich die Auffälligkeiten entsprechend korrigieren, bis ich unter meinem Grenzwert liege.

Wo genau Eure Grenzen sind, müsst Ihr in Euren Projekten selbst ausloten – die Requirements zu beschreiben, ist für mich eine sehr gute und ausreichende Hilfe.

Das Ergebnis

Mit dieser Vorgehensweise in drei Schritten habe ich die Möglichkeit, schnell zu erkennen, ob ich mit meinen Ergebnissen wirklich eine hohe Qualität erreiche.

Um diese für ein Lastenheft sicherzustellen und eine klare Aussage dazu treffen zu können, sind also die folgenden Aspekte hilfreich:

  1. Habe ich Schwierigkeiten, mich für eine Testebene zu entscheiden, befinden sich meine Aussagen wahrscheinlich nicht auf der richtigen Testebene und ich muss sie verbessern.
  2. Wenn ich ein Requirements-Management-Werkzeug nutze, kann ich überprüfen, ob alle Anforderungen verlinkt sind.
  3. Indem ich Reviews mit Kollegen durchführe, kann ich sicherstellen, dass ich nichts vergessen habe.