Was ist Anforderungsanalyse und -erfassung in SDLC?

In diesem Tutorial werden Anforderungsanalyse, Anforderungsanalyseschritte, Beispiele und Ziele der Anforderungserfassung in SDLC erläutert:

Softwareentwicklung ist eine enorme Aufgabe, die ein funktionierendes Softwareprodukt erstellt.

Das Softwareprodukt wird gemäß den Anforderungen des Kunden erstellt. Meistens entspricht dieses Softwareprodukt den Erwartungen des Endkunden / Benutzers, während dieses Produkt manchmal nicht vollständig den Erwartungen des Kunden / Endbenutzers entspricht.

Was ist Anforderungsanalyse?

Lassen Sie uns die Anforderungsanalyse anhand eines Beispiels verstehen.

Kunden-/Endbenutzererwartungen:

Kunden-/Endbenutzererwartungen:

Wie Sie anhand der obigen Bilder analysieren können, stimmt das Endprodukt nicht mit den Kundenerwartungen überein. Dies könnte auf unzählige Gründe zurückzuführen sein, nämlich. falsche Umsetzung der Kundenanforderungen, fehlerhaftes Design, falsches Verständnis der Kundenanforderungen durch Programmierer und Qualitätsteam usw.

Wie Sie jedoch sehen können, ist der Hauptgrund für die falsche Produktlieferung die Anforderung. Wenn daher das richtige Verständnis, Erfassen, Implementieren und Testen von Anforderungen durchgeführt worden wäre, hätte dies dazu beigetragen, die fehlerhafte und unvollständige Produktlieferung an den Kunden / Endbenutzer zu verringern.

Eine gute Produktlieferung erfordert die korrekte Anforderungserfassung, die effiziente Prüfung der gesammelten Anforderungen und schließlich eine klare Anforderungsdokumentation als Voraussetzung. Dieser gesamte Prozess wird auch als Anforderungsanalyse im Software Development Life Cycle (SDLC) bezeichnet)

Anforderungsanalyse Stufen / Schritte

Wie Sie sehen können, ist die Anforderungsanalyse die erste Aktivität in SDLC, gefolgt von der Funktionalen Spezifikation und so weiter. Die Anforderungsanalyse ist ein wichtiger Schritt in SDLC, da sie mit Akzeptanztests einhergeht, die für die Produktakzeptanz durch Kunden entscheidend sind.

In diesem Tutorial erklären wir, wie die Anforderungsanalyse in SDLC durchgeführt wird. Wir werden auch die verschiedenen beteiligten Schritte, Ergebnisse, Herausforderungen und Korrekturmaßnahmen in der Anforderungsanalyse sehen.

Anforderungsanalyse beginnt mit:

1. Anforderungserfassung, die auch als Elicitation bezeichnet wird.
2. Anschließend werden die gesammelten Anforderungen analysiert, um die Richtigkeit und Durchführbarkeit der Umwandlung dieser Anforderungen in ein mögliches Produkt zu verstehen.
3. Und schließlich die Dokumentation der gesammelten Anforderungen.

#1) Anforderungserfassung

Um sicherzustellen, dass alle oben genannten Schritte ordnungsgemäß ausgeführt werden, müssen klare, präzise und korrekte Anforderungen vom Kunden eingeholt werden. Der Kunde sollte in der Lage sein, seine Anforderungen richtig zu definieren, und der Business Analyst sollte in der Lage sein, sie auf die gleiche Weise zu erfassen, wie der Kunde sie vermitteln möchte.

Oft ist es nicht möglich, dass die Anforderungserfassung von Business Analysten des Kunden effizient durchgeführt wird. Dies kann auf die Abhängigkeit von vielen Personen zurückzuführen sein, die sich auf das erwartete Endprodukt, die Tools, die Umgebung usw. beziehen. Daher ist es immer eine gute Idee, alle Stakeholder einzubeziehen, die das Endprodukt beeinflussen könnten oder von ihm beeinflusst werden könnten.

Die mögliche Stakeholder-Gruppe könnten Software-Qualitätsingenieure (sowohl QC als auch QA), Drittanbieter, die Unterstützung im Projekt leisten könnten, Endbenutzer, für die das Produkt bestimmt ist, Softwareprogrammierer, ein anderes Team innerhalb der Organisation, das ein Modul oder eine Softwareplattform bereitstellen könnte, Softwarebibliotheken usw. sein. für die Produktentwicklung.

Beispiel: In einer Organisation entwickeln sie ein ADAS-Produkt (Surround-View-Kamerasystem für einen renommierten OEM), das Autosar-Stack und Bootloader-Binärdateien benötigt, die von einem anderen Lieferanten erhalten werden.

