generated from leonetienne/LaTeX-Paper-template
feat: worked on RE
This commit is contained in:
parent
22157e372a
commit
83881be834
3
.gitignore
vendored
3
.gitignore
vendored
@ -5,4 +5,7 @@
|
|||||||
*.lot
|
*.lot
|
||||||
*.toc
|
*.toc
|
||||||
*.tps
|
*.tps
|
||||||
|
*.bbl
|
||||||
|
*.blg
|
||||||
|
*.out
|
||||||
.auctex-auto/
|
.auctex-auto/
|
||||||
|
@ -3,5 +3,5 @@
|
|||||||
%
|
%
|
||||||
|
|
||||||
\begin{appendices}
|
\begin{appendices}
|
||||||
\input{appendix/example}
|
\input{appendix/interview-questions}
|
||||||
\end{appendices}
|
\end{appendices}
|
||||||
|
@ -1,8 +0,0 @@
|
|||||||
%
|
|
||||||
% Anhang-Beispielsdokument:
|
|
||||||
%
|
|
||||||
|
|
||||||
\chapter{Beispiel}
|
|
||||||
\label{chap:anhang/beispiel} % Mit dieser Marke kann im Dokument auf diesen Anhang verwiesen werden
|
|
||||||
|
|
||||||
Hallo, Welt!
|
|
50
appendix/interview-questions.tex
Normal file
50
appendix/interview-questions.tex
Normal file
@ -0,0 +1,50 @@
|
|||||||
|
\chapter{Interview-Fragebogen}
|
||||||
|
|
||||||
|
Wie stellen Sie sich den Prozess des Einscannens der QR-Codes beim Entgegennehmen der Flaschen vor? Beschreiben Sie den Ablauf.
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Mit was soll dieser Code gescannt werden? Soll der Scanner in der Applikation eingebaut sein, oder soll das System auch mit
|
||||||
|
Drittanbieter-Apps funktionieren?
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Von welchem Endgerät wird gescannt?
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Welche Fallbacks soll es geben, sollte ein Code nicht scanbar sein? Z.B.: Der Code-Inhalt in Text unter dem Code,
|
||||||
|
der auch von Hand eintippbar sei.
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Gegen welche Missbrauchsszenarien sollte der QR-Code geschützt sein?
|
||||||
|
Sollte ggf. ein Passwort nach dem Einscannen verlangt werden? -> Diskurs über versch. Authentifizierungsmethoden
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Wie viel soll der Kunde beim Versand selbst machen? Muss er das Paket selbst frankieren?
|
||||||
|
Muss er es selbst mit einem Empfänger versehen, oder gibt es diesen als PDF zum Ausdruck zum aufkleben?
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Wenn es ein PDF zum Ausdruck zum Aufbringen des Empfängers gibt, sollte man auch ein PDF zum Ausdruck des Absenders generieren,
|
||||||
|
falls die relevanten Daten vorliegen?
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
In welcher Form sollten Mitarbeiter die ausstehenden und eingegangenen Weinen sehen? Reicht eine einfache Liste, oder sind
|
||||||
|
Export- und Filtermöglichkeiten erwünscht?
|
||||||
|
Wenn ja: Welche Filter (auch Sortierungen)? Welche Exportformate (Excel kann auch csv öffnen)?
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Wenn nun ein Wein als \enquote{eingetragen} vermerkt ist, sollte ein Mitarbeiter das rückgängig machen können?
|
||||||
|
Sollte ein Mitarbeiter Weine löschen können? Wenn eines der beiden ja: Einzeln, oder als Bulk-Action?
|
||||||
|
(Bulk-Actions sind teuer/aufwändig umzusetzen)
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Welche Informationen soll der Kunde über seine Sendunge(n) sehen?
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Soll auch ein Kunde in der Lage sein, seine eigene Weinsendung(en) aus dem System zu löschen? (Eventuell vertippt man sich)
|
||||||
|
Ist hierbei eine Bulk-Action wichtig?
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
Die Einlieferungsnummer ist eine inkrementell erhöhte Ganzzahl.
|
||||||
|
Ist der tatsächliche Wert dieser wichtig, oder ist es lediglich wichtig, dass sie
|
||||||
|
eindeutig ist? Der einfachste/günstigste Weg wäre es, sie in der Datenbank als \enquote{auto\_increment} zu deklarieren.
|
||||||
|
Dann hätte man niemals, auch über x Auswahlproben hinweggehend, die selbe Einlieferungsnummer zwei mal.
|
||||||
|
Das verkürzt und vereinfacht die Entwicklung, den entstehenden Code, und die Nutzererfahrung auf Seiten von Weinland Mosel.
|
@ -1,2 +1,8 @@
|
|||||||
\chapter{Problemanalyse}
|
\chapter{Anforderungserfassung}
|
||||||
\label{chap:problemanalyse}
|
\label{chap:anforderungserfassung}
|
||||||
|
Obwohl bereits ein grober Anriss des Zielsystems bekannt ist, ist es unabdinglich eine Anforderungsanalyse durchzuführen,
|
||||||
|
um Details auszumachen \cite{bib:aaa}.
|
||||||
|
|
||||||
|
Hierbei ist es wichtig, kein exzessives Pflichtenheft aufzubauen, denn letztendlich zählt nur, was dem Kunden geliefert wird.
|
||||||
|
Nicht, wie viele gar nicht benötigte Anforderungen umgesetzt wurden.
|
||||||
|
\enquote{\textit{Zu viele oder falsche Anforderungen ruinieren Budgets, Termine und die Qualität.}}
|
||||||
|
@ -64,3 +64,26 @@ vier Jahre in der Vergangenheit. Vier von den sechs Commits erfolgten innerhalb
|
|||||||
Commit erfolte wenige Tage später. Der aktuellste Commit wurde knapp zwei Jahre später, 2018, veröffentlicht.
|
Commit erfolte wenige Tage später. Der aktuellste Commit wurde knapp zwei Jahre später, 2018, veröffentlicht.
|
||||||
Damit ist diese Bibliothek de-facto sechseinhalb Jahre alt und wurde seitdem ein mal um Featuers erweitert
|
Damit ist diese Bibliothek de-facto sechseinhalb Jahre alt und wurde seitdem ein mal um Featuers erweitert
|
||||||
\cite{bib:kreativkorp-barcode}.
|
\cite{bib:kreativkorp-barcode}.
|
||||||
|
|
||||||
|
% Hiervor muss unbedingt die RE analyse!
|
||||||
|
\subsection*{Vergleich in Bezug auf die Problemstellung}
|
||||||
|
Um eine Bibliothek als \enquote{die Beste} für einen Anwendungsfall zu kurieren,
|
||||||
|
müssen die konkreten Anforderungen und Constraints für diesen Anwendungsfall beachtet werden.
|
||||||
|
Das ist so, da verschiedene Eigenschaften der Bibliotheken verschiedene Auswirkung in Gewichtung und Richtung
|
||||||
|
je nach Anwendungsfall aufweisen.
|
||||||
|
Hierfür werden die zuvor vorgestellten Bibliotheken zur Erstellung von QR-Codes in den folgenden Attributen gegenübergestellt:
|
||||||
|
\begin{description}
|
||||||
|
\item [Funktionialität] \hfill \\
|
||||||
|
Der Umfang der für diese Problemstellung relevanten Funktionen in Annahme dessen, dass die Bibliothek
|
||||||
|
syntaktisch und pragmatisch korrekt \cite{bib:heinemann-vorlesung-re} funktioniert.
|
||||||
|
|
||||||
|
\item [Gepflegtheit] \hfill \\
|
||||||
|
Das Ausmaß, in dem das Projekt aktiv gepflegt und ordnungsgemäß entwickelt zu sein scheint.
|
||||||
|
Hierzu zählen beispielsweise: Bearbeitung von Issues, Bearbeitung von Pull-Requests, Präsenz von Tests,
|
||||||
|
Präsenz einer angemessenen Dokumentation, häufige Commits, mehr als nur ein Contributor, Anzahl der
|
||||||
|
Sterne auf Github (Ausmaß an tieferem, öffentlichem Interesse \cite{bib:github-stars}), sowie der Anzahl der
|
||||||
|
Downloads bzw Installationen, falls verfügbar.
|
||||||
|
|
||||||
|
\item [Workflow-Eignung] \hfill \\
|
||||||
|
Die Eignung einer Bibliothek in existierende Workflows und Constraints übernommen zu werden.
|
||||||
|
\end{description}
|
||||||
|
@ -196,3 +196,11 @@
|
|||||||
year = {2023},
|
year = {2023},
|
||||||
note = {Zugriff: Januar 2023}
|
note = {Zugriff: Januar 2023}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@article{bib:aaa,
|
||||||
|
author = {{Github}},
|
||||||
|
howpublished = "\url{https://docs.github.com/en/get-started/exploring-projects-on-github/saving-repositories-with-stars}",
|
||||||
|
title = {{Saving repositories with stars}},
|
||||||
|
year = {2023},
|
||||||
|
note = {Zugriff: Januar 2023}
|
||||||
|
}
|
||||||
|
Loading…
x
Reference in New Issue
Block a user