1.1.

Definición de requerimiento

Los requerimientos para un sistema son la descripción

de los servicios proporcionados por el sistema y sus
restricciones operativas. Estos requerimientos reflejan
las necesidades de los clientes de un sistema que ayude
a resolver algún problema como el control de un
dispositivo, hacer un pedido o encontrar información.

El proceso de descubrir, analizar, documentar y verificar

estos servicios y restricciones se denomina ingeniería
de requerimientos.

En el modelo clásico de desarrollo de sistemas, la etapa

de los requerimientos viene antecedida de la etapa de
factibilidad del sistema y precedida por la etapa de
diseño del sistema.

1
 1.2. Clasificación de los requerimientos

Algunos de los problemas que surgen durante el proceso de ingeniería de

requerimientos son resultado de no hacer una clara separación entre estos
diferentes niveles de descripción. Aquí se distinguen utilizando la denominación
requerimientos del usuario para designar los requerimientos abstractos de alto
nivel, y requerimientos del sistema para designar la descripción detallada de lo
que el sistema debe hacer.

1. Requerimientos de Usuario: Es un documento donde describes “qué”

debe hacer el sistema en términos no técnicos y debe ser lo más detallado
posible para evitar ambigüedades.

2. Requerimientos de Sistema: Estos requerimientos establecen con detalle

las funciones, servicios y restricciones operativas del sistema. El documento
de requerimientos del sistema deberá ser preciso, y definir exactamente lo
qué se va a implementar.

2
 1.2. Clasificación de los requerimientos

A menudo, los requerimientos de sistemas de software se clasifican en

funcionales y no funcionales, o como requerimientos del dominio:

1. Requerimientos Funcionales: Son declaraciones de los servicios que debe

proporcionar el sistema, de la manera en que éste debe reaccionar a
entradas particulares y de cómo se debe comportar en situaciones
particulares. En algunos casos, pueden declarar explícitamente lo que el
sistema no debe hacer.

2. Requerimientos No Funcionales: Son restricciones de los servicios

o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo,
sobre el proceso de desarrollo y estándares. Los requerimientos no
funcionales a menudo se aplican al sistema en su totalidad. Normalmente
apenas se aplican a características o servicios individuales del sistema.
Dentro de estos requerimientos encontramos todo lo referente a fiabilidad,
el tiempo de respuesta y la capacidad de almacenamiento

3
 1.2. Clasificación de los requerimientos

3. Requerimientos de Dominio: Son requerimientos que provienen del

dominio de aplicación del sistema y que reflejan las características y
restricciones de ese dominio. Pueden ser funcionales o no funcionales.

Los conceptos antes analizados se refieren a las clasificaciones de los

requerimientos de software, pero también se dividen en base a la constancia o
tiempo que tardan en modificarse los requerimientos, a continuación
observamos los tipos de requerimientos:

❑ Requerimientos Duraderos: Son requerimientos

relativamente estables que se derivan de la actividad principal de la
organización y que están relacionados directamente con el dominio del
sistema.

❑ Requerimientos Volátiles: Son requerimientos que probablemente

cambian durante el proceso de desarrollo del sistema o después de que
este se haya puesto en funcionamiento.

4
 1.2. Clasificación de los requerimientos

Requerimientos
Funcionales
Clasificación
Requerimientos
de Usuario Requerimientos
No Funcionales
Requerimientos
Funcionales
Requerimientos Requerimientos
de Sistema No Funcionales
Requerimientos
de Dominio

5
 1.2. Clasificación de los requerimientos

En este gráfico se puede observar los tipos de requerimientos existentes en base al tipo
de modificaciones:

Clasificación tomando en cuenta

el tiempo en modificarse
Duraderos

Volátiles

6
 1.2.1 Funcionales

Los requerimientos funcionales son las descripciones explicitas del

comportamiento que debe tener una solución de software y que información
debe manejar.

Por lo tanto, los requerimientos funcionales:

Expresan las capacidades o cualidades que debe tener la solución para

satisfacer los requerimientos de los interesados de proyecto.

❑ Se expresan en términos de cuál debe ser el comportamiento de la solución y

que información debe manejar.
❑ Deben proporcionar una descripción lo suficientemente detallada para
permitir el desarrollo e implementación de la solución.
❑ Son los que más influyen en si la solución será aceptada o no por los
usuarios.

7
 1.2.1 Funcionales

Importancia de definir los requerimientos funcionales

Los problemas y errores en la gestión de requerimientos funcionales son citados como

una de las causas más frecuentes que ocasionan insatisfacción de las expectativas de los
interesados en proyectos de software.

Profundizando en las causas de estos problemas, las situaciones observadas con mayor
frecuencia son:

❑ Requerimientos funcionales con descripciones muy ambiguas, produciendo

interpretaciones inadecuadas por parte del equipo de desarrollo.
❑ El requerimiento funcional no fue entendido adecuadamente cuando fue levantado
con el interesado, pasando información incorrecta al equipo de desarrollo.
❑ En su forma original, el requerimiento funcional no era factible técnicamente y el
equipo de desarrollo realizó modificaciones que no fueron aprobadas por los
interesados.

8
 1.2.1 Funcionales

Es fundamental la aplicación de metodologías probadas de gestión de requerimientos

funcionales que eviten que estos problemas sucedan, algunas de las prácticas más
recomendadas son:

❑ Ante la presencia de ambigüedades, solicitar información adicional, mesas de trabajo

o reuniones con los interesados. Es menos costoso esperar a obtener una descripción
que aclare las dudas antes que asumir y avanzar en el desarrollo.
❑ Validar las descripciones escritas de los requerimientos funcionales antes de
comenzar su desarrollo.
❑ Cualquier duda que presente el equipo de desarrollo buscar comunicación con los
interesados para su resolución.
❑ Si durante el desarrollo se presentará la necesidad de modificar algún requerimiento
funcional debido a razones técnicas, solicitar mesas de trabajo o reunir, no proceder
con un desarrollo e implementación que no ha sido validado por los interesados.