Die Einbeziehung verschiedener Stakeholder in die Anforderungserfassungsphase hilft, verschiedene Abhängigkeiten voneinander zu verstehen und mögliche zukünftige Konflikte zu vermeiden.

Manchmal ist es eine gute Idee, ein Prototypmodell des geplanten Produkts zu erstellen und es dem Kunden zu zeigen. Dies ist eine hervorragende Möglichkeit, den Kunden zu vermitteln, welches Produkt sie erwarten und wie es später aussehen kann. Dies hilft dem Kunden bei der Visualisierung des Produkts, das er erwartet, und hilft ihm, klare Anforderungen zu stellen.

Diese Prototypenerstellung hängt von zwei Produkttypen ab:

1. Ein ähnliches Produkt, das Kunden beabsichtigten, existiert innerhalb der Organisation.
2. Neues zu entwickelndes Produkt.

( i) Im ersten Fall ist es einfacher, dem Kunden zu zeigen, wie das Endprodukt aussehen und wie es entwickelt werden würde. In Automobil-ADAS ist es möglich, Kunden ein anderes Produkt zu zeigen, das bereits auf dem Markt ist und innerhalb der Organisation entwickelt wurde.

Zum Beispiel ein Surround-View-Kamerasystem, das für einen OEM (GM, Volkswagen, BMW usw.) entwickelt wurde.) und kann einem anderen OEM präsentiert werden.

Bitte beachten Sie, dass es nicht ratsam ist, dem Kunden ein Produkt / Proto-Produkt zu zeigen, das sich in der Entwicklung befindet, da dies gegen die Geheimhaltungsvereinbarung verstoßen kann, die mit einem anderen Kunden unterzeichnet wurde, für den dieses Produkt entwickelt wird. Es kann auch zu einem unnötigen rechtlichen Streit führen.

Ein weiteres Beispiel könnte das Infotainmentsystem sein, das von der Organisation entwickelt wird und bereits auf dem Markt ist. Geschäftsanalysten und andere Stakeholder innerhalb einer Organisation können eine Workshop-Demo für den Kunden planen, in der Infotainmentsysteme mit greifbarem HMI, Geräteanschlussanschlüssen, Sandbox usw. angezeigt werden.

Dies wird dem Kunden helfen zu verstehen, wie das Endprodukt aussehen würde, und seine Anforderungen viel klarer darstellen.

(ii) Der zweite Fall kann erreicht werden, indem ein grundlegendes Arbeitsmodell durch einfache Codierung und Assemblierung erstellt wird (die meisten Funktionen sind hier in Softwareprogrammen fest codiert) oder indem ein Flussdiagramm oder Diagramm erstellt wird, das den Kunden davon überzeugen kann, wie das Produkt aussehen würde.

In jedem Fall wäre es eine Verschnaufpause für den Anforderungsprozess, da der Kunde jetzt weiß, was er will.

Der Business Analyst kann jetzt formelle Anforderungserhebungsmeetings organisieren, bei denen alle Stakeholder eingeladen werden können und so die verschiedenen Anforderungen des Kunden notieren können (in einigen Fällen, wenn die Stakeholder zahlreicher sind, könnte ein separater Schreiber ernannt werden, um Kundenanforderungen oder User Stories zu notieren, damit sich der Business Analyst auf die Moderation des Meetings konzentrieren kann).

Die gesammelten Anforderungen können in Form von User Stories (in der agilen Entwicklung), Anwendungsfällen, Dokumenten in natürlicher Sprache des Kunden, Diagrammen, Flussdiagrammen usw. vorliegen. User Stories werden im modernen Lebenszyklus der Softwareentwicklung immer beliebter. User Stories sind im Grunde eine Reihe von Kundeneingaben in ihrer natürlichen Sprache.

Anforderungserfassung Beispiel: Im Surround-View-Kamerasystem ADAS könnte eine mögliche User Story lauten: „Als Benutzer sollte ich sehen können, was sich im Rückspiegel meines Autos befindet“.

Zu jeder User Story können viele „Warum“ -Fragen gestellt werden, die dem Kunden helfen, detailliertere Informationen über die Anforderung bereitzustellen.

Wenn ein Kunde in der obigen User Story sagt: „Als Benutzer sollte ich in der Lage sein zu sehen, was sich im Rückspiegel meines Autos befindet“, stellt er die Frage „Warum“ und könnte „Als Benutzer sollte ich in der Lage sein zu sehen, was sich im Rückspiegel meines Autos befindet, damit ich mein Auto sicher parken kann“.

