INGENIERIA DE REQUERIMIENTOS

SIS-125

Ing. Gustavo Poquechoque

INTRODUCCIÓN

A la hora de plantear un proyecto es fundamental que todos los que lo lleven

adelante, conozcan de forma precisa el problema que van a resolver o la
necesidad que se va satisfacer, de tal manera que la solución o el producto
que se construya sea correcta y útil. Por tal motivo la correcta obtención de los
requerimientos del sistema es uno de los aspectos clave en la construcción
de proyectos de cualquier índole (Tecnológicos, Comunicación, Software,
Diseño, Sistemas,..)

Sea en proyectos grandes o pequeños con complejidades diferentes la mala

captura de los mismos es la causa de los problemas que surgen a lo largo del
proceso de construcción.

La ingeniería de requisitos permite la definición de los servicios,

características y propiedades que se debe tener.
REQUERIMIENTOS – ¿Realmente que es un requerimiento?

Proyectos Tecnológicos,
Comunicación, Software, Diseño,
Negocio
Sistemas

Interesados Acuerdo

Necesidades ?

Exigencias ?

Equipo de Desarrollo
REQUERIMIENTOS

• Según Benet (2003:110) “Los requisitos son la especificación de lo que debe hacer
el software, son descripciones del comportamiento, propiedades y restricciones
del software que hay que desarrollar”.

• Los requisitos son descripciones de las propiedades necesarias y suficientes de un

producto para que satisfaga las necesidades del consumidor. (Gottesdiener E. ,
2005).

• “Un requisito del software es una característica que debe exhibir para solucionar
cierto problema del mundo real. Por lo tanto, un requisito del software es una
característica que se debe exhibir por el software desarrollado o adaptado para
solucionar un problema particular.” (SWEBOK, 2004:2-1).
REQUERIMIENTOS

El no definir los requisitos correctamente tiene un precio

bastante alto; estos errores pueden causar requisitos
incompletos, incorrectos o requisitos contradictorios, entre los
que se pueden mencionar a:

• Sobrecosto,
• Reproceso costoso,
• Mala calidad,
• Retraso en la entrega,
• Clientes descontentos,
• Miembros de equipo agotados y desmoralizados.
 REQUERIMIENTOS

IMPORTANCIA

La importancia de tener requisitos de calidad radica en:

• Involucran del 10 al 15% del coste total del proyecto.

• Un error en los requisitos puede ser de 10 hasta 100 veces

más costoso que un error en el código.

• Una equivocación en la etapa de requisitos se arrastra en

las demás fases.
 REQUERIMIENTOS

CARACTERISTICAS

• Ser una combinación compleja de los requisitos

(necesidades) de diferentes personas (stakeholders) que
pertenecen a diferentes niveles de una organización y
entorno en donde se operará el software.

• Deben ser verificables.

• Deben ser lo más claros que se pueda y cuantificables en

medida de lo posible.
REQUERIMIENTOS

CARACTERISTICAS
 REQUERIMIENTOS

SU IMPORTANCIA EN LA INGENIERÍA DE SOFTWARE

• “La correcta obtención de los requisitos es uno de los

aspectos más críticos de un proyecto software,
independientemente del tipo de proyecto que se trate, dado
que una mala captura de los mismos es la causa de la mayor
parte de los problemas que surgen a lo largo del ciclo de vida”.
Johnson 1995: 2(1):41-47.
REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

Dificultad en los requisitos

REQUERIMIENTOS

DIFICULTAD EN LOS REQUISITOS

Resumiendo, las principales dificultades que se presentan en el proceso de

recolección de requisitos:

• No reflejan las necesidades reales de los clientes

• Son inconsistentes y/o incompletos.
• Realizar cambios sobre los requisitos ya definidos es muy costoso.
• Pueden existir malentendidos entre los stakeholders, y los ingenieros.
• Imprecisión de los requisitos, lo cual provoca que sean interpretados de
diferentes formas por los stakeholders.
• Frecuentemente no está clara la frontera entre requisitos y diseño.
REQUERIMIENTOS
DIFICULTAD EN LOS REQUISITOS

Dificultad y consecuencias
REQUERIMIENTOS
INGENIERIA DE REQUISITOS

Para poder solucionar estos problemas surge la ingeniería de

requisitos; a la cual Somerville, 2005:108; la define como

“El proceso de establecer los servicios que el cliente requiere

de un sistema y los límites bajo los cuales opera y se
desarrolla”.

La ingeniería de requisitos es la primera fase del ciclo de vida

del software en la que se producen especificaciones a partir de
ideas informales por parte de los stakeholders.
VERIFICACIÓN Y VALIDACIÓN DE REQUERIMIENTOS

La realización de pruebas conceptuales ayudará a descubrir la

existencia de requisitos defectuosos, sin claridad o incompletos,

