Software-Anforderungen

Die Software-Anforderungen sind Beschreibungen von Eigenschaften und Funktionalitäten des Zielsystems. Anforderungen vermitteln die Erwartungen der Nutzer an das Softwareprodukt. Die Anforderungen können offensichtlich oder versteckt, bekannt oder unbekannt, erwartet oder unerwartet aus Sicht des Kunden sein.

Requirement Engineering

Der Prozess, die Software-Anforderungen vom Kunden zu sammeln, zu analysieren und zu dokumentieren, wird als Requirements Engineering bezeichnet.

Das Ziel des Requirements Engineering ist es, ein ausgefeiltes und beschreibendes ‚System Requirements Specification‘ Dokument zu entwickeln und zu pflegen.

Requirement Engineering Prozess

Es ist ein vierstufiger Prozess,

• Machbarkeitsstudie
• Anforderungserhebung
• Software-Anforderungsspezifikation
• Software-Anforderungsvalidierung

Lassen Sie uns den Prozess kurz betrachten –

Machbarkeitsstudie

Wenn der Kunde an das Unternehmen herantritt, um das gewünschte Produkt entwickeln zu lassen, hat er eine grobe Vorstellung davon, welche Funktionen die Software erfüllen muss und welche Eigenschaften von der Software erwartet werden.

Auf der Grundlage dieser Informationen führen die Analysten eine detaillierte Studie darüber durch, ob das gewünschte System und seine Funktionen entwicklungsfähig sind.

Diese Machbarkeitsstudie ist auf das Ziel der Organisation ausgerichtet. Diese Studie analysiert, ob das Softwareprodukt in Bezug auf die Implementierung, den Beitrag des Projekts zur Organisation, die Kostenbeschränkungen und die Werte und Ziele der Organisation praktisch realisiert werden kann. Sie untersucht technische Aspekte des Projekts und des Produkts wie Benutzerfreundlichkeit, Wartbarkeit, Produktivität und Integrationsfähigkeit.

Das Ergebnis dieser Phase sollte ein Bericht über die Machbarkeitsstudie sein, der angemessene Kommentare und Empfehlungen für das Management enthält, ob das Projekt durchgeführt werden sollte oder nicht.

Anforderungserhebung

Wenn der Machbarkeitsbericht positiv für die Durchführung des Projekts ausfällt, beginnt die nächste Phase mit der Erhebung der Anforderungen vom Benutzer. Analysten und Ingenieure kommunizieren mit dem Kunden und den Endbenutzern, um deren Vorstellungen darüber zu erfahren, was die Software bieten soll und welche Funktionen sie in die Software aufnehmen wollen.

Software-Anforderungsspezifikation

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

SRS definiert, wie die geplante Software mit der Hardware interagieren wird, externe Schnittstellen, Betriebsgeschwindigkeit, Reaktionszeit des Systems, Portabilität der Software über verschiedene Plattformen, Wartbarkeit, Geschwindigkeit der Wiederherstellung nach einem Absturz, Sicherheit, Qualität, Einschränkungen usw.

Die vom Kunden erhaltenen Anforderungen sind in natürlicher Sprache verfasst. Es liegt in der Verantwortung des Systemanalytikers, die Anforderungen in technischer Sprache zu dokumentieren, so dass sie vom Softwareentwicklungsteam verstanden und genutzt werden können.

SRS sollte mit folgenden Merkmalen aufwarten:

• Benutzeranforderungen werden in natürlicher Sprache ausgedrückt.
• Technische Anforderungen werden in strukturierter Sprache ausgedrückt, die innerhalb der Organisation verwendet wird.
• Die Designbeschreibung sollte in Pseudocode geschrieben werden.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Anforderungserhebung – Die Entwickler diskutieren mit dem Kunden und den Endbenutzern und kennen deren Erwartungen an die Software.
• Organisation der Anforderungen – Die Entwickler priorisieren und ordnen die Anforderungen nach Wichtigkeit, Dringlichkeit und Zweckmäßigkeit.

