INGENIERÍA DE REQUERIMIENTOS

INGENIERÍA DE REQUERIMIENTOS

Ing. Séfora Román Sánchez

UNHEVAL - Ingeniería de Requerimientos 2

“La parte más difícil de construir un sistema de software es decidir qué construir […]”

“Ninguna otra tarea afecta tanto negativamente al sistema, al final, si se realiza de manera incorrecta, al inicio.”

Frederick Phillips Brooks Professor Department of Computer Scienc.University of North Carolina. USA.

“La construcción del software no es el problema.”

“El verdadero problema radica en saber cuáles son los requerimientos que deben ser construidos y los que no.”

UNHEVAL- Ingeniería de Requerimientos 4

ESTADÍSTICAS DE ÉXITO – NO ÉXITO

UNHEVAL - Ingeniería de Requerimientos 5

PRINCIPALES PROBLEMAS EN EL DESARROLLO DE SW

• Mala comprensión de las necesidades del usuario.• Requisitos y necesidades incompletas.• Cambio constante en los requerimientos.• Falta de estándares.• Detección tardía de errores.• Mala integración de módulos.• Pruebas insuficientes.

27/04/2023 UNHEVAL- Ingeniería de Requerimientos 6

NECESIDADES

Arquitectura

Requerimientos

Nece-sidades

• Interesados de la organización: Clientes, usuarios, etc

• Necesidades de información y expectativas.• Análisis y diseño de los procesos de la organización.• Modelado del negocio.• Análisis de las actividades. • Personas que se benefician de los procesos.• Personas que ejecutan los procesos.• Información usada en los procesos.• Mejoramiento de procesos. • Identificar los problemas de información actuales y

futuros.

27/04/2023 UNHEVAL- Ingeniería de Requerimientos 7

ARQUITECTURA

Arquitectura

Requerimientos

Nece-sidades • Análisis y diseño de las clases del sistema.

• Definir las capas, subsistemas, dependencias, interfases y servicios.

• Construir el modelo de datos.• Identificar patrones de diseño. • Construir el modelo de despliegue.

• Equipo del proyecto: Desarrolladores, etc

27/04/2023UNHEVAL- Ingeniería de Requerimientos

8

• Interesados de la organización: Clientes, usuarios, etc

• Requisitos a ser satisfechos por el software.• Descripción de lo que un sistema debe realizar.• Características y atributos del sistema.• Acuerdos con los interesados y desarrolladores.

• Equipo del proyecto: Desarrolladores, etc

REQUERIMIENTOS

Arquitectura

Requerimientos

Nece-sidades

UNHEVAL- Ingeniería de Requerimientos9

Arquitectura

Requerimientos

INGENIERÍA DE REQUERIMIENTOS

Nece-sidades

• Determinar las necesidades y condiciones de los interesados y

• Convertirlas en requisitos acordados, documentados y mantenidos a ser satisfechos por un software.

27/04/2023 UNHEVAL- Ingeniería de Requerimientos

10

Arquitectura

Requerimientos

INGENIERÍA DE REQUERIMIENTOS

Nece-sidades

• Implica: Identificar las necesidades de los

interesados. Analizar las expectativas adicionales. Negociar con los interesados y

el equipo de proyecto los acuerdos de desarrollo.

Documentar los requerimientos adecuadamente.

Validar los requerimientos contra las necesidades.

DEFINICION DE IR SEGÚN DISTINTOS AUTORES

DEFINICION DE IR SEGÚN DISTINTOS AUTORES

No existe proceso único que sea validado de aplicar en todas las

organizaciones. Cada organismo debe desarrollar su propio proceso de

acuerdo al tipo de producto que se esté desarrollando, a la cultura

organizacional y al nivel de experiencia y habilidad de las personas

involucradas en la ingeniería de requerimientos.

 ¿QUIÉN HACE LA INGENIERÍA DE REQUISITOS?

• Los Ingenieros de Software (Ingenieros de Sistemas o Analistas de Sistemas) y los interesados (gerentes, clientes, usuarios finales).

• El diseño y la construcción de un elegante programa de computadora que resuelva el problema incorrecto no satisface las necesidades de nadie. Por lo tanto, es muy importante entender lo que el cliente quiere antes de comenzar a diseñar y construir un sistema basado en PC.

IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS?

PASOS PARA HACER INGENIERÍA DE REQUERMIENTOS

Inicio

Obtención

Elaboración

NegociaciónEspecificación

