Bibliografia: Ingeniería del Software, Guillermo Pantaleo, Alfaomega.

10.1 Relevamiento de requerimientos

10.1.1 Objetivos

10.1.1.1 Especificación de qué desarrollar

La primera actividad en un proyecto de software, independientemente de la metodología a

utilizar, consiste en construir un listado de requerimientos constituido por aquello “qué” debe
permitir hacer el sistema en desarrollo a los usuarios. Estos son los requerimientos funcionales.
“Cómo” debe funcionar dicho sistema en relación a su ambiente operacional será definido por
los requerimientos no funcionales. Unos expresan la funcionalidad a implementar, los otros las
restricciones vinculadas a su funcionamiento [1]. Estos requerimientos deben ser escritos en
frases simples, claras, directas y atómicas de manera que posean ciertas propiedades tales como:
no ambigüedad, completitud y ser correctos. Para el sistema del caso testigo se construyó
previamente un diagrama del contexto, figura 10.1, el cual muestra la primera aproximación al
sistema.

Figura 10.1. Diagrama de contexto del sistema del caso testigo

1
Bibliografia: Ingeniería del Software, Guillermo Pantaleo, Alfaomega.

Figura 10.2. Listado de requerimientos del sistema del caso testigo

En la figura 10.2 se muestra un listado de los requerimientos del sistema a construir para el
caso testigo del libro, el cual fue presentado en la sección “Descripción del problema a resolver”
del capítulo 1. En la figura 10.3 se muestran los requerimientos no funcionales. En ambos
listados puede verse que cada requerimiento está identificado, esto es para poder establecer una
traza desde y hacia ellos con los otros artefactos del desarrollo en el futuro.

Figura 10.3. Listado de requerimientos no funcionales del sistema del caso testigo

2
Bibliografia: Ingeniería del Software, Guillermo Pantaleo, Alfaomega.

Estos requerimientos fueron relevados en reuniones planificadas con los usuarios y otros
involucrados por parte de la empresa cliente. Para ello se utilizaron algunas de las técnicas que
describimos en la próxima sección.

En este relevamiento se buscó cumplir con el objetivo de obtener los requerimientos que
permitieran definir el alcance del sistema, para lo cual se utilizó el material relevado en forma
preliminar cuando se elaboró la propuesta técnico económica a efectos de acordar la realización
del proyecto, en la fase de preventa. En esa oportunidad se relevaron con el propósito de
determinar la intensión del sistema. El foco fue puesto en diferentes aspectos de manera de guiar
el relevamiento a partir de responder a las siguientes preguntas: qué, quién, cuándo, dónde, por
qué y cómo [2]. La vista que aportan los listados de requerimientos ayuda a definir la estructura
del sistema en desarrollo. Para trabajar en estas tareas del proyecto el grupo se organizó de la
forma que describimos en una próxima sección.

Es una práctica común en las metodologías conducidas por los planes volcar estos listados en
un documento denominado Especificación de requerimientos de Software (ERS), como fue
presentado en el capítulo 3.

En las metodologías ágiles estos listados aportarán al “product backlog”.

Otra vista de interés y de fundamental importancia es la del control, aportada por las reglas del negocio.
En la figura 10.4 se presenta el listado de reglas que serán asignadas a las clases del modelo de dominio
que elaboraremos en el próximo capítulo, para obtener así un modelo que describa en estructura y
comportamiento al negocio que busca resolver el sistema en desarrollo.

Figura 10.4. Listado de las reglas del negocio del sistema del caso testigo

3
Bibliografia: Ingeniería del Software, Guillermo Pantaleo, Alfaomega.

10.1.1.2 Definición del alcance

A efectos de definir el alcance a la información ya relevada sumamos otra vista de

importancia, la del comportamiento y la dinámica aportada por los casos de uso. En la figura
10.5 se muestra un diagrama de los casos de uso obtenido a partir de los requerimientos
funcionales y los actores del sistema mostrados en la figura 10.1. Estos casos de uso no son
detallados, lo que implica que cuando se refinen aparecerán otros no mostrados en este diagrama.
Se obtienen a partir de cada uno de los actores y el uso que estos hacen del sistema.

A partir del alcance que se determina de la información relevada estamos en condiciones de establecer
una estimación de esfuerzo que permita realizar una planificación más precisa que la expresada en la
fase de preventa. Estos temas serán abordados en detalle en los capítulos de gestión de proyectos.

Figura 10.5. Diagrama de casos de uso preliminares del sistema del caso testigo

4
Bibliografia: Ingeniería del Software, Guillermo Pantaleo, Alfaomega.

10.1.1.3 Acuerdo del proyecto

A partir del alcance definido y de la estimación de esfuerzo basada en este, se acuerda el

proyecto. Existe una forma de desambiguar los acuerdos respecto del alcance y es la inclusión en
la ERS de una sección que exprese en forma explícita “qué” no se construirá. La experiencia nos
muestra que la mayor parte de los casos en que son incluidas se convierte en un tema de
discusión entre las partes, lo cual indica que existió alguna ambigüedad en el alcance definido.
Esta sección de no inclusiones funciona como un disparador al momento de establecer el acuerdo
del proyecto y ayuda a cerrar y acordar el alcance definitivo.

Cuando se trabaje en cada una de las iteraciones del ciclo de vida del proyecto, se refinarán
los casos de uso y se especificarán a efectos de elaborar un diseño detallado orientado a su
implementación. También se elaborarán casos de prueba en base a los casos de uso refinados.
Todas estas cuestiones serán tratadas a lo largo del libro en próximos capítulos.

10.1.2 Técnicas de relevamiento

