Software Anforderungen

Die Softwareanforderungen sind eine Beschreibung der Merkmale und Funktionen des Zielsystems. Die Anforderungen vermitteln die Erwartungen der Benutzer an das Softwareprodukt. Die Anforderungen können offensichtlich oder verborgen, bekannt oder unbekannt, aus Sicht des Kunden erwartet oder unerwartet sein.

Requirement Engineering

Der Prozess zum Sammeln, Analysieren und Dokumentieren der Softwareanforderungen vom Kunden wird als Requirement Engineering bezeichnet.

Das Ziel des Requirement Engineering ist die Entwicklung und Pflege eines anspruchsvollen und beschreibenden Dokuments zur Spezifikation der Systemanforderungen.

Requirement Engineering-Prozess

Es ist ein vierstufiger Prozess, der Folgendes umfasst:

Machbarkeitsstudie
Anforderungserfassung
Spezifikation der Softwareanforderungen
Validierung der Softwareanforderungen

Lassen Sie uns den Prozess kurz sehen -

Machbarkeitsstudie

Wenn sich der Kunde an die Organisation wendet, um das gewünschte Produkt zu entwickeln, erhält er eine ungefähre Vorstellung davon, welche Funktionen die Software ausführen muss und welche Funktionen von der Software erwartet werden.

Unter Bezugnahme auf diese Informationen führen die Analysten eine detaillierte Studie darüber durch, ob die Entwicklung des gewünschten Systems und seiner Funktionalität möglich ist.

Diese Machbarkeitsstudie ist auf das Ziel der Organisation ausgerichtet. Diese Studie analysiert, ob das Softwareprodukt in Bezug auf Implementierung, Beitrag des Projekts zur Organisation, Kostenbeschränkungen und gemäß den Werten und Zielen der Organisation praktisch verwirklicht werden kann. Es werden technische Aspekte des Projekts und des Produkts wie Benutzerfreundlichkeit, Wartbarkeit, Produktivität und Integrationsfähigkeit untersucht.

Das Ergebnis dieser Phase sollte ein Machbarkeitsstudienbericht sein, der angemessene Kommentare und Empfehlungen für das Management darüber enthalten sollte, ob das Projekt durchgeführt werden sollte oder nicht.

Anforderungserfassung

Wenn der Durchführbarkeitsbericht für die Durchführung des Projekts positiv ist, beginnt die nächste Phase mit der Erfassung der Anforderungen vom Benutzer. Analysten und Ingenieure kommunizieren mit dem Kunden und den Endbenutzern, um zu erfahren, was die Software bieten soll und welche Funktionen die Software enthalten soll.

Spezifikation der Softwareanforderungen

SRS ist ein Dokument, das vom Systemanalysten erstellt wird, nachdem die Anforderungen von verschiedenen Stakeholdern gesammelt wurden.

SRS definiert, wie die beabsichtigte Software mit Hardware, externen Schnittstellen, Betriebsgeschwindigkeit, Reaktionszeit des Systems, Portabilität der Software auf verschiedenen Plattformen, Wartbarkeit, Wiederherstellungsgeschwindigkeit nach einem Absturz, Sicherheit, Qualität, Einschränkungen usw. interagiert.

Die vom Kunden erhaltenen Anforderungen sind in natürlicher Sprache verfasst. Es liegt in der Verantwortung des Systemanalysten, die Anforderungen in der Fachsprache zu dokumentieren, damit sie vom Softwareentwicklungsteam verstanden und nützlich sind.

SRS sollte folgende Funktionen bieten:

Benutzeranforderungen werden in natürlicher Sprache ausgedrückt.
Technische Anforderungen werden in einer strukturierten Sprache ausgedrückt, die innerhalb der Organisation verwendet wird.
Die Entwurfsbeschreibung sollte in Pseudocode geschrieben sein.
Format von Formularen und GUI-Siebdrucken.
Bedingte und mathematische Notationen für DFDs usw.

Validierung der Softwareanforderungen

Nach der Entwicklung der Anforderungsspezifikationen werden die in diesem Dokument genannten Anforderungen validiert. Der Benutzer kann nach einer illegalen, unpraktischen Lösung fragen oder Experten interpretieren die Anforderungen möglicherweise falsch. Dies führt zu einem enormen Kostenanstieg, wenn es nicht im Keim erstickt wird. Anforderungen können gegen folgende Bedingungen geprüft werden -