Validación

Gestión

Inicio.- Se define al ámbito y la naturaleza del problema que debe resolverseObtención .- Ayuda al cliente a definir sus necesidades. QFDElaboración.- Se refinen y modifican los requisitos básicos Negociación .- Se definen las prioridades, cuales aspectos son esenciales y en qué momento se requieren Especificación.- Puede ser un documento escrito, modelos gráficos, matemáticos, etc.Validación.- Examinar existencia, omisiones y ambigüedadesGestión.- Identificar, controlar y rastrear los requisitos y los cambios de éstos en el proyecto

Las actividades del proceso incluyen :• Extracción de requerimientos• Análisis del problema• Especificación• Validación • Evolución

ROLES O TIPOS DE PARTICIPANTES EN LA INGENIERÍA DE REQUISITOS 

Rol Descripción

Ingeniero de requisitos

También conocido como analista, es el responsable de interactuar con clientes y usuarios para obtener sus necesidades y también de desarrollar y gestionar los requisitos.

ClienteEs el responsable de la financiación del proyecto y tiene capacidad ejecutiva para tomar decisiones sobre el mismo. Suele tener una visión global del modelo de negocio.

UsuarioEs el usuario potencial del software a desarrollar en el proyecto y tiene una visión detallada, aunque puede que parcial, del modelo de negocio.

Director del proyecto

Es el responsable de la ejecución del proyecto y tiene capacidad ejecutiva para tomar decisiones sobre el mismo de acuerdo con el cliente.

Responsable de calidad

Es el responsable del aseguramiento de la calidad de los productos obtenidos durante las actividades de la ingeniería de requisitos.

Comité de control de cambios

Rol colectivo responsable de decidir si se aceptan o se rechazan las peticiones de cambios. Tanto el director del proyecto como un representante del cliente suelen formar parte de él.

Personal TIC del cliente

Es el responsable de proporcionar información sobre el entorno tecnológico del cliente.

El Problema•Si un proceso es utilizado, equipos funcionales diferentes, normalmente utilizan procesos y lenguajes de modelación inconsistentes.

Requerimientos

PruebasAnálisisDiseño

•La mayoría de los proyectos de softwareutilizan procesos que no están biendefinidos. En su lugar los miembros del equipo (re)inventan sus propios procesos.

??

??

??

?

•Los procesos no están apropiadamente relacionados con herramientas, ó no están propiamente automatizados.

?Proceso Herramienta

• Los elementos del análisis y diseño estructurado más relevantes son (algunos autores tienen distintas visiones de la cantidad de elementos y cuales son ellos):

• DFD Diagrama de Flujo de Datos• Diccionario de Datos• DE Diagrama de Estructura• Mini especificaciones

SÍMBOLOS DEL DFD(NOTACIÓN YOURDON/DE MARCO)

PProceso

Entidad Externa

D ALMACÉN DE DATOS

Flujo de eventos

Flujo de datos

Transformaciones o procesos (funciones, cálculo, selección)

Terminadores (Fuentes o Destinos)(personas, entidades)

Flujos de información(inputs-outputs)

Flujos de control (Ward & Mellor 85)

Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.)

SÍMBOLOS DEL DFD(NOTACIÓN MÉTRICA/SSADM)

Entidad Externa

D ALMACÉN DE DATOS

Flujo de datos

Transformaciones o procesos

Terminadores (Fuentes o Destinos)

Flujos de información

Ficheros o depósitos temporales de información

Localización

ProcesoID

PROCESOS• TRANSFORMACIÓN

(cálculo, operación)• FILTRO

(verificación fecha, validación transacción)• DISTRIBUCIÓN

(menú, selección transacción)

PTransformación

E2

E3

E1

S2

S1

• Nombres únicos, significativos y concisos• Preferiblemente expresados en función de las

entradas y salidas• Recomendación:

verbo (no ambiguo) + objeto• Evitar verbos ambiguos

procesar, gestionar, manejar...• “objeto” está definido en el DD

• Los procesos se descomponen en “subprocesos”, hasta llegar a los procesos primitivos

PROCESOS

DIAGRAMA DE CONTEXTO• Es el DFD más general de todos• Está formado por un solo macroproceso (el

sistema), las entidades externas (fuentes y destinos) y sus relaciones con el macroproceso

• Delimita el sistema y su entorno

ENTIDADES EXTERNASSeñalan los límites del sistema y establecen sus relaciones con el entorno

