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 auswรคhlen | Unternehmen, das Bankfunktionen oder -dienstleistungen bereitstellt |
|---|---|
| Indien | Kontoรผbersicht und Geldtransfer |
| China, Kambodscha | Kontoรผbersicht und Bill Zahlung |
- 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 Zahlung | 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 Zahlung | 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 erfรผllt sein traceable, da es bereits unterschiedliche Anforderungsebenen gibt. Wir haben bereits gesehen, dass wir ganz oben Geschรคftsanforderungen haben, dann Architektur- und Designanforderungen, gefolgt von Systemintegrationsanforderungen.
Wenn wir nun Geschรคftsanforderungen in Architektur- und Designanforderungen oder Architektur- und Designanforderungen in Systemintegrationsanforderungen umwandeln, muss Folgendes gegeben sein: tracZuordnungsfรคhigkeit bedeutet, dass wir jede einzelne Geschรคftsanforderung einer oder mehreren entsprechenden Softwarearchitektur- und Designanforderungen zuordnen kรถnnen sollten. Ein Beispiel fรผr eine fehlerhafte Anforderung lautet: โStudenteninformationen pflegen โ Zuordnung zur BRD-Anforderungs-ID?โ Die Anforderungs-ID fehlt.
Die Umwandlung in eine sinnvolle Anforderung besagt also dasselbe, ist aber der Anforderungs-ID 4.1 zugeordnet.ping Fรผr jede einzelne Anforderung sollte etwas vorhanden sein. Genauso wie wir eine รbersichtskarte und eine Detailkarte haben.ping Anforderung, die Karteping Es besteht auch eine Verbindung zwischen System- und Integrationsanforderungen an den Code, der diese Anforderungen implementiert, und es gibt auch eine Zuordnung.ping zwischen der System- und Integrationsanforderung und dem Testfall, der diese spezielle Anforderung prรผft.
Also das tracDie Belastbarkeit zieht sich durch 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.
Fazit
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.