Wenn sie praktisch umgesetzt werden können
Wenn sie gültig sind und der Funktionalität und Domäne der Software entsprechen
Wenn es Unklarheiten gibt
Wenn sie vollständig sind
Wenn sie demonstriert werden können

Anforderungserhebungsprozess

Der Anforderungserhebungsprozess kann anhand des folgenden Diagramms dargestellt werden:

Requirements gathering - Die Entwickler diskutieren mit dem Kunden und den Endbenutzern und kennen ihre Erwartungen an die Software.
Organizing Requirements - Die Entwickler priorisieren und ordnen die Anforderungen in der Reihenfolge ihrer Wichtigkeit, Dringlichkeit und Zweckmäßigkeit.
Negotiation & discussion - Wenn die Anforderungen nicht eindeutig sind oder es zu Konflikten bei den Anforderungen verschiedener Stakeholder kommt, werden diese ausgehandelt und mit den Stakeholdern diskutiert. Anforderungen können dann priorisiert und angemessen kompromittiert werden.

Die Anforderungen kommen von verschiedenen Stakeholdern. Um Mehrdeutigkeiten und Konflikte zu beseitigen, werden sie aus Gründen der Klarheit und Korrektheit erörtert. Unrealistische Anforderungen werden vernünftigerweise kompromittiert.
Documentation - Alle formellen und informellen, funktionalen und nicht funktionalen Anforderungen werden dokumentiert und für die Verarbeitung in der nächsten Phase zur Verfügung gestellt.

Anforderungserhebungstechniken

Anforderungserhebung ist der Prozess zum Ermitteln der Anforderungen für ein beabsichtigtes Softwaresystem durch Kommunikation mit Kunden, Endbenutzern, Systembenutzern und anderen Personen, die an der Entwicklung von Softwaresystemen beteiligt sind.

Es gibt verschiedene Möglichkeiten, Anforderungen zu ermitteln

Interviews

Interviews sind ein starkes Medium, um Anforderungen zu sammeln. Die Organisation kann verschiedene Arten von Interviews durchführen, z.

Strukturierte (geschlossene) Interviews, bei denen jede einzelne zu sammelnde Information im Voraus entschieden wird, folgen Muster und Diskussionsgegenstand fest.
Nicht strukturierte (offene) Interviews, bei denen die zu sammelnden Informationen nicht im Voraus entschieden werden, sind flexibler und weniger voreingenommen.
Mündliche Interviews
Schriftliche Interviews
Einzelinterviews, die zwischen zwei Personen am Tisch stattfinden.
Gruppeninterviews, die zwischen Teilnehmergruppen stattfinden. Sie helfen dabei, fehlende Anforderungen aufzudecken, da zahlreiche Personen beteiligt sind.

Umfragen

Die Organisation kann Umfragen unter verschiedenen Interessengruppen durchführen, indem sie ihre Erwartungen und Anforderungen an das bevorstehende System abfragt.

Fragebögen

Ein Dokument mit vordefinierten objektiven Fragen und entsprechenden Optionen wird allen Beteiligten zur Beantwortung übergeben, die gesammelt und zusammengestellt werden.

Ein Nachteil dieser Technik besteht darin, dass das Problem möglicherweise unbeaufsichtigt bleibt, wenn eine Option für ein Problem im Fragebogen nicht erwähnt wird.

Aufgabenanalyse

Ein Team von Ingenieuren und Entwicklern kann den Betrieb analysieren, für den das neue System benötigt wird. Wenn der Client bereits über eine Software verfügt, mit der bestimmte Vorgänge ausgeführt werden können, wird diese untersucht und die Anforderungen des vorgeschlagenen Systems werden erfasst.

Domänenanalyse

Jede Software fällt in eine Domain-Kategorie. Die Experten auf diesem Gebiet können eine große Hilfe bei der Analyse allgemeiner und spezifischer Anforderungen sein.

Brainstorming

Es findet eine informelle Debatte zwischen verschiedenen Interessengruppen statt, und alle ihre Beiträge werden zur weiteren Anforderungsanalyse aufgezeichnet.