• Verhandlung &Diskussion – Wenn Anforderungen mehrdeutig sind oder es einige Konflikte in den Anforderungen der verschiedenen Stakeholder gibt, wird dies mit den Stakeholdern verhandelt und diskutiert. Die Anforderungen können dann priorisiert und mit vernünftigen Kompromissen versehen werden.

  Die Anforderungen kommen von verschiedenen Stakeholdern. Um die Mehrdeutigkeit und Konflikte zu beseitigen, werden sie auf Klarheit und Korrektheit diskutiert. Unrealistische Anforderungen werden sinnvoll kompromittiert.

• Dokumentation – Alle formalen & informellen, funktionalen und nicht-funktionalen Anforderungen werden dokumentiert und für die Bearbeitung in der nächsten Phase zur Verfügung gestellt.

Anforderungserhebungstechniken

Anforderungserhebung ist der Prozess zur Ermittlung der Anforderungen für ein geplantes Softwaresystem durch Kommunikation mit Kunden, Endbenutzern, Systembenutzern und anderen, die ein Interesse an der Entwicklung des Softwaresystems haben.

Es gibt verschiedene Möglichkeiten, Anforderungen zu ermitteln

Interviews

Interviews sind ein starkes Mittel zur Erhebung von Anforderungen. Eine Organisation kann verschiedene Arten von Interviews durchführen, wie zum Beispiel:

• Strukturierte (geschlossene) Interviews, bei denen jede einzelne Information, die gesammelt werden soll, im Voraus festgelegt wird, sie folgen einem festen Muster und Diskussionsgegenstand.
• Nicht-strukturierte (offene) Interviews, bei denen die zu sammelnden Informationen nicht im Voraus festgelegt werden, sie sind flexibler und weniger voreingenommen.
• Mündliche Interviews
• Schriftliche Interviews
• Einzelinterviews, die zwischen zwei Personen an einem Tisch geführt werden.
• Gruppeninterviews, die zwischen Gruppen von Teilnehmern geführt werden. Sie helfen, fehlende Anforderungen aufzudecken, da zahlreiche Personen beteiligt sind.

Umfragen

Eine Organisation kann Umfragen unter verschiedenen Interessengruppen durchführen, indem sie deren Erwartungen und Anforderungen an das zukünftige System abfragt.

Fragebögen

Ein Dokument mit vordefinierten objektiven Fragen und entsprechenden Optionen wird allen Beteiligten zur Beantwortung ausgehändigt, die dann gesammelt und zusammengestellt werden.

Ein Manko dieser Technik ist, dass, wenn eine Option für ein bestimmtes Problem im Fragebogen nicht erwähnt wird, das Problem möglicherweise unbeachtet bleibt.

Aufgabenanalyse

Ein Team von Ingenieuren und Entwicklern kann die Aufgabe analysieren, für die das neue System benötigt wird. Wenn der Kunde bereits über eine Software verfügt, die einen bestimmten Vorgang ausführt, wird diese untersucht und die Anforderungen an das vorgeschlagene System werden gesammelt.

Domänenanalyse

Jede Software fällt in eine bestimmte Domänenkategorie. Die Experten in diesem Bereich können eine große Hilfe bei der Analyse der allgemeinen und spezifischen Anforderungen sein.

Brainstorming

Eine informelle Debatte wird unter den verschiedenen Interessenvertretern geführt und alle ihre Beiträge werden für die weitere Anforderungsanalyse aufgezeichnet.

Prototyping

Prototyping bedeutet, dass eine Benutzeroberfläche gebaut wird, ohne dass der Benutzer detaillierte Funktionen hinzufügt, um die Eigenschaften des geplanten Softwareprodukts zu interpretieren. Es hilft, eine bessere Vorstellung von den Anforderungen zu bekommen. Wenn beim Kunden keine Software installiert ist, auf die der Entwickler zurückgreifen kann, und der Kunde seine eigenen Anforderungen nicht kennt, erstellt der Entwickler einen Prototyp auf der Grundlage der anfangs genannten Anforderungen. Der Prototyp wird dem Kunden vorgeführt und das Feedback wird notiert. Das Kundenfeedback dient als Input für die Anforderungserhebung.

Beobachtung

Ein Expertenteam besucht die Organisation oder den Arbeitsplatz des Kunden. Sie beobachten die tatsächliche Funktionsweise der installierten Systeme. Sie beobachten den Arbeitsablauf beim Kunden und wie Ausführungsprobleme behandelt werden. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