Die Frage nach dem „Warum“ zu stellen, hilft auch dabei, objektive und atomare Anforderungen aus riesigen Aussagen des Kunden in natürlicher Sprache zu erstellen. Dies kann später im Code einfach implementiert werden.

Eine andere Möglichkeit, die Anforderung zu erfassen, besteht in Form von Anwendungsfällen. Ein Anwendungsfall ist ein schrittweiser Ansatz, um ein bestimmtes Ergebnis zu erzielen. Dies sagt nicht, wie die Software auf Benutzereingaben arbeiten wird, sondern sagt, was von Benutzereingaben erwartet wird.

Beispiel:

#2) Analyse der gesammelten Anforderungen

Nach der Anforderungserfassung beginnt die Analyse der Anforderungen. In dieser Phase sitzen verschiedene Stakeholder zusammen und führen ein Brainstorming durch. Sie analysieren die gesammelten Anforderungen und suchen nach Machbarkeit, um sie umzusetzen. Sie diskutieren miteinander und jede Unklarheit wird aussortiert.

Dieser Schritt ist im Anforderungsanalyseprozess aus folgenden Hauptgründen wichtig:

(i) Der Kunde kann einige Anforderungen bereitstellen, die aufgrund verschiedener Abhängigkeiten nicht implementiert werden können.

Beispiel: Kunden können darum bitten, das Kamerasystem mit einer Rückfahrkamerafunktion zu umgeben, die beim Einparken des Autos hilft. Der Kunde kann auch nach der Anhängerkupplungsfunktion fragen, die auch die Rückfahrkamera verwendet.

Wenn der Kunde eine Anforderung angibt, dass die Rückfahrkamera für die Einparkhilfe ausnahmslos jederzeit funktionieren soll, würde die Trailer-Funktion niemals funktionieren und umgekehrt.

( ii) Ein Business Analyst hätte die Anforderung des Kunden möglicherweise anders verstanden als ein Programmierer.

Da Programmierer als technische Experten denken, ist es immer möglich, dass Kundenanforderungen fälschlicherweise in funktionale Spezifikationen umgewandelt werden, die später fälschlicherweise in Architektur- und Designdokumente und anschließend in Code umgewandelt werden. Die Auswirkungen sind exponentiell und sollten daher überprüft werden.

Eine mögliche Abhilfemaßnahme könnte darin bestehen, einer agilen Methode der Softwareentwicklung zu folgen, Anwendungsfällen zu folgen, die der Kunde bereitstellt usw.

#3) Dokumentation der analysierten Anforderungen

Sobald die Analyse der Anforderungen abgeschlossen ist, beginnt die Anforderungsdokumentation. Verschiedene Arten von Anforderungen ergeben sich aus der Anforderungsanalyse.

Einige davon sind:

(i) Kundenanforderungsspezifikation.

(ii) Anforderung an die Softwarearchitektur.

Beispiel:

( iii) Software-Design-Anforderung.

Beispiel:

( iv) Funktionale Anforderungsspezifikation (direkt aus Kundenspezifikationen abgeleitet.)

Beispiel: „Wenn der Benutzer auf das Bluetooth-Symbol im Infotainment-HMI tippt, sollte der Bluetooth-Bildschirm angezeigt werden“

(v) Nicht funktionale Anforderungsspezifikation (dh. leistung, Belastung, Belastung usw.).

Beispiel: „Es sollte möglich sein, 15 Bluetooth-Geräte mit dem Infotainmentsystem zu koppeln, ohne die Systemleistung zu beeinträchtigen“.

(vi) Anforderungen an die Benutzeroberfläche.

Beispiel: „Auf dem Tuner FM-Bildschirm sollte eine Schaltfläche zur Auswahl verschiedener Sender angezeigt werden.“

Die oben genannten Anforderungen werden in Anforderungsmanagementtools wie IBM DOORS, HP QC aufgezeichnet und dokumentiert. Manchmal haben Organisationen ihre maßgeschneiderten Anforderungsmanagement-Tools, um die Kosten zu senken.

Lassen Sie uns nun den Prozess der Umwandlung von Geschäftsanforderungen in Softwareanforderungen (funktional und nicht funktional) betrachten.

Konvertieren von Geschäftsanforderungen in Softwareanforderungen

Geschäftsanforderungen sind, wie oben erläutert, Anforderungen auf hoher Ebene, die darüber sprechen, was der Endbenutzer von einer definierten Aktion auf dem Softwaresystem erwartet. Die Entwicklung des gesamten Softwaresystems auf der Grundlage dieser Anforderungen ist nicht möglich, da eine detaillierte Beschreibung, wie das Softwaresystem oder die Komponente implementiert wird, nicht erwähnt wird.