Prototyp entwickeln

Beim Prototyping wird eine Benutzeroberfläche erstellt, ohne dass dem Benutzer Detailfunktionen hinzugefügt werden müssen, um die Funktionen des beabsichtigten Softwareprodukts zu interpretieren. Es hilft, eine bessere Vorstellung von den Anforderungen zu bekommen. Wenn am Ende des Clients keine Software als Referenz für den Entwickler installiert ist und der Client seine eigenen Anforderungen nicht kennt, erstellt der Entwickler einen Prototyp basierend auf den ursprünglich genannten Anforderungen. Der Prototyp wird dem Kunden gezeigt und das Feedback wird notiert. Das Kundenfeedback dient als Eingabe für das Sammeln von Anforderungen.

Überwachung

Ein Expertenteam besucht die Organisation oder den Arbeitsplatz des Kunden. Sie beobachten die tatsächliche Funktionsweise der vorhandenen installierten Systeme. Sie beobachten den Workflow am Ende des Kunden und wie Ausführungsprobleme behandelt werden. Das Team selbst zieht einige Schlussfolgerungen, die dazu beitragen, die von der Software erwarteten Anforderungen zu formulieren.

Merkmale der Softwareanforderungen

Das Sammeln von Softwareanforderungen ist die Grundlage des gesamten Softwareentwicklungsprojekts. Daher müssen sie klar, korrekt und klar definiert sein.

Eine vollständige Softwareanforderungsspezifikation muss sein:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Glaubwürdige Quelle

Software Anforderungen

Wir sollten versuchen zu verstehen, welche Art von Anforderungen in der Anforderungserhebungsphase auftreten können und welche Arten von Anforderungen vom Softwaresystem erwartet werden.

Allgemein sollten Softwareanforderungen in zwei Kategorien eingeteilt werden:

Funktionale Anforderungen

Anforderungen, die sich auf den Funktionsaspekt von Software beziehen, fallen in diese Kategorie.

Sie definieren Funktionen und Funktionalitäten innerhalb und außerhalb des Softwaresystems.

Beispiele -

Suchoption für Benutzer zur Suche aus verschiedenen Rechnungen.
Der Benutzer sollte in der Lage sein, jeden Bericht an das Management zu senden.
Benutzer können in Gruppen unterteilt werden und Gruppen können separate Rechte zugewiesen werden.
Sollte Geschäftsregeln und Verwaltungsfunktionen erfüllen.
Die Software wurde unter Beibehaltung der Abwärtskompatibilität entwickelt.

Nicht-funktionale Anforderungen

Anforderungen, die sich nicht auf den Funktionsaspekt von Software beziehen, fallen in diese Kategorie. Sie sind implizite oder erwartete Merkmale von Software, von denen Benutzer ausgehen.

Nichtfunktionale Anforderungen umfassen -

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Notfallwiederherstellung
Accessibility

Anforderungen werden logisch als kategorisiert

Must Have : Software kann ohne sie nicht als betriebsbereit bezeichnet werden.
Should have : Verbesserung der Funktionalität von Software.
Could have : Software kann mit diesen Anforderungen weiterhin ordnungsgemäß funktionieren.
Wish list : Diese Anforderungen sind keinem Softwareziel zugeordnet.

Während der Entwicklung von Software muss "Must Have" implementiert werden. "Should Have" ist eine Frage der Debatte mit den Stakeholdern und der Verneinung, während "Have Have" und "Wunschliste" für Software-Updates aufbewahrt werden können.

Anforderungen an die Benutzeroberfläche

Die Benutzeroberfläche ist ein wichtiger Bestandteil jeder Software, Hardware oder jedes Hybridsystems. Eine Software wird allgemein akzeptiert, wenn es -

leicht zu bedienen
schnell als Antwort
Betriebsfehler effektiv behandeln
Bereitstellung einer einfachen und dennoch konsistenten Benutzeroberfläche

