Warum Sie als Software-Ingenieur die Softwareanforderungen verstehen müssen

In diesem Artikel erfahren Sie alles über Softwareanforderungen. Sie erhalten einen Überblick über den Themenbereich, den Prozess und vor allem über Ihre Aufgaben in diesem Bereich als Softwareentwickler.

Sie sollten einen Einblick in Ihre Rolle und Aktivitäten mit Softwareanforderungen erhalten. Wenn überhaupt, haben Sie nach Ihrem nächsten Aufstehen etwas mit Kollegen zu besprechen?

Dieser Artikel lehnt sich stark an den Band an, der der IEEE SWEBOK-Leitfaden ist. Es versucht, einen Teil dieses Wissens zu destillieren und es präziser zu definieren. Falls Sie sich fragen, ist SWEBOK ein Akronym für den Software Engineering Body of Knowledge, der von der IEEE Computer Society verwaltet wird.

Im Voraus, warum ist das wichtig?

Es gibt ein Missverständnis von jenen, die nicht in der Softwareentwicklung sind, dass die Rolle eines Softwareentwicklers darin besteht, nur "Code zu schreiben".

Ja, wir sind Technologen, die es im Allgemeinen lieben, Programmieren zu lernen. In Wirklichkeit ist dies eine vereinfachte Sichtweise, die unterschätzt, was ein Softwareentwickler in seiner täglichen Arbeit und Karriere tatsächlich tut. Es konzentriert sich nur auf einen Teil ihrer Gesamtverantwortung.

Die Rolle eines Softwareentwicklers besteht darin, Geschäftslösungen im Unternehmensmaßstab zu erstellen. Dies beinhaltet eine große Anzahl von Verantwortlichkeiten, die nicht mit dem von ihnen erstellten Code zusammenhängen.

Ein Verantwortungsbereich, den Sie als professioneller Softwareentwickler haben, ist der Bereich der Softwareanforderungen.

Was sind Softwareanforderungen?

Softwareanforderungen an die Oberfläche klingen einfach. Die Software muss X für Y ausführen, damit Z. Denken Sie lange genug über jedes Problem nach, das durch Software gelöst werden könnte (oder über vorhandene Software, die bereits ein Problem löst), und Sie könnten wahrscheinlich eine große Anzahl von Anforderungen erarbeiten. Einfach richtig?

Nein, in der Tat für die meisten Unternehmenssoftware.

Wie erfassen Sie Ihre Anforderungen? Berücksichtigen Sie die Bedürfnisse und Prioritäten der Stakeholder? Ist dies wirklich eine Voraussetzung für Benutzer der Software? Gibt es technische Einschränkungen bei Überlegungen? Woher weißt du, wann es fertig ist? Erfüllt die Anforderungsimplementierung ein festgelegtes Kriterium? Und so weiter...

Wenn Sie sich mit der Idee der Softwareanforderungen befassen, stellen Sie fest, dass sie einen großen und tieferen Wissensbereich verbergen.

Wie tief und groß ist ein Wissensbereich? SWEBOK definiert den Bereich der Softwareanforderungen als " die Ermittlung, Analyse, Spezifikation und Validierung von Softwareanforderungen sowie die Verwaltung von Anforderungen während des gesamten Lebenszyklus des Softwareprodukts ".

Die Größe dieses Bereichs, wie die Anzahl der Aktivitäten und wie involviert sie sein können, gab genügend Glaubwürdigkeit, um einen als " Anforderungs-Engineering " bezeichneten technischen Zweig zu widmen, der sich ausschließlich auf den Anforderungsprozess konzentriert.

Bestimmte Organisationen stellen möglicherweise speziell für die Rolle eines Anforderungsingenieurs ein. Dies tritt möglicherweise häufiger in wirklich großen Organisationen auf, die beispielsweise Lösungen auf Systemebene anbieten, bei denen die vorgeschlagenen Lösungen für Kundenprobleme eine Gesamtlösung umfassen, bei der die Software nur eine einzige Komponente darstellt.

In der Regel teilen Unternehmen die Verantwortung für das Anforderungs-Engineering durch Aktivitäten, die den verschiedenen anderen Projektrollen zugewiesen sind, z. B. Designer, Geschäftsanalysten, Produktbesitzer, Angebots- oder Kundenverwaltung, technische Redakteure, Softwarearchitekten / -ingenieure usw.

