En esta unidad se describen los elementos más importantes para identificar requerimientos, pues en la ingeniería de requerimientos este proceso se conoce como elicitación.

La elicitación se define como la acción de transmitir la información entre los interesados a un grupo de desarrollo de software.

Para ejecutar la elicitación es importante identificar los interesados e involucrados, seleccionar un esquema de clasificación de los requerimientos, identificar las fuentes y técnicas de recolección, y finalmente especificar escenarios o casos de uso.

Propósito general

Identificar los elementos necesarios para facilitar la comunicación entre las fuentes y la selección de los requerimientos.

Propósitos específicos

• Conocer la relación que existe entre los elementos básicos de la identificación de requerimientos.
• Identificar a todos los interesados en la problemática y la oportunidad que se solucionará con un determinado software.
• Seleccionar el esquema adecuado de clasificación para guiar la identificación de requerimientos.
• Seleccionar las fuentes y técnicas que faciliten el proceso de identificación de requerimientos.
• Identificar los casos de uso y los escenarios de los requerimientos.

La identificación de requerimientos es un proceso que se conoce formalmente como elicitación y que busca la transferencia de conocimiento entre los interesados y un grupo de desarrollo de software. En este proceso se identifican cuatro elementos como fundamentales y esenciales, pues de manera relacionada producen la identificación completa de las necesidades y restricciones principales.

Conozca la descripción de los cuatro elementos y la relación que se entabla entre ellos.

La identificación de interesados tiene por objetivo seleccionar a todos los sujetos que van a estar involucrados en la solución de software. Este grupo de interesados no solo está compuesto por quienes dan origen a la necesidad, sino que debe incluir a todas las personas que se verán afectadas por la solución de software, tanto directa como indirectamente.

La identificación de interesados, como la base de los requerimientos, tiene una relación en el flujo de trabajo con el modelo de negocio, es decir que es importante relacionar en la solución del problema —a nivel del negocio— a todas las personas que aporten un valor agregado al software.

La importancia de involucrar a los interesados en el proceso de establecimiento de los requerimientos radica en la necesidad de proveer las necesidades principales a resolver y las restricciones que puedan presentarse. Además, identificar los interesados y sus aportes permite tener un mejor entendimiento del proceso por parte de todas las personas involucradas.

A propósito de esta última idea, la imagen que aparece en pantalla demuestra lo que puede pasar cuando no se involucra a todos los interesados en el proceso.

A continuación se describen los diferentes tipos de perfiles que suelen encontrarse en el grupo de interesados en un proceso de identificación de requerimientos:

• Usuarios.
• Clientes.
• Analistas de mercado.
• Analistas de sistemas.
• Reguladores.
• Ingenieros de software.

El video que aparece en pantalla ejemplifica los conceptos expuestos hasta este punto. En él se relata un caso de estudio sobre una empresa de desarrollo de videojuegos en el que se caracterizan los interesados en un proyecto de software.

Existe una gran variedad de opciones para clasificar los requerimientos, pero independiente de la clasificación seleccionada todas ellas permiten priorizar el trabajo y tener en cuenta las propiedades emergentes y de cuantificación de los mismos.

Existen tres alternativas comunes para clasificar los requerimientos:

• Requerimientos funcionales y no funcionales.
• Requerimientos de producto y de proceso.
• Requerimientos de sistema y de software.

Así mismo, los requerimientos tienen dos tipos de características particulares:

• Propiedades SMART.
• Propiedades emergentes.

En esta clasificación los requerimientos funcionales describen las funciones que el software debe ejecutar y algunas veces se relacionan incluso con los requerimientos del negocio o de la organización. Un ejemplo de este tipo de requerimientos son los que a diario plantea el problema que se está tratando de solucionar con la implementación del nuevo software, pero desde el punto de vista de los involucrados.

Para identificar la solución se dispone de un conjunto de herramientas y técnicas como las historias de usuario, que le permiten al especialista de requerimientos identificar el problema y la solución que determina los requerimientos funcionales.

Por otra parte, los requerimientos no funcionales son aquellos que actúan para restringir la solución, por ejemplo las restricciones de seguridad, confiabilidad, disponibilidad y mantenimiento, entre otras.

Según esta clasificación, los requerimientos de producto son aquellos que hacen referencia a las funciones que debe cumplir el software, es decir que son los que tienen relación con la solución del problema desde el punto de vista de los usuarios finales.

Los requerimientos de proceso, por su parte, tienen una relación directa con el proceso de desarrollo de software; por ejemplo, las metodologías que se usarán.

En el contexto de la solución de un problema estos requerimientos tienen relación con la forma de estructurar el proceso de desarrollo de software, además, dependiendo de los requerimientos funcionales, el especialista propone los requerimientos no funcionales.

El sistema hace referencia a un conjunto de componentes que interactúan para cumplir determinados objetivos. Estos componentes son: hardware, software, firmware, personas, información, técnicas, servicios y otros elementos de soporte.

