Analyse der Softwareanforderungen anhand eines Beispiels

Eine Softwareanforderung ist ein funktionales oder nicht-funktionales Bedürfnis, das im System umgesetzt werden muss. Funktional bedeutet, dem Benutzer einen bestimmten Dienst bereitzustellen.

Beispielsweise besteht die funktionale Anforderung im Kontext einer Banking-Anwendung darin, dass ein Kunde, wenn er „Kontostand anzeigen“ auswählt, seinen aktuellen Kontostand einsehen können sollte.

Eine Softwareanforderung kann auch nicht-funktionaler Natur sein, wie beispielsweise eine Leistungsanforderung. So könnte eine nicht-funktionale Anforderung besagen, dass jede Seite des Systems innerhalb von 5 Sekunden für die Benutzer geladen werden soll.

Also im Wesentlichen Softwareanforderung ist a

• Funktional oder
• Nicht funktionsfähig

technische Das muss in das System implementiert werden. Softwareanforderungen werden üblicherweise als Aussagen formuliert.

Arten von Anforderungen

GeschäftsanforderungenDies sind übergeordnete Anforderungen, die dem Business Case des Projekts entnommen wurden. Beispielsweise bietet ein mobiles Banking-System Bankdienstleistungen in Südostasien an. Die für Indien festgelegte Geschäftsanforderung umfasst Kontoübersicht und Geldtransfer, während sie für China Kontoübersicht und Rechnungszahlung beinhaltet.

Land auswählen	Unternehmen, das Bankfunktionen oder -dienstleistungen bereitstellt
Indien	Kontoübersicht und Geldtransfer
China, Kambodscha	Kontoübersicht und Bill Zahlung

Architechnische und gestalterische AnforderungenDiese Anforderungen sind detaillierter als Geschäftsanforderungen und bestimmen die Lösungsarchitektur. Sie legen das Gesamtdesign fest, das zur Umsetzung der Geschäftsanforderungen erforderlich ist. Typische Anwendungsfälle für Architektur und Design in einer Bildungseinrichtung umfassen Login, Kursdetails und Einschreibung. Die Anforderungen wären wie folgt:

Anwendungsfall Banking

Anforderung

Bill Zahlung

Dieser Anwendungsfall beschreibt, wie sich ein Kunde beim Net Banking anmelden und das nutzen kann Bill Zahlungsfunktion. Der Kunde kann ein Dashboard mit offenen Rechnungen registrierter Rechnungssteller einsehen. Er kann Rechnungssteller hinzufügen, bearbeiten und löschen. Zudem kann er SMS- und E-Mail-Benachrichtigungen für verschiedene Abrechnungsvorgänge konfigurieren und seine Zahlungshistorie einsehen. Diese Anwendung wird von Bankkunden oder Supportmitarbeitern genutzt.

System- und IntegrationsanforderungenAuf der untersten Ebene finden sich die System- und Integrationsanforderungen. Diese liefern eine detaillierte Beschreibung jeder einzelnen Anforderung. Sie lassen sich in Form von User Stories in verständlicher Geschäftssprache festhalten. Die Anforderungen sind so detailliert, dass die Entwickler direkt mit der Programmierung beginnen können. Bill Das unten stehende Beispiel des Zahlungsmoduls zeigt die Anforderung zum Hinzufügen eines Rechnungsstellers.

Bill Zahlung	Voraussetzungen:
Speichern BillERS	Name des Versorgungsunternehmens, Kundennummer, Automatische Zahlungen – Ja/Nein, Gesamtbetrag bezahlen Bill – Ja/Nein, Limit für automatische Zahlungen – Nicht zahlen, wenn Bill liegt über dem angegebenen Betrag

Manchmal erhalten Sie für ein Projekt keine Anforderungen oder Dokumente. Auch dann gibt es andere Informationsquellen, auf die Sie sich bei der Entwicklung Ihrer Software oder Ihres Testdesigns stützen können. Diese Informationsquellen sind unten aufgeführt.

Andere Anforderungsquellen

• Wissenstransfer von Kollegen oder Mitarbeitern, die bereits an diesem Projekt arbeiten
• Besprechen Sie das Projekt mit dem Business Analysten, dem Produktmanager, dem Projektleiter und den Entwicklern.
• Analysieren Sie die vorherige Version des bereits implementierten Systems.
• Ältere Anforderungsdokumente aus dem Projekt analysieren
• RevSehen Sie sich frühere Fehlerberichte an; einige Fehlerberichte werden in Verbesserungsvorschläge umgewandelt, die möglicherweise in der aktuellen Version umgesetzt werden.
• Prüfen Sie, falls verfügbar, die Installationsanleitung, um zu erfahren, welche Installationen erforderlich sind.
• Analysieren Sie das Domänen- oder Branchenwissen, das das Team implementieren möchte.