Daher müssen Geschäftsanforderungen in detailliertere Softwareanforderungen zerlegt werden, die weiter in funktionale und nicht funktionale Anforderungen unterteilt werden.

Dazu können die folgenden Schritte ausgeführt werden:

1. Brechen Sie die Geschäftsanforderungen auf hoher Ebene in detaillierte User Stories auf.
2. Ableiten eines Flussdiagramms zur Definition des Ablaufs von Aktivitäten.
3. Bereitstellung der Bedingung, die die abgeleiteten User Stories rechtfertigt.
4. Drahtgitterdiagramme zur Erläuterung des Arbeitsablaufs von Objekten.
5. Nicht-funktionale Anforderungen aus den Geschäftsanforderungen heraus definieren.

Nehmen wir zunächst ein Beispiel für ein Infotainmentsystem im Automobil.

Die Geschäftsanforderung lautet: „Der Endbenutzer sollte über das Infotainmentsystem HMI auf die Navigations-Widget-Box zugreifen und die Zieladresse festlegen können“.

Die oben genannten Schritte können also wie folgt implementiert werden:

#1) Brechen Sie die Geschäftsanforderungen auf hoher Ebene in detaillierte User Stories auf.

Lassen Sie uns diese Geschäftsanforderung in eine Benutzergeschichte auf hoher Ebene umwandeln: „Als Benutzer sollte ich in der Lage sein, auf das Navigations-Widget-Feld zuzugreifen, damit ich die Zieladresse eingeben kann“. Diese User Story erzählt, was der Endbenutzer benötigt. Wir werden versuchen zu definieren, wie diese Anforderung implementiert werden kann.

Beginnen wir mit möglichen Fragen zu dieser User Story.

1. Wer sind die Benutzer?
2. Wie kann ich auf die Navigation an Bord (von SD-Karte) oder vom SmartPhone aus zugreifen?
3. Welche Art von Zieleinträgen kann ich eingeben?
4. Soll ich das Ziel betreten dürfen, auch wenn das Auto geparkt ist?

Dies sind detailliertere User Stories, die aus hochrangigen User Stories abgeleitet wurden und uns helfen würden, mehr Einblick in unsere Geschäftsanforderungen zu erhalten.

An dieser Stelle können wir eine der Benutzer-Untergeschichten aufnehmen und mit der Befragung beginnen. Lass uns nehmen (nein. 3):

1. Kann ich Zieleinträge wie Geokoordinaten, Postanschrift, über Spracherkennung usw. eingeben.?
2. Benötige ich GPS für die Eingabe von Geo-Koordinaten?
3. Kann ich die aktuelle Zieladresse eingeben, indem ich in der Adresshistorie suche?

#2) Ableiten eines Flussdiagramms zur Definition des Ablaufs von Aktivitäten.

Jetzt können wir sehen, dass die Geschäftsanforderung in sehr detaillierte Anwendungsfälle unterteilt ist, die im Flussdiagramm wie folgt markiert werden können:

#3) Bereitstellung von Bedingungen, die abgeleitete User Stories rechtfertigen.

Wir können sehen, dass detailliertere Informationen aufgrund der Zerlegung der Geschäftsanforderungen auf hoher Ebene in detaillierte Benutzergeschichten auf niedriger Ebene und in das Flussdiagramm entstehen. Aus diesem Flussdiagramm können wir die technischen Details erhalten, die für die Implementierung erforderlich sind.

• Die Ladezeit des Bildschirms zur Anzeige des Zieleintrags sollte 1 Sek. betragen.
• Die Tastatur des Zieleintrags sollte alphanumerische Zeichen und Sonderzeichen enthalten.
• Die Umschalttaste zum Aktivieren / Deaktivieren von GPS sollte auf dem Bildschirm zur Eingabe des Navigationsziels vorhanden sein.

Die obigen Informationen erfüllen User Stories und ermöglichen es, die Anforderung diskret und messbar zu testen, um Verwechslungen mit der Anforderung zu vermeiden, während sie als Funktionen implementiert werden.

#4) Drahtgitterdiagramme zur Erläuterung des Arbeitsablaufs von Objekten.

Aus dem obigen Anwendungsfall leiten wir ein Drahtgitterdiagramm ab, das die Benutzeroberfläche klarer macht.

#5) Definition nicht funktionaler Anforderungen aus den Geschäftsanforderungen heraus.