Die Benutzerakzeptanz hängt hauptsächlich davon ab, wie der Benutzer die Software verwenden kann. Die Benutzeroberfläche ist die einzige Möglichkeit für Benutzer, das System wahrzunehmen. Ein leistungsfähiges Softwaresystem muss außerdem mit einer attraktiven, klaren, konsistenten und reaktionsschnellen Benutzeroberfläche ausgestattet sein. Andernfalls können die Funktionen des Softwaresystems nicht bequem genutzt werden. Ein System gilt als gut, wenn es Mittel zur effizienten Nutzung bietet. Die Anforderungen an die Benutzeroberfläche werden im Folgenden kurz aufgeführt.

Inhaltspräsentation
Einfache Navigation
Einfache Schnittstelle
Responsive
Konsistente UI-Elemente
Rückkopplungsmechanismus
Standardeinstellungen
Zweckmäßiges Layout
Strategischer Einsatz von Farbe und Textur.
Geben Sie Hilfeinformationen an
Benutzerzentrierter Ansatz
Gruppenbasierte Ansichtseinstellungen.

Software System Analyst

Der Systemanalyst in einer IT-Organisation ist eine Person, die die Anforderungen des vorgeschlagenen Systems analysiert und sicherstellt, dass die Anforderungen richtig und korrekt konzipiert und dokumentiert werden. Die Rolle eines Analysten beginnt während der Softwareanalysephase von SDLC. Es liegt in der Verantwortung des Analysten, sicherzustellen, dass die entwickelte Software den Anforderungen des Kunden entspricht.

Systemanalysten haben folgende Verantwortlichkeiten:

Analysieren und Verstehen der Anforderungen der beabsichtigten Software
Verstehen, wie das Projekt zu den Organisationszielen beitragen wird
Anforderungsquellen identifizieren
Validierung der Anforderung
Entwicklung und Implementierung eines Anforderungsmanagementplans
Dokumentation der geschäftlichen, technischen, Prozess- und Produktanforderungen
Koordination mit Kunden, um Anforderungen zu priorisieren und Unklarheiten zu beseitigen
Festlegung der Akzeptanzkriterien mit dem Kunden und anderen Stakeholdern

Software-Metriken und -Messungen

Software-Maßnahmen können als ein Prozess zur Quantifizierung und Symbolisierung verschiedener Attribute und Aspekte von Software verstanden werden.

Software-Metriken bieten Messwerte für verschiedene Aspekte des Softwareprozesses und des Softwareprodukts.

Softwaremaßnahmen sind eine Grundvoraussetzung für das Software-Engineering. Sie helfen nicht nur, den Softwareentwicklungsprozess zu steuern, sondern auch, die Qualität des Endprodukts ausgezeichnet zu halten.

Laut Tom DeMarco, einem (Software Engineer), können Sie nicht steuern, was Sie nicht messen können. Durch sein Sprichwort wird sehr deutlich, wie wichtig Softwaremaßnahmen sind.

Sehen wir uns einige Software-Metriken an:

Size Metrics - LOC (Lines of Code), meist berechnet in Tausenden von gelieferten Quellcodezeilen, bezeichnet als KLOC.

Die Funktionspunktzahl ist ein Maß für die von der Software bereitgestellte Funktionalität. Die Anzahl der Funktionspunkte definiert die Größe des Funktionsaspekts der Software.
Complexity Metrics - McCabes zyklomatische Komplexität quantifiziert die Obergrenze der Anzahl unabhängiger Pfade in einem Programm, die als Komplexität des Programms oder seiner Module wahrgenommen wird. Es wird in Form von graphentheoretischen Konzepten unter Verwendung eines Kontrollflussgraphen dargestellt.
Quality Metrics - Mängel, ihre Arten und Ursachen, Folgen, Intensität der Schwere und ihre Auswirkungen bestimmen die Qualität des Produkts.

Die Anzahl der im Entwicklungsprozess festgestellten Fehler und die Anzahl der vom Kunden gemeldeten Fehler, nachdem das Produkt auf Kundenseite installiert oder geliefert wurde, bestimmen die Produktqualität.
Process Metrics - In verschiedenen Phasen von SDLC sind die verwendeten Methoden und Werkzeuge, die Unternehmensstandards und die Leistung der Entwicklung Softwareprozessmetriken.
Resource Metrics - Aufwand, Zeit und verschiedene verwendete Ressourcen repräsentieren Metriken für die Ressourcenmessung.