Guía 1 Escuela de Ingeniería de Requerimientos de

Tecnologías Software

Ingeniería de
Requerimientos

Tema Nº1:
TEMA 01 a la Ingeniería
Introducción Teoría
de de los
Requerimientos

Indicador de logro Nº1:

Reconoce la importancia de la Ingeniería de Requerimientos para el modelamiento
de1software, de acuerdo al UML
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

Tema 1: Introducción a la Ingeniería de Requerimientos

OBJETO DE LA EXPERIENCIA
 Conoce la estructura de la ingeniería de requerimientos y su importancia para la correcta
construcción del modelado y posterior implementación en un lenguaje de programación.
 Identifica los diferentes tipos de requerimientos y entiende el ámbito de cada uno de
ellos.

Subtema 1.1:

1. Fundamentos de Ingeniería de Requerimientos de

Software
1.1. ¿Qué es Ingeniería?
“La ingeniería es la ciencia, arte, y profesión de adquisición y aplicación de
conocimientos matemáticos, técnicos y científicos en la creación, desarrollo e
implementación de los servicios públicos tales como materiales, estructuras,
maquinas, dispositivos, sistemas o procesos que realizan una función en
particular” (es.wikipedia.org//wiki/Engineering)

1.2. Requerimientos
Los Requerimientos fueron definidos por la IEEE como [IEEE90]:

1. Condición o capacidad requerida por el usuario para resolver un problema o

alcanzar un objetivo
2. Condición o capacidad que debe satisfacer o poseer un sistema o una
componente de un sistema para satisfacer un contrato, un standard, una
especificación u otro documento formalmente impuesto
3. Representación documentada de una condición o capacidad como en 1 o 2.

No es lo mismo un pedido o deseo de un usuario o cliente que un requerimiento. No

todos los pedidos o deseos de un usuario o cliente se convierten necesariamente
en requerimientos, pero todos los requerimientos se originan en un pedido o deseo
de un usuario o cliente.
Para que un pedido o deseo de un usuario o cliente se convierta en requerimiento,
este debe ser documentado apropiadamente y el solicitante debe validarlo.

1.3. Ingeniería de Requerimientos

(Leite) Es el proceso mediante el cual se intercambian diferentes puntos de vista
para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una
combinación de métodos, herramientas y actores, cuyo producto es un modelo del
cual se genera un documento de requerimientos.

Cuando nos encontramos al frente de un proyecto de desarrollo de sistemas es

importante dejar claramente definidos los requerimientos del software, en forma
consistente y compacta, esta tarea es difícil básicamente porque consiste en la

2
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

traducción de unas ideas vagas de necesidades de software en un conjunto

concreto de funciones y restricciones. Además el analista debe extraer información
dialogando con muchas personas y cada una de ellas se expresará de una forma
distinta, tendrá conocimientos informáticos y técnicos distintos, y tendrá unas
necesidades y una idea del proyecto muy particulares.

1.4. Proceso de Análisis de Requerimientos

El proceso del establecimiento de requerimientos de un sistema de software es el

primer paso esencial en entregar lo que el cliente desea. A pesar de esto, la
insuficiencia de tiempo y esfuerzo son a menudo encontrado en esta actividad y
existen pocos métodos sistemáticos para soportarlo. Entre los métodos conocidos
se puede citar a los siguientes:

Método CORE
El método Controlled Requirements Expression (CORE) [Norris] es un conjunto de
notaciones textuales y gráficas, con guías especificadas para la captura y validación
de requerimientos del sistema, en las etapas iniciales del diseño del sistema. CORE
ha sido, por tradición, pensado como puramente una técnica de captura y análisis
de requerimientos (RCA), aunque soporta algunos aspectos de diseño tales como
estructuras de datos. CORE está basada en el principio de primero definir el
problema a ser analizado (definición del problema), y luego dividirlo en unidades o
puntos de vista a considerar.

El método CORE consiste en siete etapas. Cada una produce salidas que alimentan
a la etapa subsecuente como entrada o que forman parte de la especificación de
requerimientos final. CORE pretende examinar el sistema y su ambiente en un
número de niveles, con detalles más finos progresivamente en cada nivel. Las siete
etapas se presentan a continuación:

1. Definición del problema.

El propósito de la definición del problema es identificar los límites del mismo.
Contiene detalles de los objetivos de la empresa de los usuarios del sistema, la base
para la necesidad de un nuevo sistema, limitaciones de costo y tiempo, y quién va
a ser el responsable de la revisión y aceptación de los resultados finales.

2. Estructuración del punto de vista.

El propósito de esta etapa es descomponer el ambiente del sistema en los
elementos para que el sistema propuesto pueda ser analizado desde los puntos de
vista de todas las entidades que se comunican con él, la más importante de las
cuales son los usuarios. Durante esta etapa, todas las entidades que son fuentes
potenciales de información deben ser identificadas.

3. Colección tabular.
Esta etapa es cuando la información sobre los flujos de datos entre los puntos de
vista y el procesamiento de éstos son reunidos. Esto ayuda a establecer la totalidad
y consistencia.

3
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

4. Estructuración de datos.
En la etapa previa, los elementos de información que pasan entre los puntos de vista
son referidos por sus nombres generales. En esta etapa, se da una vista más
cercana al contenido, a la estructura y a la derivación de datos, al producir
diagramas de estructura de datos.

5. Modelación individual de puntos de vista.

Esta etapa puede dividirse en dos partes. Lo único concerniente a la primera es
convertir las TCF'S en una notación diferente para producir los diagramas
individuales del modelo de punto de vista. La segunda parte se refiere a agregar
alguna información nueva perteneciente a flujos de datos internos, control de
acciones y tiempo de acciones.

6. Modelación combinada de punto de vista.

Esta etapa facilita el análisis de una secuencia de eventos de más de un punto de
vista. Cada diagrama de modelo combinado de punto de vista producido durante
esta etapa es una representación del procesamiento de información que ocurre
entre puntos de vista.

7. Análisis de restricciones.
En esta etapa, se consideran restricciones adicionales tales como desempeño y
seguridad. Éstas pueden afectar los diagramas de puntos de vista ya producidos.
Las restricciones se documentan en una especificación de restricción del sistema.

Para Pressman, en el proceso de análisis de requerimientos del software se puede

identificar cinco tareas o etapas fundamentales:

1. Reconocimiento del problema

Se deben de estudiar inicialmente las especificaciones del sistema y el plan del
proyecto del software. Realmente se necesita llegar a comprender el software dentro
del contexto del sistema. El analista debe establecer un canal adecuado de
comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la
función primordial del analista en todo momento es reconocer los elementos del
problema tal y como los percibe el usuario.

2. Evaluación y síntesis
En esta etapa el analista debe centrarse en el flujo y estructura de la información,
definir las funciones del software, determinar los factores que afectan el desarrollo
de nuestro sistema, establecer las características de la interfaz del sistema y
descubrir las restricciones del diseño. Todas las tareas anteriores conducen
fácilmente a la determinación del problema de forma sintetizada.

3. Modelización
Durante la evaluación y síntesis de la solución, se crean modelos del sistema que
servirán al analista para comprender mejor el proceso funcional, operativo y de
contenido de la información. El modelo servirá de pilar para el diseño del software y
como base para la creación de una especificación del software.

4
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

4. Especificación
Las tareas asociadas con la especificación intentan proporcionar una
representación del software. Esto más adelante permitirá llegar a determinar si se
ha llegado a comprender el software, en los casos que se lleguen a modelar se
pueden dejar plasmados manuales.

5. Revisión
Una vez que se han descrito la información básica, se especifican los criterios de
validación que han de servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito el software. La documentación
del análisis de requerimientos y manuales, permitirán una revisión por parte del
cliente, la cual posiblemente traerá consigo modificaciones en las funciones del
sistema por lo que deberán revisarse el plan de desarrollo y las estimaciones
previstas inicialmente.

Loucopoulos [Loucopoulos], en el que se plantea que en esta fase hay que

considerar por lo menos tres aspectos fundamentales:

• Comprender el problema
• Describir formalmente el problema
• Obtener un acuerdo sobre la naturaleza del problema

Esto nos llevaría a simplificar el proceso a tres etapas para obtener los
requerimientos del problema que estamos atacando, estas etapas son las
siguientes:

• Elicitación de requerimientos
• Especificación
• Validación

Elicitación de requerimientos
El propósito de la Elicitación de requerimientos es ganar conocimientos relevantes
del problema, que se utilizarán para producir una especificación formal del software
necesario para resolverlo. “Un problema puede ser definido como la diferencia entre
las cosas como se perciben y las cosas como se desean”. Aquí vemos nuevamente
la importancia que tiene una buena comunicación entre desarrolladores y clientes;
de esta comunicación con el cliente depende que entendamos sus necesidades.
Al final de la fase de análisis de requerimientos el analista podría llegar a tener un
conocimiento extenso en el dominio del problema.

Especificación
Una especificación puede ser vista como un contrato entre usuarios y
desarrolladores de software, que define el comportamiento funcional deseado del
artefacto de software (y otras propiedades de éste, tales como performance,
confiabilidad, etc.), sin mostrar cómo será alcanzada tal funcionalidad.

Validación

5
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

La validación es el proceso que certifica que el modelo de los requerimientos es

consistente con las intenciones de los clientes y los usuarios; ésta es una visión más
general que el concepto común de validación, pues se produce en paralelo con la
Elicitación y la especificación, tratando de asegurar que tanto las ideas como los
conceptos presentados en una descripción se identifican y explican con claridad La
necesidad de validación aparece cuando:

• Se incorpora una nueva pieza de información al modelo actual

• Cuando diferentes piezas de información se incorporan en un todo coherente.

La validación no sólo se aplica al modelo final de los requerimientos, sino también

a los modelos intermedios

En la figura 1 podemos ver el esquema del proceso planteado

Fig 01: Esquema del proceso de ingeniería de requerimientos (Fuente:

Loucopoulos)

1.5. Enfoques:

6
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

Un enfoque organizado para el desarrollo de software es esencial para reducir estos

factores de dificultad. Hay muchas oportunidades para cometer errores por
requerimientos mal interpretados en el camino hacia una implantación incorrecta.
Con el fin de servir como guía y agilizar el proceso de desarrollo de software, se
desarrollaron varios modelos de ciclo de vida. No hay un modelo correcto para todos
los propósitos, aun así, el uso de un modelo apropiado puede ayudar de manera
considerable en el control de un proyecto de software.
Entre los más populares y por todos conocidos podemos nombrar: El modelo de
cascada, modelo en espiral de Boehm y Prototipado Evolutivo.

El modelo de cascada o ciclo de vida clásico

La versión original del modelo en cascada, fue presentada por Royce en 1970,
aunque son más conocidos los refinamientos realizados por Boehm (1981),
Sommerville (1985) y Sigwart et al. (1990).

En este modelo, el producto evoluciona a través de una secuencia de fases

ordenadas en forma lineal, permitiendo iteraciones al estado anterior.
El número de etapas suele variar, pero en general suelen ser:

• Análisis de requerimientos del sistema.

• Análisis de requerimientos del software.
• Diseño preliminar.
• Diseño detallado
• Codificación y pruebas.
• Explotación (u operación) y mantenimiento.

En este enfoque se presentan las siguientes situaciones:

1. Todas las actividades son ejecutadas a partir de una única fase.

2. La fase o etapa coincide con la disciplina
3. Dificultad para adoptar cambios a lo largo del proyecto
4. El ciclo de entrega es prolongado, se corre el riesgo de descubrir errores al final

Modelo en espiral de Boehm

En 1988 Boehm propone el modelo en espiral, para superar las limitaciones del
modelo en cascada. La espiral se forma a partir de una serie de ciclos de desarrollo
y va evolucionando. Los ciclos internos del espiral denotan análisis y prototipado y
los extemos el modelo clásico. En la dimensión radial están los costos acumulativos
y la dimensión angular representa el progreso realizado en cada etapa.
En cada ciclo se empieza identificando los objetivos, las alternativas y las
restricciones del mismo. Se deben evaluar las alternativas de solución respecto de
los objetivos, considerando las restricciones en cada caso. Es en este momento en
que se puede llevar a cabo el siguiente ciclo

Iterativo e incremental
Se divide el proyecto en fase que busca realizar entregas parciales y sucesivas para
llegar al producto final y completo

7
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

Este método tiene las siguientes consideraciones:

1. No se asume que todo el trabajo de una disciplina debe estar completado antes
de que haya actividades de otra disciplina.
2. Los cambios se abordan más fácilmente a través de la planificación de las
siguientes iteraciones.
3. La disciplina de requerimientos se lleva en todo el proyecto.

1.6. Esfuerzo por disciplina en el Proceso Unificado

Fig 02: Proceso de desarrollo de software con RUP

(Fuente: https://mcsdlopez.wordpress.com/2012/12/24/proceso-de-desarrollo-de-software-
con-rup/)

1.7. ¿Qué es la Ingeniería de Requisitos?

Es la disciplina de la ingeniería de software que consiste en un uso sistemático y
repetitivo de técnicas que abarcan las actividades de identificación, documentación
y mantenimiento de un conjunto de requerimientos para el software, con el fin de
que éstos cumplan con los objetivos de negocio y sean de calidad.

8
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

Fig 03: Definición de requisitos

(Fuente: @FATTO Consultoría y sistemas – www.fatto.com)

Subtema 1.2:

Requerimientos: Notación y Clasificación de Requerimientos

Explícitos:
Los requerimientos establecidos explícitamente se reflejan en el documento de
Especificación de Requerimientos del Sistemas (ERS)
Requerimientos funcionales: Funciones a realizar el software
Requerimientos no funcionales: requerimientos de seguridad, rendimiento, interfaz,
etc. Describen restricciones que limitan opciones de soluciona el problema.
Restricciones cuantitativas o precisión
Pseudorequerimientos: Impuestos por el cliente que restringen la implementación
del sistema

Implícitos:
Los requerimientos implícitos no aparecen en la ERS, pero si no se cumplen con ellos
la calidad del software queda en entredicho.

9
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

Fig 04: Clasificación de los requerimientos (Fuente:

https://slideplayer.es/slide/1489804/)

2.1. REQUERIMIENTOS FUNCIONALES

2.1.1. Requerimientos de Negocio:
Se expresan desde la perspectiva de la empresa
 Describen porque la empresa o el cliente desea desarrollar el sistema
 Expresan que objetivos, metas o necesidades la empresa espera
alcanzar

Ejemplos:
 La empresa RAFMA. C.A. quiere abrir su mercado a cualquier usuario
interesado en la adquisición de monedas antiguas.
 La aplicación oldcurrency.com deberá contribuir a abrir el mercado e
incrementar el volumen de ventas anuales de monedas antiguas.
2.1.2. Requerimientos de Usuarios:
Se expresan desde la perspectiva del usuario
 Describen las necesidades que los usuarios tienen y las tareas que los
usuarios deben realizar con el sistema y la aplicación.
 Expresan lo que el usuario será capaz de hacer con el sistema.
Ejemplos:
 Hojear los catálogos de monedas antiguas
 Visualizar una moneda
 Comprar una moneda.

10
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

2.1.3. Requerimientos del Sistema:

 Se expresan desde la perspectiva del sistema Hardware/Software que
contiene la aplicación. Asume que el software es parte de un sistema
mayor.
 Son de alto nivel para productos que contienen componentes Hardware
y Software.
Ejemplos:
 La aplicación oldcurrency.com deberá enviar un mensaje electrónico
cada vez que RAFMA. C.A. disponga de una moneda antigua de su
interés.

2.1.4. Requerimientos de Comportamiento:

Se expresan desde la perspectiva del desarrollador
 Se denominan requerimientos funcionales propiamente dichos
 Describen los servicios que el sistema presta a todos los usuarios
directos.
 Expresa que el sistema bajo ciertos eventos (comportamiento)
Ejemplos:
 La aplicación oldcurrency.com deberá permitirle al cliente efectuar el
pago de su pedido en línea, usando cualquier tarjeta de crédito.
 El sistema deberá permitirle al usuario visualizar la moneda o monedas
seleccionadas por el usuario de los contenidos en el catálogo de
monedas.

2.2. REQUERIMIENTOS NO FUNCIONALES

2.2.1. Reglas de Negocio
Expresan todas las regulaciones que la aplicación deberá acatar, entre otras:
 Regulaciones gubernamentales (Leyes decretos, providencias, etc.)
 Regulaciones de la empresa (Políticas, normas, procedimientos,
estrategias, etc.)
 Regulaciones propias de la aplicación (Estándares, metodología que
debe seguirse, algoritmos o clases que deben usarse)

Ejemplos:

 Oldcurrency.com deberá desarrollarse usando la metodología RUP

11
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

 Un cliente puede descargar gratuitamente las actualizaciones de un

catálogo adquirido por el durante los dos primeros meses a partir de la
publicación de la actualización.
2.2.2. De Interfaz
Expresan las características de la interacción del usuario con el sistema. Se
divide en:
 Requerimientos de interfaz gráfica (GUI): Describen las propiedades
generales de la interfaz gráfica que permitirá la interacción entre el
usuario y el sistema.
 Requerimientos de interfaces con otros sistemas: Describe con que o
como la aplicación interactuará con otras aplicaciones de software o
hardware.

Ejemplos:

 Oldcurrency.com deberá ser implementada usando una interfaz web.

 Oldcurrency.com deberá interactuar con el sistema de pagos PayPal.
2.2.3. Restricciones
Expresan las limitaciones que se le imponen al desarrollo del sistema, tales
como:
 Plataforma de desarrollo y operación
 Uso de estándares, prácticas métodos de desarrollo
 Tiempo máximo de desarrollo.
 Costo máximo de desarrollo

Ejemplos:
Oldcurrency.com deberá ser una aplicación web desarrollada con las
herramientas:
 Plataforma LAMP: Linux, Apache, MySQL y PHP
 Tiempo máximo de desarrollo 6 meses.
 Costo máximo de desarrollo $10000.
2.2.4. Atributos de Calidad
Expresan las propiedades de calidad que el sistema debe satisfacer
 El rendimiento que la aplicación debe tener
 La confiabilidad que debe poseer
 La seguridad que debe proveer
 La utilidad que debe garantizar.

12
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

Ejemplos:
 Oldcurrency.com deberá tener una confiabilidad del 95%
 Oldcurrency.com deberá ser fácil de usar.
2.3. DIFERENCIAS ENTRE LOS TIPOS DE REQUERIMIENTOS
REQUERIMIENTOS REQUERIMIENTOS NO FUNCIONALES
FUNCIONALES
Establecen los objetivos de negocio No están relacionados con la
respecto al sistema. funcionalidad o comportamiento del
sistema
Establecen los servicios que el
sistema debe proporcionarle al Restringen el diseño del sistema (la
sistema. solución)
Determinan la funcionalidad del Describen:
sistema
 Las restricciones que se imponen al
Determinan lo que le sistema sistema
deberá hacer, es decir:  Los atributos de calidad que el
sistema debe satisfacer.
 Su comportamiento
 Las reglas de negocio que el sistema
 Su interacción con los usuarios y
debe respetar o implementar.
su dominio de aplicación
 Las interfaces con otros sistemas.
(negocio)
 Sus respuestas a eventos

13
Guía 1 Escuela de Ingeniería de Requerimientos de
Tecnologías Software

ACTIVIDAD:
Describe e identifica los tipos de Requerimientos bajo el enfoque sistémico

CASO ESTUDIO:
La empresa INFOTEL BUSINESS, es una empresa que se dedica a la
comercialización y distribución de productos informáticos.
Tiene 15 años en el mercado informático y sus procesos principales son Gerencia,
Ventas, Compras y Almacén. Tiene una cartera de clientes muy fidelizada y sus
proveedores les proporcionan los productos informáticos de las mejores marcas y
modelos con tecnología moderna.
Los objetivos planteados para el 2021 son los siguientes:
 Gerencia: Incrementar el nivel de rentabilidad de la empresa en un 60%
 Ventas: Incrementar el volumen de las ventas en un 50%
 Compras: Seleccionar los mejores proveedores de productos para obtener buenos
precios con un margen del 40%
 Almacén: Optimizar las entradas y salidas de productos del almacén en un 90%
 Se pide elaborar el Diagrama del Modelo de Casos de Uso de Negocio (MCUN)

Solución

Ingresa a la plataforma virtual, luego desarrolla la siguiente actividad propuesta:

a) CUESTIONARIO TÉCNICO

1.0 Identifique los requerimientos funcionales

2.0 Identifique los requerimientos no funcionales

b) CONCLUSIONES DE LA EXPERIENCIA

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_________________________________________________

14