Requirements engineering – Wikipedia auf Deutsch

Dieser Artikel oder Abschnitt enthält eine enge Paraphrasierung einer oder mehrerer nicht freier, urheberrechtlich geschützter Quellen. Eine entsprechende Diskussion finden Sie auf der Diskussionsseite. Bitte verbessern Sie diesen Artikel, indem Sie ihn mit Ihren eigenen Worten neu schreiben. (September 2020) (Erfahren Sie, wie und wann Sie diese Vorlagennachricht entfernen können)

Anforderungsengineering (BETREFF) ist der Prozess der Definition, Dokumentation und Pflege von Anforderungen im Konstruktionsprozess. Dies ist eine häufige Rolle im System- und Software-Engineering.

Die erste Verwendung des Begriffs Anforderungsengineering wurde vermutlich 1964 im Konferenzpapier „Maintenance, Maintainability, and System Requirements Engineering“ erwähnt, gelangte jedoch erst Ende der 1990er Jahre mit der Veröffentlichung eines Tutorials der IEEE Computer Society im März 1997 und der Gründung einer Konferenzreihe zur allgemeinen Verwendung zum Thema Anforderungstechnik, die sich zur Internationalen Anforderungstechnik-Konferenz entwickelt hat.

Im Wasserfallmodell wird das Requirements Engineering als erste Phase des Entwicklungsprozesses dargestellt. Spätere Entwicklungsmethoden, einschließlich des Rational Unified Process (RUP) für Software, gehen davon aus, dass die Anforderungsentwicklung über die gesamte Lebensdauer eines Systems fortgesetzt wird.

Das Anforderungsmanagement, eine Unterfunktion der Systems Engineering-Praktiken, ist auch in den Handbüchern des International Council on Systems Engineering (INCOSE) aufgeführt.

Aktivitäten

Die an der Anforderungsentwicklung beteiligten Aktivitäten variieren stark, abhängig von der Art des zu entwickelnden Systems und den spezifischen Praktiken der Organisation. Dazu können gehören:

1. Anforderungserstellung oder Anforderungsermittlung – Entwickler und Stakeholder treffen sich; Letztere werden nach ihren Bedürfnissen und Wünschen bezüglich des Softwareprodukts befragt.
2. Anforderungsanalyse und -verhandlung – Anforderungen werden identifiziert (einschließlich neuer, wenn die Entwicklung iterativ ist) und Konflikte mit Stakeholdern werden gelöst. Als Hilfsmittel werden sowohl schriftliche als auch grafische Hilfsmittel (letztere werden häufig in der Entwurfsphase verwendet, manche finden sie aber auch in dieser Phase hilfreich) erfolgreich eingesetzt. Beispiele für schriftliche Analysetools: Anwendungsfälle und User Stories. Beispiele für grafische Tools: UML und LML.
3. Systemmodellierung – In einigen technischen Bereichen (oder in bestimmten Situationen) muss das Produkt vollständig entworfen und modelliert werden, bevor mit der Konstruktion oder Fertigung begonnen wird. Daher muss die Entwurfsphase im Voraus durchgeführt werden. Beispielsweise müssen Baupläne für ein Gebäude ausgearbeitet werden, bevor ein Vertrag genehmigt und unterzeichnet werden kann. Viele Bereiche könnten Modelle des Systems mit der Lifecycle Modeling Language ableiten, während andere möglicherweise UML verwenden. Hinweis: In vielen Bereichen, beispielsweise im Software-Engineering, werden die meisten Modellierungsaktivitäten als Design-Aktivitäten und nicht als Anforderungs-Engineering-Aktivitäten klassifiziert.
4. Anforderungsspezifikation – Anforderungen werden in einem formalen Artefakt namens Anforderungsspezifikation (RS) dokumentiert, das erst nach der Validierung offiziell wird. Ein RS kann bei Bedarf sowohl schriftliche als auch grafische (Modell-)Informationen enthalten. Beispiel: Softwareanforderungsspezifikation (SRS).
5. Anforderungsvalidierung – Überprüfung, ob die dokumentierten Anforderungen und Modelle konsistent sind und den Bedürfnissen der Stakeholder entsprechen. Erst wenn der endgültige Entwurf den Validierungsprozess besteht, wird der RS ​​offiziell.
6. Anforderungsmanagement – ​​Verwaltung aller Aktivitäten im Zusammenhang mit den Anforderungen seit der Einführung, Überwachung der Entwicklung des Systems und sogar bis nach seiner Inbetriebnahme (z. B. Änderungen, Erweiterungen usw.)

Diese werden manchmal als chronologische Phasen dargestellt, obwohl es in der Praxis erhebliche Verflechtungen dieser Aktivitäten gibt.

Es hat sich gezeigt, dass das Anforderungsmanagement eindeutig zum Erfolg von Softwareprojekten beiträgt.

Probleme

In einer begrenzten Studie in Deutschland wurden mögliche Probleme bei der Umsetzung des Anforderungs-Engineerings dargestellt und die Befragten gefragt, ob sie zustimmen, dass es sich dabei um tatsächliche Probleme handele. Die Ergebnisse wurden nicht als verallgemeinerbar dargestellt, deuteten jedoch darauf hin, dass die wichtigsten wahrgenommenen Probleme unvollständige Anforderungen, sich verschiebende Ziele und Zeiteinschränkungen waren, während kleinere Probleme Kommunikationsmängel, mangelnde Rückverfolgbarkeit, terminologische Probleme und unklare Verantwortlichkeiten waren.

Kritik

Es wurde spekuliert, dass die Problemstrukturierung, ein zentraler Aspekt des Anforderungsengineerings, die Designleistung verringert. Einige Untersuchungen deuten darauf hin, dass es möglich ist, dass bei Mängeln im Anforderungsentwicklungsprozess, die dazu führen, dass Anforderungen nicht vorhanden sind, Softwareanforderungen trotzdem erstellt werden, als Illusion, die Designentscheidungen fälschlicherweise als Anforderungen darstellt

Siehe auch

• Liste der Anforderungs-Engineering-Tools
• Anforderungsanalyse, Anforderungsengineering mit Schwerpunkt Software-Engineering.
• Anforderungs-Engineering-Spezialistengruppe (RESG)
• International Requirements Engineering Board (IREB)
• Internationaler Rat für Systemtechnik (INCOSE)
• IEEE 12207 „Systems- und Software-Engineering – Software-Lebenszyklusprozesse“
• TOGAF (Kapitel 17)
• Betriebskonzept (ConOps)
• Betriebsführung
• Software Anforderungen
• Softwareanforderungen
• Software-Engineering-Wissensbestand (SWEBOK)
• Gestaltungsspezifikation
• Spezifikation (technischer Standard)
• Formale Spezifikation
• Softwarequalität
• Qualitätsmanagement
• Scope-Management

Verweise

Externe Links

• 29148-2011 – System- und Softwareentwicklung – Lebenszyklusprozesse – Anforderungsentwicklung. ISO/Iec/IEEE 29148:2011(E). 2011. S. 1–94. doi:10.1109/IEEESTD.2011.6146379. ISBN 978-0-7381-6591-2.(„Dieser Standard ersetzt IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 –
• Systemtechnischer Wissensbestand
• Anforderungsmanagement-Handbuch der FAA
• International Requirements Engineering Board (IREB)
• IBM Rational Resource Library von IEEE Spectrum