From 037ac8d483d8041c210b329574409ba8565ac944 Mon Sep 17 00:00:00 2001 From: gumartinm Date: Sun, 14 Oct 2012 03:06:39 +0200 Subject: [PATCH] Working on chapter 3. Software requirements. --- capitulo4/capitulo4.tex | 57 ++++++++++++++++++++++++++++++++++++++++++++++--- myrefs.bib | 8 +++++++ 2 files changed, 62 insertions(+), 3 deletions(-) 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", +} -- 2.1.4