Por lo anterior, los requerimientos de sistema son requerimientos derivados de los componentes del sistema y su interacción. En el contexto de una solución de software el sistema es la visión de todos los elementos de una organización, que se necesitan para generar un efecto positivo con la solución.

De otro lado, los requerimientos de software son los que se derivan de los usuarios y tienen una relación directa con las necesidades u oportunidades. En el contexto de la solución de un problema son los que se relacionan con las funciones del negocio.

SMART es la sigla que resume las características que deben identificar a los requerimientos. Estas características son:

Suficiente.

Medible.

Aplicable.

Recursos asignados.

Temporal.

En el esquema interactivo se explica de manera detallada cada una de estas características.

Algunos requerimientos representan propiedades emergentes del software. Estos requerimientos no se pueden manejar por un solo componente, sino que repercuten en, por lo menos, dos componentes del sistema. Un buen ejemplo de estos requerimientos son los de desempeño.

Los requerimientos que representan propiedades emergentes del software son especialmente dependientes en el sistema de la arquitectura.

Tras identificar a los interesados y seleccionar la forma de clasificar los requerimientos se deben describir las fuentes de las que se obtendrán los requerimientos y las técnicas que se usarán para dicho fin.

Para recordar… Fuente: de dónde se obtienen los requerimientos. Técnica: forma para obtener los requerimientos.

En la fase inicial de la especificación de los requerimientos y teniendo en cuenta que el software tiene como objetivo resolver un problema es importante involucrar todas las fuentes necesarias para determinar los requerimientos.

Las fuentes usadas en la fase inicial de elicitación son:

• Metas.
• Dominio del conocimiento.
• Stakeholders.
• Reglas del negocio.
• El entorno operacional.
• El entorno organizacional.

Para saber en qué consiste cada una de estas fuentes consulte el esquema interactivo.

Las técnicas son los medios que se utilizan para obtener la información de los requerimientos. Teniendo en cuenta que en la etapa inicial es importante la adecuada transmisión de conocimiento entre los involucrados y el grupo de desarrollo, estas son las principales técnicas a considerar:

• Entrevistas.
• Escenarios.
• Prototipos.
• Reuniones.
• Observaciones.
• Historias de usuario.
• Otras (competencia).

Un caso de uso se define formalmente como la descripción de un proceso desde que inicia hasta que culmina. A pesar de que el diagrama es parte importante de un proceso, no es el único elemento que lo caracteriza. En tal contexto, los casos de uso son una descripción detallada de la interacción, aunque no describen todos los requerimientos.

• Actor. Es el rol que juega una persona. También se entiende como un dispositivo de hardware o incluso otro sistema que interactúa con el sistema. En este elemento se identifica quienes inician las funciones en el proyecto de software.


• Escenario. Describe un uso del sistema en términos de una serie de interacciones entre el usuario y el sistema. En este contexto existen tres tipos de escenarios: exitosos, alternativos y fallidos. En los casos de uso es importante describir, desde la perspectiva de los actores, las interacciones básicas con el sistema. Son estas interacciones las que se describen en los escenarios.


• Caso de uso. Se entiende como la colección de escenarios y de otros datos que describen a los actores utilizando un sistema para satisfacer un objetivo. Los casos de uso tienen dos descripciones: una general, donde se utiliza con frecuencia una imagen, y una detallada, que se expresa por medio de una documentación.

Actividad de aprendizaje

Repase los conceptos estudiados hasta este punto, al acceder a la siguiente actividad.

El proceso de levantamiento de requerimientos inicia con la representación gráfica del caso de uso, para lo cual se utiliza el lenguaje unificado de modelado (UML). Tras una descripción resumida del caso de uso —en la que se determinan los elementos relevantes de la funcionalidad del proyecto de software— se elabora una descripción casual en la que se relacionan los componentes relevantes de la interacción entre el actor y la funcionalidad del proyecto. Finalmente se elabora una descripción detallada en la que se documentan todos los elementos relevantes de la interacción por medio de una tabla.

Material de apoyo

En esta unidad se describieron los elementos más importantes para identificar requerimientos, los cuales se explicaron en cuatro etapas a saber:

1. Identificación de todos los interesados en la problemática a la que dará solución el nuevo software.


2. Selección de un esquema adecuado de clasificación para guiar la identificación de requerimientos.


3. Mención de las fuentes y técnicas que facilitan el proceso de identificación de requerimientos.


4. Elaboración de los casos de uso, que empieza con un proceso gráfico y pasa por tres tipos de descripción: resumida, casual y detallada. Para obtener una descripción completa, en esta última se incluyen escenarios como: el exitoso, alternativos y fallidos.

Pedagogía activa

Resuelve el siguiente ejercicio que le permitirá poner en práctica los conocimientos adquiridos en esta unidad.