Im Allgemeinen ist es schwierig, den Anforderungsprozess in der Praxis in einem linearen Prozess wie einer Wasserfallmethode zu implementieren. Dies würde erfordern, dass Softwareanforderungen von den Stakeholdern ermittelt, klassifiziert, zugewiesen und schließlich dem Softwareentwicklungsteam zur Implementierung übergeben werden. Dies ist für langfristig erfolgreiche Lösungen im Maßstab oft nicht möglich.

Die Anforderungen für diese großen Softwareprojekte werden niemals perfekt verstanden oder genau spezifiziert. Stattdessen iterieren sie normalerweise auf ein Niveau, das gerade so hoch ist, dass Design- und Beschaffungsentscheidungen getroffen werden können.

Das Anforderungs-Engineering unterscheidet sich vom Software-Engineering in der Art der Arbeit, auf die Sie sich konzentrieren.

Es ist wichtig, dass Sie Ihre Verbindung zum Anforderungsprozess verstehen, da Sie wahrscheinlich irgendwann irgendwann an bestimmten Anforderungsaktivitäten beteiligt sind.

Was ist mit den Softwareanforderungen für den Softwareentwickler verbunden?

Abhängig vom Anforderungsprozess Ihres Unternehmens und / oder den Anforderungsaktivitäten, für die der Softwareentwickler verantwortlich ist, können Sie an einer oder allen Phasen beteiligt sein. Dies kann von der Erfassung der Anforderungen bis zur Überprüfung ihrer Implementierung reichen.

Bereiche, in denen Sie beteiligt sein können:

  • Elicitation - das Sammeln von Anforderungen an die Software
  • Klassifizierung - Kategorisierung der Anforderung
  • Validierung - Bestätigung der Anforderung mit den Stakeholdern
  • Entwicklung & Implementierung - Erstellen der Software, um die Anforderungen zu erfüllen
  • Verhandlung - Umgang mit Interessenkonflikten von Stakeholdern
  • Überprüfung - Die Bewertung der Softwarefunktion erfüllt die Anforderung

Es ist erwähnenswert, dass dies kein Duplikat des Anforderungsentwicklungsprozesses ist. Sie erfordern ein tieferes Maß an Einbeziehung und Arten von Aktivitäten in bestimmten Bereichen, wie z. B. die Verwaltung und Dokumentation von Anforderungen.

Das Verwalten und Dokumentieren von Anforderungen liegt normalerweise nicht in Ihrer Verantwortung. Es wird wahrscheinlich eine der anderen Rollen sein, die die Verantwortung für die Anforderungen teilen.

Es ist wichtig, dass Sie wissen, wie Sie auf das Managementsystem von Anforderungen zugreifen und es verwenden, um Anforderungsänderungen und Auswirkungsanalysen zu bewerten.

Ähm, es gibt kein Managementsystem für Anforderungen ...

In einigen Fällen erfolgt die Erfassung und Verwaltung von Anforderungen möglicherweise nicht in einem speziellen System. Sie können in anderen Arten von Aufzeichnungssystemen aufgezeichnet werden, z. B. in einer Software zur Problemverfolgung, in Projektmanagement-Tools oder sogar im Versionskontrollsystem.

In anderen Fällen entwickeln Organisationen oder Projektteams keine Mittel, um Anforderungen zu dokumentieren und zu verwalten. Sie könnten sich stattdessen auf die Vision der Führung stützen (eine Einzelperson oder ein Team, wobei das gemeinsame Beispiel der Firmengründer ist) und / oder über begrenzte Ressourcen verfügen. Sie können dem entgegenwirken, dass das Aufzeichnen oder Verwalten von Anforderungen nicht erforderlich ist.

Das Nichterfassen und Verwalten von Anforderungen kann möglicherweise ein ernstes Risiko für ein Unternehmen und den Softwarelösungsprozess darstellen.

Beispielsweise muss Ihre Organisation, die Lösungen für Kundenbedürfnisse entwickelt, bestimmte gesetzliche Verpflichtungen erfüllen. Sie geben an, dass Ihre Softwarekomponente für bestimmte Funktionen ausgelegt ist und ein bestimmtes Servicelevel (SLAs) bereitstellen kann.