Por lo cual es aconsejable que de acuerdo a como se vayan

desarrollando los requisitos estos sean verificados para
comprobar si cumplen las condiciones o especificaciones de la
actividad de desarrollo los requisitos.
VERIFICACIÓN Y VALIDACIÓN DE REQUERIMIENTOS

Proceso de verificar y validar requerimientos

 VERIFICACIÓN Y VALIDACIÓN DE REQUERIMIENTOS

• Cuando se identifican los requisitos y se tiene la aceptación del

usuario se asegura que se satisfacen las necesidades del
usuario.

• La verificación de requisitos representa el punto de vista del

equipo de desarrollo asegurando que lo que el producto
satisface son los requisitos especificados.

• Mientras que la validación de requerimientos está preocupada

por el punto de vista del cliente asegurando que las
necesidades del cliente se cumplan.
TIPOS DE REQUISITOS
FUNCIONALES NO FUNCIONALES
• Requisitos de producto
¿Por qué se está realizando el Proyecto?

Objetivos del
negocio Documento de visión
y alcance

Procesos del
negocio Arquitectura
• Requisitos de organización

Lo que los usuarios podrían hacer con el producto

Actividades Documento de
requerimientos de
de los usuario criterios de
usuarios calidad
• Requisitos externos
Lo que los desarrolladores necesitan construir

Fragmentos Especificación de
de requisitos de software
funcionalidad
TIPOS DE REQUISITOS

Los requisitos se clasifican en:

• Funcionales
• No funcionales
TIPOS DE REQUISITOS

a) Requisitos Funcionales:

“Describen las funciones que el software debe ejecutar, a veces se conocen

como capacidades”. SEWBOK, 2004: 2-2.

A los requisitos funcionales se los puede dividir en:

• De usuario: Los requerimientos de usuario, según Sommerville, 2005: 116; “Son

declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera
que el sistema provea y de las restricciones bajos las cuales se debe operar.

• Del sistema: “Establecen con detalle los servicios y restricciones del sistema. El
documento de requerimientos del sistema, algunas veces denominado
especificación funcional, debe ser preciso”. Sommerville, 2005: 118
TIPOS DE REQUISITOS

a) Requisitos Funcionales:

Enunciado: Permitir al usuario registrar los datos de los estudiantes nuevos que se
inscriban al curso.

Análisis del problema:

Requisito de usuario expresado en términos generales. ¿Qué servicio debe prestar
el sistema?

Enunciado: El sistema debe permitir a los usuarios buscar el producto por nombre,
número de factura, código de barras.

Análisis del problema:

Requisito del sistema: Que define específicamente una parte de funcionalidad
del sistema.
TIPOS DE REQUISITOS

a) Requisitos Funcionales:

Enunciado: Permitir al usuario controlar la asistencia de los empleados.

Análisis del problema:

Requisito de usuario expresado en términos generales. ¿Qué servicio debe prestar
el sistema?

Enunciado 1: El sistema debe permitir registrar la huella digital el ingreso y la salida

de los empleados en el lapso de 10 minutos antes o después de la hora establecida.

Enunciado 2: El sistema debe permitir configurar los horarios de trabajo de los

distintos turnos

Análisis del problema:

Requisito del sistema: Que define específicamente una parte de funcionalidad
del sistema.
TIPOS DE REQUISITOS

a) Requisitos Funcionales Ejemplos (De proceso o 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.
• El sistema permitirá el envío automatizado de cartas de entrega de órdenes directamente al
almacén.
• A cada orden se le asignará un identificador único, que será utilizado para identificarla en
todos los procesos subsecuentes que se realicen sobre esta.
• Al ingresar ordenes de entrega, toda orden de entrega estará asociada a un pedido de venta.
• La facturación de pedidos de venta se realizara en lotes, por medio de una pantalla de
pedidos pendientes de facturación, la cual mostrará los pedidos no facturados. Una vez
facturados los pedidos no se mostrarán en esta lista.
TIPOS DE REQUISITOS

a) Requisitos Funcionales Ejemplos (De proceso o de negocio):

• El sistema también permitirá el registro de facturas manuales no asociadas a pedidos, sin

embargo, estas requerirán autorización por parte del grupo de Gerentes antes de ser
contabilizadas.
• El proceso de compras en el sistema abarcará los siguientes pasos y transacciones: Ingreso de
la requisición, emisión de la solicitud de cotización y emisión de la orden de compra.
• Los elementos de la solicitud de cotización serán los mismos de la requisición asociada, al
igual que los de la orden de compra. El sistema permitirá la emisión de solicitudes de
cotización y órdenes de compra parciales.
• La contabilización de transacciones de facturas de venta y facturas de compra podrá
configurarse para realizarse de forma automatizada a su registro, o manualmente en lotes
(Proceso Batch).
• El software debe poder emitir los siguientes estados financieros: Balance general, Estado de
ganancias y pérdidas, Estado de flujos de efectivo. Además, debe poder emitir un listado de
mayor general y mayor analítico.
• Los pedidos de compra que excedan los montos establecidos en el flujo de liberaciones de
pedidos configurados, deberán pasar por las aprobaciones establecidas en dicho flujo de
aprobación.
 TIPOS DE REQUISITOS