PSistema

DESTINO

DESTINO

DESTINO

FUENTE

FUENTE

FUENTE

Los identificadores (nombres) de las entidades externas serán únicos, significativos y concisos

en principio, no son materiales,

son datos

0. Sistema de

Pedidos EDITOR

libros entregados

pedidosCLIENTE

órdenes de compra

libros pedidos

DIAGRAMA DE CONTEXTO

FLUJOS DE DATOS• Los nombres de los FD deben ser únicos,

significativos y concisos• Son datos, así que nómbralos como datos.• Pueden estar indistintamente en singular o

en plural, ya que en los DFDs no se representan cantidades (Barranco 95)

• Los nombres no sirven sólo para identificar los datos, sino también la información que se tiene sobre ellos

P.ej. Información (fecha-válida) > Información (fecha)

• Los Flujos de datos pueden tener lugar:• Entre dos procesos

• Entre un Proceso y un almacén de datos

• Entre una entidad externa y un proceso

PB

PA

X

X

1.Verificar validez

de pedido

pedidos válidos

D PEDIDOS PENDIENTES

0. Sistema de

Pedidoslibros entregados

pedidosCLIENTE

FLUJOS DE DATOS• Flujos de datos interactivos (dialog flows)

• Cuando dos FD establecen un diálogo o comparten una acción de estímulo-respuesta, pueden dibujarse como un único FD de doble flecha, donde ambos extremos deben llevar el nombre del FD que representan.

PDeterminar

estado pedido respuesta estado pedido

petición estado pedido

denegacióncréditoP

AnalizarPeticióncrédito

PAceptar pago solicitud crédito

autorización crédito

recibo

pago

DESCOMPOSICIÓN FUNCIONAL

• Cada proceso se puede explotar, refinar o descomponer en un DFD más detallado

• El DFD de un sistema es realmente un conjunto de DFDs dispuestos jerárquicamente

• Los niveles de la jerarquía están determinados por la descomposición funcional de los procesos

• La raíz de la jerarquía es el “diagrama de contexto”, que es el más general de todos

DESCOMPOSICIÓN FUNCIONAL (II)

Pf5

Pf4

Pf3

Pf2

Pf1

B

Z

Y

X

W

V

A

Pf45

Pf44

Pf43

Pf42

Pf41

Z

y2

x2

y1

x1

Y

X

PSist

BA

FUENTE

DESTINO

CONSISTENCIA EN EL DFD

• Cada proceso en un diagrama “padre” es una consolidación del DFD “hijo”

• Balanceo de DFDs• Las E/S de un proceso “padre” deben corresponderse

con las E/S del DFD “hijo” que lo explica

JERARQUÍA DE DFDS• En un DFD completo cada proceso tiene un

número único que lo identifica en función de su situación en la jerarquía

• Cada DFD tiene también un número único que coincide con el proceso que describe

• Las hojas o nodos terminales corresponden a “procesos primitivos” o indescomponibles

• Para cada proceso primitivo existirá una miniespecificación.

LocalizaciónProceso Proceso primitivo en Métrica

JERARQUÍA DE DFDS (II)

P 1.2Proceso A

B

A

P 1.2.3f3

P 1.2.1f1

Y

W

V

A

XP 1.2.2

f2

DFD 1.2

JERARQUÍA DE DFDSDFD 0

• El primer diagrama general que sigue al de contexto es el número 0 por convenio

• En el DFD 0 se hace una descomposición en subsistemas, es decir, se indican los procesos más importantes en el sistema

Han de ser SUBSISTEMAS

DESCOMPOSICIÓN FUNCIONAL Y ALMACENES DE DATOS

• Los almacenes aparecen lo más tarde posible• En un nivel superior únicamente cuando son

interfaz entre procesos• Una vez que aparezca en un DFD, el almacén

aparecerá otra vez en cada DFD de nivel más bajo relacionado

DESCOMPOSICIÓN FUNCIONAL Y ALMACENES

DE DATOS (II)

PB

PA D FICH

PA.2

PA.1

D FICH

PB.2

PB.1

D FICH

IDEAS ÚTILES PARA CONSTRUIR EL DFD (II)

• Nombrar adecuadamente todos los objetos del DFD

• Numerar adecuadamente procesos y diagramas• Realizar una correcta división en subsistemas

(DFD 0)• Utilizar la descomposición funcional jerárquica

hasta alcanzar las funciones primitivas