Sollte jedoch ein Konflikt (legal oder anderweitig) auftreten, möglicherweise eine fehlende Funktionalität, eine nicht funktionale Anforderung, die nicht wie erwartet funktioniert, oder sogar Zeit / Budget für unerwünschte Funktionen, wie zeigen Sie, was implementiert wurde, was was war wurde von den Stakeholdern nach Bedarf und Notwendigkeit vereinbart?

Ihre Organisation sollte in der Lage sein, die Zuordnung zwischen den allgemeinen Lösungsanforderungen (was der Kunde als Lösung benötigt) und den validierten Softwareanforderungen zu demonstrieren (was die Stakeholder als Erfüllung der funktionalen Anforderungen der Lösung vereinbart haben, nicht unbedingt 1 zu 1) 1) bis zur Implementierung der Dokumentation und Aufzeichnung von Abnahme- oder Service-Level-Tests, die die bereitgestellte Funktionalität demonstrieren.

Ein weiteres häufigeres (und weniger ausgeklügeltes) Beispiel ist die Bewertung der Auswirkungen. Wenn Ihre Organisation oder Ihr Projektteam wächst und sich weiterentwickelt, wächst auch die von Ihnen erstellte Software. Sofern die Software nicht entbehrlich sein soll, sollte sie über einen bestimmten Zeitraum betrieben werden und daher Upgrades, neuen Funktionen und Wartungsarbeiten unterliegen.

Diese neue Arbeit kann vorhandene Funktionen negieren, beeinflussen oder ändern, um eine historische Anforderung auf verschiedene Weise zu erfüllen (z. B. Ändern der Softwarearchitektur oder des Entwurfs einer Komponente).

In diesem Fall müssen Sie die alten Anforderungen erneut prüfen, um die zugrunde liegenden Motivationen besser zu verstehen. Warum wurde es zum Beispiel so implementiert? Muss sich die aktuelle Arbeit ändern? Ist die alte Anforderung noch relevant? etc.

Ermittlung von Softwareanforderungen

Die Ermittlung von Anforderungen bezieht sich auf die Aktivität, die beschreibt, wie die Anforderungen erfasst oder erfasst werden. Nicht alle Anforderungen werden von einem Kunden "gesammelt" und können von dem System oder der Domäne abgeleitet werden, in dem die Software betrieben wird (z. B. Bedienbarkeit und Zuverlässigkeit für kritische Systeme).

Aus Sicht des Projektmanagements ist die Ermittlung von entscheidender Bedeutung, um den Projektumfang und die für die Kunden- oder Benutzeranforderungen wichtigen Ergebnisse abzuleiten und die wichtigsten Anforderungen zuerst zu priorisieren.

Was ist mit der Ermittlung von Softwareanforderungen verbunden?

Abhängig von der Beteiligung Ihrer Rolle am Anforderungsprozess müssen Sie möglicherweise Anforderungen aus der Quelle entnehmen.

Die Ermittlung von Anforderungen hilft bei der Information über das Design und die Architektur der Gesamtlösung. Es ist wichtig, dass Sie verstehen, woher die Anforderungen kommen und welche Techniken verwendet werden.

Woher kommen die Softwareanforderungen?

Es gibt viele Quellen für Anforderungen, wie zum Beispiel:

  • Ziele (auch bekannt als Business Concern, Critical Success Factor usw.)
  • Fachwissen
  • Interessengruppen
  • Geschäftsregeln
  • Betriebsumgebung