a) Requisitos Funcionales Ejemplos (De interfaz grafica):

• 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.
• El campo país consistirá en una lista de preselección. El país asociado a una dirección debe ser
previamente registrado en el sistema.
• El campo estado, provincia o departamento consistirá en una lista de preselección. A los
usuarios se les presentará únicamente los estados asociados al país seleccionado
previamente. El departamento o provincia a seleccionar deberá ser registrado en la
funcionalidad correspondiente.
• El campo material de elemento de la pantalla de requisiciones de compra será una lista de
preselección, que mostrará únicamente los materiales registrados en el maestro de
materiales.
• El campo fecha contable acepta únicamente fechas que correspondan con periodos contables
que estén abiertos en el sistema.
• La pantalla de registro de pago puede imprimir los datos en pantalla a la impresora.
• Se mostrará el nombre, tamaño total, espacio disponible y formato de un pen drive o flash
drive conectado al puerto USB del computador.
 TIPOS DE REQUISITOS

a) Requisitos Funcionales Ejemplos (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.
TIPOS DE REQUISITOS

b) Requisitos no funcionales

• Estos requisitos incluyen áreas tales como el rendimiento, el diseño y

las limitaciones de la aplicación; en SWEBOOK, 2004: 2-2 se los define
como “Son los que actúan para limitar la solución, se los conoce como
restricciones o requisitos de calidad”.

• Además los requisitos no funcionales pueden estar relacionados con

propiedades emergentes del sistema, describen restricciones externas
del sistema; definen las cualidades globales que el sistema ha de
exhibir y son más críticos que los requisitos funcionales.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales

Los requisitos no funcionales son propiedades que el producto debe tener lo que
no puede ser evidente al usuario, incluyendo atributos de calidad, coacciones, e
interfaces externas. (Gottesdiener E. , 2005) Sommerville, 2005:111; clasifica a
los requisitos no funcionales en: “requisitos de producto, de organización y
externos”.

• Requisitos de producto: Estos especifican el comportamiento del producto.

• Requisitos de organización: Se derivan de las políticas y procedimientos

existentes en la organización del cliente y en la del desarrollador.

• Requisitos externos: Son los requisitos que derivan de los factores externos al
sistema y de su proceso de desarrollo, incluyen requerimientos de
interoperabilidad que definen la manera en que el sistema interactúa con los
otros sistemas de la organización.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (ANALISIS)

• El máximo espacio de almacenamiento ocupado por el sistema debe ser de 20

MB porque el sistema debe alojarse completamente en una memoria de solo
lectura e instalarse en el dispositivo móvil.

Análisis del problema:

Requisito de producto que define una restricción en el tamaño del producto.

• El proceso software y los documentos a realizar deben conformar el proceso y

los estándares de documentación recogidos en la norma IEEE-830”.

Análisis del problema:

Requisito de organización que especifica que el sistema debe desarrollarse
de acuerdo a un proceso estándar dentro de la empresa.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (ANALISIS)

• Enunciado: El sistema no debe revelar ninguna información personal sobre los

clientes excepto su nombre y su número de referencia”

Análisis del problema:

• Requisito externo se deriva de la necesidad del sistema de cumplir la
legislación vigente sobre protección de datos.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (Ejemplos)

• El sistema debe visualizarse y funcionar correctamente en cualquier navegador,
especialmente en Internet Explorer, Firebird, Mozilla y Nautilus.
• El sistema debe cumplir las disposiciones recogidas en la Ley Orgánica de Datos
Personales y en el Reglamento de medidas de seguridad
• El sistema no debe tardar más de cinco segundos en mostrar los resultados de
una búsqueda. Si se supera este plazo, el sistema detiene la búsqueda y muestra
los resultados encontrados
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.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (Ejemplos)

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.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (Ejemplos)

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.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (Ejemplos)

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).

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.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (Ejemplos)

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.
TIPOS DE REQUISITOS

b) Requisitos no funcionales (Ejemplos)

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.
 TIPOS DE REQUISITOS

b) Requisitos no funcionales (Ejemplos)

Ejemplos de requerimientos no funcionales externos

• Sistemas de datos médicos: El nuevo sistema y sus procedimientos de