Es ist zwingend erforderlich, dass detaillierte Softwareanforderungen aus übergeordneten Geschäftsanforderungen abgeleitet werden, aber oft werden nur funktionale Anforderungen identifiziert, die angeben, wie sich ein System bei einer bestimmten Benutzereingabe / -aktion verhält.

Funktionale Anforderungen klären jedoch nicht die Systemleistung und andere qualitative Parameter wie Verfügbarkeit, Zuverlässigkeit usw.

Beispiele:

a) Wir nehmen das Beispiel des obigen Automobil-Infotainmentsystems.

Wenn der Fahrer (Endbenutzer) des Autos Musik von USB abspielt und die Navigationsführung ausgeführt wird, erhält er auch einen eingehenden Anruf über Bluetooth im Freisprechmodus, dann steigt die CPU- und RAM-Auslastung auf ein Maximum, da mehrere Prozesse im Hintergrund ausgeführt werden.

Wenn der Fahrer zu diesem Zeitpunkt auf die Touchscreen-Oberfläche eines Infotainmentsystems tippt, um eingehende Anrufe per SMS mit automatischer Antwort abzuweisen (wie bei unseren Mobiltelefonen), sollte das System in der Lage sein, diese Aufgabe auszuführen und sollte nicht hängen bleiben oder abstürzen. Dies ist die Leistung des Systems bei hoher Last und wir testen Verfügbarkeit und Zuverlässigkeit.

b) Ein weiterer Fall ist das Stressszenario.

Zum Beispiel empfängt das Infotainmentsystem SMS (vielleicht 20 SMS innerhalb von 10 Sekunden) über ein angeschlossenes Bluetooth-Telefon. Das Infotainmentsystem sollte in der Lage sein, alle eingehenden SMS zu verarbeiten und zu keinem Zeitpunkt eine der eingehenden SMS-Benachrichtigungen auf dem Infotainment-HMI zu verpassen.

Die obigen Beispiele sind Fälle von nicht-funktionalen Anforderungen, die nicht über funktionale Anforderungen allein getestet werden konnten. Obwohl Kunden manchmal diese nicht funktionalen Anforderungen nicht erfüllen. Es liegt in der Verantwortung der Organisation, ihnen diese Informationen zur Verfügung zu stellen, wenn ein Produkt an den Kunden geliefert wird.

Nicht-funktionale Anforderungen verstehen Fälle

Die folgende Tabelle erläutert nicht-funktionale Anforderungen:

Nicht-funktionale Anforderungen, im Gegensatz zu funktionalen Anforderungen, nehmen Sie den gesamten Lebenszyklus eines Projekts in Anspruch, um es zu implementieren, da es inkrementell in entsprechenden agilen Sprints oder in verschiedenen Iterationen implementiert wird.

So leiten wir Softwareanforderungen von Geschäftsanforderungen ab.

Unterschied zwischen Geschäftsanforderungen und Softwareanforderungen

Wir haben oben gesehen, wie Softwareanforderungen aus übergeordneten Geschäftsanforderungen abgeleitet werden können. Softwareanforderungen ermöglichen es dem Programmierer und Testingenieur, das System zu entwickeln und effizient zu testen. Wir wissen jetzt, dass Geschäftsanforderungen Anforderungen an die natürliche Sprache des Kunden auf hoher Ebene sind, während Softwareanforderungen detaillierte Anforderungen auf niedriger Ebene sind, die bei der Implementierung des Softwaresystems helfen.

Schauen wir uns den detaillierten Unterschied zwischen den beiden Anforderungstypen an.

Fazit

Die Anforderungsanalyse ist das Rückgrat jedes SDLC-Modells.

Ein Problem, das während der Anforderungsanalyse übersehen und bei Unit-Tests festgestellt wurde, könnte eine Organisation Zehntausende von Dollar kosten, und diese Kosten könnten zu Millionen von Dollar führen, wenn es als Rückruf vom Markt kommt (in 2017 haben die USA dem Airbaghersteller Takata eine Geldstrafe von 1 Milliarde US-Dollar wegen explodierender Airbags auferlegt).

Die Organisation würde am Ende Schadenskontrollaufgaben wie Ursachenanalyse, Vorbereitung von 5D-Dokumenten, Fehlerbaumanalyse, 8D-Dokument usw. ausführen. anstatt sich auf Softwareentwicklung und Qualität zu konzentrieren.

Im schlimmsten Fall würde die Organisation in rechtliche Klagen des Kunden verwickelt, wenn die betroffene Funktion sicherheitsrelevant ist, wie Sicherheitszugang, Airbag, ABS (Antiblockiersystem) usw.