Wenn Sie an der Ermittlung von Quellen beteiligt sind, müssen Sie:

  • Achten Sie besonders auf die Ziele.
    • Diese sind im Allgemeinen vage, z. B. "Die Software muss mithilfe von Best Practices implementiert werden" oder "Die Software muss benutzerfreundlich sein".
    • Bewerten Sie den relativen Wert zur Priorität der Lösung. Studieren Sie relativ kostengünstige Wege, um dies zu erreichen.
  • Erwerben Sie Kenntnisse über die Anwendungsdomäne oder verfügen Sie über diese
    • Auf diese Weise erhalten Sie Hintergrundinformationen, die die Gründe für die Anforderungen verstehen.
    • Die Entwicklung von Modellen des realen Problems, wie z. B. Entity-Relationship-Modelle, ist der Schlüssel für eine gute Analyse der Softwareanforderungen. Versuchen Sie, mit einem ontologischen Ansatz zu denken.
  • Identifizieren, vertreten und verwalten Sie die Standpunkte vieler verschiedener Arten von Stakeholdern
    • Anforderungen können widersprüchlich sein, sich überschneiden oder teilweise andere Motivationen erfordern als die Bedürfnisse verschiedener Stakeholder.
    • Es ist wichtig, dass Sie die unterschiedlichen Anforderungen erkennen, insbesondere bei der Vorplanung der Implementierung, bei der die Anforderungen in das Design einbezogen werden.
  • Zeigen Sie Sensibilität für die Betriebsumgebung der Lösung
    • Das Betriebsumfeld unterliegt der Struktur, Kultur und Innenpolitik einer Organisation.
    • Ein allgemeines Prinzip, nach dem Ihre Software streben sollte, besteht darin, keine ungeplanten oder erzwungenen Änderungen am Geschäftsprozess des Unternehmens vorzunehmen.

Wie erhalte ich die Softwareanforderungen?

Einige Haupttechniken, mit denen Sie möglicherweise befasst sind (Bereitstellung von technischem Fachwissen), könnten sein:

  • Durchführung von Stakeholder-Interviews
  • Szenarien skizzieren
  • Prototypen bauen
  • Beobachtung im Problembereich
  • benutzergeschichten

Beim Erstellen von Prototypen sollten Sie generell versuchen, in diesen früheren Phasen häufiger Prototypen mit niedriger Wiedergabetreue zu verwenden.

Diese werden bevorzugt, um eine Fixierung der Stakeholder auf geringfügige oder zufällige Merkmale zu vermeiden. Ein höherwertiger Prototyp kann die Designflexibilität auf unbeabsichtigte Weise einschränken.

Klassifizierung der Softwareanforderungen

Wenn Softwareanforderungen ermittelt wurden, können diese vom Projektteam in eine Reihe von Kategorien eingeteilt werden.

Dies hilft auf verschiedene Weise, z. B. beim Schätzen des Projektaufwands, beim Identifizieren von Komponenten für das Lösungsdesign oder sogar bei einfachen Überlegungen zur Implementierung.