mantenimiento de datos deben cumplir con las leyes y reglamentos de protección
de datos médicos.
• El nuevo sistema se acogerá a las reglas de las licencias generales públicas (GNU), es
decir será gratuito, código abierto en el que cualquiera podrá cambiar el software,
sin patentes y sin garantías.
• Las páginas web a ser desarrolladas deben cumplir con la ley de tratamiento en
condiciones de igualdad para personas con discapacidad.
• El sistema no revelara a sus operadores otros datos personales de los clientes
distintos a nombres y números de referencia.
 TIPOS DE REQUISITOS

b) Consideraciones importantes Requisitos no FUNCIONALES Y NO

FUNCIONALES
Los requerimientos no funcionales suelen expresarse de una manera general y sin hacer referencia
a algún modulo, transacción o característica del sistema, pues sino pasarían a ser requerimientos
funcionales y es recomendable acompañar las definiciones de requerimientos no funcionales con
criterios de aceptación que puedan medirse.

Por ejemplo: “El sistema debe asegurar que los datos estén protegidos del acceso no autorizado”

Los requerimientos no funcionales pueden a su vez derivar en requerimientos funcionales,

tomando como ejemplo el anterior:

“El sistema incluirá un procedimiento de autorización de usuarios, en el cual los usuarios deben
identificarse usando un nombre de usuario y contraseña. Sólo los usuarios autorizados de esta
forma podrán acceder a los datos del sistema.”

Escrito de esta forma, el requerimiento pasa a ser funcional. Sin embargo, no todos los
requerimientos no funcionales pueden derivarse en requerimientos funcionales, por lo cual es muy
importante definir los criterios de aceptación.
TIPOS DE REQUISITOS

Jerarquía de especialización de requisitos

¿DE DÓNDE PROVIENEN LOS REQUISITOS?

Los requisitos provienen de tres niveles:

¿DE DÓNDE PROVIENEN LOS REQUISITOS?

Los requisitos provienen de tres niveles:

Nº Nivel Descripción
Nivel

Los requerimientos del negocio son las

declaraciones de la empresa para justificar la
Requerimientos
1 ejecución del proyecto; incluye una visión del
del negocio: ¿Por
producto de software impulsado por los objetivos
qué se está
del negocio. Es decir describen el propósito y las
realizando el
necesidades a alto nivel que el producto debe
Proyecto?
satisfacer; además con la visión del producto se
determinan las capacidades que el producto debe
tener y también las limitaciones del mismo.
¿DE DÓNDE PROVIENEN LOS REQUISITOS?

Los requisitos provienen de tres niveles:

Nº
Nivel Descripción
Nivel

Los requerimientos de los usuarios son la definición de los

requisitos desde el punto de vista del usuario. Se
describen las tareas que los usuarios necesitan llevar a
cabo con el software y las características de calidad
necesarias del software.
Requerimientos del
Los documentos que contienen los requisitos del
2 usuario: Lo que los
usuario a menudo se llaman capacidades operativas,
usuarios podrían
características del producto, el concepto de las
hacer con el
operaciones, o casos de uso.
producto.
Los requisitos de los usuarios son el puente entre
los objetivos de negocio y los requisitos de
software/sistema detallados. Por esta razón, es importante
asegurar que los analistas que escriben los
requisitos tengan excelentes habilidades de comunicación,
así como conocimiento de modelos de requisitos de
usuario.
¿DE DÓNDE PROVIENEN LOS REQUISITOS?

Los requisitos provienen de tres niveles:

• Los requisitos de sistema son las descripciones

detalladas de todos los requisitos funcionales
y no funcionales que el producto debe cumplir para
satisfacer las necesidades del negocio y del usuario, sin
salirse de los límites del diseño e implementación.
Requerimientos de • Los requisitos de sistema establecen un acuerdo
3 sistema: Lo que los entre el personal técnico y los empresarios sobre las
desarrolladores características que el producto debe tener.
necesitan construir • Los documentos que contienen los requisitos de
software se los conoce como especificación de
requisitos de sistema, requisitos detallados,
especificación, especificación técnica o especificación
funcional.
• Por lo general, los autores de la especificación de
requerimientos de sistema son analistas, sin embargo,
los clientes también deben revisar y aprobar los
requisitos de sistema.
 FORMAS DE DOCUMENTAR LOS REQUERIMIENTOS

Existen varias formas de documentar los requisitos:

a) En forma Textual
FORMAS DE DOCUMENTAR LOS REQUERIMIENTOS

b) Diagrama de árbol
FORMAS DE DOCUMENTAR LOS REQUERIMIENTOS

c) Requisitos como modelos

 CARACTERÍSTICAS DESEABLES DE LOS REQUERIMIENTOS

Realizar una recolección y documentación de los requisitos de alta calidad es

fundamental para el desarrollo de productos de software con éxito; para asegurarse de
que están desarrollando los requisitos eficazmente, debe asegurarse de que todos sus
requerimientos tengas las siguientes características