Siguiendo estas prácticas podemos asegurar una mejor aceptación de los requerimientos
funcionales cuando llegue el momento de la implementación.

9
 1.2.1 Funcionales

Ejemplos de requerimientos funcionales de proceso o área de negocio

❑ El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de cliente,
despacho de mercancía al cliente, emisión de factura a cliente y registro de pago de cliente.
❑ Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse posteriormente
modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos.
❑ Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de aprobación configurado en el sistema.
❑ El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas de proyecto.
❑ El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de proyecto.

Ejemplos de requerimientos funcionales de interfaz gráfica

❑ La solución validara automáticamente el cliente asociado a una orden con el sistema de gestión de contactos.
❑ El campo de monto acepta únicamente valores numéricos con dos decimales.
❑ El campo fecha de transacción acepta únicamente fechas anteriores al día de hoy (día actual).
❑ El campo nombre acepta caracteres alfabéticos únicamente.
❑ El campo dirección acepta caracteres alfabéticos, numéricos y especiales.

Ejemplos de requerimientos funcionales legales o regulatorios

❑ El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados.

❑ La base de datos será implementada con trazas de auditoría.
❑ Las hojas de cálculo aseguraran los datos usando firmas electrónicas.
❑ El sistema permitirá elaborar y emitir el reporte regulatorio XX, según los requerimientos establecidos en el reglamento y ley
aplicable.
❑ Los libros de venta y de compras serán emitidos en el formato establecido por las autoridades tributarias de dicha materia.

10
 1.2.1 Funcionales

Ejemplos de requerimientos de seguridad

❑ El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados. Los usuarios deben ingresar al
sistema con un nombre de usuario y contraseña.
❑ El sistema enviará una alerta al administrador del sistema cuando ocurra alguno de los siguientes eventos:
Registro de nueva cuenta, ingreso al sistema por parte del cliente, 2 o más intentos fallidos en el ingreso de la
contraseña de usuario y cambio de contraseña de usuario.
❑ Los integrantes del grupo de usuarios de analistas pueden ingresar solicitudes pero no pueden aprobarlas o
borrarlas.
❑ Los integrantes del grupo de usuarios de gerentes pueden ingresar y aprobar solicitudes, pero no pueden
borrarlas.
❑ Los integrantes del grupo de usuario de administradores no pueden ingresar o aprobar solicitudes, pero si
pueden borrarlas.
❑ Cualquier intercambio de datos vía internet que realice el software se realizará por medio del protocolo
encriptado https.

Ejemplos de requerimientos de interfaces externas (Hardware y Software)

❑ El software podrá ser utilizado en los sistemas operativos Windows, Linux y OSX.
❑ La aplicación debe poder utilizarse sin necesidad de instalar ningún software adicional además de un
navegador web.
❑ La aplicación debe poder utilizarse con los navegadores web Chrome, Firefox e Internet Explorer.

11
 1.2.2 No Funcionales

Los requerimientos no funcionales, como su nombre sugiere, son aquellos

requerimientos que no se refieren directamente a las funciones específicas que
proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el
tiempo de respuesta y la capacidad de almacenamiento. También especifican criterios
para evaluar la operación de un servicio de tecnología de información, en contraste con
los requerimientos funcionales que especifican los comportamientos específicos.

Para algunos proyectos, estos requerimientos implican una cantidad considerable de

trabajo y esfuerzos, mientras que para otros no. Con frecuencia, los requerimientos no
funcionales son ignorados o subestimados en la fase de análisis de requerimientos. El
error, termina identificándose en la fase de implementación cuando remediarlos implica
más trabajo y costo, pudiendo ocasionar que no sean adoptados por los usuarios y
clientes.

Por lo general, el plan para implementar los requerimientos no funcionales se detalla en

la arquitectura del sistema, mientras que el de los requerimientos funcionales se
especifica en el diseño.

12
 1.2.2 No Funcionales

La clasificación de Requerimientos No Funcionales de Sommerville

13
 1.2.2 No Funcionales
Requerimientos No Funcionales de Producto

Suele referirse a limites o restricciones sobre el comportamiento del sistema, por lo cual establece límites y restricciones sobre lo que
los diseñadores (arquitectos de software) e ingenieros de software pueden hacer.

Algunos de estos requerimientos pueden ser fáciles de cuantificar, por ejemplo el desempeño y la confiabilidad, pero otros son más
difíciles como por ejemplo usabilidad y adaptabilidad.

Los requerimientos de producto pueden clasificarse en:

❑ Requerimientos de usabilidad: La usabilidad se define como el esfuerzo que necesita hacer un usuario para aprender, usar,
ingresar datos e interpretar los resultados obtenidos de un software de aplicación. En tiempos recientes, la usabilidad ha adquirido
mucha importancia, en especial ante la demanda de desarrollo de software para móviles y tabletas.
❑ Requerimientos de eficiencia: Relacionado con desempeño en cuanto a tiempo de respuesta, número de operaciones por
segundo, entre otras mediciones, así como consumo de recursos de memoria, procesador, espacio en disco o red.
❑ Requerimientos de dependibilidad: Engloba varios atributos.
▪ Disponibilidad: Disposición del sistema para prestar servicio correctamente.
▪ Confiabilidad: Continuidad del servicio prestado por el sistema.
▪ Seguridad industrial: Ausencia de consecuencias catastróficas para el usuario o el ambiente.
▪ Integridad: Ausencia de alteraciones inadecuadas al sistema.
▪ Mantenibilidad: Posibilidad de realizar modificaciones o reparaciones a un proceso sin afectar la continuidad del servicio.
❑ Requerimientos de seguridad: Capacidades funcionales o no funcionales que debe tener un sistema para cumplir atributos en el
área de seguridad de tecnología de información, seguridad de datos, seguridad lógica, control de acceso a información
(restricciones de acceso), autenticidad de la información, privacidad, entre otros aspectos.