Zu den Klassifizierungstypen können gehören:

  • Funktionell / nicht funktionsfähig
    • Funktionsanforderungen beschreiben die Funktionen, die die Software ausführen soll. Beispiel: Bereitstellen eines Kommunikationskanals für einen Benutzer oder Übertragen von Daten von einem Format in ein anderes. Sie können auch als Produktmerkmale oder -fähigkeiten bezeichnet werden.
    • Nicht funktionale Anforderungen dienen dazu, bestimmte Einschränkungen der Lösung durchzusetzen, häufig in Bezug auf die Qualität. Diese können weiter in die vielen Arten von " Fähigkeiten " eingeteilt werden, wie Verfügbarkeit, Zuverlässigkeit, Wiederherstellbarkeit, Wartbarkeit, Skalierbarkeit, Leistung, Sicherheit usw.
  • Abgeleitet / Auferlegt / Emergent
    • Ergibt sich die Anforderung aus anderen Anforderungen?
    • Wird die Anforderung ausdrücklich von einem Stakeholder auferlegt?
    • Ist die Anforderung eine aufstrebende Eigenschaft? Mit anderen Worten, es kann nicht von einer einzelnen Komponente adressiert werden, sondern hängt davon ab, wie alle Softwarekomponenten zusammenarbeiten.
  • Prozess / Produkt
    • Ist die Anforderung produktbezogen? (ein Beispiel: " Die Software muss die Berechtigung einer Person überprüfen ")
    • Ist die Anforderung prozessbezogen? (Ein Beispiel: " Die Software muss schrittweise entwickelt werden und kontinuierliche Integrations- und Bereitstellungsworkflows verwenden. )
  • Priorität
    • Abwägen zwischen Entwicklungs- und Implementierungskosten und Lieferbedarf.
    • Kann eine Skala mit festem Etikett verwenden, die obligatorisch, äußerst wünschenswert, wünschenswert und optional ist.
  • Umfang
    • Wird verwendet, um die Auswirkungen auf die Softwarearchitektur und das Komponentendesign zu berücksichtigen.
    • Nichtfunktionale haben oft einen globalen Geltungsbereich.
  • Volatilität / Stabilität
    • Das Potenzial der Anforderung ändert sich während des Lebenszyklus der Software.
    • Dies hilft bei der Implementierung von Designs, die Änderungen tolerieren

Validierung der Softwareanforderungen

Sobald die Softwareanforderungen ermittelt und klassifiziert wurden, müssen sie mit den Stakeholdern auf ihre Richtigkeit und die tatsächliche Erfüllung ihrer Anforderungen überprüft werden. Anforderungen, die nicht validiert werden können, sind eigentlich nur "Wünsche" der Stakeholder.

Wenn Sie einer iterativen Entwicklungsmethode folgen, kann die Validierung von Anforderungen regelmäßig durchgeführt werden, getrennt nach Umfang um bestimmte Lösungsbereiche oder in Blöcken oder einer anderen Art von Trennung, die logisch sinnvoll ist.

Bei der Anforderungsvalidierung gibt das Lösungsteam in der Regel das Verständnis der Anforderung an die Stakeholder zurück. Es kann sich auch um ein erstes Design (geschäftlich oder technisch oder beides) handeln, das zeigt, wie die Anforderungen der einzelnen Stakeholder umgesetzt werden.

Diese Erkenntnisse werden iterativ in der Planungsphase erstellt und bestehen normalerweise aus den Ansichten eines funktionsübergreifenden Teams (Designer, Geschäftsanalysten, technische Experten).

In einigen Fällen erfordert das Design möglicherweise einige Vorimplementierungsarbeiten, um das Verständnis des Teams besser zu demonstrieren, normalerweise in Form eines funktionalen Prototyps.

Während der Validierung kann Ihr Team möglicherweise nicht die Anforderungen aller Stakeholder perfekt erfüllen. Es liegt in Ihrer Verantwortung als technischer Experte, die Kompromisse zu demonstrieren und zu verhandeln, die den Einschränkungen entsprechen. Es muss für die Hauptakteure akzeptabel sein, aber auch im Rahmen von Haushalts-, technischen, regulatorischen und anderen Maßnahmen.

Verwendung funktionaler Prototypen

Funktionale Prototypen sind nützlich, da sie Folgendes ermöglichen:

  • Bestätigung, dass die Anforderungen verstanden werden
  • einfachere Interpretation der Annahmen des Ingenieurs
  • Feedback, das neue Anforderungen stellen kann

Sie müssen berücksichtigen, dass Stakeholder durch kosmetische oder Qualitätsprobleme abgelenkt werden können. Sie können dies abmildern, indem Sie die wahre Bedeutung der Demonstration - die zugrunde liegende Kernfunktionalität - konsequent kommunizieren.

Wie der Prototyp gebaut wird, bestimmt Ihr Projektteam. Einige Befürworter bevorzugen Prototypen, die Software vollständig vermeiden (ähnlich denen, die bei der Ermittlung von Anforderungen erstellt wurden). Andere bevorzugen eine Art von Softwareanzeige durch Design-Toolkits oder eine schnell erstellte Entwurfsiteration der Software hinter einer Funktionssteuerung.

Unabhängig davon, für welche Wahl sich Ihr Team entscheidet, sollte die Geschwindigkeit der Erstellung des Prototyps im Vergleich zur Effektivität der Demonstration der Kernfunktionalität berücksichtigt werden.

Entwicklung und Implementierung von Softwareanforderungen

Wenn die Anforderung mit den Stakeholdern validiert wurde, können Sie mit der Entwicklung / Implementierung der Anforderung beginnen.

In vielen Fällen fungieren Sie als Softwarearchitekt, da für die Analyse und Ausarbeitung der Anforderungen die Identifizierung der Architektur- / Designkomponenten erforderlich ist, die für die Erfüllung der Anforderungen verantwortlich sind.

Ein wichtiges Interesse für Ihr Unternehmen ist es, von der Softwarelösung zu profitieren. Es liegt in Ihrer Verantwortung, Methoden zu verwenden, die die Entwicklungs- und Wartungskosten senken.

Sie können dies beispielsweise durch Wiederverwendung von Komponenten (intern oder von anderen Produkten), unter Verwendung genau definierter Muster und durch Arbeiten mit gut getesteten und gut dokumentierten Tools / Frameworks tun.

Spezifische Anforderungen, insbesondere Einschränkungen, können enorme Auswirkungen auf die Softwarekosten haben. Zum Beispiel, wenn Ihre Fähigkeiten in der Implementierung schlecht sind oder die Anforderung möglicherweise entgegengesetzt ist oder nicht zur aktuellen Architektur passt. Wichtige Kompromisse zwischen solchen Anforderungen sollten dem Projektteam mitgeteilt werden.

Während des gesamten Anforderungsprozesses ist ein wichtiger Punkt, den Sie verstehen sollten, die Erwartung, dass sich ein erheblicher Teil der Anforderungen ändern wird. Erkennen Sie die Unvermeidlichkeit von Änderungen und versuchen Sie, Schritte in Ihrem Design zu unternehmen, um dies zu berücksichtigen.

Die User Story

Ein Softwareentwickler arbeitet häufig im Kontext einer User Story. Die User Story ist eine natürliche Wortdarstellung der Interaktion eines bestimmten Benutzertyps mit der Software und der Funktionalität, die sie bieten sollte. Es folgt normalerweise dem Format von:

Als will ich, damit

Ein Beispiel:

Als Kursadministrator möchte ich die Anzahl der in einem Kurs eingeschriebenen Personen anzeigen, damit ich die aktuelle Kurskapazität sehen kann

In einigen Fällen wird die User Story mit einem Design oder Prototyp geliefert, wenn diese in der Validierungsphase erforderlich waren.

Es ist möglich, dass die User Story nicht benutzerzentriert ist und sich stattdessen aus einer aufkommenden Eigenschaft oder einer nicht funktionalen Anforderung ergibt. In diesen Fällen erhalten Sie die Anforderung möglicherweise in einem anderen zu liefernden Kontext (z. B. einer Spezifikation oder einem Szenariosatz).

Eine User Story soll gerade genug Informationen enthalten, damit Ihr Engineering-Team eine vernünftige Schätzung des Aufwands für die Implementierung erstellen kann. Wenn Ihr Team keine vernünftige Schätzung erstellen kann, kann dies ein Zeichen für eine schlechte Übereinstimmung von Wissen / Fähigkeiten, individuellem Konfidenzniveau, Anpassungs- oder Abhängigkeitsbeschränkungen oder entscheidend dafür sein, dass die User Story an Qualität mangelt.

Softwareentwickler sind (notwendigerweise) durch Projektmanagementpläne eingeschränkt, daher müssen Sie versuchen, Schritte zu unternehmen, um zu überprüfen, ob die Qualität der Anforderungen angesichts der verfügbaren Ressourcen so hoch wie möglich ist.

Überprüfen Sie vor der Implementierung einer User Story Folgendes:

  • Für ein geeignetes Akzeptanzkriterium, das schriftlich oder mit den Stakeholdern vereinbart wurde, wird festgelegt, wie die Ziele der User Story mit der Implementierung erreicht werden können.
    • Dies bildet die Grundlage für die Abnahmetests des Merkmals (mit anderen Worten, die Tests, die nachweisen, dass die Anforderung erfüllt ist).
    • Dies kann auch Teil der Teamdefinition von "erledigt" oder vollständig sein.
  • Das Prototypendesign (falls erstellt) ist machbar und kann in die aktuelle Architektur, die technischen Fähigkeiten und die Werkzeuge passen, die für die Verwendung im Projekt zugelassen sind.
  • alle Annahmen, die die Anforderung stützen.
    • Dies kann Wissenslücken, potenzielle Probleme oder andere nicht berücksichtigte Szenarien / Randfälle aufzeigen, die eine weitere Klärung durch die Stakeholder erfordern.

Aushandlung von Softwareanforderungen

Bei der Umsetzung einer Anforderung ist es möglich, dass nicht jedes Stakeholder-Interesse perfekt erfüllt wird. Dies kann beispielsweise zwischen funktionalen und nicht funktionalen Anforderungen geschehen oder wenn sich eine Anforderungsimplementierung auf ein anderes Stakeholder-Interesse auswirkt.

In den meisten Fällen ist es für Sie unklug, eine einseitige Entscheidung zu treffen.

Stattdessen sind Sie dafür verantwortlich, das Problem zu bewerten, einfach zu kommunizieren und Kompromisse auszuhandeln, die für die Hauptakteure akzeptabel sind, während Sie die budgetären, technischen, regulatorischen und sonstigen Einschränkungen einhalten.

Überprüfung der Softwareanforderungen

Alle Softwareanforderungen erfordern die Notwendigkeit, als Merkmal oder Funktionsanforderung oder auf globaler Ebene als nichtfunktionale Anforderung überprüfbar zu sein. Die Anforderungen sollten anhand des fertigen Produkts überprüft werden.

Eine wichtige Aufgabe für Sie ist die Planung der Überprüfung der einzelnen Anforderungen.

Ein Softwareentwickler überprüft eine Anforderung mithilfe eines Abnahmetests. Der Abnahmetest zeigt, wie die Anforderung erfüllt wurde (Erfüllung der Abnahmekriterien), indem das Verhalten des Endbenutzers bei der Geschäftsabwicklung mit der in der Anforderung definierten Software gezeigt wird.

Bei Anforderungen, bei denen es schwieriger ist, die Überprüfung nachzuweisen, wie z. B. nicht funktionale Anforderungen, kann eine konstruierte Simulation erforderlich sein. Um beispielsweise die Leistungslast von Software zu testen, die einen Aufnahmeprozess implementiert, kann eine Testsoftware erstellt werden, um Hunderte oder Tausende von Anwendungen für das System in einem Black-Box-Abnahmetest zu simulieren.

Da sich die Software im Laufe der Zeit weiterentwickelt, kann die Implementierung einer neuen Anforderung versehentlich die Erfüllung einer zuvor implementierten Anforderung beeinträchtigen. Dieser Regression kann durch die Automatisierung der Abnahmetests entgegengewirkt werden. Sie finden viele Tools und Bibliotheken für Programmiersprachen, die von Unternehmen allgemein verwendet werden und die Automatisierung von Abnahmetests ermöglichen.

Verwechseln Sie den Abnahmetest nicht als Ihre alleinige Testverantwortung. Versuchen Sie angemessen, die Implementierung mit anderen Tests als der Akzeptanz abzudecken, z. B. Unit- oder Integrationstests.

Akzeptanztests unterscheiden sich in der Komplexität in Abhängigkeit von den Akzeptanzkriterien. Verschiedene Organisationen können auch unterschiedliche Terminologie und Praktiken verwenden. Dies bedeutet, dass sie mit anderen Testarten verwechselt oder mit unterschiedlichen Namen bezeichnet werden können, z. B. End-to-End-Tests, Funktionstests oder Szenariotests. Ihre Organisation kann auch strenge Kriterien oder Formate haben, mit denen Abnahmetests demonstriert werden.

Denken Sie daran, dass der Kern jedes Abnahmetests lediglich eine formale Überprüfung ist, ob eine implementierte Lösung die Softwareanforderungen erfüllt, indem das Benutzerverhalten beim Ausführen einer Anwendung für das Endprodukt repliziert wird.

Das war's auf den Punkt gebracht

Du hast es geschafft. Hut ab!

Ich hoffe, dieser Artikel hat einige Vorteile bei der Anerkennung Ihrer Rolle als Softwareentwickler mit Softwareanforderungen gebracht.

Sie können mehr meiner Artikel in meinem Blog lesen.

Dieser Artikel wird frei geteilt und der Autor hat keinen Beitrag oder Gewinn erhalten, wie dies durch die Urheberrechts- und Nachdruckberechtigungen von SWEBOK vorgeschrieben ist. Alle geäußerten Ansichten oder Meinungen spiegeln nicht die von IEEE oder einer Einrichtung / Organisation wider, mit der ich verbunden bin, werden von der IEEE nicht gebilligt und repräsentieren ausschließlich meine eigenen Ansichten und Meinungen.