„Das ist nicht nur möglich, sondern macht an vielen Stellen auch Sinn. So kann der funktionale Anteil einer Anforderung unter Einhaltung eines qualitativen Attributs (formuliert als nicht-funktionaler Anteil der Anforderung) spezifiziert sein. Im Seminar hatten wir das am Beispiel einer Interaktion des Benutzers mit der Bedienschnittstelle gelernt, wo beim Betätigen eines Bedienelements (z.B. auf dem Touchscreen) das System responsiv innerhalb eines spezifizierten Latenzzeit-Intervalls reagiert, innerhalb dessen die eingeforderte Funktion ausgeliefert werden soll.“

„Das RE wird gemeinhin als Bestandteil des SE gesehen. Historisch kommen beide Disziplinen aus dem Bereich der Systemanalyse. Das SE hat vor allem auch einen Schwerpunkt auf der Systemarchitektur sowie der Verifizierung und Validierung (V&V). Im Seminar haben wir gesehen, dass diese Disziplinen (und andere Methoden wie z. B. das Risikomanagement) vorteilhaft miteinander verbunden werden können.“

„Die Begriffe „Lastenheft“ (LH) und „Pflichtenheft“ (PH) werden im Kontext des Systems- bzw. Requirements-Engineering nicht mehr so häufig verwendet. Das LH spezifiziert die Kundenanforderungen an das Produkt bzw. das System. Die Bestandteile des PH verweisen auf das LH, allerdings geschieht hier bereits der Kontextwechsel von der Kundensicht zur Entwicklungssicht. Somit entspricht das PH eher der Technischen (System-)Spezifikation, die idealerweise auch die passende Systemarchitektur beinhalten sollte.“

„Anhand der Formulierung sind Requirements und Constraints schwer voneinander zu trennen, aber diese beiden Aspekte machen den Unterschied klarer:

• Constraints beschreiben bevorzugt Gegebenheiten im Lösungsraum, während (gute) Requirements lösungsfrei verfasst werden
• Constraints fallen oft „vom Himmel“ – das heißt, es gibt keine darüber gelagerten Anforderungen, aus dem die Constraints sinnvoll abgeleitet werden könnten.“
• Constraints an den „richtigen Stellen“ (und dort entsprechend gekennzeichnet) können aber auch ungewollte Freiheitsgrade einschränken – und somit den Entwicklungsablauf bis zur Design-Phase verkürzen

„Ein kleiner Widerspruch in sich. Idealerweise beinhaltet jede Anforderung bereits alle zur weiteren Verarbeitung (Verfeinerung, Übergang zum Design) benötigten „harten“ Informationen „in sich“ (intrinsisch).
Es kann hier und dort hilfreich sein, eine „weiche“ begleitende Erklärung oder eine Referenz zu externen Dokumenten beizustellen. Dann ist es in der Praxis sinnvoll, dieses informelle Element per Attribut nicht als „Requirement“ sondern z.B. als „Info“ zu kennzeichnen. Entsprechendes gilt auch für Überschriften von Abschnitten (Gliederung), die als „Heading“ ausgezeichnet werden – und helfen können, einen Kontext zwischen Anforderungen zu geben.
Die gängigen ALM-Werkzeuge bieten solche Attribute in der Regel an bzw. lassen sich anwenderspezifisch definieren.“

„Mit einem Anwendungsfall (Use Case) beschreibt man Interaktionen von (rollenbasierten) Aktoren mit grob dargestellten Aktionen im Kontext einer Nutzung (Szenario) des Produkts oder Systems. Damit eignet sich der Use Case (dargestellt im zugehörigen Diagramm) zur Findung und Ausarbeitung von Nutzerbedürfnissen und in weiterer Verfeinerung auch zur Erstellung von Kundenanforderungen. Aufgrund der übersichtlichen und intuitiven Notation lassen sich Anwendungsfalldiagramme schnell am Whiteboard erstellen und ändern – und helfen als Tool zur Unterstützung der Kommunikation zwischen den Stakeholdern.“

„Die SysML ist ein interdisziplinäres Sprachkonzept bzw. eine Notation, mit dessen Hilfe eine Systemarchitektur modelliert und visualisiert werden kann. Sie entstammt der UML, die seit den 1990er Jahren den de facto Standard bei der Modellierung von Software darstellt. Dabei verallgemeinert die SysML die UML, indem der „Block“ als universeller Grundbaustein definiert wird, mit dem sowohl Strukturen als auch Verhaltensweisen darstellbar sind.
Als zusätzliches Modell-Element existiert in der SysML das „Requirement“ – und gerade dieser Umstand macht den Einsatz der SysML im gesamten Spektrum des Model Based Systems Engineering (MBSE) so interessant. Auch spannend: Die an sich nebenläufige Verfeinerung von Systemarchitektur und Anforderungsspezifikation entspricht im Ablauf eher einem Zickzack-Muster. In meinem Seminar lernen Sie – anhand von hands-on Beispielen – wie sich so etwas in der Praxis „anfühlt“.“ Für das Jahr 2025 steht eine grundlegend aktualisierte Version der SysML – die SysML v2 – an. Hier wurden eine ganze Reihe von Konzepten im Vergleich zur v1 „glattgezogen“ sowie eine vollständige Syntax als Alternative zur rein visuellen Repräsentation als natürlicher Bestandteil dieser Sprache ergänzt. Alle gängigen Hersteller – und wohl auch neue Player – auf dem Markt der ALM- und Modellierungswerkzeuge stellen sich „hinter den Kulissen“ bereits auf diese Innovation um: Mit SysML v2 wird das MBSE-Paradigma mit Sicherheit auch im MedDev- / IVD-Entwicklungsumfeld unverzichtbar sein!