Considerar los requerimientos de producto es vital para lograr la integración continua de aplicaciones y el desarrollo de cambios que
sean rápidos pero sostenibles en el tiempo. Este nuevo paradigma es necesario para implementar las nuevas tecnología de
información y aplicaciones de software como la movilidad, internet de las cosas, analítica avanzada de datos (Big Data), evolución de
los sistemas a la nube y tecnología de información escalable.

14
 1.2.2 No Funcionales
Requerimientos No Funcionales Organizacionales

Se derivan de las políticas y procedimientos de la organización como por ejemplo estándares de procesos o
requerimientos de implementación.

Pueden incluir metodologías de desarrollo de software, estándares de programación (codificación) y

herramientas de soporte al desarrollo de software (por ej. Herramientas CASE) que deben usarse
(siguiendo las políticas de la organización), también reportes a la gerencia que deben proveerse, entre
otros.

Las herramientas para la gestión de desarrollo de software que conocemos, se definen como
requerimientos no funcionales organizacionales.

Los requerimientos organizacionales pueden clasificarse en (según Sommerville):

❑ Requerimientos de entorno: Describen el ambiente operativo en el que se debe desenvolver el

sistema.
❑ Requerimientos operacionales: Procedimientos operativos que describen como será usado el sistema
dentro del contexto de la organización.
❑ Requerimientos de desarrollo: Lenguaje de programación a usar, estándares de codificación, patrones
de diseño y programación, herramientas para gestionar el desarrollo de software, entorno de
desarrollo de software, entorno de pruebas de software (ambiente de pruebas), entre otros aspectos.

15
 1.2.2 No Funcionales
Requerimientos No Funcionales Externos

Estos derivan del entorno organizacional (no entorno técnico) en el cual se desarrolla el sistema y
pueden hacerse tanto sobre el producto (el software desarrollado) o también sobre el proceso de
desarrollo de software.
Este tipo de requerimientos incluyen limitaciones de índole económica, interacción o necesidad del
sistema de interoperar con otros sistemas, requerimientos regulatorios en el área de salud,
seguridad industrial o protección de datos, requerimientos legales concernientes con licencias,
regulaciones o certificaciones que necesita el producto según la industria en el que se desempeñe,
entre otros.

Sommerville a su vez clasifica estos requerimientos en:

❑ Requerimientos regulatorios: Leyes y reglamentos que establecen que debe hacer el sistema y
como debe hacerlo para cumplirlas. El foco de un sistema o nueva funcionalidad puede ser
exclusivamente para cumplir una regulación.
❑ Requerimientos éticos: Requerimientos que aseguran que el sistema será aceptable para el
usuario, público en general y se adapta a las costumbres de la sociedad en la que se desenvuelve
o a la que presta servicios.
❑ Requerimientos legislativos: Características que debe cumplir el sistema para cumplir con la ley,
por ejemplo en el área de contabilidad (normas contables y estándares financieros),
requerimientos de seguridad industrial (para sistemas críticos), entre otros aspectos.

16
 1.2.2 No Funcionales

Ejemplos de requerimientos no funcionales de producto

Eficiencia

❑ El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por medio de la
herramienta SoapUI aplicada al Software Testing de servicios web.
❑ Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de 5 segundos.
❑ El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con sesiones concurrentes.
❑ Los datos modificados en la base de datos deben ser actualizados para todos los usuarios que acceden en
menos de 2 segundos.

Seguridad lógica y de datos

❑ Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de acceso a datos.
❑ El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de programación que
incrementen la seguridad de datos.
❑ Todos los sistemas deben respaldarse cada 24 horas. Los respaldos deben ser almacenados en una localidad
segura ubicada en un edificio distinto al que reside el sistema.
❑ Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben estar
encriptadas utilizando el algoritmo RSA.
❑ Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando hasta ser
desbloqueado por un administrador de seguridad.

17
 1.2.2 No Funcionales

Ejemplos de requerimientos no funcionales de producto

Seguridad industrial

❑ El sistema no continuará operando si la temperatura externa es menor a 4 grados Celsius.

❑ El sistema no continuará operando en caso de fuego. (Ej. Un ascensor).

Usabilidad

❑ El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.
❑ La tasa de errores cometidos por el usuario deberá ser menor del 1% de las transacciones
totales ejecutadas en el sistema.
❑ El sistema debe contar con manuales de usuario estructurados adecuadamente.
❑ El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario
final.
❑ El sistema debe contar con un módulo de ayuda en línea.
❑ La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada
visualización en múltiples computadores personales, dispositivos tableta y teléfonos inteligentes.
❑ El sistema debe poseer interfaces gráficas bien formadas.

18
 1.2.2 No Funcionales
Ejemplos de requerimientos no funcionales de producto

Dependibilidad

❑ El sistema debe tener una disponibilidad del 99,99% de las veces en que un usuario intente
accederlo.
❑ El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos.
❑ La tasa de tiempos de falla del sistema no podrá ser mayor al 0,5% del tiempo de operación
total.
❑ El promedio de duración de fallas no podrá ser mayor a 15 minutos.
❑ La probabilidad de falla del Sistema no podrá ser mayor a 0,05.

Otros ejemplos de requerimientos de producto

❑ El sistema será desarrollado para las plataformas PC y Macintosh.

❑ La aplicación debe ser compatible con todas las versiones de Windows, desde Windows 95.
❑ La aplicación deberá consumir menos de 500 Mb de memoria RAM.
❑ La aplicación no podrá ocupar más de 2 GB de espacio en disco.
❑ La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas latinos (Español,
Frances, Portugués, Italiano), Arábico y Chino.
❑ La interfaz de usuario será implementada para navegadores web únicamente con HTML5 y
JavaScript.

