-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path6_Quality_Requirements.tex
183 lines (168 loc) · 9.39 KB
/
6_Quality_Requirements.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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
\section{Quality Requirements}
\subsection{Quality Tree}
The priority of each element will be expressed using the following notation:
\begin{itemize}
\item ([Customer view], [Architect view])
\item H - High
\item M - Medium
\item L - Low
\end{itemize}
\Glsplural{user} and the development team have different perspective of an app. The former think about how attractive and easy to use
it is, the latter want to build something what achieves a goal. For that reason is the interpretation of the priority sometimes
so different, according to which group has been asked.
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{assets/quality_tree.png}
\caption{Elements of the quality tree combined with the quality attributes, the prioritization for the two main
stakeholders group, \glsplural{provider} and \glsplural{client} and development team, and the scenarios}
\label{fig:quality_tree}
\end{figure}
\newpage
The next table presents the reason for the previous evaluation of the Quality Attributes in the view of the \glsplural{client} and \glsplural{provider}
and development team:
\begin{table}[H]
\setstretch{1.0}
\begin{tabularx}{\textwidth}{lXXc}
\toprule
ID & Reasoning for \Glsplural{user} & Reasoning for Development Team & Associated Scenario \\
\midrule
QA-1.1 & All important information should be there so his shop can be well promoted &
An initial registration with filter for the input is important, but aesthetically details are
the goal now. & QS-1 \\
QA-1.2 & Once he get something new, he wants to make it available & First we need to guarantee that no overrides occur
than they see if it is promptly displayed. & QS-2\\
QA-1.3 & They want to browse and see all available options & Search engine can be very helpful,
but filtering can wait a litte, since it does not affect the app itself & QS-3\\
QA-2.1 & The most important is that they can use and purchase & This integration must be done fast and careful
so no mistakes shows up. & QS-4\\
QA-2.2 & They just want to easily and secure pay, it does not matter how it works & The compliance with payment regulations is a must, since any mistake can costs huge fines
and damage to the image of the company. & QS-5\\
QA-3.1 & They want to get confirmation that everything worked fine. & The communication between the \gls{API} and the \gls{API Gateway} or the \gls{federated login} show comply with all existing regulations. Push notification can be added once the main feature works. & QS-6 \& QS-7\\
QA-3.2 & That is something that they don't want to see, but want to make sure that it exists & Since the payment is processed by the third party operator, all concerns should be addressed to them
and specified in the \glsfirst{SLA} & QS-7\\
\bottomrule
\end{tabularx}
\end{table}
\subsection{Evaluation Scenarios} \label{table_use_case}
From the requirements, \ref{Requirement_Overview}, we could develop the following uses cases and depict the main quality
attributes of this project.
\begin{table}[H]
\setstretch{1.0}
\begin{tabularx}{\textwidth}{lX}
\toprule
Use Case & Description \\
\midrule
UC-1: Register as \gls{client} & The \gls{client} registers an e-mail address.\\
UC-2: Login & The \gls{client} logins in to the system. \\
UC-3: Places an order & The \gls{client} chooses a \gls{provider}. \\
UC-4: Register payment & The \gls{client} registers a payment method. \\
UC-5: Register as \gls{provider} & The \gls{provider} registers their facility and products. \\
UC-6: Update availability & The \gls{provider} uploads their product catalog. \\
\bottomrule
\end{tabularx}
%\caption{Use Cases}
\end{table}
With the following use cases we will be able to define the major quality attributes that are involved in the
development of this application. They should be measurable and testable so we can verify if the system meets
the needs our \glsplural{stakeholder} [\cite{refbook:DSHC}].
\begin{table}[H]
\setstretch{1.0}
\begin{tabularx}{\textwidth}{lcXc}
\toprule
ID & Quality Attribute & Scenario & Associated Use Case \\
\midrule
QA-1.1 & Usability & A \gls{provider} is able to register his company, to specify the kind of products he offers
and upload a logo or picture of his shop and products in a easy and fast (within 5 Minutes) fashion. & UC-5 \\
QA-1.2 & Usability & A \gls{provider} is able to update the offers at any time. & UC-6 \\
QA-1.3 & Usability & A \gls{client} is able to search and filter options. & UC-6 \\
QA-2.1 & Interoperability & A \gls{client} can register his e-mail using another account (Google, Microsoft, Facebook)
in a \gls{federated login} & UC-1 \\
QA-2.2 & Interoperability & A \gls{client} can pay the order using a \gls{mobile payment gateway} (e.g. Stripe, Square, PayPay, SecurePay) & UC-4 \\
QA-3.1 & Security & The \gls{client} selects a payment method from an existing service. The client inputs no payment data
in the app. Everything is processed between the \gls{API Gateway} and the financial institute. & UC-4 \& UC-4 \\
\bottomrule
\end{tabularx}
\end{table}
\newpage
The defined quality attributes are represented in the following scenarios:
\begin{table}[H]
\setstretch{1.0}
\begin{tabularx}{\textwidth}{|c|X|X|X|}
\hline
\multicolumn{4}{c}{\textbf{Usability}} \\
\hline
\toprule
\multicolumn{1}{|c|}{\textbf{Scenario}} & \multicolumn{3}{|c|}{\textbf{Value}} \\
\midrule
\multicolumn{1}{|c|}{ID} & \multicolumn{1}{|c|}{QS-1} & \multicolumn{1}{|c|}{QS-2} & \multicolumn{1}{|c|}{QS-3} \\
\hline
Source & \Gls{provider} & Registered \Gls{provider} & \Gls{client} \\
\hline
Stimulus & wants to register his shops & wants to make a last minute offer & wants to search/filter offers \\
\hline
Artifact & app & app & app \\
\hline
Environment & working time, during afternoon & peak period, between 4 and 7 pm on Friday & peak period, between 4 and 7 pm on Friday \\
\hline
Response & offer available in the app & immediate availability of the offer in the app & display of the filter/search output \\
\hline
Response Measure & How long did the registration and upload process take? How many and what kind of error messages did the \gls{provider} get?
& How long did it take to upload an offer? How many and what kind of error messages did the \gls{provider} get?
& What kind of inputs did the user has to place until he finds what he wants? Did he have to type anything or were filter/search
options available? How long it takes until the client finds a product? \\
\bottomrule
\end{tabularx}
\end{table}
\begin{table}[H]
\setstretch{1.0}
\begin{tabularx}{\textwidth}{|c|X|X|}
\hline
\multicolumn{3}{c}{\textbf{Interoperability}} \\
\hline
\toprule
\multicolumn{1}{|c|}{\textbf{Scenario}} & \multicolumn{2}{|c|}{\textbf{Value}} \\
\midrule
\multicolumn{1}{|c|}{ID} & \multicolumn{1}{|c|}{QS-4} & \multicolumn{1}{|c|}{QS-5} \\
\hline
Source & \Gls{client} & \Gls{client} \\
\hline
Stimulus & wants register using a \gls{federated login} & wants to pay using existing mobile payment account \\
\hline
Artifact & app and \gls{federated login} provider & app and \gls{mobile payment gateway} \\
\hline
Environment & peak period (on the context of the \gls{federated login} provider) & peak period (on the context of the gateway) \\
\hline
Response & authentication succeed or failed & confirmation / declined \\
\hline
Response Measure & How much data was transmitted and how much was queued? Focus on System overload [\cite{refart:MKMS}]
& Total amount generated data in the app that are transferred and processed and rejected by the gateway? Focus o connectivity
and system overload [\cite{refart:MKMS}] \\
\bottomrule
\end{tabularx}
\end{table}
\begin{table}[H]
\setstretch{1.0}
\begin{tabularx}{\textwidth}{|c|X|X|}
\hline
\multicolumn{3}{c}{\textbf{Security}} \\
\hline
\toprule
\multicolumn{1}{|c|}{\textbf{Scenario}} & \multicolumn{2}{|c|}{\textbf{Value}} \\
\midrule
\multicolumn{1}{|c|}{ID} & \multicolumn{1}{|c|}{QS-6} & \multicolumn{1}{|c|}{QS-7} \\
\hline
Source & \Gls{client} & \Gls{client} \\
\hline
Stimulus & clicks on registration using an existing login & click on pay using an existing mobile payment account \\
\hline
Artifact & app, \gls{API Gateway} and \gls{federated login} provider & app, \gls{microservice} and \gls{mobile payment gateway} \\
\hline
Environment & peak period (on the context of the \gls{federated login} provider) & peak period (on the context of the gateway) \\
\hline
Response & authentication succeed or failed & confirmation / declined \\
\hline
Response Measure & Required time and effort to intercept and/or block requests (create \glsfirst{DoS})
& Extension and impact to image/damage of the app/company in case of attack \\
\bottomrule
\end{tabularx}
\end{table}