a) Características de requisitos individuales

• Completo: Un requerimiento está completo si no necesita ampliar detalles en su
redacción, es decir, proporciona la información suficiente para su comprensión.

• Correcto: Cada requerimiento debe describir con exactitud la funcionalidad para ser
construida (K.,2003).

• Claro: Pueden ser entendidos de la misma manera por todas las partes interesadas
con un mínimo de explicación complementaria. (Gottesdiener E. , 2005).

• Factible: Debe ser posible poner en práctica cada requerimiento dentro de las
capacidades conocidas y las limitaciones del sistema en su entorno de operaciones
(K., 2003).
CARACTERÍSTICAS DESEABLES DE LOS REQUERIMIENTOS

a) Características de requisitos individuales

• Necesario: Un requerimiento es necesario, si cuando se prescinde del mismo

provoca una deficiencia en el sistema a construir; además cuando sus características
físicas o factor de calidad no pueden ser reemplazados por otras capacidades del
producto.

• Priorización: Dentro del conjunto de requerimientos, alguno de ellos debe ser más
importante que los otros; en este proceso deben intervenir los stakeholders.

• Sin ambigüedades: Un requerimiento no tiene ambigüedades cuando se lo puede

interpretar de una sola forma, y por lo tanto el lenguaje usado en su definición no
causa confusiones al lector.

• Verificable: Un requerimiento es verificable cuando puede ser cuantificado de

manera que se pueden utilizar los métodos de verificación de inspección, análisis,
demostración o pruebas.
CARACTERÍSTICAS DESEABLES DE LOS REQUERIMIENTOS

b) Características de especificaciones de requerimientos

No es suficiente tener excelentes declaraciones de los requisitos individuales; sino

que también deben cumplir condiciones dentro del conjunto de requerimientos:

Condiciones dentro del conjunto de requerimientos

• Completo: Ningún requerimiento o información necesaria deberían estar

ausentes, sin embargo los requisitos que faltan son difíciles de detectar porque no
están descritos.

• Consistente: Los requisitos de conformidad no deben entrar en conflicto con otros

requisitos del mismo tipo o con un mayor nivel de negocios, sistema o necesidades
de los usuarios (Wiegers, 2003).
CARACTERÍSTICAS DESEABLES DE LOS REQUERIMIENTOS

b) Características de especificaciones de requerimientos

Condiciones dentro del conjunto de requerimientos

• Modificable: Debe ser capaz de ser revisado cuando sea necesario y para
mantener un historial de los cambios realizados de acuerdo a cada necesidad
surgida; cada requisito debe aparecer solo una vez en la especificación.

•Trazable: El requisito de trazabilidad puede estar vinculado a su origen hacia

atrás y hacia adelante a los elementos de diseño y código fuente que aplicarla a
uno de los casos de prueba que verifique la aplicación como correcta.

Los requisitos trazables están escritos en una forma estructurada, de

granularidad fina en lugar de párrafos largos. Se debe evitar agrupar múltiples
requerimientos en una sola instrucción, los diferentes requisitos pueden rastrear
hasta el diseño y elementos de código.
CARACTERÍSTICAS DESEABLES DE LOS REQUERIMIENTOS

(Gottesdiener E. , 2005), recomienda las siguientes prácticas clave que promueven

desarrollar requisitos de calidad:

• Desarrollar una visión clara para el producto final.

• Desarrollar una comprensión bien definida, del alcance del proyecto.

• Involucrar a los stakeholders durante el proceso de requisitos.

• Representar y descubrir los requisitos usando múltiples modelos.

• Documentar los requisitos con claridad y coherencia.

CARACTERÍSTICAS DESEABLES DE LOS REQUERIMIENTOS

(Gottesdiener E. , 2005), recomienda las siguientes prácticas clave que promueven

desarrollar requisitos de calidad:

• Validar continuamente que los requisitos sean correctos con el enfoque del
proyecto.

• Verificar la calidad de los requisitos frecuentemente.

• Priorizar los requerimientos y eliminar los innecesarios.

• Establecer una línea base para los requerimientos, ya que pueden servir para
futuros proyectos.

• Rastrear los orígenes de los requisitos y la forma de vinculación con otros

requisitos y con los elementos del sistema.

• Anticipar y gestionar todos los cambios de los requisitos.

INGENIERÍA DE REQUERIMIENTOS

Existen algunas definiciones de ingeniería de requerimientos, entre ellas se

mencionan:

• “La ingeniería de requisitos es ampliamente utilizada para indicar el tratamiento

sistemático de los requisitos”. SWEBOOK, 2004: cap. 2.

• Pressman, 2010:83 “El espectro amplio de tareas y técnicas que llevan a

entender los requerimientos.”.

• Gottesdiener, 2009:16; “La Ingeniería de requisitos es una disciplina dentro de