19
 1.2.2 No Funcionales

Ejemplos de requerimientos no funcionales organizacionales

❑ El procedimiento de desarrollo de software a usar debe estar definido explícitamente

(en manuales de procedimientos) y debe cumplir con los estándares ISO 9000.
❑ La metodología de desarrollo de software será Behaviour Driven Development (BDD)
apoyada en Cucumber.
❑ El sistema debe ser desarrollado utilizando las herramientas CASE XYZ.
❑ El proceso de desarrollo se gestionará por medio de una determinada herramienta
web para gestionar el proceso de desarrollo de software.
❑ Debe especificarse un plan de recuperación ante desastres para el sistema a ser
desarrollado.
❑ Cada dos semanas deberán producirse reportes gerenciales en los cuales se muestre
el esfuerzo invertido en cada uno de los componentes del nuevo sistema.
❑ Las pruebas de software se gestionaran con una herramienta de gestión de software
testing.
❑ Las pruebas de software se ejecutarán utilizando Selenium y Ruby como herramienta
y lenguaje Scripting para automatización de software testing.

20
 1.3 Proceso de la Ingeniería de los Requerimientos

Como pueden observar, todos los procesos involucrados con la Ingeniería de

Requerimientos están relacionados con identificar, modelar, comunicar y documentar los
requerimientos de un sistema o producto de software y los contextos en los cuales este
sistema o producto está envuelto. Los requerimientos deben describir lo que se debe
hacer y cómo se debe llevar acabo. Esto en la vida real es algo muy difícil de realizar.

Por esto existen muchas técnicas disponibles para la aplicación de la Ingeniería de

Requerimientos, con el fin de asegurar que los requerimientos obtenidos cuenten, al
final del proceso de Ingeniería de Requerimientos, con las características necesarias para
ser implementados. Por tanto, lo que se busca al aplicar un proceso de Ingeniería de
Requerimientos es el ayudar a la totalidad de los participantes del proyecto a conocer
que desean construir antes de empezarlo a construir.

Ésta práctica trae beneficios en dos aspectos:

❑ Minimiza los riesgos de fracaso del proyecto.

❑ Contribuye a cumplir aspectos de calidad, tiempo y presupuesto.

21
 1.3 Proceso de la Ingeniería de los Requerimientos

Por esto, el proceso de Ingeniería de Requerimientos describe de manera detallada y precisa cada
uno de los aspectos del ciclo de vida de un conjunto de requerimientos. Este proceso presenta dos
grandes ramas: El Desarrollo de requerimientos, y la Administración de requerimientos.

Ingeniería de
Requerimientos

Desarrollo Administración

Recolección Análisis Especificación Verificación

22
 1.3.1. Elicitación
Elicitar un requerimiento significa, indagar, investigar, comprender: una situación que
necesita solventarse, una necesidad que debe ser cubierta, una funcionalidad que ha de
ser creada. Con la salvedad de que todo lo que capturemos en la elicitación debe ser
traducido y documentado para que cualquier persona que se involucre en el proyecto lo
entienda y pueda aportar para llevar a cabo la actividad que le corresponda. Es decir;
analistas, diseñadores, programadores, arquitectos de software, tester, etc., al leer el
requerimiento empezaran a proyectar como solucionarlo.

La elicitación de requerimientos es una de las principales tareas que debe llevarse a cabo
para la correcta implementación de un desarrollo software. Su incorrecta especificación
genera costos innecesarios a lo largo del proyecto e inclusive, su completo fracaso.

La Elicitación de requerimientos es el proceso mediante el cual se descubren las

necesidades y propiedades de un sistema de información a partir de la comunicación
con los usuarios y todos los beneficiarios del sistema. No es una labor sencilla y
comprende distintas fases, técnicas y ciclos de evaluación. La persona que la realiza no
solo necesita una experticia en el área, sino también manejar adecuadamente
elementos sociales y técnicos que le permitan desarrollar esta labor de manera
adecuada.

23
 1.3.2. Interpretación

Los documentos de ingeniería de requerimientos son largos. La mayoría están compuestos de

cientos o miles de páginas; cada página contiene muchos detalles que pueden tener efectos
profundos en el resto del sistema.

Normalmente, las personas se encuentran con dificultades para comprender documentos de este
tamaño, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de
especificación de gran tamaño, pues difícilmente una persona puede memorizar los detalles del
documento. Esto causa problemas y errores que no son detectados hasta después de haberse
construido el sistema.

Actividades de la Ingeniería de Requerimientos

En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas

secuencialmente, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas
actividades son aplicadas de manera continua y en orden variado.

Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo
de desarrollo, las actividades de la IR varían tanto en número como en nombres.

24
 1.3.2. Interpretación
La tabla siguiente muestra algunos ejemplos de las actividades identificadas para cada proceso.
Tabla Actividades de la IR para diferentes modelos de procesos de Ingeniería de Software

MODELO Oliver and Steiner EIA / IS-632 IEEE Std 1220- 1994 CMM nivel Repetitivo RUP
1996 (2)

Evaluar la información Análisis de Análisis de Identificación de Análisis del

disponible requerimientos Requerimientos requerimientos Problema
Definir métricas Análisis funcional Estudio de los Identificación de Comprender las
efectivas requerimientos restricciones del necesidades de los
sistema a desarrollar involucrados

Crear un modelo del Síntesis Validación de Análisis de los Definir el sistema