• “Es un conjunto de metadatos, es decir, de información (datos) sobre datos”

• Contiene las definiciones de todos los elementos de los diagramas

• Implementación• Manual• Procesador de textos• Base de datos• Automático e integrado

DICCIONARIO DE DATOS

DICCIONARIO DE DATOS

• No sólo se considera un catalogo de datos del sistema sino de flujos de datos, almacenes y procesos, guardando descripciones y detalles de todos estos elementos.

• Los analistas utilizan el diccionario entre otras finalidades para:• Documentar las características del sistema• Manejar detalles en grandes sistemas• Dar un significado común para todos los elementos

del sistema• Localizar errores y omisiones• Mantenimiento del sistema

PREGUNTAS QUE SE HACEN LOS ANALISTAS SOBRE LOS DATOS…

• ¿Dónde se usa este elemento de datos?• ¿Qué mas hay que cambiar si lo modificamos?• ¿Cuál será el impacto general del cambio?

EL DICCIONARIO DE DATOS CONTIENE DOS TIPOS DE DESCRIPCIONES PARA LOS FLUJOSDE DATOS DENTRO DEL SISTEMA: Elementos de datos y estructuras de datos.•El nivel más importante de datos es el elemento dato, bloque básico e indivisible para todos los demás datos del sistema•Una estructura de datos es un grupo de datos elementales relacionados, que el sistema trata como un componente. Los flujos de datos y los almacenes de datos son estructuras de datos.•DESCRIPCION DEL ELEMENTO DATO:

• Incluye entre otras informaciones, nombre, descripción, alias o nombre alternativo, longitud y en aquellos procesos que lo necesiten valores permitidos.

• DESCRIPCION DE LAS ESTRUCTURAS DE DATOS:• Se construyen sobre cuatro relaciones de componentes , que

pueden ser a su vez elementos dato o estructuras de datos. • Incluye nombre de la estructura, descripción y el contenido

(cuales son sus datos elementales y/o estructuras)• DESCRIPCIÓN DE FLUJOS Y ALMACENES DE DATOS:

• Los flujos y almacenes de datos son estructuras de datos, una estaticas y otras dinámicas. Su descripción se hace en base a esto, añadiendo otras características relevantes.

• Para el flujo: nombre del flujo, descripción, viene de los procesos, va hacia los procesos, estructuras de datos.

• Para el almacén: nombre del almacén , descripción, flujos recibidos, flujos proporcionados, descripción de datos, tipo de acceso

• DESCRIPCIÓN DE PROCESOS:• Se hace en base al resto de los componentes, en el momento en

que se pueden considerarse como primitivas funcionales.• Nombre del proceso, descripción, entrada de datos, salida de

datos, resumen de la lógica.

NOTACIÓN UTILIZADA PARA LA DESCRIPCIÓN

Construcción de datos

Notación Significado

Agregación = Está compuesto de

Secuencia + y

Selección [ I ] Uno u otro

Repetición { } “( )

*…..*

N repeticiones deDatos opcionalesDelimitadores de comentarios

NOTACIÓN..

• Permite representar una composición de datos en una de las tres alternativas fundamentales que pueden ser construidas:• Como una secuencia de elementos de datos.• Como una selección de entre un conjunto de

elementos de datos.• Como una agrupación repetitiva de elementos

de datos.

EJEMPLO:

• Nombre: número de teléfono• Alias: Fono• Donde se usa/cómo se usa:

• Comprobar con ajustes iniciales (salida)• Marcar número (entrada)

• Descripción:• número de teléfono = prefijo + número acceso.• Prefijo= [*un número de cuatro dígitos que comience en

0 ó un número de cinco dígitos que comience por ()]• Número de acceso= *secuencia numérica de cualquier

tamaño*

Flujo de datos: entregaDescripción: Conjunto de libros enviados por un proveedor a la biblioteca, basado en la relación que previamente había recibido.

Sinónimos: *** none ***Componente de: *** none ***Composición:Libros+ { Albarán }

Información de entrada y salidaOrigen Destino*** Off the diagram *** Compra librosPROVEEDORES Biblioteca

DICCIONARIO DE DATOS

DICCIONARIO DE DATOS

Almacen: FacturasDescripción: Información, por número de factura, sobre facturas en el sistema actual.

Sinónimos: *** none ***Composición:

@Número-factura+ Fecha-factura+ Dirección-cliente+ { Número-producto+ Cantidad-producto+ Costo-unidad-producto }+ Costo-envío+ Tasa-de-descuento+ Neto-factura+ Estado-factura

Procesos asociados: Según DFD generalProc_cancelación Proc_pagoProc_consultas Adjuntar_albarán

Proceso: Verificar estado del socioNúmero: 1.1.1 Descripción: Se examina si el socio no está sancionadoMiniespecificación:

Recibir “Socio ID” del socioLeer “SOCIOS” paraLeer “Flag-de-precaución”

Si OK, enviar “Socio ID válido”

Complejidad: Prioridad:Ratio de transacciones: Memoria requerida (Kb):

Tiempo de proceso:

DICCIONARIO DE DATOS PROCESO :PSEUDOCÓDIGO.

• Técnicas para describir la lógica de los procesos primitivos• Lenguaje estructurado• Pre y post-condiciones• Tablas de decisión• Árboles de decisión

• Son una descripción detallada de los procesos asociados al DFD de último nivel

LÓGICA DE PROCESO. MINI ESPECIFICACIONES

• Se debe evitar:• Descripciones confusas• Ambiguedades• Exceso de papel• Especificaciones pobres o sobreespecificaciones

• Debe contar con:• Claridad• Concisa y completa• Lógica y no física• Debe especificar el Qué y no el Cómo• Relación armónica con los demás objetos del

diseño estructurado

• Lenguaje estructurado• SI la factura excede de 300€

• SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días, dejar la confirmación pendiente de este pago.

• SI NO (la cuenta está en buen estado) hacer confirmación y factura

• SI NO (la factura es de 300€ o menos)• SI la cuenta del cliente tiene alguna factura sin pagar

más de 60 días hacer la confirmación, la factura y escribir un mensaje sobre informe de crédito

• SI NO (la cuenta está en buen estado)hacer confirmación y factura

• FIN-SI.

• Pre y post-condicionesPre1 (la factura excede de 300€) Y (la cuenta del cliente tiene

alguna factura sin pagar más de 60 días)Pos1 (confirmación pendiente de este pago)

Pre2 (la factura excede de 300€) o (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días)

Pos2 (confirmación y factura realizadas)

Pre3 (la factura no excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días)

Pos3 (confirmación y factura realizadas) Y (mensaje impreso sobre informe de crédito)

Pre4 (la factura no excede de 300€) Y (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días)

Pos4 (confirmación y factura realizadas)

ESTADO DE LA CUENTA

CORRECTO IMPAGADO CORRECTO IMPAGADO

NETO-FACTURA >300€ >300€ <=300€ <=300€

CONFIRMACIÓN PENDIENTE

x

HACER CONFIRMACIÓN

x x x

HACER FACTURA

x x x

ESCRIBIR MENSAJE x

Tablas de decisión

Árboles de decisión

Política contabl

e

Factura excede de 300€

Factura menos de 300€

Cuentas impagadas más de 60 días

Cuentas en buen estado

Cuentas impagadas más de 60 días

Cuentas en buen estado

1. Dejar confirmación pendiente de los pagos debidos.

2. Hacer confirmación y factura

3. Hacer confirmación y factura y escribir mensaje sobre informe de crédito

4. Hacer confirmación y factura

Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo.

Sistema de distribución sin inventario“Se trata de un sistema que sirve pedidos de libros a unos clientes, con la particularidad de que no mantiene un stock o inventario interno. El sistema puede agrupar los pedidos que clientes distintos hacen a un mismo editor, de manera que se puedan conseguir descuentos.”

Ejemplo DFD

Diagrama de contexto

Análisis de los procesos del sistema

en principio, no son materiales,

son datos

0. Sistema de

Pedidos EDITOR

libros entregados

pedidosCLIENTE

órdenes de compra

libros pedidos

Aplicamos la visión sistémica

0. Sistema de pedidos

1.Verificar validez

de pedido

pedidos

2.Armar pedidos

a editores

pedidos en lote

3.Verificar

envíode editores

libros pedidos4.

Asignar libros a pedidos

5.Armar entrega

a clientes

pedidos por título

libros recibidos

libros por clientes

D CLIENTES

estado del crédito

dirección

D LIBROS

libros entregados

libros entregados = albarán + lista-

novedades

DD

DD

libros recibidos = {título + cantidad}

pedidos válidos

D PEDIDOS PENDIENTES

órdenes de compra

D ÓRDENES DE COMPRA

EJEMPLO PRÁCTICO