los sistemas y de la ingeniería de software que abarca todas las actividades y
resultados asociados a definir un producto de las necesidades – es una de las
mejores maneras de desarrollar requisitos de excelencia. En definitiva podríamos
decir que la Ingeniería de Requisitos es el conjunto de actividades para descubrir,
documentar y mantener un conjunto de requisitos.
INGENIERÍA DE REQUERIMIENTOS

NOTA IMPORTANTE

• Recuerde que la ingeniería de requisitos no es solo un proceso técnico; debido a

que los requisitos del sistema están influenciados por las preferencias, prejuicios
de los usuarios, aspectos políticos y legales de la organización; es decir
proporciona un mecanismo apropiado para entender las necesidades del
cliente, evaluar la factibilidad de las mismas, ofrecer una solución acertada y
finalmente especificar esta solución sin ambigüedades.

• En el proceso de la ingeniería de requisitos el equipo de desarrollo se enfrenta al

problema de identificar correctamente los requisitos, pero para realizar este
proceso no existe una técnica estandarizada y estructurada que garantice la
calidad del resultado.
INGENIERÍA DE REQUERIMIENTOS

EL PROCESO DE LA INGENIERÍA DE REQUISITOS

La ingeniería de requisitos se compone del desarrollo y de la gestión de requisitos
Objetivos del
Modelado del negocio
negocio Actividades
Procesos del de los
negocio usuarios
Visionamiento Funcionalidad
detallada

Gestión de Requisitos
INGENIERÍA DE REQUERIMIENTOS

EL PROCESO DE LA INGENIERÍA DE REQUISITOS

La ingeniería de requisitos se compone del desarrollo y de la gestión de requisitos
Visionamiento
INGENIERÍA DE REQUERIMIENTOS

a) Elicitación de requisitos:

En esta fase el equipo de desarrollo junto con los interesados se

identifican, articulan y entienden los requisitos de la aplicación a desarrollar. El
descubrimiento de los requisitos implica entender el dominio de la aplicación, el
servicio que va a prestar la aplicación, los problemas que se requieren resolver y las
necesidades de los usuarios de la aplicación.

A esta fase también se la conoce como Descubrimiento de Requisitos; Según

Gottersdiener (2009:17), esta fase consiste en: “Identificar las partes interesadas, la
documentación y las fuentes externas de información sobre los requisitos, y solicitar
los requisitos de esas fuentes”.
INGENIERÍA DE REQUERIMIENTOS

a) Elicitación de requisitos:

Proceso de descubrimiento de requisitos

INGENIERÍA DE REQUERIMIENTOS

b) Análisis de Requisitos:

Es el proceso mediante el cual obtiene una compresión precisa de los requisitos, se

analizan las necesidades identificadas por parte de los stakeholders de tal forma que
se obtiene el Documento de definición de requisitos Validado.

Proceso de análisis de requisitos

 INGENIERÍA DE REQUERIMIENTOS

b) Análisis de Requisitos: El análisis de requisitos comprende las siguientes actividades:

• Analizar los requisitos funcionales (RF) recolectados.

• Agrupar los requisitos funcionales recolectados y clasificarlos.

• De la clasificación de los requisitos determinar: los que no son necesarios, son

incompatibles entre sí, no son completos, no son factibles y los que están repetidos.

• Aprobar la lista tentativa de requisitos funcionales definitivos por parte de los

usuarios expertos en el dominio de la aplicación.

• Estructurar el contenido de Documentos de Definición de Requisitos (DDR).

• Elaborar el documento de Definición de Requisitos DDR con el listado de los requisitos

funcionales; el cual debe estar aprobado por parte de los stackeholders.
En esta fase el cuidado se debe tomar para describir requisitos con exactitud,
suficientemente como para permitir que los requisitos sean validados, su
implementación sea verificada, y sus costes estimados. (IEEE Computer Society, 2004).
INGENIERÍA DE REQUERIMIENTOS

c)Especificación de requisitos: “Se refiere a la producción de un documento a su

equivalente electrónico que pueda estar sistemáticamente repasado, evaluado y
aprobado”. (IEEE Computer Society, 2004).

La Especificación de requisitos se refiere a: “Diferenciar y documentar los requisitos funcionales

y no funcionales, identificar los atributos de calidad, requisitos importantes y restricciones, y
verificar que los requisitos documentados sean completos y no sean ambiguos”. (Gottesdiener,
2009:17)
INGENIERÍA DE REQUERIMIENTOS

c)Especificación de requisitos

En esta fase se elaboran tres tipos de documentos:

• Documento de definición del sistema: Define los requisitos del sistema de alto nivel desde
las perspectiva del dominio, además se incluye información de fondo sobre los objetivos del
sistema, su ambiente, declaración de limitaciones y los requisitos no funcionales.
• Documento de requisitos del sistema: En este documento se manifiesta lo que requieren
los desarrolladores del sistema; además se incluyen los requerimientos del usuario para el
sistema como una especificación detallada de los requerimientos del sistema.
• Documento de requisitos de software: Contiene una descripción completa de las
necesidades y funcionalidades del sistema que se va a desarrollar además determina el alcance
del sistema y la forma en la que realizará las funciones, definiendo los requerimientos
funcionales y los no funcionales.
INGENIERÍA DE REQUERIMIENTOS

c)Especificación de requisitos

En esta fase se elaboran tres tipos de documentos:

Documentos de la fase de especificación de requisitos

INGENIERÍA DE REQUERIMIENTOS

d) Validación de requisitos:
Los requisitos deben ser validados para asegurarse que el equipo de desarrollo de software
haya entendido los requisitos; además se verifica que los documentos de los requisitos
contempla estándares, es comprensible, constante y finito. Con esta premisa se puede concluir
que la validación de los requisitos es el proceso de examinar el documento de los requisitos para
asegurarnos que este define el software correctamente.

El proceso de validación implica las siguientes tareas:

• Revisiones de Requisitos,
• Prototipado,
• Validación del Modelo,
• Pruebas d e Aceptación,
• Verificación de Validez,
• Verificación de Consistencia,
• Verificación de Integridad,
• Realismo,
• Verificabilidad
 INGENIERÍA DE REQUERIMIENTOS

Gestión de requisitos:

La gestión de requisitos es un conjunto de actividades que ayudan al equipo de desarrollo a

identificar, controlar y seguir los requisitos y los cambios en cualquier momento.

La gestión o administración de requisitos se definió para sistemas grandes y cambiantes, debido a

que durante el proceso del software, la comprensión del problema por el desarrollador está
cambiando constantemente y estos cambios retroalimentan a los requerimientos. (Sommerville,
2005).
INGENIERÍA DE REQUERIMIENTOS

Gestión de requisitos:

a) Establecer una línea base: Se establece una línea de base mediante la documentación del
estado actual de las necesidades a un punto en el tiempo, para usar como punto
de partida. La línea de base muestra una serie de requisitos con los atributos de
estado acordados en un punto determinado en el tiempo y captura atributos
importantes acerca de los requisitos. El desarrollo de una línea de base crea una
referencia a utilizar para realizar un seguimiento de las necesidades evolucionan con el
tiempo.

b) Control de cambios: Se deben establecer mecanismos y políticas para reconocer,

evaluar y decidir como integrar las nuevas necesidades e ir evolucionando hacia una línea de
base de las necesidades existentes.

c) Seguimiento de requisitos: Mediante la identificación y documentación de

cómo los requisitos están relacionados de forma lógica y de los tipos de estos requisitos. La
Trazabilidad de los requisitos le permite identificar la forma en el que los requisitos se
relacionan con las metas y objetivos de negocio; y cuáles son los entregables del desarrollo
futuro.
INGENIERÍA DE REQUERIMIENTOS

Stakeholders (interesados)

a) Los interesados o su equivalente en inglés stakeholders son personas u organizaciones

que tienen influencia directa, indirecta, o se ven influenciados por un proceso de
software. Muchos autores en los mismos proyectos de desarrollo utilizan el término en
inglés stakeholders.

b) Los interesados más representativos y más fáciles de identificar son los clientes,
usuarios finales y desarrolladores. Sin embargo existen otros que se relacionan con el
proyecto como son: auditores, accionistas, proveedores, directivos, administradores, etc.

c) Cuando se desarrolla un proyecto de software inicialmente es sencillo identificar a los

interesados obvios, como: el equipo de desarrollo, usuarios finales y clientes. Pero hay
que descubrir otra gente que a simple vista no se relacionan con los anteriores pero que
sus actividades giran en torno al sistema; como es el caso de la gente que está en el nivel
más bajo del organigrama organizativo hasta aquellos que dirigen la organización.
INGENIERÍA DE REQUERIMIENTOS

Stakeholders (interesados)

d) En (Lamsweerde, 2009) se indica que para abordar una visión compartida de los
problemas que se abordarán en la construcción del sistema se necesita de la cooperación
de los interesados para obtener los requisitos completos, adecuados y realistas. Por tanto,
hay que seleccionar a los interesados apropiados para definir un modus operandi que
permitan superar dificultades en el proyecto. El desarrollo de requisitos y gestión de
requisitos implica a muchos stakeholders en diversos cargos.

e) Recuerde que, por lo general un proyecto de software comienza con un patrocinador,

que aprueba la justificación del proyecto y por lo tanto autoriza la ejecución del mismo;
además intervienen el jefe del proyecto, analistas, los desarrolladores de software y
evaluadores; a continuación se detallan las funciones de cada uno de ellos.
INGENIERÍA DE REQUERIMIENTOS