comportamiento del requerimientos requerimientos
sistema
Crear un modelo de Análisis y control del Análisis funcional Representación de los Analizar el alcance
los objetos sistema requerimientos del proyecto
Ejecutar el análisis Evaluación y estudio Comunicación de los Modificar la
Actividades de funciones requerimientos definición del
sistema
Crear un plan Verificación de Validación de Administrar los
secuencial funciones requerimientos cambios de
de construcción y requerimientos
pruebas
Síntesis
Estudio
y evaluación del
diseño
Verificación física
Control

25
 1.3.2. Interpretación

A pesar de las diferentes interpretaciones que cada desarrollador

tenga sobre el conjunto de actividades mostradas en la tabla
anterior, podemos identificar y extraer cinco actividades
principales que son:

❑Análisis del Problema

❑Evaluación y Negociación
❑Especificación
❑Validación
❑Evolución

26
 1.3.3. Estructuración análisis y documentación

El análisis de requerimientos trata de capturar y describir detalladamente

los requerimientos de funcionalidad y de calidad de servicio del producto
que se desarrolla. La tarea la desarrollan entre los “expertos de dominio”
(usuarios, expertos de marketing, etc.) que saben lo que se quiere hacer
y los analistas que definen de forma no ambigua lo que se va a hacer.
Dentro de un proceso en espiral, no es una actividad única, sino una
tarea que se va desarrollando incrementalmente.

Los principales aspectos del análisis de requerimientos son:

❑ Identificar los paquetes de funcionalidad y detallarlos hasta hacerlos

no ambiguos.
❑ Establecer los límites de la aplicación, identificando los agentes
externos con los que interacciona.
❑ Identificar las características de las interacciones mediante la
elaboración de un catálogo de mensajes y de sus semánticas.

27
 1.3.3. Estructuración análisis y documentación

Para construir algo primero debe entenderse lo que debe ser ese algo. El
proceso de entender y documentar una aplicación software se llama “Análisis
de requerimientos”. En general los requerimientos expresan qué se supone
debe hacer una aplicación y no intentan expresar como logra estas funciones.

El análisis inicial de un sistema debe tratar de descubrir los requerimientos del

producto final que se desarrolla en detalle.

Unos de los principales objetivos de UML es hacer que este análisis sea lo
suficientemente intuitivo para que los clientes y expertos en el dominio que
solicitan el producto puedan comprenderlo, y lo suficientemente formal y
riguroso para que se establezca una formulación no ambigua que pueda ser
utilizada por los técnicos que la desarrollan.

28
 1.3.3. Estructuración análisis y documentación

Los aspectos básicos que deben tratarse en esta fase son:

❑ Determinar los paquetes de funcionalidad y de la calidad de servicio del producto,

formulados de una forma independiente de su implementación, y refinar y detallar
estas especificaciones hasta que den lugar a una especificación no ambigua del
producto que se desarrolla
❑ Identificar los actores externos al sistema que interactúan con la aplicación de forma
relevante
❑ Identificar la semántica y las características de los mensajes que intercambian los
actores con el sistema que se desarrolla
❑ Refinar los protocolos de interacción que usan los actores para llevar a cabo las
diferentes transacciones que se pueden realizar con el sistema. El análisis de
requerimientos es una necesidad, no un lujo. Para apoyarlo considérese su efecto
sobre las pruebas del producto concluido. Si alguien le proporciona una caja negra
con un cable rojo, rosa y morado que sale de ella, sería imposible probarlo. No se
sabe que hace, para que sirve

29
 1.3.3. Estructuración análisis y documentación

Proceso de análisis de requerimientos

1. Identificar al cliente.
2. Entrevistar al cliente.
❑ Identificar deseos y necesidades
❑ Utilizar las herramientas de expresión de requerimientos (las ofrecidas
por UML)
❑ Bosquejar las interfaces de usuario (protocolos y GUIs)
❑ Identificar las plataformas hardware que debe soportar el software
3. Elaborar un documento de los requerimientos de usuario (Debe validarse
con el cliente)
4. Inspeccionar los requerimientos de usuario
5. Elaborar los requerimientos detallados mediante documentos gráficos y
textuales

30
 1.3.3. Estructuración análisis y documentación

Recursos para la especificación del sistema.

Para la especificación del sistema se usan tres tipos de recursos:

❑ Descripción del proyecto: Documento textual que describe de forma concisa

el objetivo del sistema, su oportunidad de mercado y el análisis de riesgos.
❑ Análisis del contexto: Modelo de objetos que identifica las interacciones
externas y los mecanismos de interacción física entre los actores que
constituyen el entorno y el propio sistema.
❑ Casos de uso: Recursos UML para describir la funcionalidad del sistema.
Identifican los límites del sistema a través de la captura de los tipos de
usuario, de los elementos básicos de funcionalidad a través de casos de uso,
y de los protocolos de interacción a través de diagramas de secuencia o de
interacción.

31
 1.3.3. Estructuración análisis y documentación

Descripción del proyecto

Un proyecto que se inicia siempre debe partir de un documento breve que lo

describa y plantee sus principales características.
Sirve de contrato para que todos los que participan en su promoción tengan el
mismo concepto sobre su contenido y objetivos.

El documento debe ser breve (2 o 3 páginas) y debe ser realizado por una o dos
personas y aceptado por todos los promotores.
❑ Usuarios del producto
❑ Los que encargan y financian el producto
❑ Responsable de la empresa
❑ Administradores
❑ Programadores
El documento debe contener:
❑ La naturaleza y objetivos del producto.
❑ Las características más relevantes.
❑ La oportunidad de mercado del producto.
❑ Análisis de riesgos para el desarrollo del proyecto.

32
 1.3.3. Estructuración análisis y documentación

Análisis del contexto

El contexto o dominio del sistema es la descripción del entorno donde opera el sistema y
las interacciones que se producen con él.

En el diagrama de contexto el sistema aparece como un único objeto con características

de caja negra.

En UML el diagrama de contexto es un diagrama de objetos en el que se introducen los

