-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathch3.tex
120 lines (111 loc) · 6.34 KB
/
ch3.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
\section{Requirements Elicitation - ''Anforderungserhebung''}
(Wikipedia:) ''In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders.''
\begin{itemize}
\item Prozess des \textit{Suchens, Aufdeckens, Erwerbens, Ausarbeiten} von R für computerbasierte Systeme
\item Teil der frühen Entwicklungsphase, aber fortlaufend und kritisch
\item komplex, verschiedenste Techniken - vor allem aus Sozialwissenschaften - finden Anwendung
\begin{itemize}
\item großer Problemfaktor liegt in Kommunikation zw. Engineers und Kunde
\item Iterative Erarbeitung, setzt stark auf Kommunikationskills der Engineers und Bereitschaft der Stakeholder
\item Problem: Konzepte, die für A verständlich sind, könnten für B komplett unverständlich sein
\end{itemize}
\item Probleme der Erhebung
\begin{itemize}
\item Scope: Systemgrenzen sind falsch definiert; unnötige technische Details spezifiziert, die eher verwirren als helfen
\item Understanding: Kunde weiß nicht genau was er will; was seine Computer-Umgebung her gibt; versteht das Problem nicht ganz; Lässt Infos aus die ''offensichtlich'' sind0
\item Flüchtigkeit: R verändern sich mit der Zeit
\end{itemize}
\end{itemize}
5 Fundamentale Aktivitäten zur Erhebung
\begin{enumerate}
\item Verstehen der Anwendungsdomäne\\
Beschreibung existierender Arbeitsprozesse und die zugehörigen Probleme, die vom System gelöst werden sollen.
\item Quellen der R identifizieren\\
verschiedenste Quellen -> Stakeholder (meistens); Existierende Systeme und Prozesse; exist. Doku über aktuelles System und Prozesse
\item Analyse Stakeholder\\
Identifizieren wer der ''offensichtlichste'' Stakeholder ist -> mal der Endkunde, mal der Geldgeber etc
\item Methoden, Ansätze, Tools auswählen\\
Gründe für Methodenauswahl: einzige, die der Analyst kennt; sein Favorit; vorgeschrieben;...
\item R erheben von Stakeholder und anderen Quellen\\
Ergebnis = detaillierte Menge von R in natürlicher Sprache und einfachen Diagrammen
\end{enumerate}
\begin{figure}[!h]
\centering
\includegraphics[scale=0.6]{img/elicitation_techniques.png}
\caption{Which techniques and approaches should be used for a given
requirements elicitation activity?}
\end{figure}
Wir benötigen unterschiedliche Techniken, da jede Technik anderes Wissen als Ergebnis liefert.
\subsection{Techniken und Ansätze}
\subsubsection{Task Analysis and Domain Analysis}
Beschreibung der Aufgaben, Rollen und Aufgabendomain in der aktuell vorgestellten Situation.\\
\textbf{Task Modeling}
\begin{itemize}
\item \textit{Hierarchisches Beschreibung} in SubTasks und deren Beschreibung; Basic-Tasks werden durch Operationen ausgeführt
\item Tasks werden ausgeführt um ein Ziel zu erreichen; meist von Actor in bestimmter Rolle
\item Zusatz: \textit{Temporale Beschreibung}
\item Wurzel eines Task Models ist ein Use Case
\end{itemize}
\begin{figure}[!h]
\centering
\includegraphics[scale=0.3]{img/task_model_ex.png}
\caption{Beispiel Task Model}
\end{figure}
\textbf{Task Domain}\\
oft objektorientiert modelliert\\
Beziehung zw. Task Domain und Task Model herstellen \\
\newpage
\textbf{Analysis Synthesis Bridge Model}
\begin{figure}[!h]
\centering
\includegraphics[scale=0.6]{img/analysis_synthesis_bridge_model.png}
\caption{Analysis Synthesis Bridge Model}
\end{figure}
\subsubsection{Repertory Grids}
\begin{itemize}
\item liefert impliziertes Wissen
\item basiert auf den persönlichen Konstrukten (Rollen, Gruppen, Situationen, Gegenstände) eines Individuums, in denen die Interaktion mit anderen eingeordnet wird -> hat Einfluss auf die weitere Interaktion mit anderen Menschen
\item Zuordnung von Werten zu einer Domain Entität\\
Ergebnis => System wird als Matrix modelliert bei der die Elemente des Systems kategorisiert werden
\item Ziel ist das Identifizieren von Unterschieden und Gemeinsamkeiten zwischen den einzelnen Domainbereichen
\end{itemize}
\subsubsection{Interviews}
\begin{itemize}
\item meist verbreitet und oft eingesetzt
\item Human Based social Activity -> eher informal und Ergebnis hängt stark vom Zsmspiel der Beteiligten ab
\item große Datenmenge in kurzer Zeit mgl
\item 3 Arten:
\begin{itemize}
\item unstructured: kein vordefinierter Ablauf von Fragen etc; oft eingesetzt wenn Domäne etc noch sehr unklar formuliert; Risiko das manche Themen komplett wegfallen
\item semi-structured: Zwischending
\item structured: vorgefertigter Fragenkatalog, der abgearbeitet wird; Erfolg hängt von den richtigen Fragen ab, wann und wem sie gestellt werden
\end{itemize}
\end{itemize}
\subsection{Contextual Design Approach}
Grundidee: Daten vom Kunden direkt beim Arbeitsprozess sammeln ('Field Studies') und daraus entscheiden was das System können soll\\
Ablauf in 2 Phase
\begin{enumerate}
\item Kontextuelle Anfrage:
\begin{itemize}
\item Kombination aus verschiedenen Elicitation Techniken (Interview, Observation)
\item Führende/Lenkende Prinzipien
\begin{itemize}
\item Kontext: analysieren des Kundenarbeitsplatzes
\item Partnership: Analyst sucht nach Strukturen/Abläufen in der Arbeit; Kunde erläutert wie Arbeit tatsächlich abläuft (Technik: Kunde bringt dem Analysten den Arbeitslauf bei)
\item Interpretation: Analyst interpretiert gesammelte Daten über Arbeitsplatz und gleicht mit dem Eindruck des Kunden ab
\item Fokus: jede Elicitation Technik fokusiert auf einen Teilaspekt. Am Ende muss das ''Große Ganze'' daraus entstehen
\end{itemize}
\end{itemize}
\item Erstellung von 5 Work Models
\begin{itemize}
\item Flow Models: Beschreiben Arbeitsteilung und -koordination aus Sicht eines Arbeiters\\
oft: mehrere Flow Models (aus unterschiedlichen Perspektiven) benötigt
\item Sequence Models: Beschreibt konkrete Aufgaben der Arbeit\\
Zweck, Trigger, Arbeitsschritte, Unterbrechungen, Probleme,
\item Artefact Models: beschreibt Artefakte\\
Wann/von wem erstellt?; Struktur; Inhalt des Artefakts; Wie werden sie präsentiert?
\item Cultural Models: Organisationskultur -> beschreibt Erwartungen, Wünsche der Arbeiter; organisatorische Vorschriften
\item Physical Models: beschreibt den physikalischen Arbeitsplatz -> Aufbau; Bewegung innerhalb; eingesetzte Technik;
\end{itemize}
\item Analyse der 5 Modelle um die 'System-to-be' zu bestimmen; Quasi das Redesign der Arbeit erbringt das Design der Software
\end{enumerate}