Unabhängig davon, welche Anforderungsquelle Sie verwenden, dokumentieren Sie die Anforderungen in einem gemeinsamen Format und lassen Sie sie von erfahrenen Teammitgliedern überprüfen.

So analysieren Sie Anforderungen

Nehmen wir als Beispiel ein Lernsoftwaresystem, in dem sich ein Student für verschiedene Kurse anmelden kann.

Lassen Sie uns untersuchen, wie die Anforderungen analysiert werden. Jede Anforderung muss eine Reihe von Standardqualitätsmerkmalen aufweisen, darunter die folgenden:

• Atomic
• Eindeutig identifiziert
• Komplett
• Konsequent und eindeutig
• Rückverfolgbar
• Priorisiert
• Testbar

Die folgende Tabelle veranschaulicht jedes Attribut anhand von drei Spalten:

1. Die erste Spalte gibt an: „Anforderungsqualität“
2. Die zweite Spalte gibt an: „schlechte Anforderung mit einigen Problemen“
3. In der dritten Spalte wird dieselbe Anforderung „in eine gute Anforderung umgewandelt“ dargestellt.

Anforderungsqualität	Beispiel für eine schlechte Anforderung	Beispiel für eine gute Anforderung
Atomic	Studierende können sich für Bachelor- und Postgraduiertenstudiengänge anmelden	Studierende können sich für Bachelorstudiengänge anmelden. Studierende können sich für Masterstudiengänge anmelden.
Eindeutig identifiziert	1. Studierende können sich für Bachelorstudiengänge einschreiben. 1. Studierende können sich für Masterstudiengänge einschreiben.	Kursanmeldung. Studierende können sich für Bachelor-Kurse anmelden. Studierende können sich für Master-Kurse anmelden.
Komplett	Ein Professor-Benutzer meldet sich beim System an, indem er seinen Benutzernamen, sein Passwort und andere relevante Informationen angibt	Ein Professor-Benutzer meldet sich beim System an, indem er seinen Benutzernamen, sein Passwort und seinen Abteilungscode angibt
Konsequent und eindeutig	Ein Student wird entweder Grundstudiengänge oder Aufbaustudiengänge belegen, jedoch nicht beides. Einige Kurse stehen sowohl Bachelor- als auch Postgraduierten-Studierenden offen	Ein Student hat entweder einen Bachelor- oder einen Postgraduiertenabschluss, aber nicht beides
Rückverfolgbar	Studenteninformationen beibehalten, die der BRD-Anforderungs-ID zugeordnet sind?	Pflegen Sie Studenteninformationen – zugeordnet zu BRD-Anforderungs-ID 4.1
Priorisiert	Registrierter Student – ​​Priorität 1. Benutzerinformationen verwalten – Priorität 1. Kurse belegen – Priorität 1. Zeugnis einsehen – Priorität 1	Schülerregistrierung – Priorität 1. Benutzerinformationen verwalten – Priorität 2. Kurse belegen – Priorität 1. Zeugnis einsehen – Priorität 3.
Testbar	Jede Seite des Systems wird in einem akzeptablen Zeitrahmen geladen	Die Seiten „Studenten registrieren“ und „Kurse anmelden“ des Systems werden innerhalb von 5 Sekunden geladen

Lassen Sie uns jedes dieser Merkmale genauer betrachten, beginnend mit AtomNS.

Atomic

Jede Anforderung sollte atomar sein, d. h. sie muss auf der kleinstmöglichen Detailebene formuliert sein und darf nicht weiter in Komponenten zerlegt werden. Die folgenden Beispiele vergleichen atomare und nicht-atomare Anforderungen.

Um beim Beispiel des Bildungssystems zu bleiben: Die fehlerhafte Anforderung lautet: „Studierende können sich sowohl für Bachelor- als auch für Masterstudiengänge einschreiben.“ Diese Anforderung ist fehlerhaft, da sie nicht atomar ist – sie vermischt Bachelor- und Masterstudiengänge. Die entsprechende korrekte Anforderung trennt sie in zwei separate Anforderungen: eine für die Einschreibung in Bachelorstudiengänge und eine für die Einschreibung in Masterstudiengänge.

