Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > Anforderungsanalyse > Flashcards

Anforderungsanalyse Flashcards

1
Q

Softwarelebenszyklus

A

Ist ein Prozess der Entwicklung und beinhaltet alle Phasen, die ein Software-Produkt von der ersten Idee bis zur Außerbetriebnahme durchläuft

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Phasen im Softwarelebenszyklus

A

Entwicklung
Anwendung
Wartung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Mögliche Gründe für das Fehlschlagen von Projekten

A
  • unvollständige Anforderungen
  • unzureichende Ressourcen
  • unrealistische Erwartungen
  • Schwächen bei der Planung
  • System wurde nicht mehr gebraucht

Qualität der Anforderungen entscheidend!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Gründe für mangelhafte Anforderungsanalyse

A
  • Falsche Annahmen der Stakeholder
  • “Fachsprache”
  • Kommunikationsprobleme
  • unterschiedlicher Erfahrungs- und Wissensstand bei den Projektbeteiligten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Was ist eine Anforderung?

A

Eine Bedingung oder Fähigkeit, die von einem Benutzer zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Aktive Stakeholder

A

Aktive Stakeholder arbeiten direkt am Projekt mit oder sind direkt vom Projekt betroffen

  • Leitung
  • Projektmitarbeiter
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Passive Stakeholder

A

Passive Stakeholder sind von der Projektdurchführung oder den Projektauswirkungen nur indirekt betroffen

  • Interessenvertretung
  • Verbände
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Anforderungsanalyse

A

ist ein kooperativer, iterativer, inkrementeller Prozess, dessen ziel es ist zu gewährleisten, dass

  • alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind,
  • die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen,
  • alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Vier Haupttätigkeiten der Anforderungsanalyse

A

Ermitteln

  • Nutzung verschiedener Techniken und Methoden (Interviews, Beobachtung,…)
  • Detaillierung und Verfeinerung

Dokumentieren

  • Beschreibung der Anforderungen
  • Textuelle Beschreibungen
  • Modelle (UML)

Prüfen und abstimmen

  • Prüfung dokumentierter Anforderungen
  • Vielfältige Methoden: Reviews, Prototyping,…)
  • Gewährleistung, dass sie geforderten Qualitätskriterien entsprechen

Verwalten

  • Anforderungsmanagement
  • Strukturierung, Aufbereitung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Arten von Anforderungen

A

Funktionale Anforderungen
- legt fest, was das Produkt tun soll
Beispiel: Programm soll den Saldo eines Kontos zum Stichtag berechnen

Qualitätsanforderungen,
nichtfunktionale Anforderungen
- geht über die funktionale Anforderung hinaus.
- beschreiben, wie gut das System die Leistung erbringen soll
Beispiel: Programm soll innerhalb einer Sekunde antworten

Randbedingungen (Rahmenbedingungen)
- ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.
Beispiel: Programm muss bis zur Messe am … fertig sein

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Aufgabe der System- und Kontextabgrenzung

A

das System von dessen Umgebung abzugrenzen und den Teil der Umgebung zu identifizieren, der die Anforderungen an das zu entwickelnde System bestimmt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Systemkontext

A

ist der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen des betrachteten Systems relevant ist

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Systemkontext - Welche Aspekte müssen beachtet werden

A 
Personen
Systeme im Betrieb
Prozesse
Ereignisse
Dokumente
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Warum Systemkontext betrachten

A
  • Falscher oder fehlender Systemkontext führt zu unvollständigen oder fehlerhaften Anforderungen
  • Anforderungen kommen aus dem Systemkontext
    > Ermittlung und Dokumentation des Systemkontextes ist überaus hilfreich
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Prozessaktivität Überblick

A
  1. Software Spezifikation
  2. Software Design und Implementierung
  3. Überprüfung/Testen
  4. Software Weiterentwicklung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Software Spezifikation

A

Was soll die Software können
Was sind die Grenzen der Systemoperation & Entwicklung?
Anforderungen analysieren, spezifizieren und validieren

17
Q

Softwaredesign und Implementierung

Definition, Aktivitäten, Methoden

A

Eine Softwarestruktur, die Spezifikationen erfüllt

Aktivitäten:

  • Architektur-, Komponenten- und Interfacedesign, Abstrakte Spezifikation
  • Umsetzung der Anforderungen