Funciones de los Stakeholders

Stakeholder Función
• Asigna recursos (personal, materiales y fondos) para el proyecto.

• Asegura que las metas y objetivos del proyecto estén alineados con los de la
organización.
Sponsor del proyecto
• Guía apropiadamente la participación de los clientes y usuarios en el proyecto.

• Define o aprueba la visión y alcance del producto.

• Toma decisiones acerca del alcance del proyecto y problemas de

versionamiento del producto.

• Resuelve conflictos en la priorización de requerimientos.

• Puede delegar autoridad para la aprobación de requisitos detallados a los

expertos del negocio o administradores de empresas.
INGENIERÍA DE REQUERIMIENTOS

Funciones de los Stakeholders

Stakeholder Función

• Actúa como enlace entre el equipo de software y el administrador del negocio.

• Coordina la implicación del usuario.

Gerente de • Asegura que el analista y los expertos tengan los recursos, herramientas,
proyecto o producto entrenamiento y conocimiento para desarrollar los requerimientos.

• Establece el proceso de control de cambios de los requerimientos. e)

Supervisa la priorización de requerimientos.

• Monitoriza el progreso del desarrollo y gestión de requisitos.

INGENIERÍA DE REQUERIMIENTOS

Funciones de los Stakeholders

Stakeholder Función

• Selecciona técnicas de elicitación.

• Colabora con los expertos del negocio.

Analista • Coordina actividades de gestión de requisitos.

• Diseña modelos y documentos.

• Traduce requerimientos de usuario a especificaciones.

• Monitoriza el cambio de los requerimientos y coordina la negociación.

• Verifica que requerimientos son necesarios, correctos, completos y

consistentes
INGENIERÍA DE REQUERIMIENTOS

Funciones de los Stakeholders

Stakeholder Función

• Provee detalles acerca de las necesidades de los usuarios.

• Provee detalles acerca de los procesos de negocio, reglas y datos.
• Identifica gente adicional que puede asesorar en los requerimientos.
• Representa a los usuarios quienes no pueden directamente involucrarse en
el desarrollo.
Experto en la materia
• Identifica y consulta con otros expertos en la materia o asesores que tienen
conocimiento relevante de los requerimientos.
• Aseguran que los requerimientos estén alineados a la visión del producto.
• Revisan la documentación de requerimientos para asegurarse que esta
adecuada y completamente representando las necesidades de los usuarios.
• Participa en la creación o revisión de los modelos y documentos de
requerimientos.
• Prioriza requerimientos.
INGENIERÍA DE REQUERIMIENTOS

Funciones de los Stakeholders

Stakeholder Función
Provee detalles acerca de restricciones de diseño y sugerencias respecto a la
viabilidad de requerimientos no funcionales.
Desarrollador y
Puede contribuir a escribir partes de la especificación de requerimientos de
tester de software.
software
Revisa toda la documentación de requerimientos.

Revisa las especificaciones de software para asegurarse de que se puede

transformar en un diseño de software viable.

Asegura que los requerimientos puedan ser probados.

INGENIERÍA DE REQUERIMIENTOS

Funciones de los Stakeholders

GESTIÓN DE
DESARROLLO DE REQUERIMIENTOS
REQUERIMIENTOS

Define requerimiento del Desarrolla Especificar

negocio requerimientos de requerimientos de
usuario software

Sponsor del Propietario

proyecto aprobador Revisor Aprobador Aprobador

Gerente del
proyecto o Productor Revisor Revisor Revisor
producto

Analista Revisor Productor Productor Productor

Propietario,
aprobador, Propietario
Usuario experto Revisor Propietario
productor Revisor

Desarrollador y tester Revisor

de software Revisor Revisor Productor Revisor
 Bibliografia
• Lamsweerde, A., (2009). Requirements Engineering: from system goals to UML models to software
Specifications. Inglaterra. Editorial Wiley.
En este libro se hace un especial referencia a los conceptos preliminares de la Ingeniería de
Requisitos, además de un profundo análisis de los casos de los requisitos.

• Pressman, R., (2010). Ingeniería del Software: Un enfoque práctico. México. Editorial McGraw-
Hill.
El texto se presenta como un medio de consulta a nivel general para entender a la ingeniería de
requisitos en el contexto de la ingeniería del software.

• International Institute of Business Analysis. (2009) A Guide to the Business Analysis Body of
Knowledge.
Guía que recoge el análisis de negocios en donde se reflejan las mejores prácticas proporcionando un
marco que describe las áreas de conocimiento, con actividades y tareas asociadas.

• Wiegers, K. (2003) Software Requirements. Microsoft Press.

Texto que reúne los principales componentes del proceso de gestión y administración de
requerimientos.