Eindeutig identifiziert

Das nächste Qualitätsmerkmal ist die eindeutige Identifizierung. Im ungünstigen Beispiel teilen sich zwei separate Anforderungen dieselbe ID#1. Wenn ein Team eine Anforderung anhand ihrer ID referenziert, ist unklar, welche der beiden gemeint ist. Die korrekte Anforderung gruppiert sie unter Abschnitt 1 – Kurseinschreibung – mit den Unteranforderungen 1.1 (Einschreibung in Bachelorstudiengänge) und 1.2 (Einschreibung in Masterstudiengänge).

Komplett

Jede Anforderung sollte vollständig sein. Beispielsweise lautet die fehlerhafte Anforderung hier: „Ein Professor meldet sich im System an, indem er seinen Benutzernamen, sein Passwort und weitere relevante Informationen angibt.“ „Weitere relevante Informationen“ ist ungenau. Eine vollständige Anforderung listet die exakten Felder auf, wie beispielsweise den Fachbereichscode, die der Professor angeben muss.

Konsequent und eindeutig

Jede Anforderung sollte einheitlich und eindeutig sein. Im negativen Beispiel heißt es in einer Anforderung: „Ein Student belegt entweder Kurse im Bachelor- oder im Masterstudium, aber nicht beides“, während in einer anderen Anforderung steht: „Einige Kurse stehen sowohl Bachelor- als auch Masterstudierenden offen“.

Die erste Anforderung impliziert, dass die Kurse in zwei sich gegenseitig ausschließende Kategorien unterteilt werden, die zweite Anforderung widerspricht dem jedoch, indem sie einige Kurse für beide Gruppen öffnet.

Die positive Anforderung löst den Konflikt, indem sie klarstellt, dass jeder Kurs entweder als Bachelor- oder Masterkurs gekennzeichnet ist und ein Student sich nur in Kurse einer Kategorie einschreiben kann.

Rückverfolgbar

Jede Anforderung muss erfüllt sein traceable, da Anforderungen auf mehreren Ebenen existieren: Geschäftsebene, Architektur- und Designebene sowie System- und Integrationsebene.

Wenn Sie eine Geschäftsanforderung in Architektur- und Designanforderungen oder Architektur- und Designanforderungen in System- und Integrationsanforderungen umwandeln, tracDie Funktionalität muss erhalten bleiben. Jede Geschäftsanforderung sollte einer oder mehreren Architektur- und Designanforderungen zugeordnet werden. Im negativen Beispiel „Studenteninformationen pflegen – Zuordnung zur BRD-Anforderungs-ID?“ fehlt die Anforderungs-ID.

Die korrekte Anforderung enthält dieselbe Aussage, ist aber explizit der BRD-Anforderungs-ID 4.1 zugeordnet. Jede Anforderung muss eine tracFähigkeitskartepingSystem- und Integrationsanforderungen sollten auch dem Code, der sie implementiert, und den Testfällen, die sie überprüfen, zugeordnet werden.

TracDie Funktionalität erstreckt sich daher durch das gesamte Projekt.

Priorisiert

Jede Anforderung muss priorisiert werden, damit das Team weiß, was zuerst umgesetzt werden muss und was warten kann. Im negativen Beispiel haben die Funktionen „Student registrieren“, „Benutzerinformationen verwalten“, „Kurse belegen“ und „Zeugnis anzeigen“ alle die Priorität 1. Da nicht alles Priorität 1 haben kann, müssen die Anforderungen realistisch eingestuft werden. Im positiven Beispiel erhalten „Student registrieren“ und „Kurse belegen“ die höchste Priorität 1, „Benutzerinformationen verwalten“ Priorität 2 und „Zeugnis anzeigen“ Priorität 3.

Testbar

Jede Anforderung sollte testbar sein. Das schlechte Beispiel „Jede Seite des Systems wird in einem akzeptablen Zeitraum geladen“ ist aus zwei Gründen nicht testbar. Erstens kann „jede Seite“ Dutzende von Seiten bedeuten, was den Testaufwand enorm erhöht. Zweitens ist der Begriff „akzeptabler Zeitraum“ nicht definiert – akzeptabel für wen und anhand welcher Kriterien? Die gute Anforderung behebt beide Probleme, indem sie die spezifischen Seiten benennt („Studentenregistrierung“ und „Kursanmeldung“) und ein messbares Ziel von 5 Sekunden festlegt.

Häufig gestellte Fragen