Methoden:
- Modelle (Objekt-, Zustands-,…Modelle)

18
Q

Softwareüberprüfung

Phasen der Softwareüberprüfung

A

Validation und Verifikation (Tests)

  • Komponenten sind unabhängig voneinander
  • Systeme und Akzeptanz testen
Phasen:
- Fehler finden
- Wie kann der Fehler beseitigt werden 
- Fehler entfernen
Programm erneut testen
19
Q

Softwarevalidation + Teststufen

A
  • Sind die Überlegungen zum Projekt korrekt?
  • Entspricht es dem Kundenwunsch?

Teststufen:

  • Component - einzelne Komponenten werden getestet
  • Systemtest - Test des gesamten Systems
  • Akzeptiertes Testen - Mit dem Kunden testen (Herausfinden, ob Spezifikationen eingehalten wurden und der Kunde zufrieden ist)
20
Q

Softwareevolution

A
  • Weiterentwicklung
  • Anpassung an wechselnde Wirtschaftsbedingungen
  • Anforderungen können sich ändern/neu hinzu kommen
21
Q

RUP (Rational Unified Prozess)

3 Sichten

A
  • Dynamische: beschreibt Phasen über Zeit
  • Statische: zeigt Aktivitäten des Prozesses
  • Praktische: schlägt gute Anwendung vor
  • Beginn: für System wird Wirtschaftsfall aufgebaut
  • Ausarbeitung: Entwicklung und Verständnis des Problembereichs und Systemarchitektur
  • Konstruktion: Systemdesign, Programmierung, Testen
  • Wandel: System in operativer Umgebung anwenden

Vorgehensweise:
- Software iterativ entwickeln, Anforderungen managen, Komponentenbasierte Architektur nutzen, Qualität & Veränderungen prüfen

22
Q

Computer-aided software engineering

A

Wir sind in der Lage unsere eigenen Werkzeuge für die Systementwicklung herzustellen

  • grafische Editoren
  • Verwaltung von Begriffen
  • GUI
  • Debugger zur Fehlerfindung
  • Übersetzer
23
Q

CASE technology (Werkzeuge)

A

Unterstützt Softwareentwicklung und Evolution (kann Kreativität & Teamarbeit nicht ersetzen)

Aktivitäten:
- Debugger, grafischer Editor, automatischer Übersetzer

24
Q 
CASE technology (Werkzeuge)
Klassifikationen
A

Funktionale Perspektive:
- Tools sind nach Spezifikationen gegliedert

Prozessperspektive:
- Tools sind nach Prozessaktivitäten gegliedert

Integrierende Perspektive:
- nach Organisation in Integrierungseinheiten gegliedert

25
Q 
CASE technology (Werkzeuge)
Integrierung
A

Tools:
- unterstützen individuelle Prozessaufgaben (z.B. Texteditor)

Workbench:
- unterstützt Prozessphase (z.B. Spezifikation, Design), beinhaltet Tools

26
Q

Benutzeranforderung - Probleme

A
  • Mangel an Genauigkeit (unterschiedliche Interpretation)
  • Anforderungen können vermischt werden
  • Verwirrung/Verschmelzung
27
Q

Systemanforderung

A
  • Genaue Beschreibung der Anforderung
  • Benutzt strukturiert/beschreibende Sprache
  • Schnittstellendefinition
28
Q

Lastenheft + Personen

A

definiert Benutzeranforderung

Personen:
- Manager/Kunde, Manager/Softwareentwickler

29
Q

Pflichtenheft

A

Systemanforderungen abhängig von:

  • Technischer Beauftragte vom Kunden
  • Endbenutzer des Systems
  • System/Software Architektur
  • Entwickler

Kriterien für ein gutes Pflichtenheft:

  • Äußeres Systemverhalten beschrieben
  • Beschränkungen bzgl. Implementierung vorgeben
  • Leicht veränderbar/erweiterbar
  • Als Referenz für spätere Wartung
  • Leichte Systemerweiterung
30
Q

Nichtfunktionale & Funktionale Anforderungen

A

Nichtfunktionale Anforderungen:

  • Zuverlässigkeit
  • Performance
  • Stabilität

Funktionale Anforderungen
- Beschreibung was das System können muss

Software Engineering (3 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions