UNIDAD I

Procesos de la
Ingeniería de
Requerimientos
 Introducción
Sistema de Información
Un sistema de información
puede definirse técnicamente
como un conjunto de
componentes
interrelacionados que
permiten capturar, procesar,
almacenar y distribuir la
información para apoyar la
toma de decisiones y el
control en una institución, ya
sea pública o privada.
 Introducción
Sistema de Información

Los Sistemas de Información

pueden también ayudar a los
administradores a analizar
problemas, visualizar
cuestiones complejas y crear
nuevos productos.
 Sistema de Información
Medio ambiente

Clientes INSTITUCION Proveedores

SISTEMA DE
INFORMACION

Almacenamiento
Salida
o Procesamiento
o producto
Insumo

Retroalimentación

Entidades Accionistas Competidores

reglamentadoras
 Sistema de Información
Los sistemas de información
proporcionan la solución institucional
más importante a los retos y
problemas que surgen del medio
ambiente de negocios.
Instituciones Tecnología

Un administrador debe conocer en Sistemas

de Información
amplitud las tecnologías de la
organización, administración e
información en los sistemas.
Administración

Luego es necesario examinar las

capacidades y oportunidades que
proporciona la tecnología de la
información actual para dar
soluciones.
 Tipos de Sistemas de Información
T ip o s d e G r u p o S e r v id o
s is t e m a d e
in fo r m a c ió n

D ir e c to r e s o a d m in is tr a d o r e s
N iv e l e s tr a té g ic o d e n iv e l s u p e r io r

N iv e l d e G e re n te s o
a d im in is tr a c ió n a d m in is tr a d o r e s m e d io s

N iv e l d e T r a b a ja d o r e s d e l
c o n o c im ie n to c o n o c im ie n t o y la
in fo r m a c ió n

N iv e l o p e r a tiv o
G e re n te s
o p e r a tiv o s

V e n ta s y M a n u fa c tu ra F in a n z a s C o n t a b ilid a d R e c u rso s
m e r c a d o t e c n ia h u m a n o s
 Sistema de Información
En la actualidad, los Sistemas de Información
juegan un papel estratégico en la vida de la
empresa.

Hardware

Negocio
Estratégia Software Base de
Reglas datos
procedimientos

Interdependencia
Comunica
ciones
Institución Sistemas de
información
Ningún sistema proporciona
por sí mismo toda la
información que
uncioaAplf lesdon
neg ocis

la Co ordinacó
Sistemarégco

Ventasymrcdoi Manufctr FinazsCotbl Recursohm da anos

cómsiteaB desputo Hardwe Software Informacióyhvs comuniaTel iones-c
deSis adminstrcóe
Sistemadcon
Sistemaoprv
uncioaAplf lesdon
neg ocis
Co ordinacó
Sistemarégco

Ventasymrcdoi Manufctr FinazsCotbl daRecursohm anos

cómsiteaB putodes Hardwe Software Informacióyhvs comuniaTel iones-c
deSis adminstrcóe
Sistemadcon
Sistemaoprv

institución requiere.
 ¿Qué son Requerimientos?
• Una condición o necesidad de un usuario para resolver un problema
o alcanzar un objetivo.

• Una condición o capacidad que debe estar presente en un sistema o

componentes de sistema para satisfacer un contrato, estándar,
especificación u otro documento formal.

• Una representación documentada de una condición o capacidad.

 Características de los requerimientos
 Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema
a construir, y además su capacidad, características físicas o factor de calidad no pueden ser
reemplazados por otras capacidades del producto o del proceso.
 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser
simple y clara para aquellos que vayan a consultarlo en un futuro.
 Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es
decir, si se proporciona la información suficiente para su comprensión.
 Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El
lenguaje usado en su definición, no debe causar confusiones al lector.
 Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que
permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración
o pruebas.
Dificultades para definir los requerimientos
 Los requerimientos no son obvios y vienen de muchas fuentes.
 Son difíciles de expresar en palabras (el lenguaje es ambiguo).
 Existen muchos tipos de requerimientos y diferentes niveles de detalle.
 La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
 Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más
estables que otros.
 Los requerimientos están relacionados unos con otros, y a su vez se relacionan con
otras partes del proceso.
 Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales
específicas.
 Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
 Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular
para cada proyecto.
 Cada requerimiento debe…
 Expresarse de modo adecuado
 Ser de acceso sencillo
 Numerarse
 Acompañarse con pruebas que lo
verifiquen
 Tomarse en cuenta en el diseño
 Tomarse en cuenta en el código
 Probarse aislado
 Probarse junto con otros
requerimientos
 Validarse con las pruebas después de
construir la aplicación
Definición de Ingeniería de Requerimientos
 "Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa,
consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las
partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm
1979.

 "Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos

declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no
ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones,
interfaces, rendimiento y limitaciones". STARTS Guide 1987.
Definición de Ingeniería de Requerimientos
 "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" Leite 1987.

 "Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar

los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre
los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software
 Los principales beneficios que se obtienen
de la Ingeniería de Requerimientos son:
 Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad
de la IR consiste de una serie de pasos organizados y bien definidos.
 Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados:
La IR proporciona un punto de partida para controles subsecuentes y actividades de
mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.
 Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que
reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro;
especialmente aquellas decisiones tomadas durante la RE.
 Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un
conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
 Mejora la comunicación entre equipos: La especificación de requerimientos representa
una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto
no será exitoso.
 Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a
considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por
lo que se le involucra durante todo el desarrollo del proyecto.
Procesos de la Ingeniería de Requerimientos

Requerimientos
Requerimientos Requerimientos Requerimientos
de
de de para la
Análisis y
Proceso Usuarios Gestión
Negociación
 Requerimientos de Proceso
 Estos requerimientos
existen porque los
procesos los usan
durante el desarrollo
del software.
 Requerimientos del Usuario
 Describen los requerimientos funcionales y no
funcionales de tal forma que sean comprensibles por
los usuarios del sistema que no posean un
conocimiento técnico detallado.
 Únicamente especifican el comportamiento externo
del sistema y evitan, tanto como sea posible, las
características de diseño del sistema.
 Deben redactarse utilizando el lenguaje natural,
representaciones y diagramas intuitivos sencillos.
 Requerimientos del Usuario
Problemas que se presentan cuando se redacta en
lenguaje natural:

 Falta de claridad
 Confusión de requerimientos
 Conjunción de requerimientos
 Requerimientos del Usuario
Pautas sencillas para redactar requerimientos:

 Inventar un formato estándar y asegurar que todos

los requerimientos se adhieren al formato.
 Utilizar el lenguaje en forma consistente.
 Resaltar el texto para ver las partes claves del
requerimiento.
 Evitar utilizar el lenguaje “técnico” de computación.
Requerimientos para el Análisis y Negociación

Los requisitos se agrupan en categorías y se organizan

en subconjuntos, se analiza cada requisito en relación
con el resto, se examina los requisitos en su
consistencia, completitud y ambigüedad, y se
clasifican en base a las necesidades de los
clientes/usuario.
 Requerimientos para el Análisis y Negociación

Para hacer el Análisis de requisitos se plantean las siguientes

cuestiones:
1. ¿Cada requisito es consistente con los objetivos generales del
sistema/producto?
2. ¿Tienen todos los requisitos especificados el nivel adecuado
de abstracción? ¿Algunos requisitos tienen un nivel de detalle
técnico inapropiado en esta etapa?
3. ¿El requisito es necesario o representa una característica
añadida que puede no ser esencial a la finalidad del sistema?
4. ¿Cada requisito está delimitado y sin ambigüedad?
 Requerimientos para el Análisis y Negociación

5. ¿Cada requisito tiene procedencia? Es decir, ¿Existe un origen

(general o específico) conocido para cada requisito?
6. ¿Existen requisitos incompatibles con otros requisitos?
7. ¿Es posible lograr cada requisito en el entorno técnico donde
se integrará el sistema o producto?
8. ¿Se puede probar el requisito una vez implementado?
 Requerimientos para el Análisis y Negociación
Proceso de Negociación
 Los clientes deberán clasificar sus requisitos y discutir los
posibles conflictos según su prioridad.
 Los riesgos asociados con cada requisito serán identificados y
analizados.
 Se efectúan estimaciones del esfuerzo de desarrollo que se
utilizan para valorar el impacto de cada requisito en el coste
del proyecto y en el plazo de entrega.
 Utilizando un procedimiento iterativo, se irán eliminando
requisitos, se irán combinando y/o modificando para
conseguir satisfacer los objetivos planteados.
 Requerimientos para la Gestión
 Es un conjunto de actividades que ayudan al equipo de
trabajo a identificar, controlar y seguir los requisitos y los
cambios en cualquier momento.
 Como en la Gestión de Configuración del Software (GCS), la
gestión de requisitos comienza con la actividad de
identificación. A cada requisito se le asigna un único
identificador, que puede tomar la forma:

<tipo de requisito><requisito no.>

Requerimientos para la Gestión
Identificadores, según el tipo de requisito:
F Funcional
D Datos
C Comportamiento
I Interfaz
S Salida
 Requerimientos para la Gestión
Matrices que se deben realizar para la Gestión de Requisitos:

 Matriz de seguimiento de características: muestra los requisitos

identificados en relación a las características definidas por el cliente del
sistema/producto.
 Matriz de seguimiento de orígenes: identifica el origen de cada requisito.
 Matriz de seguimiento de dependencias: indica cómo se relacionan los
requisitos entre sí.
 Matriz de seguimiento de subsistema: vincula los requisitos a los
subsistemas que lo manejan.
 Matriz de seguimiento de interfaces: muestra cómo los requisitos están
vinculados a las interfaces externas o internas del sistema.
 Requerimientos para la Gestión

 Matriz de seguimiento de características: muestra los requisitos

identificados en relación a las características definidas por el cliente del
sistema/producto.
 Ejemplo:

El problema de
Afecta a
Cuyo impacto
ocasiona
Una solución
exitosa debería
 Requerimientos para la Gestión
 Matriz de seguimiento de orígenes: identifica el origen de cada requisito.

 Ejemplo:

Requerimiento Tipo Usuario Origen

 Requerimientos para la Gestión
 Matriz de seguimiento de interfaces: muestra cómo los requisitos están
vinculados a las interfaces externas o internas del sistema.

 Ejemplo:

Requerimiento Interfaz Tipo Usuario Módulo