estereotipos necesarios para introducir la semántica de los agentes que intervienen. Los
objetivos del diagrama de contexto son:

❑ Identificar el entorno en que opera el sistema

❑ Identificar los elementos del sistema con los que interacciona físicamente el operador
y los elementos externos con los que opera el sistema (GUIs)
❑ Capturar los mensajes que intercambia el sistema y sus protocolos

33
 1.3.3. Estructuración análisis y documentación

Diagramas de Casos de Uso

Los diagramas de caso de uso constituyen un método alternativo y complementario a los diagramas
de contexto para formular los requerimientos del sistema. Un caso de uso describe una interacción
entre el sistema y un agente externo que se denomina actor:

❑ Un caso de uso capta siempre una función visible para el usuario

❑ Un caso de uso logra un objetivo concreto y específico para el usuario
❑ Un caso de uso puede ser algo simple o algo complejo, en este caso se puede formular en
función de otros casos de uso

Los diagramas de casos de uso son recursos UML destinados a:

❑ Delimitar que partes pertenecen al sistema y cuales son externas a él

❑ Captura los elementos de funcionalidad del sistema
❑ Identifica y clasifica los elementos externos que interaccionan con él
❑ Formula los protocolos de interacción entre actores y sistema

Los diagramas de casos de uso hacen referencia a la funcionalidad del sistema y no hacen referencia
a la implementación. Los casos de uso constituyen una representación de la funcionalidad que se
utiliza como guía de las restantes fases (análisis, diseño, codificación, prueba y despliegue)

34
1.3.3. Estructuración análisis y documentación

Documentación

El propósito de la documentación de requerimientos es

el comunicar los requerimientos a los diferentes
participantes del desarrollo de software.

El documento de requerimientos de software es una

herramienta que puede servir como base para la
evaluación de los requerimientos en el producto, y para
la evaluación misma del proceso que se llevó a cabo
(evaluar las actividades de diseño, implementación, las
pruebas realizadas y la verificación y validación de estas
actividades).

De igual manera este documento es producto que debe

ser controlado y administrado, ya que contiene los
requerimientos que finalmente se van a llevar a cabo.

35
1.3.4. Negociación

En el caso de que se detecten conflictos que

requieran soluciones no triviales, es necesaria la
Negociación de requerimientos.

Proceso de negociación de requerimientos

El proceso habitual suele ser:

1. Registrar el conflicto (normalmente con una

herramienta).
2. Identificar los requerimientos afectados.
3. Analizar el impacto del conflicto (analizando la
trazabilidad de los requerimientos).
4. Identificar las fuentes (participantes) relevantes.
5. Convocar y realizar la reunión de negociación.
6. Asimilar la solución del conflicto.

36
 1.3.5. Verificación y Validación

La validación de requerimientos es importante pues de ella depende que no

existan elevados costos de mantenimiento para el software desarrollado.

Permite demostrar que los requerimientos definidos en el sistema son los que
realmente quiere el cliente, además revisa que no se haya omitido ninguno, que
no sean ambiguos, inconsistentes o redundantes.

La validación es la etapa final de la IR. Su objetivo es, ratificar los

requerimientos, es decir, verificar todos los requerimientos que aparecen en el
documento especificado para asegurarse que representan una descripción, por
lo menos, aceptable del sistema que se debe implementar. Esto implica verificar
que los requerimientos sean consistentes y que estén completos.

37
 1.3.5. Verificación y Validación

Verificación y Validación (V&V):

Los dos procesos en conjunto van asegurar que el software que se desarrolla
está acorde a su especificación y cumple con las necesidades de los clientes.

Existen actividades de V&V en cada etapa del proceso de desarrollo del

software.

Verificación: ¿Estamos construyendo el producto correctamente? .

Se comprueba que el software cumple los requerimientos funcionales y no
funcionales de su especificación.

Validación: ¿Estamos construyendo el producto correcto? .

Comprueba que el software cumple las expectativas que el cliente espera.
Importante: Nunca se va a poder demostrar que el software está
completamente libre de defectos

38
 1.3.5. Verificación y Validación

Técnicas de Verificación y Validación

Inspecciones del Software:

❑ Se analizan las diferentes representaciones del sistema (diagramas de

requerimientos, diagramas de diseño y código fuente) en búsqueda de defectos.
❑ Son técnicas de validación estáticas => No requieren que el código se ejecute.
❑ Debe realizarse durante todo el ciclo de desarrollo.

Pruebas del Software:

❑ Se contrasta dinámicamente la respuesta de prototipos ejecutables del sistema

con el comportamiento operacional esperado.
❑ Técnicas de validación dinámicas => El sistema se ejecuta.
❑ Requiere disponer de prototipo ejecutables, por lo que sólo pueden utilizarse en
ciertas fases del proceso.

39
 1.4. La Ingeniería de Requerimientos como parte del contexto de la
ingeniería

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado
ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de
requerimientos de software correcta y completa.

Algunos otros conceptos de ingeniería de requerimientos son:

“Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución
trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el
negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software”. (Pressman,
2006: 155)

“La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones
pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema”. (Sommerville,
2005: 82)

En síntesis, el proceso de ingeniería de requerimientos se utiliza para definir todas las actividades involucradas en
el descubrimiento, documentación y mantenimiento de los requerimientos para un producto de software
determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendrá a ayudar a determinar la
viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un
subproceso de obtención y análisis de requerimientos, su especificación formal, para finalizar con el subproceso
de validación donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

40
1.5. Los diferentes niveles de Requerimientos

Los niveles de descripción de un requerimiento

permiten hacer una clara separación entre los diferentes
tipos de requerimientos que se pueden concebir en un
documento de requerimientos.
Son necesarios para evitar errores y mejorar la
descripción de los mismos. El clasificar los
requerimientos en estos niveles facilita su
entendimiento y su descripción.

