Analyse der Softwareanforderungen anhand eines Beispiels
Charles Moore
Im Zusammenhang mit Bankanwendungen besteht die funktionale Anforderung beispielsweise darin, dass der Kunde, wenn er „Kontostand anzeigen“ auswählt, in der Lage sein muss, seinen aktuellen Kontostand anzuzeigen.
Eine Softwareanforderung kann auch eine nichtfunktionale oder eine Leistungsanforderung sein. Eine nicht funktionale Anforderung besteht beispielsweise darin, dass jede Seite des Systems für die Benutzer innerhalb von 5 Sekunden sichtbar sein sollte.
Also im Wesentlichen Softwareanforderung ist a
- Funktionelle bzw
- Nicht funktionsfähig
technische Das muss in das System implementiert werden. Softwareanforderungen werden normalerweise als Aussagen ausgedrückt.
Arten von Anforderungen
- Geschäftsanforderungen: Dies sind Anforderungen auf hoher Ebene, die aus dem Business Case der Projekte übernommen werden. Beispielsweise bietet ein mobiles Bankdienstsystem Bankdienstleistungen für Südostasien an. Die Geschäftsanforderungen, die für Indien festgelegt werden, sind Kontoübersicht und Geldtransfer, während für China Kontoübersicht und Rechnungszahlung als Geschäftsanforderungen festgelegt werden
| Land | Unternehmen, das Bankfunktionen oder -dienstleistungen bereitstellt |
|---|---|
| Indien | Kontoübersicht und Geldtransfer |
| China | Kontoübersicht und Bill Bezahlung |
- Architechnische und gestalterische Anforderungen: Diese Anforderungen sind detaillierter als Geschäftsanforderungen. Sie bestimmen das Gesamtdesign, das zur Implementierung der Geschäftsanforderungen erforderlich ist. Für unsere Bildungseinrichtung wären die Anwendungsfälle für Architektur und Design Login, Kursdetails usw. Die Anforderungen wären wie unten dargestellt.
| Anwendungsfall Banking | Anforderung |
|---|---|
| Bill Bezahlung | Dieser Anwendungsfall beschreibt, wie sich ein Kunde beim Net Banking anmelden und das nutzen kann Bill Zahlungsmöglichkeit.
Der Kunde kann ein Dashboard mit den offenen Rechnungen registrierter Rechnungssteller sehen. Er kann Rechnungsstellerdetails hinzufügen, ändern und löschen. Der Kunde kann SMS- und E-Mail-Benachrichtigungen für verschiedene Rechnungsaktionen konfigurieren. Er kann den Verlauf der zuletzt bezahlten Rechnungen sehen. Die Akteure, die diesen Anwendungsfall starten, sind Bankkunden oder Supportmitarbeiter. |
- System- und Integrationsanforderungen: Auf der untersten Ebene haben wir System- und Integrationsanforderungen. Es handelt sich um eine detaillierte Beschreibung jeder einzelnen Anforderung. Dies kann in Form von Benutzergeschichten erfolgen, die eigentlich die alltägliche Geschäftssprache beschreiben. Die Anforderungen sind sehr detailliert, sodass Entwickler mit dem Codieren beginnen können. Hier ein Beispiel für Bill Zahlungsmodul, in dem die Anforderung zum Hinzufügen eines angegeben wird Biller
| Bill Bezahlung | Voraussetzungen: |
|---|---|
| Speichern BillERS |
|
Manchmal erhalten Sie für ein Projekt keine Anforderungen oder Dokumente, mit denen Sie arbeiten können. Dennoch gibt es noch andere Anforderungsquellen, die Sie für die Anforderung oder Informationen berücksichtigen können, sodass Sie Ihre Software oder Ihr Testdesign auf diesen Anforderungen aufbauen können. Die anderen Quellen für Anforderungen, auf die Sie sich verlassen können, sind also:
Andere Anforderungsquellen
- Wissenstransfer von Kollegen oder Mitarbeitern, die bereits an diesem Projekt arbeiten
- Sprechen Sie mit Business-Analysten, Produktmanagern, Projektleitern und Entwicklern über das Projekt
- Analysieren Sie die vorherige Systemversion, die bereits im System implementiert ist
- Analysieren Sie das ältere Anforderungsdokument des Projekts
- Schauen Sie sich die früheren Fehlerberichte an. Einige der Fehlerberichte werden in Verbesserungsanfragen umgewandelt, die möglicherweise in die aktuelle Version implementiert werden
- Schauen Sie in der Installationsanleitung nach, falls diese verfügbar ist, um zu erfahren, welche Installation erforderlich ist
- Analysieren Sie das Domänen- oder Branchenwissen, das das Team implementieren möchte
Unabhängig von der Quelle Ihrer Anforderungen dokumentieren Sie diese unbedingt in irgendeiner Form und lassen Sie sie von anderen erfahrenen und sachkundigen Teammitgliedern überprüfen.
So analysieren Sie Anforderungen
Betrachten Sie das Beispiel eines Bildungssoftwaresystems, bei dem sich ein Student für verschiedene Kurse anmelden kann.
Lassen Sie uns untersuchen, wie die Anforderungen analysiert werden. Die Anforderungen müssen eine Standardqualität ihrer Anforderung aufrechterhalten, die verschiedene Arten der Anforderungsqualität umfasst
- Atomic
- Eindeutig identifiziert
- Komplett
- Konsequent und eindeutig
- Rückverfolgbar
- Priorisiert
- Testbar
Lassen Sie uns dies anhand eines Beispiels verstehen. Die hier gezeigte Tabelle enthält drei Spalten:
- Die erste Spalte gibt an: „Anforderungsqualität“
- Die zweite Spalte gibt an: „schlechte Anforderung mit einigen Problemen“
- Die dritte Spalte entspricht der zweiten Spalte, jedoch „in eine gute Anforderung umgewandelt“.
| Anforderungsqualität | Beispiel für eine schlechte Anforderung | Beispiel für eine gute Anforderung |
|---|---|---|
| Atomic |
|
|
| Eindeutig identifiziert | 1- Studierende können sich für Grundstudiengänge anmelden. 1- Studierende können sich für Aufbaustudiengänge 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 | Registrierte Studierende – Priorität 1. Benutzerinformationen verwalten – Priorität 1. Kurse anmelden – Priorität 1 – Zeugnis anzeigen – Priorität 1 | Studenten registrieren – Priorität 1 – Benutzerinformationen verwalten – Priorität 2 – Kurse anmelden – Priorität 1 – Zeugnis anzeigen – 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 nun jede dieser Anforderungen im Detail verstehen, beginnend mit AtomNS.
Atomic
Jede einzelne Anforderung sollte also atomar sein, das heißt, sie sollte auf einem sehr niedrigen Detailniveau sein und nicht in Komponenten zerlegt werden können. Hier sehen wir die beiden Beispiele für Anforderungen, AtomIC- und eindeutig identifizierte Anforderungsniveaus.
Fahren wir also mit dem Beispiel eines Systems fort, das für den Bildungsbereich erstellt wurde. Hier lautet die schlechte Anforderung: „Studenten können sich für Grund- und Aufbaustudiengänge einschreiben.“ Dies ist eine schlechte Anforderung, da sie nicht atomar ist, da sie sich auf zwei verschiedene Einheiten bezieht: Grund- und Aufbaustudiengänge. Es handelt sich also offensichtlich nicht um eine gute Anforderung, sondern um eine schlechte Anforderung. Eine entsprechende gute Anforderung wäre also, sie in zwei Anforderungen aufzuteilen. Die eine betrifft also die Einschreibung in Grundstudiengänge, die andere die Einschreibung in Aufbaustudiengänge.
Eindeutig identifiziert
In ähnlicher Weise besteht die nächste Anforderungsqualität darin, auf eindeutige Identifizierung zu prüfen. Hier haben wir zwei separate Anforderungen, die jedoch beide dieselbe ID Nr. 1 haben. Wenn wir also unsere Anforderung mit Bezug auf die ID-Nummer verweisen, aber nicht klar ist, auf welche genaue Anforderung wir uns beziehen, auf ein Dokument oder einen anderen Teil des Systems, da beide dieselbe ID-Nummer 1 haben. Wenn man also mit eindeutigen IDs trennt, ist es eine gute Voraussetzung, als Abschnitt 1-Kurseinschreibungen erneut zurückgegeben zu werden, und es gibt zwei Anforderungen: 1.1 ID ist die Einschreibung für Grundstudiengänge, während 1.2 ID die Einschreibung für Aufbaustudiengänge ist.
Komplett
Außerdem sollte jede einzelne Anforderung vollständig sein. Hier heißt es zum Beispiel in der schlechten Anforderung, dass „ein Professor-Benutzer sich beim System anmeldet, indem er seinen Benutzernamen, sein Passwort und andere relevante Informationen angibt“. Hier sind die anderen relevanten Informationen nicht klar, daher sollten die anderen relevanten Informationen in einer guten Anforderung dargelegt werden, um die Anforderung zu vervollständigen.
Konsequent und eindeutig
Als Nächstes sollte jede einzelne Anforderung konsistent und eindeutig sein. Hier haben wir beispielsweise die Anforderungen „Ein Student muss entweder Grundstudiengänge oder Aufbaustudiengänge belegen, aber nicht beides.“ Dies ist eine Anforderung, es gibt eine andere Anforderung, die besagt: „Einige Kurse werden dies tun.“ sowohl für Bachelor- als auch für Postgraduiertenstudierende offen sein“.
Das Problem bei dieser Anforderung besteht darin, dass es bei der ersten Anforderung so aussieht, als seien die Kurse in zwei Kategorien unterteilt: Graduiertenkurse und Postgraduiertenkurse, und der Student kann sich für eine von beiden, aber nicht für beide entscheiden. Wenn Sie jedoch die anderen Anforderungen lesen, stehen diese im Widerspruch zur ersten Anforderung und weisen darauf hin, dass einige Kurse sowohl für Postgraduierte als auch für Bachelor-Studierende offen sind.
Daher ist es naheliegend, diese schlechte Anforderung in eine gute Anforderung umzuwandeln, die lautet: „Ein Student wird entweder Bachelor- oder Postgraduiertenkurse belegen, aber nicht beides.“ Das bedeutet, dass jeder Kurs entweder als Bachelor- oder Postgraduiertenkurs gekennzeichnet wird
Rückverfolgbar
Jede einzelne Anforderung sollte nachvollziehbar sein, da es bereits unterschiedliche Anforderungsebenen gibt. Wir haben bereits gesehen, dass wir ganz oben die Geschäftsanforderungen haben, dann kommen Architektur- und Designanforderungen, gefolgt von den Anforderungen an die Systemintegration.
Wenn wir nun Geschäftsanforderungen in Architektur- und Designanforderungen oder Architektur- und Designanforderungen in Systemintegrationsanforderungen umwandeln, muss eine Rückverfolgbarkeit gewährleistet sein. Das bedeutet, dass wir in der Lage sein müssen, jede einzelne Geschäftsanforderung zu nehmen und sie den entsprechenden einer oder mehreren Software-Architektur- und Designanforderungen zuzuordnen. Hier ist also ein Beispiel für eine fehlerhafte Anforderung, die lautet: „Studenteninformationen pflegen – der BRD-Anforderungs-ID zugeordnet?“ Die Anforderungs-ID wird hier nicht angegeben.
Wenn man es also in eine gute Anforderung umwandelt, heißt es dasselbe, aber es ist der Anforderungs-ID 4.1 zugeordnet. Daher sollte für jede einzelne Anforderung eine Zuordnung vorhanden sein. Genauso wie wir Mapping-Anforderungen auf hoher und niedriger Ebene haben, gibt es auch eine Zuordnung zwischen System und Integrationsanforderung zu dem Code, der diese Anforderung implementiert, und es gibt auch eine Zuordnung zwischen System und Integrationsanforderung zu dem Testfall, der diese bestimmte Anforderung testet .
Diese Rückverfolgbarkeit erstreckt sich also über das gesamte Projekt
Priorisiert
| Priorisiert | Eingeschriebener Student – Priorität 1 Benutzerinformationen beibehalten – Priorität 1 Kurse anmelden – Priorität 1 Zeugnis anzeigen – Priorität 1 |
Registrieren Sie sich mit Studentenpriorität 1 Benutzerinformationen beibehalten – Priorität 2 Kurse anmelden – Priorität 1 Zeugnis anzeigen-Priorität3 |
Dann muss jede einzelne Anforderung priorisiert werden, damit das Team Richtlinien hat, welche Anforderungen zuerst umgesetzt werden können und welche später erledigt werden können. Hier können Sie sehen, dass die schlechte Priorität „Studenten registrieren“, „Benutzerinformationen pflegen“ und jede einzelne Anforderung die Priorität 1 hat. Nicht alles kann die gleiche Priorität haben, daher können Anforderungen priorisiert werden. Das Beispiel einer guten Anforderung hier ist also, dass „Studenten registrieren“ und „Kurse belegen“ die höchste Priorität 1 haben, während „Benutzerinformationen pflegen“ darunter auf Priorität 2 kommt und wir dann „Zeugnis anzeigen“ auf Priorität 3 haben.
Testbar
| 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 |
Jede einzelne Anforderung sollte testbar sein. Hier lautet die schlechte Anforderung: „Jede Seite des Systems wird in einem akzeptablen Zeitrahmen geladen.“ Nun gibt es bei dieser Anforderung zwei Probleme. Erstens besteht darin, dass jede Seite viele Seiten umfassen kann, was den Testaufwand sprengen würde. Das andere Problem besteht darin, dass es heißt, dass die Seite in einem akzeptablen Zeitrahmen geladen wird. Was ist nun ein akzeptabler Zeitrahmen? Akzeptabel für wen. Wir müssen also das nicht überprüfbare Argument in ein überprüfbares Argument umwandeln, das konkret angibt, um welche Seite es sich handelt: „Seiten „Studenten registrieren und Kurse einschreiben““ und der akzeptable Zeitrahmen ist ebenfalls angegeben, der 5 Sekunden beträgt.
Schlussfolgerung
So müssen wir jede einzelne Anforderung auf der entsprechenden Ebene betrachten. Wenn wir beispielsweise eine Software im Hinblick auf System- und Integrationsanforderungen entwickeln wollen, müssen wir uns die System- und Integrationsanforderungen ansehen, die in den Softwareanforderungsspezifikationen oder Benutzergeschichten angegeben sind, und sie auf die Qualität jeder einzelnen Anforderung anwenden. Dann prüfen wir, ob jede einzelne Anforderung atomar, eindeutig identifiziert und vollständig ist usw.