Requirements Engineering – Wikipedia

Posted on by
before-content-x4

Anforderungen in der Systemtechnik definieren und pflegen

Requirements Engineering ((RE)[1] ist der Prozess des Definierens, Dokumentierens und Verwaltens von Anforderungen[2] im Konstruktionsprozess. Es ist eine häufige Rolle in der System- und Softwareentwicklung.

Die erste Verwendung des Begriffs Anforderungs-Engineering war wahrscheinlich im Jahr 1964 in der Konferenzarbeit “Maintenance, Maintainability and System Requirements Engineering”,[3] Es wurde jedoch erst Ende der neunziger Jahre mit der Veröffentlichung eines Tutorials der IEEE Computer Society allgemein verwendet[4] im März 1997 und die Einrichtung einer Konferenzreihe zum Thema Requirements Engineering, die sich zur International Requirements Engineering Conference entwickelt hat.

Im Wasserfallmodell[5] Requirements Engineering wird als erste Phase des Entwicklungsprozesses vorgestellt. Spätere Entwicklungsmethoden, einschließlich des Rational Unified Process (RUP) für Software, setzen voraus, dass das Anforderungs-Engineering während der gesamten Lebensdauer eines Systems fortgesetzt wird.

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

Aktivitäten[edit]

Die Aktivitäten im Bereich Requirements Engineering variieren stark, abhängig von der Art des zu entwickelnden Systems und den spezifischen Praktiken der Organisation.[6] Dies können sein:

  1. Anforderungsbeginn oder Anforderungserhebung – 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. Sowohl schriftliche als auch grafische Werkzeuge (letztere werden häufig in der Entwurfsphase verwendet, aber einige finden sie auch in dieser Phase hilfreich) werden erfolgreich als Hilfsmittel verwendet. Beispiele für schriftliche Analysewerkzeuge: Anwendungsfälle und User Stories. Beispiele für grafische Werkzeuge: UML[7] und LML.
  3. Systemmodellierung – In einigen technischen Bereichen (oder in bestimmten Situationen) muss das Produkt vor Beginn seiner Konstruktion oder Herstellung vollständig entworfen und modelliert werden. Daher muss die Entwurfsphase im Voraus durchgeführt werden. Zum Beispiel müssen Pläne für ein Gebäude ausgearbeitet werden, bevor ein Vertrag genehmigt und unterzeichnet werden kann. Viele Felder leiten möglicherweise Modelle des Systems mit der Lifecycle Modeling Language ab, während andere möglicherweise UML verwenden. Hinweis: In vielen Bereichen, z. B. beim Software-Engineering, werden die meisten Modellierungsaktivitäten als Entwurfsaktivitäten und nicht als Anforderungs-Engineering-Aktivitäten klassifiziert.
  4. Anforderungsspezifikation – Anforderungen werden in einem formalen Artefakt dokumentiert, das als Anforderungsspezifikation (Requirements Specification, RS) bezeichnet wird und erst nach der Validierung offiziell wird. Ein RS kann bei Bedarf sowohl schriftliche als auch grafische (Modell-) Informationen enthalten. Beispiel: Software Requirements Specification (SRS).
  5. Anforderungsvalidierung – Überprüfung, ob die dokumentierten Anforderungen und Modelle konsistent sind und den Anforderungen 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 ihrer Einführung, Überwachung während der Entwicklung des Systems und sogar bis zu seiner Inbetriebnahme (z. B. Änderungen, Erweiterungen usw.)

Diese werden manchmal als chronologische Stadien dargestellt, obwohl in der Praxis eine erhebliche Verschachtelung dieser Aktivitäten besteht.

Es hat sich gezeigt, dass das Requirements Engineering eindeutig zum Erfolg von Softwareprojekten beiträgt. [8]

Probleme[edit]

Eine begrenzte Studie in Deutschland stellte mögliche Probleme bei der Implementierung des Requirements Engineering vor und fragte die Befragten, ob sie sich einig seien, dass es sich um tatsächliche Probleme handele. Die Ergebnisse wurden nicht als verallgemeinerbar dargestellt, sondern deuteten darauf hin, dass die wichtigsten wahrgenommenen Probleme unvollständige Anforderungen, sich bewegende Ziele und Zeitboxen waren, wobei geringere Probleme Kommunikationsfehler, mangelnde Rückverfolgbarkeit, terminologische Probleme und unklare Verantwortlichkeiten waren.[9]

Kritik[edit]

Die Problemstrukturierung, ein Schlüsselaspekt des Anforderungs-Engineerings, wurde spekuliert, um die Entwurfsleistung zu verringern.[10] Einige Untersuchungen legen nahe, dass bei Mängeln im Anforderungsentwicklungsprozess, die zu einer Situation führen, in der keine Anforderungen vorhanden sind, Softwareanforderungen erstellt werden können, unabhängig davon, ob es sich um eine Illusion handelt, die Entwurfsentscheidungen als Anforderungen falsch darstellt [11]

Siehe auch[edit]

Verweise[edit]

  1. ^ Nuseibeh, B.; Easterbrook, S. (2000). Requirements Engineering: eine Roadmap (PDF). ICSE’00. Tagungsband zur Zukunft des Software Engineering. S. 35–46. CiteSeerX 10.1.1.131.3116. doi:10.1145 / 336512.336523. ISBN 1-58113-253-0.
  2. ^
  3. ^ Dresner, KH Borchers (1964). Wartung, Wartbarkeit und Systemanforderungs-Engineering. SAE World Congress & Exhibition 1964. SAE Technical Paper 640591. doi:10.4271 / 640591.
  4. ^ Thayer, Richard H.; Dorfman, Merlin, Hrsg. (März 1997). Software Requirements Engineering (2. Aufl.). IEEE Computer Society Press. ISBN 978-0-8186-7738-0.
  5. ^ Royce, WW (1970). Management der Entwicklung großer Softwaresysteme: Konzepte und Techniken (PDF). ICSE’87. Vorträge der 9. internationalen Konferenz über Software Engineering. S. 1–9.
  6. ^ Sommerville, Ian (2009). Softwareentwicklung (9. Aufl.). Addison-Wesley. ISBN 978-0-13-703515-1.
  7. ^ “Aufdecken von Anforderungen mit UML-Klassendiagrammen Teil 1”. tynerblain.com. 7. März 2008. Abgerufen 14. März, 2018.
  8. ^ Hofmann, HF; Lehner, F. (2001). “Requirements Engineering als Erfolgsfaktor in Softwareprojekten”. IEEE-Software. 18 (4): 58–66. doi:10.1109 / MS.2001.936219. ISSN 0740-7459.
  9. ^ Méndez Fernández, Daniel; Wagner, Stefan (2015). “Den Schmerz in der Anforderungsentwicklung benennen: Ein Design für eine globale Familie von Umfragen und erste Ergebnisse aus Deutschland”. Informations- und Softwaretechnologie. 57: 616–643. arXiv:1611.04976. doi:10.1016 / j.infsof.2014.05.008. S2CID 1924926.
  10. ^ Ralph, Paul; Mohanani, Rahul (Mai 2015). “Ist Requirements Engineering von Natur aus kontraproduktiv?”. IEEE. doi:10.13140 / 2.1.3831.6321.
  11. ^ Ralph, P. (September 2013). “Die Illusion von Anforderungen in der Softwareentwicklung”. Requirements Engineering. 18 (3): 293–296. arXiv:1304.0116. Bibcode:2013arXiv1304.0116R. doi:10.1007 / s00766-012-0161-4. S2CID 11499083.

Externe Links[edit]


after-content-x4