Los diferentes niveles de descripción son útiles porque

comunican la información a diferentes tipos de lectores.

Se dividen en tres niveles:

❑ Nivel Organizacional
❑ Nivel Producto
❑ Nivel Proyecto

41
1.5.1. Nivel Organizacional
Son una consecuencia de las políticas y procedimientos
existentes en la organización: procesos estándar
utilizados, de fechas de entrega, documentación a
entregar.

Estos requerimientos son la necesidad principal por la

cual se empieza la construcción o mejora del producto.
Estos requerimientos se caracterizan por ser descritos de
manera muy generalizada en términos de beneficios o
necesidades de la organización; y se expresan en un
lenguaje natural.

En ocasiones son llamados los objetivos del software.

Ejemplo:

El sistema se debe desarrollar de acuerdo con el proceso

estándar XYZCo-SP-STAN-95.

42
1.5.2. Nivel Producto
Especifican el comportamiento del producto obtenido: velocidad
de ejecución, memoria requerida, porcentaje de fallos
aceptables.

Los requerimientos del sistema hacen referencia a la

funcionalidad que debe ser construida para permitir al producto
realizar sus tareas, en términos de las necesidades del sistema.
Los requerimientos del sistema se enfocan en las funciones del
sistema, los servicios y las restricciones de operabilidad en
detalle.

El documento que contenga los requerimientos del sistema debe

ser sumamente preciso y definir de manera exacta lo que va a
ser implementado. Debe ser parte del contrato entre el
comprador o cliente del sistema y desarrollador del mismo.

Ejemplo:

Se utilizará en todas las comunicaciones el conjunto de

caracteres ADA estándar.

43
 1.5.2. Nivel Producto
En esta figura se puede apreciar mejor la relación entre los diferentes artefactos, tipos de
requerimientos y atributos de los mismos en un proyecto de software, desarrollado con Análisis y
diseño orientado a objetos. En este caso se utilizan tecnologías particulares como los casos de uso.

Requerimientos
del Negocio

Documento de Visión y Alcance

Requerimientos Atributos de
de Usuarios Calidad

Requerimientos
No Funcionales
Documento de Casos de Uso

Restricciones

Requerimientos Requerimientos
del Sistema Funcionales SRS
(Especificación de
Requerimientos de
Software)

44
 1.5.3. Nivel Proyecto

Representan los objetivos de alto nivel que la organización o cliente requiere.

Estos requerimientos provienen en general de los dueños, administradores,
gerentes o patrocinadores del proyecto.

Incluyen los objetivos del negocio, la visión del producto y el alcance del
proyecto. Los requerimientos que se presentan en este nivel, son los más
importantes a cumplir. También debe tomarse en cuenta que cubren aspectos
muy generales acerca del funcionamiento real del producto requerido.

45
 1.6. Administración de los Requerimientos

La necesidad de recrear un proceso iterativo sobre el desarrollo de

requerimientos nos conduce a la necesidad de ejercer control y establecer una
línea base para la administración de los requerimientos; esto con el fin de
mantener la consistencia de lo que se especifica respecto a lo que se desarrolla.

Estas son las tareas de la administración de requerimientos.

46
 1.6. Administración de los Requerimientos

Actividades del Ciclo de Vida de los Requerimientos

47
 1.6. Administración de los Requerimientos

Proceso de Administración de Requerimientos

La administración de requerimientos es un proceso que tiene por objetivo comprender y controlar

los requerimientos. Como todo proceso de administración, inicia con la planeación a la par de la
identificación inicial de requerimientos. Este proceso tiene diferentes formas que dependen del
proceso de desarrollo de software que se esté empleando, independientemente de esto se deben
considerar las siguientes etapas:

Etapas:

❑ Requerimientos duraderos y volátiles.

❑ Planeación de la administración de requerimientos.
❑ Administración del cambio de los requerimientos.

Durante esta etapa, para cada proyecto, es necesario establecer el nivel de detalle. Se tiene que
decidir sobre:

❑ La identificación de los requerimientos.

❑ Un proceso de administración del cambio.
❑ Políticas de rastreo.
❑ Ayuda de herramientas CASE.

48
 1.6. Administración de los Requerimientos

La administración de requerimientos necesita de ayuda automática para:

❑ Almacenar requerimientos.
❑ Administrar los cambios.
❑ Administrar el rastreo.

Una de las principales causas para el fracaso de un proyecto de software es la mala (o

ausencia de) administración de requerimientos. Los principales problemas que se derivan de
un mal manejo de requerimientos son:

❑ Incapacidad para manejar los cambios en los requerimientos durante el desarrollo.

❑ Falta de especificación detallada de los requerimientos.
❑ Mala organización y control de requerimientos.
❑ Requerimientos mal entendidos.

La administración de requerimientos comprende las actividades relacionadas con la

definición, clasificación, asignación, seguimiento y control de los requerimientos durante todo
el ciclo de vida de desarrollo de software. Es indispensable para asegurar la calidad de los
productos, así como para llevar control y seguimiento de los proyectos. Es un proceso que se
desarrolla a lo largo de toda la vida del proyecto.

49
1.6. Administración de los Requerimientos

Administración de cambios.

Los requerimientos cambian durante todo el ciclo de

vida de desarrollo del producto como se vio en
apartados anteriores. Los cambios deben controlarse
y documentarse, es decir, hay que convivir con ellos
y por ello la gestión de cambios es esencial para
tratar dichos cambios.

Cuando, durante el proyecto y una vez aceptada la

línea base de requerimientos, se solicita un cambio
sobre esta línea base, estos cambios no se pueden
aceptar sin más ya que podrían afectar al desarrollo
de todo el sistema, o alguna parte esencial del
mismo.

El siguiente gráfico muestra el proceso de gestión de

cambios con las actividades a llevar a cabo durante
el desarrollo del mismo:

