what is requirement analysis
In diesem Lernprogramm wird erläutert, was Anforderungsanalyse, Schritte zur Anforderungsanalyse, Beispiele und Ziele für das Sammeln von Anforderungen in SDLC sind:
Softwareentwicklung ist eine gewaltige Aufgabe, die ein funktionierendes Softwareprodukt schafft.
Das Softwareprodukt wird gemäß den Anforderungen des Kunden erstellt. Meistens entspricht dieses Softwareprodukt den Erwartungen des Endkunden / Benutzers, während dieses Produkt manchmal nicht den Erwartungen des Kunden / Endbenutzers entspricht.
Was du lernen wirst:
- Was ist Anforderungsanalyse?
- Fazit
Was ist Anforderungsanalyse?
Lassen Sie uns die Anforderungsanalyse anhand eines Beispiels verstehen.
Kunden- / Endbenutzererwartung:
Kunde / Endbenutzer erhalten:
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, liegt der Hauptgrund in der Anforderung, sei es ein Grund für eine falsche Produktlieferung. Wenn das korrekte Verständnis, Erfassen, Implementieren und Testen der 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 eine korrekte Anforderungserfassung, die effiziente Prüfung der erfassten Anforderungen und schließlich eine klare Anforderungsdokumentation als Voraussetzung. Dieser gesamte Prozess wird auch als bezeichnet Anforderungsanalyse im Software Development Life Cycle (SDLC)
Stufen / Schritte der Anforderungsanalyse
Wie Sie sehen können, ist die Anforderungsanalyse die erste Aktivität in SDLC, gefolgt von der Funktionsspezifikation usw. Die Anforderungsanalyse ist ein wichtiger Schritt in SDLC, da sie mit Abnahmetests übereinstimmt, die für die Produktakzeptanz bei Kunden von entscheidender Bedeutung sind.
In diesem Tutorial erklären wir, wie die Anforderungsanalyse in SDLC durchgeführt wird. Wir werden auch die verschiedenen Schritte, Ergebnisse, Herausforderungen und Korrekturmaßnahmen in der Anforderungsanalyse sehen.
Die Anforderungsanalyse beginnt mit:
- Anforderungserfassung was auch als Auslösung bezeichnet wird.
- Darauf folgt Analysieren die gesammelten Anforderungen, um die Richtigkeit und Durchführbarkeit der Umwandlung dieser Anforderungen in ein mögliches Produkt zu verstehen.
- Und schlussendlich, dokumentieren die gesammelten Anforderungen.
# 1) Anforderungserfassung
Um sicherzustellen, dass alle oben genannten Schritte ordnungsgemäß ausgeführt werden, müssen vom Kunden klare, präzise und korrekte Anforderungen eingeholt werden. Der Kunde sollte in der Lage sein, seine Anforderungen richtig zu definieren, und der Geschäftsanalyst 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 das Sammeln von Anforderungen von Geschäftsanalysten des Kunden effizient durchgeführt wird. Dies kann auf die Abhängigkeit von vielen Personen zurückzuführen sein, die mit dem erwarteten Endprodukt, den Tools, der Umgebung usw. in Verbindung stehen. Daher ist es immer eine gute Idee, alle Beteiligten einzubeziehen, die das Endprodukt beeinflussen oder von diesem beeinflusst werden könnten.
Die mögliche Stakeholder-Gruppe könnten Software-Qualitätsingenieure (sowohl QC als auch QA) sein, alle Drittanbieter, die Unterstützung im Projekt leisten könnten, Endbenutzer, für die das Produkt bestimmt ist, Software-Programmierer, ein anderes Team innerhalb der Organisation, das möglicherweise bereitstellt ein Modul oder eine Softwareplattform, Softwarebibliotheken usw. für die Produktentwicklung.
Beispiel: In einer Organisation entwickeln sie ein ADAS-Produkt (Surround-View-Kamerasystem für einen renommierten OEM), das diese Anforderungen erfüllt Autosar-Stapel und Bootloader Binärdateien, die von einem anderen Lieferanten empfangen werden.
Die Einbeziehung verschiedener Stakeholder in die Phase der Anforderungserfassung hilft dabei, verschiedene Abhängigkeiten voneinander zu verstehen, und mögliche zukünftige Konflikte könnten abgewendet werden.
Manchmal ist es eine gute Idee, ein Prototypmodell des geplanten geplanten Produkts zu erstellen und es dem Kunden zu zeigen. Dies ist eine hervorragende Möglichkeit, Kunden zu vermitteln, welches Produkt sie erwarten und wie es später aussehen kann. Dies hilft dem Kunden bei der Visualisierung des erwarteten Produkts und hilft ihm, klare Anforderungen zu erstellen.
Diese Prototypenerstellung hängt von zwei Produkttypen ab:
- Ein ähnliches Produkt, das Kunden beabsichtigt haben, gibt es innerhalb der Organisation.
- Neues Produkt entwickelt werden.
(ich) Im ersten Fall ist es einfacher, dem Kunden zu zeigen, wie das Endprodukt aussehen und wie es entwickelt werden würde. In Automotive ADAS ist es möglich, Kunden ein anderes Produkt zu zeigen, das bereits auf dem Markt ist und innerhalb des Unternehmens entwickelt wurde.
Zum Beispiel, Ein Surround-View-Kamerasystem, das für einen OEM (GM, Volkswagen, BMW usw.) entwickelt wurde und einem anderen OEM präsentiert werden kann.
bitte beachten Sie Es ist nicht ratsam, dem Kunden, der sich in der Entwicklung befindet, ein Produkt / Proto-Produkt zu zeigen, da dies möglicherweise gegen die Geheimhaltungsvereinbarung verstößt, die mit einem anderen Kunden unterzeichnet wurde, für den dieses Produkt entwickelt wird. Dies kann auch zu unnötigen Rechtsstreitigkeiten führen.
Ein anderes Beispiel könnte das des Infotainmentsystems sein, das von der Organisation entwickelt wird und bereits auf dem Markt ist. Geschäftsanalysten und andere Stakeholder innerhalb eines Unternehmens planen möglicherweise eine Workshop-Demo für den Kunden, in der Infotainmentsysteme mit greifbarem HMI, Geräteanschlussanschlüssen, Sandbox usw. angezeigt werden.
Dies hilft dem Kunden zu verstehen, wie das Endprodukt aussehen würde, und seine Anforderungen viel klarer darzustellen.
(ii) Der zweite Fall kann erreicht werden, indem ein einfaches Arbeitsmodell durch einfaches Codieren und Zusammensetzen erstellt wird (die meisten Funktionen sind hier in Softwareprogrammen fest codiert) oder indem ein Flussdiagramm oder ein 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 Anforderungserfassungsprozess, da der Kunde jetzt weiß, was er will.
Der Geschäftsanalyst kann jetzt formelle Anforderungserhebungssitzungen organisieren, bei denen alle Stakeholder eingeladen werden können, und so die verschiedenen vom Kunden gestellten Anforderungen notieren (in einigen Fällen, wenn die Anzahl der Stakeholder größer ist, kann ein separater Schreiber ernannt werden, um den Kunden zu notieren Anforderungen oder User Stories, damit sich Business Analyst auf die Moderation des Meetings konzentrieren kann).
Die gesammelten Anforderungen können in Form von erfolgen benutzergeschichten (in der agilen Entwicklung), Anwendungsfälle, Dokumente in natürlicher Sprache des Kunden, Diagramme, Flussdiagramme usw. User Stories werden im modernen Lebenszyklus der Softwareentwicklung immer beliebter. User Stories sind im Grunde eine Reihe von Kundeneingaben in ihrer natürlichen Sprache.
Beispiel für das Sammeln von Anforderungen: Im ADAS-Surround-View-Kamerasystem könnte eine mögliche User Story lauten: 'Als Benutzer sollte ich in der Lage sein, zu sehen, was sich in der Rückansicht meines Autos befindet.'
Es könnte viele geben 'Warum,' Fragen zu jeder User Story, die dem Kunden helfen, detailliertere Informationen über die Anforderung bereitzustellen.
Wenn ein Kunde in der obigen User Story sagt 'Als Benutzer sollte ich sehen können, was sich in der Rückansicht meines Autos befindet', stellt er eine Frage 'Warum 'Könnte geben' Als Benutzer sollte ich in der Lage sein zu sehen, was sich in der Rückansicht meines Autos befindet. damit ich mein Auto sicher parken kann ”.
Die Frage stellen 'Warum' hilft auch bei der Schaffung objektiver und atomarer Anforderungen aus riesigen Aussagen des Kunden in natürlicher Sprache. Dies kann später im Code leicht implementiert werden.
Fragen und Antworten zu Automatisierungstests für erfahrene Personen
Eine andere Möglichkeit, die Anforderung zu erfassen, besteht in der Form von Anwendungsfälle . Ein Anwendungsfall ist ein schrittweiser Ansatz zum Erreichen eines bestimmten Ergebnisses. Dies sagt nicht aus, wie die Software bei Benutzereingaben funktioniert, sondern es wird angegeben, was von Benutzereingaben erwartet wird.
Beispiel:
# 2) Analyse der gesammelten Anforderungen
Nach dem Sammeln der Anforderungen beginnt die Analyse der Anforderungen. In dieser Phase sitzen verschiedene Stakeholder und führen eine Brainstorming-Sitzung durch. Sie analysieren die gesammelten Anforderungen und suchen nach Machbarkeit, um sie umzusetzen. Sie diskutieren miteinander und Unklarheiten werden ausgeräumt.
Dieser Schritt ist aus folgenden Gründen für die Anforderungsanalyse wichtig:
(ich) Der Kunde kann einige Anforderungen angeben, die aufgrund verschiedener Abhängigkeiten möglicherweise nicht implementiert werden können.
Beispiel: KundenMöglicherweise werden Sie gebeten, das Kamerasystem mit einer Rückfahrkamerafunktion zu umgeben, die Ihnen dabei hilft Parken das Auto. Der Kunde kann auch nach dem fragen Anhänger Anhängerkupplungsfunktion, bei der auch die Rückfahrkamera zum Arbeiten verwendet wird.
Wenn der Kunde eine Anforderung angibt, für die die Rückfahrkamera gilt Parken Hilfe sollte ausnahmslos jederzeit funktionieren, dann die Anhänger Funktion würde nie funktionieren und umgekehrt.
(ii) Ein Business Analyst könnte die Anforderung aus dem verstanden haben Kunde anders als wie ein Programmierer hätte interpretiert.
Da Programmierer als technische Experten denken, ist es immer möglich, dass Kundenanforderungen falsch in Funktionsspezifikationen konvertiert 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älle zu verfolgen, die der Kunde bereitstellt usw.
# 3) Dokumentation der analysierten Anforderungen
Sobald die Analyse der Anforderungen abgeschlossen ist, beginnt die Anforderungsdokumentation. Aus der Analyse der Anforderungen ergeben sich verschiedene Arten von Anforderungen.
Einige davon sind:
(ich) Kundenanforderungsspezifikation.
(ii) Softwarearchitekturanforderung.
Beispiel:
(iii) Software-Design-Anforderung.
Beispiel:
(iv) Funktionale Anforderungsspezifikation (direkt abgeleitet aus Kundenspezifikationen.)
Beispiel: 'Wenn der Benutzer auf das Bluetooth-Symbol im Infotainment-HMI tippt, sollte der Bluetooth-Bildschirm angezeigt werden.'
(v) Nicht funktionierende Anforderungsspezifikation (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.'
(wir) Anforderungen an die Benutzeroberfläche.
Beispiel: 'Auf dem Tuner FM-Bildschirm sollte eine Schaltfläche zur Auswahl verschiedener Sender bereitgestellt werden.'
Die oben genannten Anforderungen werden in Anforderungsmanagement-Tools wie IBM DOORS und HP QC aufgezeichnet und dokumentiert. Manchmal verfügen Unternehmen über maßgeschneiderte Tools für das Anforderungsmanagement, um die Kosten zu senken.
Lassen Sie uns nun den Konvertierungsprozess untersuchen Geschäftsanforderungen zu Software Anforderungen (funktional und nicht funktional).
Konvertieren von Geschäftsanforderungen in Softwareanforderungen
Geschäftsanforderungen, wie oben erläutert, sind allgemeine Anforderungen, 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 der Implementierung des Softwaresystems oder der Softwarekomponente nicht erwähnt wird.
Daher müssen die Geschäftsanforderungen in detailliertere Softwareanforderungen unterteilt werden, die detaillierter in funktionale und nicht funktionale Anforderungen unterteilt werden.
Dazu können die folgenden Schritte ausgeführt werden:
- Teilen Sie die Geschäftsanforderungen auf hoher Ebene in detaillierte User Stories auf.
- Ableiten eines Flussdiagramms zum Definieren des Aktivitätsflusses.
- Bereitstellung der Bedingung, die die abgeleiteten User Stories rechtfertigt.
- Drahtgitterdiagramme zur Erläuterung des Workflows von Objekten.
- Definieren nicht funktionaler Anforderungen aus den Geschäftsanforderungen.
Beginnen wir mit einem Beispiel für ein Infotainment-System für die Automobilindustrie.
In der Geschäftsanforderung heißt es: „Der Endbenutzer sollte über das Infotainment-System-HMI auf das Navigations-Widget-Feld zugreifen und die Zieladresse festlegen können.“
Die oben aufgeführten Schritte können also wie folgt implementiert werden:
# 1) Teilen Sie die Geschäftsanforderungen auf hoher Ebene in detaillierte User Stories auf.
Lassen Sie uns diese Geschäftsanforderung in eine hochrangige User Story umwandeln. “ Als Benutzer sollte ich auf das Navigations-Widget-Feld zugreifen können, 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 soll.
Beginnen wir damit, mögliche Fragen zu dieser User Story zu stellen.
- Wer sind die Benutzer?
- Wie kann ich auf die Navigation, an Bord (von der SD-Karte) oder von SmartPhone aus zugreifen?
- Welche Art von Zieleinträgen kann ich eingeben?
- Sollte ich das Ziel auch dann betreten dürfen, wenn das Auto geparkt ist?
Hierbei handelt es sich um detailliertere User Stories, die aus High-Level-User Stories abgeleitet wurden und uns helfen, mehr Einblick in unsere Geschäftsanforderungen zu erhalten.
An diesem Punkt können wir eine der User-Untergeschichten aufgreifen und mit der Befragung beginnen. Nehmen wir (Nr. 3):
- Kann ich Zieleinträge wie Geokoordinaten, Postanschrift, Spracherkennung usw. eingeben?
- Benötige ich GPS zur Eingabe von Geokoordinaten?
- Kann ich die aktuelle Zieladresse eingeben, indem ich aus dem Adressverlauf suche?
# 2) Ableiten eines Flussdiagramms zur Definition des Aktivitätsflusses.
Jetzt können wir sehen, dass die Geschäftsanforderungen in sehr detaillierte Anwendungsfälle unterteilt sind, 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 User Stories auf niedriger Ebene und in das Flussdiagramm entstehen. Aus diesem Flussdiagramm können wir die technischen Details abrufen, die für die Implementierung erforderlich sind.
- Die Ladezeit des Bildschirms zur Anzeige des Zieleintrags sollte 1 Sekunde betragen.
- Die Zieleingabetastatur sollte alphanumerische Zeichen und Sonderzeichen enthalten.
- Die Schaltfläche zum Aktivieren / Deaktivieren des GPS-Schalters 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 Features implementiert werden.
# 4) Drahtgitterdiagramme zur Erläuterung des Arbeitsablaufs von Objekten.
Aus dem obigen Anwendungsfall werden wir ein Drahtgitterdiagramm ableiten, das die Benutzeroberfläche klarer macht.
# 5) Definieren nicht funktionaler Anforderungen aus den Geschäftsanforderungen.
Es ist unbedingt erforderlich, dass detaillierte Softwareanforderungen aus Geschäftsanforderungen auf hoher Ebene abgeleitet werden. Oft werden jedoch nur funktionale Anforderungen identifiziert, die angeben, wie sich ein System gegenüber einer bestimmten Benutzereingabe / -aktion verhält.
Die funktionalen 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, im Freisprechmodus auch ein eingehender Anruf über Bluetooth eingeht, steigt der CPU- und RAM-Verbrauch bei mehreren Prozessen auf ein maximales Niveau läuft im Hintergrund.
Wenn der Fahrer zu diesem Zeitpunkt auf eine Touchscreen-Oberfläche des Infotainmentsystems tippt, um eingehende Anrufe per SMS mit automatischer Antwort abzulehnen (wie bei unseren Mobiltelefonen), sollte das System diese Aufgabe ausführen können und nicht hängen bleiben oder abstürzen. Dies ist die Leistung des Systems, wenn die Last hoch ist und wir die Verfügbarkeit und Zuverlässigkeit testen.
b) Ein weiterer Fall ist das Stressszenario.
Ein Beispiel: Das Infotainmentsystem empfängt über das verbundene Bluetooth-Telefon hintereinander SMS (möglicherweise 20 SMS innerhalb von 10 Sekunden). Das Infotainment-System sollte in der Lage sein, alle eingehenden SMS zu verarbeiten, und sollte zu keinem Zeitpunkt die eingehende SMS-Benachrichtigung auf dem Infotainment-HMI verpassen.
Die obigen Beispiele sind Fälle von nicht funktionalen Anforderungen, die nicht allein über funktionale Anforderungen getestet werden konnten. Obwohl Kunden manchmal die Bereitstellung dieser nicht funktionalen Anforderungen verpassen. Es liegt in der Verantwortung der Organisation, diese Informationen bereitzustellen, wenn ein Produkt an den Kunden geliefert wird.
Grundlegendes zu nicht funktionalen Anforderungsfällen
In der folgenden Tabelle werden nichtfunktionale Anforderungen erläutert:
Sl. Nein | Feature / Anwendungsfall | CPU-Auslastung (max) | RAM-Auslastung (maximal 512 MB) | Leistungsparameter |
---|---|---|---|---|
ein | Max nein von Bluetooth-Geräten, die mit dem Infotainment-System gekoppelt werden können | 75% | 300 MB | 10 Bluetooth-Geräte |
zwei | Zeit zum Herunterladen von 2000 Telefonkontakten im Infotainment-System nach Bluetooth-Kopplung und -Verbindung | 90% | 315 MB | 120 Sekunden |
3 | Zeit zum Scannen aller verfügbaren UKW-Sender im Tuner im Infotainmentsystem | fünfzig% | 200 MB | 30 Sekunden |
Nicht funktionale Anforderungen benötigen im Gegensatz zu funktionalen Anforderungen den gesamten Lebenszyklus eines Projekts, um implementiert zu werden, da sie schrittweise in den jeweiligen Agile Sprints oder in verschiedenen Iterationen implementiert werden.
Auf diese Weise leiten wir Softwareanforderungen aus Geschäftsanforderungen ab.
Unterschied zwischen Geschäftsanforderungen und Softwareanforderungen
Wir haben oben gesehen, wie Softwareanforderungen aus allgemeinen Geschäftsanforderungen abgeleitet werden können. Die Softwareanforderungen ermöglichen es dem Programmierer und Testingenieur, das System zu entwickeln und effizient zu testen. Wir wissen jetzt, dass Geschäftsanforderungen hohe Anforderungen an die natürliche Sprache der Kunden sind, während Softwareanforderungen detaillierte Anforderungen auf niedriger Ebene sind, die bei der Implementierung des Softwaresystems hilfreich sind.
Lassen Sie uns den detaillierten Unterschied zwischen den beiden Anforderungstypen untersuchen.
Geschäftsanforderungen | Software Anforderungen |
---|---|
Dies sind hohe Anforderungen eines Kunden, der sagt, was das System tun soll. Diese Anforderungen sagen nicht aus, wie die Anforderungen funktionieren sollen. | Sie konzentrieren sich auf das Wie der Kundenanforderungen. Diese Anforderungen erklären, wie das System funktionieren / implementieren würde. |
Diese Anforderungen befassen sich mit dem Geschäftsziel einer Organisation. Beispiel: Der Benutzer sollte in der Lage sein, das Navigationsziel festzulegen. | Diese Anforderungen erläutern das technische Know-how der Anforderungen. Beispiel: Wenn der Benutzer auf das Navigationszielsymbol klickt, sollte die Datenbank die Zieldetails laden, die der Benutzer eingeben kann. |
Die Geschäftsanforderungen konzentrieren sich auf den Nutzen des Unternehmens. Beispiel: Der Benutzer sollte vom Händler im Infotainment-System Informationen zum Aktualisieren der Navigationsfunktion erhalten, wenn auf dem System keine Navigation vorhanden ist und der Benutzer auf das Navigationssymbol tippt. | Die Softwareanforderungen befassen sich mit den Implementierungsdetails der Geschäftsanforderungen im System. Beispiel: Wenn der Benutzer auf das Navigationssymbol im Infotainment-System klickt, sollte ein API-Aufruf initiiert werden, um dem Benutzer eine Nachricht zur Systemaktualisierung anzuzeigen. |
Geschäftsanforderungen werden normalerweise in natürlicher Sprache oder in hochrangigen User Stories geschrieben. | Die Softwareanforderungen sind funktional und nicht funktionsfähig. Beispiel: Zu den nicht funktionalen Anforderungen zählen Leistung, Stress, Portabilität, Benutzerfreundlichkeit, Speicheroptimierung, Erscheinungsbild usw. |
Fazit
Die Anforderungsanalyse ist das Rückgrat jedes SDLC-Modells.
Ein Problem, das bei der Anforderungsanalyse übersehen und bei Unit-Tests festgestellt wurde, kann für ein Unternehmen Zehntausende von Dollar kosten, und diese Kosten können zu Millionen von Dollar führen, wenn es als Rückruf vom Markt kommt (im Jahr 2017 hat der US-amerikanische Airbag-Hersteller Takata a Geldstrafe von 1 Milliarde US-Dollar wegen explodierender Airbags).
Die Organisation würde am Ende Schadenskontrollaufgaben wie die Ursachenanalyse durchführen, 5 Warum-Dokumente, Fehlerbaum-Analyse, 8D-Dokument usw. vorbereiten, anstatt sich auf Softwareentwicklung und -qualität zu konzentrieren.
beste Software, um IP-Adresse zu verbergen
Im schlimmsten Fall würde die Organisation in vom Kunden eingereichte Rechtsstreitigkeiten verwickelt, wenn die betroffene Funktion sicherheitsrelevant ist, wie Sicherheitszugang, Airbag, ABS (Antiblockiersystem) usw.
Literatur-Empfehlungen
- SDLC-Phasen (Software Development Life Cycle), Methoden, Prozesse und Modelle
- Merkmale funktionaler und nicht funktionaler Anforderungen
- Wie teste ich die Software Requirements Specification (SRS)?
- 5 Tödliche Fehler im Anforderungsmanagement und wie man sie überwindet
- Wie teste ich eine Anwendung ohne Anforderungen?
- Maßnahmen für SSDLC (Secure Software Development Life Cycle)
- Spiralmodell - Was ist das SDLC-Spiralmodell?
- Was ist das SDLC-Wasserfallmodell?