From: gumartinm <gustavo@gumartinm.name>
Date: Sun, 14 Oct 2012 01:06:39 +0000 (+0200)
Subject: Working on chapter 3. Software requirements.
X-Git-Url: https://git.gumartinm.name/?a=commitdiff_plain;h=037ac8d483d8041c210b329574409ba8565ac944;p=PFCLatex%2F.git

Working on chapter 3. Software requirements.
---

diff --git a/capitulo4/capitulo4.tex b/capitulo4/capitulo4.tex
index 4e1ade6..7d4e10a 100644
--- a/capitulo4/capitulo4.tex
+++ b/capitulo4/capitulo4.tex
@@ -2,7 +2,59 @@
 
 \section{Análisis}
 
-\subsection{Diagrama de casos de uso}
+A lo largo de esta primera sección se intentará explicar de forma detallada todos los requisitos y los casos de uso de las dos aplicaciones de las que se compone este proyecto fin de carrera: la aplicación web y la aplicación basada en Android.
+
+\subsection{Análisis de requisitos}
+
+Todo desarrollo software comienza con la toma de requisitos y el análisis de la aplicación por parte de los \emph{analistas de software}. A lo largo del desarrollo, la especificación de los requisitos suele variar bien porque el usuario o cliente final cambia de idea o bien por motivos técnicos relacionados con la implementación de la funcionalidad inicialmente solicitada.
+
+En este apartado se especificarán los principales requisitos de la aplicación Web y la basada en Android. Para la extracción de requisitos existen diversas técnicas, en el caso de este proyecto el cliente y desarrollador son la misma persona por tanto no es necesario emplear ninguna técnica en particular.
+
+Se hará una división entre requisitos software y requisitos de restricción y se usará un formato tabular para la formulación de dichos requisitos. Los campos de los que se compondrán las tablas serán los siguientes:
+
+\begin{itemize}
+    \item \textbf{Título de la tabla}: descripción del objetivo del requisito.
+    \item \textbf{Código}: identificador único del requisito.
+    \item \textbf{Tipo}: los tipos funcionales, no funcionales y de usabilidad serán descritos en la siguiente sección.
+    \item \textbf{Descripción}: como su nombre indica es la descripción breve y detallada del requisito en sí mismo.
+    \item \textbf{Prioridad}: puede ser alta, media o baja y define la prioridad con la cual un requisito en particular debe ser cumplido durante el desarrollo del software. 
+\end{itemize}
+
+\subsection{Requisitos software}
+
+La fase de especificación de requisitos software (SRS por sus siglas en Inglés) está diseñada para documentar y describir el comportamiento de un sistema que se desea desarrollar. Supone un acuerdo entre el usuario y el desarrollador respecto a la especificación del producto software solicitado~\cite{C4:Specifications}. El principal propósito de la especificación de requisitos software consiste en proporcionar una completa y clara descripción de los requisitos solicitados por el usuario~\cite{C4:Specifications}, dicha descripción puede ser usada como referencia en etapas posteriores del desarrollo del software solicitado.
+
+Identificaremos tres tipos de requisitos:
+
+\begin{itemize}
+    \item Requisitos funcionales: suponen una funcionalidad propia del sistema software que se debe desarrollar.
+    \item Requisitos no funcionales: suelen estar relacionados con funcionalidades del software a implementar. No son una funcionalidad en sí mismos. Por ejemplo, requisitos relacionados con el rendimiento.
+    \item Requisitos de usabilidad: relacionados con cómo el usuario interactúa con las aplicaciones.
+\end{itemize}
+
+\begin{table}[h]
+\centering
+\scriptsize
+    \begin{tabularx}{\textwidth}{|l|X|}
+        \hline
+        \multicolumn{2}{|c|}{\cellcolor[gray]{0.8}\normalsize\textbf{Roles de usuario}} \\
+        \hline
+        \normalsize\textbf{Código identificador} & \multicolumn{1}{|c|}{\cellcolor[gray]{0.8}\normalsize\textbf{RSW-01}} \\
+        \hline
+        \normalsize\textbf{Tipo} & \multicolumn{1}{c|}{\normalsize{Funcional}} \\
+        \hline
+        \normalsize\textbf{Descripción} & \normalsize{Se deben definir diferentes roles para el acceso a la aplicación. Por un lado los usuarios tipo empresa pueden generar nuevo contenido y por el otro los usuarios ``normales'' accederán y recibirán en sus teléfonos dicho contenido.} \\
+        \hline
+        \normalsize\textbf{Prioridad} & \multicolumn{1}{c|}{\normalsize{Alta}} \\
+        \hline
+    \end{tabularx}
+    \caption{\emph{Tabla Requisito Funcional 1.}}
+    \label{tab:requisitoSW1}
+\end{table}
+
+
+
+\subsection{Modelando los requisitos, diagrama de casos de uso}
 
 En la Figura~\ref{fig:MobiAdsUseCaseWeb}) se puede observar el diagrama de casos de uso de la aplicación Web desarrollada. Se puede observar el diagrama de casos de uso de la aplicación Web desarrollada.
 \begin{figure}[H]
@@ -24,7 +76,7 @@ A continuación se describirán textualmente cada uno de los casos de uso indica
 \subsection{Descripción de los casos de uso}
 
 \begin{table}[h]
-\begin{center}
+\centering
 \scriptsize
     \begin{tabularx}{\textwidth}{|X|X|}
         \hline
@@ -45,5 +97,4 @@ A continuación se describirán textualmente cada uno de los casos de uso indica
     \end{tabularx}
     \caption{\emph{Tabla de casos de uso 1.}}
     \label{tab:tabladecasosdeuso1}
-\end{center}
 \end{table}
diff --git a/myrefs.bib b/myrefs.bib
index 2a30d1e..71ec4ea 100644
--- a/myrefs.bib
+++ b/myrefs.bib
@@ -239,3 +239,11 @@
     year = {2004},
     keywords = "UML",
 }
+
+@Book{C4:Specifications,
+    author = {Prof. Betty H.C. Cheng},
+    title = {Requirementes Assignment},
+    publisher = {Michigan State University},
+    year = {2007},
+    keywords = "SRS, software, requirements",
+}