Skip to content

Commit

Permalink
fixed formatting and minor corrections in 5.2.3.2
Browse files Browse the repository at this point in the history
  • Loading branch information
Tale152 committed Oct 8, 2022
1 parent 99b375d commit a48190c
Showing 1 changed file with 7 additions and 6 deletions.
13 changes: 7 additions & 6 deletions document/chapters/chapter_5/sections/2_solution_analysis.tex
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,7 @@ \subsection{Domain: Ubiquitous Language}
\vspace{20mm}

\subsection{Use Cases}
This section presents the Use Cases diagrams, graphically explaining what features need to be available from the point of view of the two actors interacting with the Grid: the Contributor and the Customer.
This section presents the \textbf{Use Cases diagrams}, \textbf{graphically explaining what features need to be available from the point of view of the two actors interacting with the Grid}: the Contributor and the Customer.

An explanation of single use cases here is omitted since the previous section indirectly explained already the non-trivial ones; furthermore, in the next chapter, \textit{section TODO} will show how said use cases are realized using Grid entities collaborating among each other, making redundant a detailed explanation here.

Expand All @@ -113,21 +113,21 @@ \subsection{Use Cases}
\end{itemize}

\subsection{Requirements: MoSCoW Prioritization}
Now that it is clear what the system needs to do from the perspective of the two major actors utilizing it (Contributor and Customer), it is possible to create a list of requirements that such system needs to satisfy. To do so, the MoSCoW method will be used.
Now that it is clear what the system needs to do from the perspective of the two major actors utilizing it (Contributor and Customer), it is possible to create a \textbf{list of requirements} that such system needs to satisfy; to do so, the \textbf{MoSCoW method} will be used.

The MoSCoW method for requirements categorization presents five different categories to put requirements into, ordered by priority. The categories, in descending order, are the following:
The MoSCoW method for \textbf{requirements categorization} presents \textbf{four different} categories to put requirements into, \textbf{ordered by priority}. The categories, in descending order, are the following:
\begin{itemize}
\item \textbf{Must have}
\item \textbf{Should have}
\item \textbf{Could have}
\item \textbf{Won't have}
\end{itemize}
Other than priority, this methodology focuses also on the concept of release, aiming to use an evolutionary approach; this means that in a first production release it is not necessary to satisfy all requirements but just the one with higher priority (Must have), laving the satisfaction of the remaining requirements to subsequent versions (always trying to first satisfy remaining requirements with the highest priority).
Other than priority, \textbf{this methodology focuses also on the concept of release}, aiming to use an \textbf{evolutionary approach}; this means that \textbf{for a first production release it is not necessary to satisfy all requirements but just the one with higher priority} (Must have), laving the \textbf{satisfaction of the remaining requirements to subsequent versions} (always trying to first satisfy remaining requirements with the highest priority).

Requirements in this list are also divided in three areas: Contributor, Customer and Grid Owner; the last area in particular (which was not included in the use cases) is introduced to assign tasks that are more technical in nature but are necessary to the success of the project, both in the short term (first working release) and in the long term (easily introduce new features) given the particular technical nature of this Domain.
Requirements in this list are \textbf{also divided in three areas}: \textbf{Contributor, Customer and Grid Owner}; \textbf{the last area} in particular (which was not included in the use cases) \textbf{is introduced to assign tasks that are more technical in nature but are necessary to the success of the project}, both in the short term (first working release) and in the long term (easily introduce new features) \textbf{given the particular technical nature of this Domain}.

\subsubsection{Must have}
All the requirements that are necessary for the successful completion of a first production release.
All the requirements that are necessary for the successful completion of a first working production release.

\paragraph{Contributor area}
\begin{itemize}
Expand Down Expand Up @@ -184,6 +184,7 @@ \subsubsection{Must have}
\item The Customer must be able to define the data source for the MapReduce execution (whether from the Invoking Device or an external source).
\end{itemize}
\end{itemize}
\vspace{10mm}
\paragraph{Grid owner area}
\begin{itemize}
\item \textbf{Scalability}
Expand Down

0 comments on commit a48190c

Please sign in to comment.