50
 1.6. Administración de los Requerimientos

En definitiva, podríamos destacar tres importantes actividades dentro del proceso de gestión de
cambios:

Evaluar el impacto

La primera tarea a realizar tras recibir una petición de cambio es valorar el impacto del mismo. Para
ello se deberá ir recorriendo todo el árbol de requerimientos viendo como les afecta el cambio, y aquí
es donde entra la trazabilidad de los requerimientos.

Aceptación del cambio

Una vez analizado el impacto del cambio, se debe tomar una decisión. Si se acepta el cambio, tras
negociarlo con el cliente, se continuará con la actividad de implementar el cambio. En caso contrario,
se deberá negociar con el cliente el siguiente paso a realizar.

Implementación del cambio

Si se ha aceptado el cambio, hay que reflejar ese cambio en todos los productos que resulten afectados
por dicho cambio (si el cambio es mínimo algunos productos como el plan del proyecto, puede que no
sea necesario modificar). Además se deberá generar un nuevo punto de partida (línea base) de
requerimientos.

51
 1.6. Administración de los Requerimientos

Trazabilidad

Un concepto clave en el proceso de gestión de cambios es la Trazabilidad. Los

requerimientos deben ser trazables, es decir, “rastreables”. Se podría decir que
un requerimiento es trazable si se pueden identificar todas las partes del
producto existente relacionadas con ese requerimiento. Todos los
requerimientos deberían ser trazables para mantener consistencia entre los
distintos documentos de un proyecto.

Es importante conocer aspectos de los requerimientos tales como:

❑ Su origen (Quién los propuso)

❑ Necesidad (Por qué existe)
❑ Relación con otros requerimientos (Dependencias)
❑ Relación con otros elementos (Dependencias)

52
 1.6. Administración de los Requerimientos

El uso de matrices de trazabilidad es una buena técnica para llevar a cabo esta actividad de forma eficiente. A
continuación se propone una posible matriz de trazabilidad:

En la matriz se irán registrando los requerimientos de negocio. Por cada requerimiento de negocio se identificarán
los requerimientos de usuario correspondientes. De cada requerimiento de usuario se identificarán cuáles son los
requerimientos de sistema asociados a cada uno de ellos…. Y así sucesivamente se irá rellenando toda la matriz de
requerimientos

53
 1.6. Administración de los Requerimientos

La siguiente matriz se utiliza para relacionar requerimientos. Es una matriz de dependencias:

En este caso los requerimientos (A) representan los requerimientos que originan las dependencias y los
requerimientos (B) serían los requerimientos que dependen de otros requerimientos, de los requerimientos (A).
Vamos a poner un ejemplo para verlo más claro.

Por ejemplo, se puede ver como los requerimientos 1,3 y 7 dependen del requerimiento 5, o que el requerimiento
3, además de depender del requerimiento 5 también depende del requerimiento 6. De esta forma se puede ver de
qué manera se relacionan los requerimientos, para analizar mejor el impacto de los cambios.

54
 1.6. Administración de los Requerimientos

Beneficios de una correcta Administración de Requerimientos

Una correcta administración se lleva a cabo mediante la especificación de Requerimientos de Software (ERS), lo cual
trae beneficios durante las siguientes fases del ciclo de vida de sistema. La ERS documenta el conjunto completo de
capacidades del sistema y provee de los siguientes beneficios:

❑ Asegura al cliente que el desarrollador entiende sus necesidades y que está respondiendo a ellas.
❑ Una oportunidad para una retroalimentación entre el cliente y el proveedor.
❑ Un método para que el cliente y proveedor o desarrollador puedan identificar tempranamente problemas y
malentendidos mientras los costos de corregirlos son relativamente bajos.
❑ Una base para la calificación y calidad del sistema para establecer que este cumple con las necesidades del
cliente.
❑ Protección para el proveedor, dando una línea base para las capacidades del sistema y una base que determine
cuando la construcción del sistema está completa.
❑ Soporte para el desarrollador en la planificación, diseño y desarrollo del programa.
❑ Ayuda en la evaluación de los efectos de los cambios en los requerimientos.
❑ Incrementa la protección en contra de malentendidos entre el cliente y el proveedor mientras se desarrolle el
software.

(Para mayor información consultar 1.5 Procesos para la administración de requerimientos, página 37)
Consultada 19 de febrero 2019 |
http://fcasua.contad.unam.mx/apuntes/interiores/docs/2012/informatica/2/1216.pdf

55
 Referencias Bibliográficas
▪ Sommerville, I. (2016). Software Engineering. (10 ed.). Pearson Addison Wesley.

▪ Pressman, R. (2010). Ingeniería del Software: Un enfoque práctico.(7 ed.). McGRAW-HILL.

▪ Pantaleo, G. y Lis Rinaudo, L. (2014). Ingeniería de software. Alfaomega.

▪ Sánchez Alonso, S. y Sicilia Urban, M.A. y Rodríguez García, D. (2012). Ingeniería de software.
Un enfoque desde la guía SWEBOK. Alfaomega.

▪ León, G. (1 de marzo de 2011). Ingeniería de Sistemas de Software. Slideshare.

https://es.slideshare.net/8800702/ingenieria-de-sistemas-de-software

▪ Gómez, M. (s.f.). Análisis de Requerimientos. UAM Cuajimalpa.

http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf

▪ UPAEP ONLINE. (5 de octubre de 2014). EL PROCESO DE ADMINISTRACIÓN

DE REQUERIMIENTOS. https://laingenieriaderequerimientos.wordpress.com/el-proceso-de-
administracion-de-requerimientos

▪ PMOinformatica.com. (13 de abril de 2015). Requerimientos no funcionales: Una clasificación.

http://www.pmoinformatica.com/2015/04/requerimientos-no-funcionales-una.html

56