Para lograr obtener el análisis detallado presentado en las secciones anteriores y que se verán
en las subsiguientes existen diferentes técnicas que pueden utilizarse. El principal objetivo de
estas técnicas, denominadas de relevamiento, es entender las necesidades del cliente; es decir,
comprender los requisitos y el porqué de estos. Además buscan obtener las propiedades del
dominio del sistema actual, si es que existe, interfaces, escenarios posibles, potenciales conflictos
y riesgos. No nos olvidemos que el cliente utiliza un lenguaje ubicuo que intentamos comprender
para plasmar sus necesidades implícitas y explícitas como requerimientos.

Por último, es importante destacar que no existe una técnica de relevamiento mejor que otra,
depende el contexto del proyecto es conveniente utilizar una u otra. Cuando nos referimos al
contexto del proyecto hacemos referencia al tiempo, a los recursos disponibles y de la clase de
información que se precisa elicitar (relevar).

Entre las técnicas de relevamiento podemos mencionar las siguientes:

Entrevistas

Es una técnica simple y directa. Puede ser muy útil para descubrir requerimientos ocultos por
medio de la comunicación directa y la exploración de distintas soluciones. En primera instancia,
las entrevistas requieren la identificación de los candidatos a ser entrevistados. Generalmente se
toman en cuenta a los stakholders (interesados en el desarrollo a llevar a cabo, puede ser el
cliente y/o usuario) como participantes de estas reuniones. Además debe tenerse en cuenta como

5
Bibliografia: Ingeniería del Software, Guillermo Pantaleo, Alfaomega.

participantes a los representantes del equipo que desarrollará el sistema (analista, líder de
proyecto, desarrollador, arquitecto). Para lograr obtener los requerimientos, el equipo que
desarrollará la aplicación guiará la reunión buscando establecer el perfil del cliente, evaluar el
problema, comprender el entorno, evaluar la oportunidad, la fiabilidad y el desempeño requerido.
Luego analizar lo recolectado para comprenderlo y continuar con las entrevistas focalizándolas
en entender el problema real del cliente y evaluar la/s posible/s solución/es. Examinar los
problemas del cliente y las soluciones que podríamos brindarle a cada uno de ellos. Cuando la
reunión haya finalizado, es conveniente resumir los puntos más importantes e identificar los
problemas en forma prioritaria para el cliente.

Cabe mencionar que es crucial llevar a cabo la reunión. Es la forma de entender su contexto y
sus necesidades en forma directa. No es posible sustituir el contacto personal por medio del
envío de un mail con el cuestionario.[1]

Simulación de usuario

Es una técnica de relevamiento de requerimientos que facilita el estudio y la compresión del

ámbito del usuario. El analista toma la posición del usuario y así se integra al ambiente de trabajo
para el cual se hará el desarrollo. Este método le permite comprender sus necesidades.

La desventaja que presenta esta técnica es que consume un tiempo considerable para llevar a
cabo la simulación. Es decir que es una técnica costosa.

Historietas (Storyboard)

Esta técnica permite analizar la reacción del usuario ante la propuesta que tiene el equipo que
desarrollará el sistema. Asimismo proporciona una respuesta temprana sobre el sistema por parte
del usuario y/o cliente, a la vez que es fácil de crear y modificar.

Generalmente se definen tres tipos de historietas, aunque en la práctica no hay reglas

definidas, lo que permite utilizar la imaginación para su elaboración. Las clases de historietas las
podemos agrupar en función del modo de interacción con el usuario y/o cliente como: historietas
pasivas, activas e interactivas.

Las historietas pasivas narran una historia al usuario por medio de imágenes, capturas de
pantallas o presentaciones. Las historietas activas son una película que no ha sido producida aún,
lo cual le permite al usuario/ cliente una perspectiva del uso típico de la aplicación. Por último,
las historietas interactivas requieren la participación activa del cliente. Pueden ser implementadas
utilizando simuladores o una presentación interactiva.

Como podrá suponerse, las historietas interactivas son más costosas que las pasivas. Por lo
tanto la utilización de cada una de estas técnicas dependerá de la complejidad y los riesgos del
sistema. Es posible, si se considera útil, comenzar por la técnica pasiva, continuar por la activa y
por último implementar las historietas interactivas.

6
Bibliografia: Ingeniería del Software, Guillermo Pantaleo, Alfaomega.

Durante el progreso de las historietas es importante detectar los actores que interactúan con el
sistema que estamos definiendo, los elementos que representan el comportamiento de los
usuarios cuando interactúan con la aplicación y viceversa; y, por último, cómo ocurre la
interacción entre el usuario y el sistema.

Finalmente, queremos destacar que no es conveniente invertir mucho tiempo en la

elaboración de las historietas, es altamente probable que el usuario/cliente desee hacer cambios.
[1].

Prototipado

En esta técnica se elabora un modelo funcional del sistema. Esto le permite al usuario tener
una idea del flujo y del estilo de la aplicación. Se utiliza cuando existe cierta incertidumbre sobre
los requerimientos o cuando es necesaria una respuesta rápida por parte de los usuarios y/o
clientes.

A partir del uso del prototipo el usuario emitirá su opinión para refinar los requerimientos. Lo
más conveniente es desarrollar un prototipo de las funcionalidades más complejas o de aquellas
que más se desconozca.

Existe una amplia variedad de técnicas de prototipado que abarcan desde versiones beta de
los productos hasta esquemas de diseños de pantallas en papel. Para el caso de las versiones beta,
permiten ser reutilizadas como base para el posterior desarrollo. En otros casos los prototipos
pueden descartarse.

Esta técnica puede emplearse en combinación con otras técnicas de elicitación de

requerimientos. También puede ser utilizada para el relevamiento de requerimientos como para
su validación, como se verá en el capítulo 12.