Grundsätzlich sollten Softwareanforderungen in zwei Kategorien eingeteilt werden:

Funktionale Anforderungen

Anforderungen, die sich auf den funktionalen Aspekt der Software beziehen, fallen in diese Kategorie.

Sie definieren die Funktionen und die Funktionalität innerhalb und von dem Softwaresystem.

Beispiele –

• Suchoption, die dem Benutzer gegeben wird, um aus verschiedenen Rechnungen zu suchen.
• Der Benutzer sollte in der Lage sein, beliebige Berichte an die Geschäftsleitung zu senden.
• Benutzer können in Gruppen eingeteilt werden und Gruppen können separate Rechte erhalten.
• Sollte Geschäftsregeln und Verwaltungsfunktionen einhalten.
• Die Software wird so entwickelt, dass die Abwärtskompatibilität erhalten bleibt.

Nicht-funktionale Anforderungen

Anforderungen, die sich nicht auf den funktionalen Aspekt der Software beziehen, fallen in diese Kategorie. Sie sind implizite oder erwartete Eigenschaften von Software, die von den Benutzern vorausgesetzt werden.

Zu den nicht-funktionalen Anforderungen gehören.

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‚Must have‘ must be implemented, ‚Should have‘ is a matter of debate with stakeholders and negation, whereas ‚could have‘ and ‚wish list‘ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Bereitstellen von Hilfeinformationen
• Benutzerzentrierter Ansatz
• Gruppenbasierte Ansichtseinstellungen

Systemanalytiker

Systemanalytiker in einer IT-Organisation ist eine Person, die die Anforderungen des vorgeschlagenen Systems analysiert und sicherstellt, dass die Anforderungen richtig konzipiert und dokumentiert werden &. Die Rolle des Analysten beginnt in der Softwareanalysephase des SDLC. Es liegt in der Verantwortung des Analysten sicherzustellen, dass die entwickelte Software den Anforderungen des Kunden entspricht.

Systemanalysten haben die folgenden Aufgaben:

• Analysieren und Verstehen der Anforderungen der geplanten Software
• Verstehen, wie das Projekt zu den Unternehmenszielen beiträgt
• Identifizieren der Anforderungsquellen
• Validieren der Anforderungen
• Entwickeln und Implementieren eines Anforderungsmanagementplans
• Dokumentation der geschäftlichen, technischen, Prozess- und Produktanforderungen
• Koordination mit dem Kunden, um Anforderungen zu priorisieren und Unklarheiten zu beseitigen
• Abschluss der Akzeptanzkriterien mit dem Kunden und anderen Beteiligten

Software-Metriken und -Maßnahmen

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

Software-Metriken liefern Maßzahlen für verschiedene Aspekte des Software-Prozesses und des Software-Produkts.

Software-Metriken sind eine grundlegende Voraussetzung für die Software-Entwicklung. Sie helfen nicht nur dabei, den Softwareentwicklungsprozess zu kontrollieren, sondern auch die Qualität des Endprodukts hervorragend zu halten.

Nach Tom DeMarco, einem (Software Engineer), „Man kann nicht kontrollieren, was man nicht messen kann.“ Anhand dieser Aussage wird deutlich, wie wichtig Software-Maßnahmen sind.

Lassen Sie uns einige Software-Metriken betrachten:

• Größenmetriken – LOC (Lines of Code), meist berechnet in Tausenden von gelieferten Quellcodezeilen, bezeichnet als KLOC.

  Function Point Count ist ein Maß für die von der Software bereitgestellte Funktionalität. Die Anzahl der Funktionspunkte definiert die Größe des funktionalen Aspekts der Software.

• Komplexitätsmetriken – Die zyklomatische Komplexität nach McCabe quantifiziert die obere Grenze der Anzahl unabhängiger Pfade in einem Programm, die als Komplexität des Programms oder seiner Module angesehen wird. Sie wird in Form von graphentheoretischen Konzepten unter Verwendung eines Kontrollflussgraphen dargestellt.

• Qualitätsmetriken – Fehler, ihre Arten und Ursachen, Folgen, Schweregrad und ihre Auswirkungen definieren die Qualität des Produkts.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.