IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos

Ingeniería de requerimientos Carrera de Software
Ph.D. Franklin Parrales 1
22/06/2021
Introducción y proceso de
Ingeniería de requerimientos
Unidad 1
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Ingeniería de Requerimientos

22/06/2021
Objetivo general de la Unidad 1
Caracterizar las actividades involucradas en el
descubrimiento, documentación y mantenimiento
de los requerimientos de un producto determinado
conociendo de forma precisa el problema que van
a resolver para que la solución que se construya
sea correcta y útil.

22/06/2021
Lección 1
La Ingeniería de
requerimientos - IDR
Unidad 1

22/06/2021
Contenido
• La Ingeniería de requerimientos – IDR
– Definición de la IDR
– Importancia de la IDR
– Actividades de la IDR

22/06/2021
Visión global
n Primera fase del ciclo de vida del
software en la que se produce una
especificación a partir de ideas
informales
n Deben obtenerse y documentarse
n Los requisitos de información
n Los requisitos funcionales
n Los requisitos no funcionales
n Los criterios para medir el grado de su consecución
n El proceso de desarrollo de dicha especificación de requisitos es lo que se
conoce como ingeniería de requisitos
n Importancia creciente de
n El correcto entendimiento (obtención), documentación (especificación) y
validación de las necesidades de los usuarios y clientes
n La medida de la calidad de los sistemas en función del grado de satisfacción
de los usuarios
Ingeniería de
Requisitos
Resto del
ciclo de vida

22/06/2021
Definición (i)
n Todas las actividades relacionadas con: (a) identificación y
documentación de las necesidades de clientes y usuarios; (b) creación de
un documento que describe la conducta externa y las restricciones
asociadas [de un sistema] que satisfará dichas necesidades; (c) análisis y
validación del documento de requisitos para asegurar consistencia,
compleción y viabilidad; (d) evolución de las necesidades [Hsia et al.,
1993]
n … el uso sistemático de procedimientos técnicas, lenguajes y
herramientas para obtener con un coste reducido el análisis,
documentación, evolución continua de las necesidades del usuario y la
especificación del comportamiento externo de un sistema que satisfaga
las necesidades del usuario. Téngase en cuenta que todas las disciplinas
de la ingeniería son semejantes, la ingeniería de requisitos no se guía por
conductas esporádicas, aleatorias o por modas pasajeras, si no que se
debe basar en el uso sistemático de aproximaciones contrastadas [Reifer,
1994]

22/06/2021
Definición (ii)
n Aplicación disciplinada de principios científicos y técnicas para desarrollar,
comunicar y gestionar requisitos [Christel y Kang 1992]
n El proceso sistemático de desarrollar requisitos mediante un proceso
iterativo y cooperativo de analizar el problema, documentar las
observaciones resultantes en varios formatos de representación y
comprobar la precisión del conocimiento obtenido [Christel y Kang 1992]
n Un proceso sistemático de desarrollo de requisitos mediante un proceso
cooperativo consistente en analizar el problema, documentar las
observaciones resultantes en una variedad de formatos de
representación, y comprobar la exactitud de la comprensión conseguida
[Loucopoulus y Karakostas, 1995]
n Un proceso de descubrimiento y comunicación de las necesidades de
clientes y usuarios y la gestión de los cambios en dichas necesidades
[Durán, 2000]

22/06/2021
Ingeniería de Requerimientos
El proceso de establecer los servicios que el
cliente requiere de un sistema y los limites
bajo los cuales opera y se desarrolla
[Sommerville]

22/06/2021
Contenido

22/06/2021
Importancia
• Uno de los principales problemas al que nos
enfrentamos como ingenieros de software en
el desarrollo de sistemas es la ingeniería de
requisitos.
• De esta fase depende el éxito del producto
de software.
– Si hay algún error en esta fase el resto de fases
del ciclo de vida también se verán afectados, y
por ende…
– El resultado es un producto de software que no
cumple con las necesidades de los
stakeholders.

22/06/2021
Stakeholders
• Es el público de interés para una
empresa que permite su
completo funcionamiento.
• Como público, se refiere a todas
las personas u organizaciones
que se relacionan con las
actividades y decisiones de una
empresa como:
– empleados, proveedores,
clientes, gobierno, entre otros.
Los stakeholders son aquellas personas o entidades
que tienen algún impacto o interés en este sistema.

22/06/2021
Stakeholders

22/06/2021
Importancia
• Para entregar un producto de software con
éxito, Ud. necesita desarrollar, documentar y
validar los requisitos de software.
• Los requisitos bien entendidos son la base
para determinar el éxito del software
implementado, lo cual permite satisfacer las
necesidades de los usuarios.
– Dichas necesidades son las que se definen en
los requisitos.

22/06/2021
Importancia
• El no definir los requisitos correctamente tiene un
precio bastante alto ya que se ocasionan
requisitos mal definidos (incompletos, incorrectos
o requisitos contradictorios)
• Estos errores pueden causar:
– Sobrecosto
– Reproceso costoso
– Mala calidad
– Retraso en la entrega
– Clientes descontentos
– Miembros de equipo agotados y desmoralizados

22/06/2021
Motivación

22/06/2021
Importancia
• Entender la naturaleza de un problema por lo
general es algo difícil → es difícil establecer
que debe hacer un sistema software
• La descripción de los servicios y restricciones
son los requisitos del sistema
• La ingeniería de requisitos es el proceso que
permite identificar dichos requisitos
• Como otras actividades de Ing. de Sw, ésta
debe adaptarse a las necesidades del
proceso, proyecto, producto y gente que
hace el software.

22/06/2021
Importancia *
• La Ing. de Requerimientos provee de un
mecanismo apropiado para:
– entender que quiere el consumidor,
– analizar sus necesidades,
– valorar la factibilidad de construcción,
– negociar una solución razonable,
– especificar de manera no ambigua una solución,
– validar la especificación y
– administrar los requerimientos conforme se
transforman.
*Referencia: capítulo 7 libro de texto (Pressman 2005)

22/06/2021
Motivación
• Se ha hecho muy evidente que una
especificación deficiente de los requisitos del
software puede conducir a proyectos fallidos,
de allí que esta disciplina cada vez adquiera
mayor importancia.
• El curso de Ingeniería de requisitos esta
diseñado para enseñarte a identificar y
analizar requisitos de manera integral, con el
cual garantizaras la elaboración de
especificaciones funcionales de calidad.

22/06/2021
Contenido

22/06/2021
Actividades de la Ing. de
Requerimientos

22/06/2021
Proceso de los Requerimientos
Obtención Análisis Validación
Administración de los Requisitos
Línea
Base
de
Requerimientos
Línea base actual
Línea base corregida
Planificación
Administración
del Cambio
Cambios en
requerimientos
Cambios
en el proyecto
Planifica-
ción Verificación
Trazabilidad
Especifica-
ción

22/06/2021
Actividades de la Ing. de
Requerimientos
– Iniciación (Inception)
– Obtención (Elicitation)
– Elaboración
– Negociación
– Especificación
– Validación (Validation)
– Administración
• Algunas de estas funciones pueden ocurrir en paralelo y
ajustarse a las necesidades del proyecto

22/06/2021
Iniciación
• Como se empieza un proyecto? Algunas veces inicia por
conversaciones informales, otras de manera mas formal;
normalmente como resultado de una necesidad
importante
• En esta parte, los ingenieros de software realizan
preguntas “libres de contexto” (generales), para
establecer un entendimiento básico del problema,
determinar las personas que quieren una solución, la
naturaleza de la solución, y la efectividad de las
colaboraciones y comunicaciones preeliminares que se
generan entre el consumidor y el desarrollador

22/06/2021
Obtención de Requerimientos
• Se refiere a definir formalmente los requerimientos de la
solución. Es difícil porque como ya se ha visto:
– Hay problemas de definición de alcances
– Hay problemas de entendimiento entre los involucrados
– Hay problemas de volatilidad (los requerimientos cambian
con el tiempo)

22/06/2021
Elaboración
• Esta actividad expande y refina la información obtenida en la
tarea de iniciación
• Se enfoca en realizar modelos técnicos refinados de las
funciones del software, características y limitantes.
• Es básicamente una función de modelado. Se conduce a
través de la definición de escenarios del usuario que
describen la interacción del usuario final con el sistema
• Se define el dominio del problema desde varios puntos de
vista: información, funciones y comportamiento

22/06/2021
Negociación
• Los usuarios y consumidores normalmente piden mas
de lo que se puede hacer con los recursos con que se
cuenta.
• Casi siempre diferentes involucrados (stakeholders)
piden cosas diferentes, por lo que hay que conciliar
intereses a través de negociaciones.
• Hay varias maneras para negociar, y depende de la
cultura de la organización y tamaño del proyecto

22/06/2021
Especificación
• Especificación significa diferentes cosas para diferentes
personas en el área de Ing. de software.
• Este es el producto de trabajo final de la ingeniería de
requerimientos.
• Sirve como base para actividades subsecuentes.
• Describe la función y desempeño de un sistema y las
restricción que tiene.
• Hay muchas técnicas para escribir especificaciones:
diagramas, narraciones en prosa, modelos matemáticos,
dibujos, etc.

22/06/2021
Validación
• El producto generado por la ingeniería de
requerimientos debe ser evaluado en términos de
congruencia y calidad. Se debe asegurar que la
especificación concuerda con las expectativas del
usuario y que no es ambigua.
• Deben detectarse y corregirse errores, omisiones e
inconsistencias con respecto a los estándares
establecidos en el proyecto.
• El mecanismo común de validación es la revisión técnica
formal.

22/06/2021
Administración de requerimientos
• Actividades que ayudan al equipo de trabajo a identificar, controlar y
seguir los requerimientos y cambios que ocurren en ellos a través
de todo el proceso de desarrollo.
• La administración empieza con la identificación de cada
requerimiento. Posteriormente se generan tablas que permitirán
darles seguimiento. Algunas de éstas son:
– Tablas de características
– Tablas de fuentes
– Tablas de dependencias
– Tablas de subsistemas
– Tablas de interfaces

22/06/2021
Lección 2
Requerimientos
Unidad 1

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
– Características
– Dificultades para definir requerimientos
– Formas de documentar los requerimientos
– Lenguajes y modelos para representar los
requerimientos

22/06/2021
Requerimiento ( = requisito)
• Atributo necesario de un
sistema
• Un enunciado que identifica
una capacidad, una
característica, un factor de
calidad del sistema para
lograr la utilidad y valor
esperados por el usuario o
cliente.

22/06/2021
¿Qué es un Requerimiento?
• Es un rango de instrucciones abstractas de alto
nivel de un servicio o de un sistema, limitado a
detallar una especificación funcional matemática.
• Así es inevitable como los Requerimientos pueden
servir en una función dual
– Puede ser la base para una declaración de un
contrato, por lo tanto, deber estar abierto a
interpretación.
– Puede ser la base para el contrato en sí, por lo tanto,
debe ser definido en detalle.
– Ambas declaraciones serán llamadas
Requerimientos.

22/06/2021
Requisitos vs. Diseño
• Requisitos definen el Qué (el problema) del
sistema
• El Diseño define el Cómo (la solución)

22/06/2021
Requisitos y diseño
• En principio, los requisitos deben indicar lo qué el
sistema debe hacer y el diseño debe describir
cómo lo debe hacer
• En la práctica, es prácticamente imposible excluir
toda la información de diseño al especificar en un
nivel adecuado los requisitos de software.
– La arquitectura del sistema puede ser diseñada para
estructurar los requisitos.
– El sistema puede interactuar con otros sistemas que
generan requisitos de diseño.
– El uso de una arquitectura especifica para satisfacer
los requisitos no funcionales puede ser un requisito.

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos

22/06/2021
Importancia
• El establecer requerimientos está
relacionado con las actividades del cliente
para el Software.
• Los errores en los requerimientos son
usualmente muy caros de corregir una vez
desarrollado el sistema.
• La revisión de requerimientos debe involucrar
al cliente y al staff de contratistas para validar
los requerimientos del sistema.

22/06/2021
Costos de errores en los requisitos
• Costo de corregir un error en los requisitos
(Boehm-Papaccio,1988)

22/06/2021
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.

22/06/2021
Importancia
• Por estas razones los requerimientos
deben tener las siguientes características:
– 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.

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos

22/06/2021
Requisitos - Abstracción
• La forma de un requisito puede variar
desde una oración con un alto nivel de
abstracción hasta una especificación
funcional matemática.
• Posibles contextos de un requisito:
– Puede ser la base de una oferta para un
contrato— por lo tanto debe estar abierto a la
interpretación.
– Puede ser la base para un contrato— por lo
tanto debe ser definido detalladamente.

22/06/2021
Tipos de requisitos - Abstracción
• Requisitos de usuario
– Son declaraciones en lenguaje natural, además
de diagramas de los servicios que proporciona el
sistema y sus limitaciones operativas. Escritos
para los clientes.
• Requisitos del sistema
– Un documento estructurado que establece
descripciones detalladas de las funciones,
servicios y restricciones operacionales del
sistema. Define lo que se debe implementar,
podría ser parte de un contrato entre el cliente y
el empresario.

22/06/2021
Tipos de requisitos - Abstracción
• Es necesario escribir los requisitos utilizando
diferentes niveles de abstracción porque
diferentes lectores los usan de diferente
forma.
Requerimientos
del usuario
Gerentes del cliente
Usuarios finales del sistema
Ingenieros del cliente
Gerentes de los contratistas
Arquitectos del sistema
Requerimientos
del sistema
Usuarios finales del sistema
Ingenieros del cliente
Arquitectos del sistema
Desarrolladores de software

22/06/2021
Otros tipos de información de requisitos
• Requisitos del dominio
– Se derivan del dominio de aplicación del sistema y no de
las necesidades específicas de los usuarios.
• Requisitos del negocio
– Un objetivo de alto nivel de una organización que
desarrolla un producto o de un cliente que lo compra.
• Regla de negocio
– Una política, guía, estándar o regulación que define o
restringe algún aspecto del negocio.
• Requisito de interfaz externa
– Una descripción de una conexión entre un sistema de
software y un usuario, otro sistema de software o un
dispositivo de hardware.

22/06/2021
Otros tipos de información de requisitos
• Característica (feature)
– Una o más capacidades relacionadas de forma lógicas
que proveen valor al usuario y son descriptas como un
conjunto de requisitos funcionales. Ejemplo: los favoritos
del navegador.
• Requisito funcional
– Una descripción de lo que el sistema debe hacer bajo
condiciones específicas.
• Requisitos no funcionales
– Una descripción de una propiedad o característica que un
sistema debe poseer o una restricción que debe respetar.
• Atributo de calidad
– Un tipo de requisito no funcional que describe una
característica de servicio o desempeño de un producto.

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos

22/06/2021
División
• Podemos identificar dos divisiones de
requisitos:
- Requisitos de usuario.
- Requisitos de sistema.

22/06/2021
Requisitos de Usuario
• Los requisitos de usuario son frases en
lenguajes natural junto a diagramas de los
servicios que el sistema debe proporcionar,
así como las restricciones bajo las que debe
operar
• Según Sommeville, 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

22/06/2021
Requisitos de sistema
• Los requisitos de sistema determinan los
servicios del sistema y las restricciones en
detalle. Sirven como contrato.
• Según Sommeville:
– Establecen con detalle los servicios y
restricciones del sistema.
– El documento de requerimientos del sistema,
algunas veces denominado especificación
funcional, debe ser preciso

22/06/2021
Reqs. Usuario vs Reqs. De sistema
• En conclusión, son los mismo, pero a
distinto nivel de detalle
– e.g. req. usuario: el sistema debe hacer
préstamos
– e.g. reg. sistema: función préstamo; entrada:
cód. socio, cód. ejemplar; salida: fecha
devolución; ......

22/06/2021
Ejemplos
• El sistema debe permitir al usuario introducir
los datos de los estudiantes nuevos.
– Requisito de usuario expresado en términos
generales. ¿Qué servicio debe prestar el
sistema?
• El sistema debe permitir a los usuarios
buscar el producto por nombre, número de
factura, código de barras.
– Requisito del sistema: Que define una parte de
funcionalidad del sistema.

22/06/2021
Otra división: Stated vs Real
requirements
• Stated requirements (requisitos manifestados):
– Son proporcionados por el usuario/cliente al inicio
del desarrollo de un sistema/software.
• Real requirements(requisitos reales):
– Reflejan las necesidades reales del sistema.
– Algunos requerimientos reales son omitidos por el
usuario /cliente cuando estos son expresados al
inicio (stated requirements).
– El reto consiste en identificar estos requisitos
reales.

22/06/2021
Requisitos de sistema
• Hay tres tipos de requisitos de sistema:
– Requisitos funcionales
– Requisitos no funcionales
– Requisitos del dominio.

22/06/2021
Requisitos
funcionales

22/06/2021
Requerimientos funcionales
• Son declaraciones de los servicios que el sistema
debería proveer, cómo el sistema debería reaccionar
a entradas particulares y cómo debería comportarse
en situaciones particulares.
• Expresan la naturaleza del funcionamiento del sistema
(cómo interacciona el sistema con su entorno y cuáles
van a ser su estado y funcionamiento).
– NOTA: A veces, también es conveniente indicar lo que no
hará el sistema.
• Ejemplos:
– Un usuario podrá buscar en las listas de citas de todas las
clínicas.
– El sistema deberá generar cada día para cada clínica una
lista de pacientes que se espera asistan a la cita durante
ese día.

22/06/2021
Los requerimiento Funcionales definen:
Ejemplos de requerimientos funcionales:
Ejemplos para el sistema de control de maletas
• El sistema debe manejar hasta 20 maletas por segundo
• Si el suministro de corriente falla, el sistema debe apagarse de manera
ordenada en menos de 5 segundo.
• Cada usuario del sistema debe identificarse de manera única utilizando su
numero de empleado de 8 dígitos.
Cuáles entradas debe aceptar el sistema
Cuáles salidas debe producir el sistema
Qué datos debe almacenar el sistema que utilizarán otros sistemas
Qué operaciones debe realizar el sistema
La sincronización y cronometraje de las actividades anteriores.

22/06/2021
Falta de precisión en los requisitos
• La falta de precisión en los requisitos es la causa
de muchos problemas en la ingeniería de software.
• Los requisitos ambiguos pueden ser interpretados de
diferentes maneras por desarrolladores y usuarios.
Ejemplo:
– Un usuario podrá buscar en las listas de citas de todas las
clínicas.
Búsqueda dentro de
cada clínica por vez
Búsqueda dentro de
todas las clínicas a
la vez
Búsqueda por
nombre y apellido
Búsqueda por hora
de la cita

22/06/2021
Requisitos
funcionales
Ejemplos

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

22/06/2021
• De interfaz gráfica:
– La solución validará automáticamente el cliente asociado
a una orden con el sistema de gestión de contactos.
– El campo de monto aceptará únicamente valores
numéricos con dos decimales.
– El campo fecha de transacción aceptará únicamente
fechas anteriores al día de hoy (día actual).
– El campo nombre aceptará caracteres alfabéticos
únicamente.
– El campo dirección aceptará 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.

22/06/2021
• Legales o regulatorios:
– El sistema controlará el acceso y lo permitirá
solamente a usuarios autorizados.
– La base de datos será implementada con trazas de
auditoría.
– Las hojas de cálculo asegurarán 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.

22/06/2021
• De seguridad:
– El sistema controlará el acceso y lo permitirá solamente a
usuarios autorizados. Los usuarios deben ingresar al
sistema con un nombre de usuario y contraseña.
– El sistema enviará una alerta al administrador del sistema
cuando ocurra alguno de los siguientes eventos: Registro
de nueva cuenta, ingreso al sistema por parte del cliente,
2 o más intentos fallidos en el ingreso de la contraseña de
usuario y cambio de contraseña de usuario.
– Los integrantes del grupo de usuarios de analistas pueden
ingresar solicitudes pero no pueden aprobarlas o
borrarlas.
– Los integrantes del grupo de usuarios de gerentes pueden
ingresar y aprobar solicitudes, pero no pueden borrarlas.

22/06/2021
Requisitos NO
funcionales

22/06/2021
Requerimientos NO funcionales
• Son restricciones a los servicios o funciones
provistas por el sistema, como restricciones de
tiempo, restricciones sobre el proceso de
desarrollo, estándares, etc.
• Generalmente son aplicables al sistema entero y
no a servicios o funciones en particular
• Por lo general:
– El Plan para implementar los requerimientos no
funcionales se detalla en la Arquitectura del
Sistema.
– El de los requerimientos funcionales se especifica
en el Diseño.

22/06/2021
Requerimientos NO funcionales
• Los requerimientos no funcionales:
– Definen las características o cualidades generales
que se esperan de un sistema
– Establecen restricciones sobre el producto, el
proceso de desarrollo de software
– Establecen restricciones externas que el software
debe lograr

22/06/2021
Necesidad de definir los requerimientos no funcionales en
términos precisos y que puedan medirse
• Para todo proyecto de TI, es crítico que los requerimientos no
funcionales sean definidos con los usuarios, clientes y otros
interesados en términos precisos y medibles en la etapa de análisis
del proyecto. No hacerlo puede poner en riesgo el éxito de un proyecto.
– Por ejemplo, tomando el caso de los tiempos de respuesta de un sistema, lo cual
podría clasificarse en disponibilidad, ¿que sucedería si no se definiera el tiempo de
respuesta deseado en la fase de análisis de requerimientos?, o si se definiera en
términos imprecisos, como por ejemplo indicado, "Se necesita un tiempo de
respuesta aceptable".
– Al llegar a la fase de implementación, quizás en sistema tendría un tiempo de
respuesta, digamos de 15 segundos(debido a muchas plataformas remotas y bases
de datos involucradas), pero el usuario lo necesitaba en menos de 5 segundos, para
por ejemplo, evitar que se forme una fila muy larga para atender a clientes.
– Errores como esto pudieran ocasionar inclusive que el usuario final decidiera no usar
el nuevo sistema, haciendo fracasar el proyecto.
– Por ende, es importante definir los requerimientos con métricas que puedan
establecer sin lugar a duda que el sistema o servicio de TI desarrollado cumple los
parámetros no funcionales solicitados.

22/06/2021
Requerimientos NO funcionales y
requerimientos 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.
– Por ejemplo: El sistema debe asegurar que los datos estén protegidos del
acceso no autorizado
• Es recomendable acompañar las definiciones de requerimientos NO
funcionales con criterios de aceptación que puedan medirse.
• 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.

22/06/2021
Categorías en las que pueden clasificarse
los requerimientos NO funcionales
• Se pueden clasificar en dos categorías:
– Cualidades observables en tiempo de ejecución
• Por ejemplo: la usabilidad y la seguridad.
– Cualidades relacionadas con la evolución del
sistema
• Por ejemplo: Mantenibilidad, Comprobabilidad,
Extensibilidad y Escalabilidad, las cuales están
inmersas en la estructura del sistema de software.

22/06/2021
Clasificación de requerimientos NO
funcionales
• Importancia de clasificar los requerimientos no
funcionales
– El especificar requerimientos no funcionales de forma
incompleta o inexacta puede ocasionar el fracaso de
tu proyecto de ingeniería de software.
– De hecho no gestionar los requerimientos no
funcionales es uno de los errores clásicos en la
gestión de desarrollo de software (definida por Steve
McConnell).
– Lograr clasificar adecuadamente cada requerimiento
no funcional identificado es muy importante para
garantizar este proceso.

22/06/2021
Algunas recomendaciones para determinarlos
Propiedad Medida
Rapidez
Transacciones procesadas por segundo
Tiempo de respuesta al usuario y a eventos
Tiempo de actualizacion de la pantalla
Tamaño
K Bytes
Numero de chips de RAM
Facilidad de Uso
Tiempo de entrenamiento
Número de pantallas de ayuda
Fiabilidad
Número promedio entre fallos
Probabilidad de no disponibilidad
Tasa de Ocurrencia de fallos
Disponibilidad
Robustez
Tiempo de reinicio entre fallos
Porcentaje de eventos que provocan fallos
Probabilidad de corrupcion de los datos
despues de fallos
Portabilidad
Porcentaje de declaraciones dependientes
de objetivos
Número de sistemas objetivo

22/06/2021
funcionales
• Existen diversas fuentes o marcos de referencia
para clasificar los requerimientos no funcionales,
de hecho, existe un estándar de la IEEE, Std 830
– 1993 que establece 13 tipos de requerimientos
no funcionales que deberían incluirse en toda
especificación de software.
• Otro modelo es el propuesto por Jacobson (1999)
para el Unified Process.
• Uno de los modelos más difundidos es el
establecido por Somerville, éste será el que
usaremos en este curso.

22/06/2021
funcionales (Sommerville)
• Del Producto: Especifican restricciones al comportamiento
del producto.
– Ejemplos: desempeño, confiabilidad, portabilidad, usabilidad
• De la Organización: Se derivan de las políticas y
procedimientos existentes en la organización del cliente y en
la del desarrollador.
– Ejemplos: estándares, lenguajes de programación, método de
diseño
• Externos: Se derivan de factores externos, como:
– Interoperabilidad: con otros sistemas
– Legislativos: privacidad, seguridad
– Éticos: dependen del contexto, las personas, etc

22/06/2021
Requerimientos de Producto
▪ Eficiencia
– Desempeño (Ejemplo: Numero de maletas por minuto)
– Espacio (Ejemplo: Mínima cantidad de memoria requerida)
▪ Fiabilidad (tiempo mínimo antes de primera falla)
▪ Portabilidad (Puede usarse con otro S.O o con otro HW?)
▪ Usabilidad (Tiempo de entrenamiento requerido)
Requerimientos Organizacionales
▪Entrega (ejemplo: Fecha de entrega, fecha cuando
estará operacional, sesiones de entrenamiento,
actualizaciones)
▪ Implementación
▪ Estándares
Requerimientos Externos
▪Interoperabilidad (Ejemplo: Comunicación con otro
equipo).
▪ Éticos (Ejem: Seguridad para los operadores)
▪ Legislativos (Ejem: Reglas de privacidad)

22/06/2021
Requerimientos
de rendimiento
Requerimientos
de espacio
Requerimientos
de usabilidad
Requerimientos
de eficiencia
Requerimientos
de confiabilidad
Requerimientos
de seguridad
Requerimientos
regulatorios
Requerimientos
éticos
Requerimientos
legales
Requerimientos
operacionales
Requerimientos
de desarrollo
Requerimientos
ambientales
Requerimientos
protección/seguridad
Requerimientos
contables
Requerimientos
del producto
Requerimientos
de la organización
Requerimientos
externos
Requerimientos
no funcionales

22/06/2021
Requerimientos NO funcionales del Producto
• Suele referirse a limites o restricciones sobre el
comportamiento del sistema, por lo cual establece límites y
restricciones sobre lo que los diseñadores (arquitectos de
software) e ingenieros de software pueden hacer.
• Algunos de estos requerimientos pueden ser fáciles de
cuantificar, por ejemplo el desempeño y la confiabilidad, pero
otros son más difíciles como por ejemplo usabilidad y
adaptabilidad.
• Se clasifican en:
– Requerimientos de usabilidad: La usabilidad se define como
el esfuerzo que necesita hacer un usuario para aprender, usar,
ingresar datos e interpretar los resultados obtenidos de un
software de aplicación. En tiempos recientes, la usabilidad ha
adquirido mucha importancia, en especial ante la demanda
de desarrollo de software para móviles y tabletas.

22/06/2021
– Requerimientos de eficiencia: Relacionado con desempeño
en cuanto a tiempo de respuesta, número de operaciones por
segundo, entre otras mediciones, así como consumo de
recursos de memoria, procesador, espacio en disco o red.
– Requerimientos de dependibilidad: Engloba varios atributos
• Disponibilidad: Disposición del sistema para prestar servicio
correctamente.
• Confiabilidad: Continuidad del servicio prestado por el sistema.
• Seguridad industrial: Ausencia de consecuencias catastróficas para
el usuario o el ambiente.
• Integridad: Ausencia de alteraciones inadecuadas al sistema.
• Mantenibilidad: Posibilidad de realizar modificaciones o reparaciones
a un proceso sin afectar la continuidad del servicio.
– Requerimientos de seguridad: Capacidades funcionales o no
funcionales que debe tener un sistema para cumplir atributos en
el área de seguridad de tecnología de información, seguridad de
datos, seguridad lógica, control de acceso a información
(restricciones de acceso), autenticidad de la información,
privacidad, entre otros aspectos.

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

22/06/2021
Requerimientos
de rendimiento
Requerimientos
de espacio
Requerimientos
de usabilidad
Requerimientos
de eficiencia
Requerimientos
de confiabilidad
Requerimientos
de seguridad
Requerimientos
regulatorios
Requerimientos
éticos
Requerimientos
legales
Requerimientos
operacionales
Requerimientos
de desarrollo
Requerimientos
ambientales
Requerimientos
Requerimientos
contables
Requerimientos
del producto
Requerimientos
de la organización
Requerimientos
externos
Requerimientos
no funcionales

22/06/2021
Requerimientos NO funcionales de organización
• Se derivan de las políticas y procedimientos de la
organización como por ejemplo estándares de procesos o
requerimientos de implementación.
• Pueden incluir:
– metodologías de desarrollo de software,
– estándares de programación (codificación) y
– herramientas de soporte al desarrollo de software (por ej.
Herramientas CASE) que deben usarse (siguiendo las políticas
de la organización),
– también reportes a la gerencia que deben proveerse, entre
otros.
• Las herramientas para la gestión de desarrollo de
software que conocemos, se definen como requerimientos no
funcionales organizacionales.

22/06/2021
• Los requerimientos organizacionales pueden
clasificarse en:
– Requerimientos de entorno: Describen el ambiente
operativo en el que se debe desenvolver el sistema.
– Requerimientos operacionales: Procedimientos
operativos que describen como será usado el sistema
dentro del contexto de la organización.
– Requerimientos de desarrollo: Lenguaje de
programación a usar, estándares de codificación, patrones
(y antipatrones) de diseño y programación, herramientas
para gestionar el desarrollo de software, entorno de
desarrollo de software (ambiente de desarrollo), entorno
de pruebas de software (ambiente de pruebas), entre
otros aspectos.

22/06/2021
• Uno de los aspectos que se documentan como
requerimientos funcionales organizacionales son los
entorno, específicamente los procedimientos de
mantenimiento y administración del ambiente de
desarrollo de software.
• Esta administración también incluye los procedimientos
para gestionar los ambientes de pruebas integrales.

22/06/2021
Requerimientos
de rendimiento
Requerimientos
de espacio
Requerimientos
de usabilidad
Requerimientos
de eficiencia
Requerimientos
de confiabilidad
Requerimientos
de seguridad
Requerimientos
regulatorios
Requerimientos
éticos
Requerimientos
legales
Requerimientos
operacionales
Requerimientos
de desarrollo
Requerimientos
ambientales
Requerimientos
Requerimientos
contables
Requerimientos
del producto
Requerimientos
de la organización
Requerimientos
externos
Requerimientos
no funcionales

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

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

22/06/2021
Requisitos NO
funcionales
Ejemplos

22/06/2021
Ejemplos de requerimientos NO funcionales
de producto
• De 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.

22/06/2021
de producto
• De 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.

22/06/2021
de producto
• De 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).
• De 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.

22/06/2021
de producto
• De 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.

22/06/2021
de producto
• 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.

22/06/2021
de organización
• 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.

22/06/2021
de organización
• 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.

22/06/2021
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.

22/06/2021
Requisitos del
dominio

22/06/2021
Requerimientos del Dominio
• Estos requerimientos se derivan del dominio de aplicación del sistema mas que de
las necesidades especificas del usuario.
• Incluyen terminología especializada del dominio o referencias a conceptos del
dominio.
• Pueden ser:
-Requerimientos funcionales nuevos,
-Restringir los existentes o
-Establecer como se deben ejecutar cálculos particulares.
• Si no se satisfacen puede ser que el sistema no funcione adecuadamente.
Para redactarlos se requieren conocimientos
especializados del dominio

22/06/2021
Requisitos del dominio
• Las reglas del negocio son:
– Aquel conjunto de prácticas y políticas,
algunas veces explícito y otras implícito, que
define cómo una organización hace negocios
– Restricciones propias del negocio que deben
ser reflejadas en la base de datos y sus
aplicaciones.
– Se derivan del dominio de aplicación del
sistema y no de las necesidades específicas
de los usuarios.

22/06/2021
¿Por qué se está realizando el
Proyecto?
• Los requerimientos del negocio son las
declaraciones de la empresa para justificar la
ejecución del proyecto.
• Incluye una visión del producto de software
impulsado por los objetivos del negocio.
• Es decir:
– describen el propósito y las necesidades a alto
nivel que el producto debe 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.

22/06/2021
Ejemplo de RD para un sistema de biblioteca:
1.- Deberá existir una interfaz de usuario estándar para todas las bases de
datos que estará basada en el estándar Z39.50
Ejemplo para un sistema de control de trenes.
La desaceleración del tren se calculará como:
Dtren = Dcontrol + Dgradiente
donde Dgradiente es 9.81ms2 * gradiente compensado/ alfa y en donde los
valores de 9.81ms2 / alfa se conocen para diferentes tipos de trenes.
Ejemplos de requisitos de dominio

22/06/2021
Problemas Relacionados con los
Requerimientos del Dominio
• Comprensibilidad
– Los requerimientos son expresados en el
lenguaje del dominio de aplicación.
– Pueden no ser entendidos por los ingenieros de
software que desarrollan el sistema.
• Implicación / Conocimiento tácito
– Los especialistas del dominio entienden el área
tan bien que no consideran necesario explicar los
requerimientos del dominio
– Las personas no están consientes del
conocimiento tácito que poseen y no lo expresan
a los otros.

22/06/2021
Resumen

22/06/2021
Resumen:
Requisitos Funcionales y No Funcionales
• Funcionales:
– Servicios o funciones que proveerá el sistema (funciones)
– La respuesta del sistema ante determinadas entradas
– El comportamiento del sistema en situaciones particulares.
– Describen la interacción entre el sistema y su entorno
– Ejemplos:
• Se deben ingresar cédula, nombre y teléfono de cada cliente
• Se quiere un listado de los clientes por zona
• No-funcionales:
– Restricciones a los servicios o funciones ofrecidos por el
sistema
– Describen restricciones que limitan las elecciones para construir
una solución
– Ejemplos:
• Las consultas deben resolverse en menos de 3 segundos
• El lenguaje de programación debe ser Java

22/06/2021

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos

22/06/2021
Cada requerimiento debe ser:
• 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 a ser construida.
• Claro: Pueden ser entendidos de la misma manera por
todas las partes interesadas con un mínimo de
explicación complementaria.
• 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.

22/06/2021
• 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.

22/06/2021
Características de especificaciones de
requerimientos (Conjunto de reqs.)
• 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 entren en
conflicto con otros requisitos del mismo tipo o con un mayor
nivel de negocios, sistema o necesidades de los usuarios.
• Modificable: Debe ser capaz de revisar en el SRS 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 el SRS.
• 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.

22/06/2021
• Necesario
• Realizable
• Conciso
• Correcto (exacto, técnica y legalmente)
• No ambiguo (solo puede ser interpretado de 1
FORMA)
• Completo (todas las condiciones bajo una oración)
• Consistente (no entra en conflicto con otros requisitos)
• Verificable (su implementación puede ser
comprobada)
• Rastreable (a través del diseño, codificación, pruebas,
documentación, etc.)

22/06/2021
• Asignable (allocated): a un componente del
diseño.
• Independiente del diseño: no debe de decir una
solución específica.
• No redundante: no está duplicado.
• Escrito correctamente en modo imperativo (debe
hacer algo)
• Con un único identificador.
• No debe incluir palabras como: excepto, pero, a
menos que , generalmente, típicamente,
normalmente, etc)

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos

22/06/2021
Motivación

22/06/2021
Dificultades en obtención & análisis 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 de software.
• 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.

22/06/2021
Las dificultades en proyectos se deben a :
• Requerimientos no explícitos. Las necesidades reales
del usuario no son definidas.
• Los cambios en los requerimientos se hacen sin
considerar costos, tiempos, impacto en la calidad.
• No se administran los requerimientos durante el ciclo
de vida del proyecto.
• Mala comunicación entre las partes involucradas en el
proyecto (administrador, desarrollo, diseño, etc.)
• Métodos, técnicas , herramientas no son utilizadas.
• Al cliente no se lo involucra como parte del proyecto.
Se recurre a él al inicio y al final.

22/06/2021
Dificultades en obtención & análisis de
requisitos
• Se trabaja en conjunto con los usuarios y clientes
• Problemas comunes:
– No saben lo que quieren del sistema, sólo en
términos generales, no conocen el costo de sus
peticiones
– Los requisitos están en sus términos y con
conocimiento implícito de su propio trabajo
– Distintos usuarios tienen distintos requisitos, se
deben encontrar todas las fuentes
– Influyen factores políticos
– La prioridad que se da a los requisitos varía con el
tiempo
– Aparecen nuevos requisitos

22/06/2021
Problemas en los requisitos
• La mayor consecuencia es el retrabajo (en
etapas más avanzadas del desarrollo o después
de liberar).
• Ejemplos:
– Poco involucramiento de los usuarios.
– Planes inadecuados – utilizar requisitos muy vagos
para crear planes.
– Recortes en los requisitos del usuario.
– Requisitos ambiguos.
– Gold plating – chapado en oro: requisitos que
creemos que el usuario va a amar.
– No identificar correctamente a los usuarios correctos.

22/06/2021
Brecha en la Comunicación (Scharer ’90)
Según desarrolladores, los usuarios... Según usuarios, los desarrolladores...
no saben lo que quieren no captan las necesidades operativas
no pueden articular lo que quieren ponen excesivo énfasis en aspectos meramente
técnicos
muchas necesidades por motivos políticos pretenden indicarnos cómo hacer nuestro trabajo
quieren todo ya no son capaces de traducir necesidades claramente
establecidas en un sistema
son incapaces de definir prioridades entre
sus necesidades
siempre dicen que no
rehúsan asumir responsabilidades por el
sistema
siempre están pasados del presupuesto
incapaces de dar un enunciado utilizable de
sus necesidades
siempre están atrasados
no están comprometidos con los proyectos
de desarrollo
nos exigen tiempo y esfuerzo aún a costa de las
obligaciones esenciales
no aceptan soluciones de compromiso establecen estándares no realistas para la definición
de requisitos
no pueden mantener el cronograma son incapaces de responder rápidamente a cambios
en las necesidades

22/06/2021
Comunicación
• Presentación de
requisitos
• Lenguaje accesible al
stakeholder
• Nivel de Abstracción
adecuado
• Participación e
integración
• Relacionada con etapa
de modelización

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos

22/06/2021
Formas de documentar los requerimientos
• Para la especificación del sistema se usan tres tipos de
recursos:
– Descripción del proyecto: Documento textual que describe de
forma concisa el objetivo del sistema, su oportunidad de
mercado y el análisis de riesgos (DOCUMENTO VISIÓN).
– Análisis del contexto: Modelo de objetos que identifica las
interacciones externas y los mecanismos de interacción física
entre los actores que constituyen el entorno y el propio sistema
(MODELO DE DOMINIO Y DE NEGOCIO).
– Casos de uso: Recursos UML para describir la funcionalidad
del sistema. Identifican los límites del sistema a través de la
captura de los tipos de usuario, de los elementos básicos de
funcionalidad a través de casos de uso, y de los protocolos de
interacción a través de diagramas de secuencia o de
interacción.

22/06/2021
Contenido
• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos

22/06/2021
Formas de documentar los
requerimientos
• Lenguaje Natural
– Comprensible para el Cliente/Usuario
– Ambiguo (glosario)
– Poca legibilidad (plantilla, formateo del texto)
– Difícil de tratar (Verificar correctitud, consistencia,
completitud)
• Notaciones Especiales (más formales)
– Poca o ninguna ambigüedad
– Facilita tratamiento
– Necesidad de entrenamiento en la notación
– Dificultades de comprensión por Cliente/Usuario

22/06/2021
Notaciones Especiales
• Gráficas vs. Basadas en texto
• Estáticas vs. Dinámicas
• Descripciones Estáticas
– Se especifican entidades y sus atributos, los requisitos se
pueden ver como las relaciones entre las entidades.
– No describe como cambian las relaciones con el tiempo
• Descripciones Dinámicas
– Especifican estados y las transiciones entre estados en el
tiempo

22/06/2021
Formas de representar los requisitos

22/06/2021
Ejemplos
FR 1.0:
FR 1.1:
FR 1.2:
etc.
FR 2.0
etc.
Nota: FR= Requerimiento funcional
Diagrama de árbol
En forma Textual (leng. Natural)

22/06/2021
Ejemplos
Requisitos como modelos

22/06/2021
Lección 3
Procesos
Unidad 1
Material docente compilado por el profesor Ph.D. Franklin Parrales

22/06/2021
Contenido
• Procesos
– Definición y elementos: entradas, salidas,
recursos y controles
– Diagrama de actividades

22/06/2021
Descripción y documentación de un
proceso
Misión del proceso.
• Un proceso puede ser definido como un conjunto de actividades enlazadas entre
sí que, partiendo de uno o más inputs los transforma, generando un output.
Documentación de proceso.
• Es un método estructurado que utiliza un preciso manual para comprender el
contexto y los detalles de los procesos claves. Siempre que un proceso vaya a ser
rediseñado o mejorado, su documentación es esencial como punto de partida.
Los pasos que deben llevarse a cabo para la realización de la documentación de
procesos y la creación de un manual son:
• 1º paso la selección del proceso a documentar.
• 2º la recolección de la información relacionada con el proceso.
• 3º análisis de la información.
• 4º desarrollo de un manual de documentación de procesos, que implica la creación
de un modelo o formato de procesos.

22/06/2021
Controles
Todo aquello que regula el proceso:
Pasos/pautas
Reglas/normas
Descripción y documentación de un
proceso
Proceso
Entradas
Materiales,
equipos,
información,
personas
Recursos
económicos, etc
Salidas
Producto o
servicio que s
creado por el
proceso, que es
entregado al
cliente.
Herramientas, funciones y
habilidades
Medios o recursos para llevar a
cabo el proceso y funciones ,
habilidades o capacidades
requeridas para desempeñar
eficazmente el proceso.

22/06/2021
Contenido
• Procesos
– Definición y elementos: entradas, salidas,
recursos y controles
– Diagrama de actividades

22/06/2021
• ¿Qué son los diagramas de actividad?
–Es una notación que forma parte de UML y que se utiliza
principalmente para modelar procesos de negocio, especificando:
✓ La secuencia de actividades que componen los procesos de
negocio.
✓ Los actores que realizan las actividades (opcional).
✓ La información que fluye de unas actividades a otras
(opcional).
–Dentro del proceso de ingeniería de requisitos, se utilizarán para
modelar los procesos de negocio, tanto actuales como a
implantar, de la organización para la que se va a desarrollar el
sistema software.
–A partir del modelo del negocio al que el sistema software debe
dar soporte, se plantean los objetivos y requisitos del sistema a
desarrollar.
Diagrama de Actividades

22/06/2021
Gestión de Pedidos
Ejemplo:
gestión
de
pedidos
Recibir Pedido
Enviar
Factura
Factura
Recibir
Pago
Satisfacer
Pedido
Pedido
Cerrar Pedido
Producción
Actividad inicial
Indica el comienzo del
proceso de negocio.
Actividad final
Indica el final del
proceso de negocio.
Calles
Permiten especificar qué
actividades hace cada actor.
Nodo de objeto
Representa información
o documentos (objetos)
que se generan en una
actividad y se
consumen en otra.
Comienzo de
paralelismo
Indica que a partir
de ahí se realizan
varias actividades en
paralelo.
Fin de paralelismo
Indica la terminación
de todas las
actividades que se
realizaban en
paralelo.
Transición
Indica que una
actividad ha
terminado y se pasa
a la siguiente.
Flujo de objeto
Representa un
flujo de
información
(objetos) entre
actividades.
Actividad compleja
Son actividades
complejas que
necesitan un
diagrama de
actividades propio
para ser descritas.
Facturación
Servicio al Cliente
Entregar
Pedido
Actividad
Representa un paso
en el proceso de
negocio.

22/06/2021
• Actividades
– Una actividad representa un paso dentro de
proceso de negocio.
• Su nombre, que debe ser siempre una forma
verbal, debe ser representativo y coherente
dentro del proceso de negocio.
• Si una actividad es compleja, puede ser necesario
mostrar su descomposición en actividades más
simples en otro diagrama.
• En cada diagrama de actividades, las actividades
deben tener un nivel de abstracción similar.
• Actividades iniciales y finales
– La actividad inicial, que debe ser única, indica dónde
comienza el proceso de negocio.
– Una actividad final, de las que puede haber varias o
ninguna (proceso sin fin), indica dónde puede
terminar el proceso
Actividad
Actividad
compleja
Actividad
inicial
Actividad
final

22/06/2021
• Transiciones
– Indican la secuencia de actividades que componen el proceso de
negocio.
– Cuando una actividad termina de realizarse se produce la
transición hacia la siguiente actividad.
• Transiciones condicionales
– Indican que la siguiente actividad a realizar depende de
cierta condición.
– Como mínimo y como máximo, sólo puede haber una opción
válida al evaluar la condición
Actividad 1 Actividad 2
– El símbolo de
condición se puede
usar también para
unir varios caminos
condicionales
(opcional).
Entrega de pedido
[otro caso] [urgente]
Entrega
Ordinaria
Entrega
Urgente

22/06/2021
Ejemplo: Cajero ATM
Se abren Flujos
Paralelos
Sincronización
Guarda de
decisión

22/06/2021
Ejemplo
Diagrama de Actividad
para calcular el Fibonacci
de un numero.

22/06/2021
• Paralelismo
– A veces, algunos pasos de un proceso de
negocio se realizan simultáneamente (en
paralelo) o sin un orden definido.
– Para indicar que comienzan varias actividades
a la vez se usa un símbolo de comienzo de
paralelismo (fork), al que llega una transición
y del que salen varias (al menos dos).
– Para indicar que todas las actividades que
se hacían en paralelo han terminado se usa
un símbolo de fin de paralelismo (join), al
que llegan varias transiciones (al menos
dos) y del que sale una sola transición.
– La transición de salida del join sólo se realiza
cuando han terminado todas las actividades
que se realizaban en paralelo.
Realizar Práctica*
Seleccionar
Sistema
Presentar
Práctica
Estudiar
Negocio
Elaborar
Requisitos
Realizar
Modelos
*Proceso muy, muy simplificado.

22/06/2021
• Calles (marcos de responsabilidad)
– La división en calles permite asociar actividades con aquellos actores
que las realizan. Cada calle corresponde a un actor del proceso de
negocio.
Gestión de fondosbibliotecarios
Director Bibliotecario Usuario
Catalogar
nuevo libro
Registrar
préstamo
Leer libro
Registrar
devolución
[libro OK]
Retirar
libro
[libro deteriorado]

22/06/2021
• Flujos de objetos
– Lo normal es que fluya información entre las
actividades de un proceso de negocio.
– En el caso de que resulte interesante mostrar ese flujo (no
siempre lo es), se pueden usar flujos de objetos.
– Si la información de salida de una actividad es la entrada de
otra actividad, se asume que existe una transición implícita
entre ambas.
Aseguramiento de la calidad de losrequisitos
Validación
Verificación
Requisitos
[borrador]
Requisitos
[analizados]
Requisitos
[verificados]
Requisitos
[validados]
Análisis
transiciones implícitas
(no es necesario dibujarlas)

22/06/2021
Ejemplo:
venta
por
caja
Cliente Banco
Incluir compras
del carrito
Calcular tasas
y descuentos
Recibo
Caja
Carrito
Solicitar
Autorización
Pago
[pago al
contado] [otro caso]
Autorizar
pago
Emitir
Recibo
Comprar y
llenar carrito
Entregar
compras
Venta por caja
Cajero

22/06/2021
Ejemplo: Veamos el caso de una firma de consultoría y el proceso de
negociación involucrado en una junta con un cliente.
1. Un vendedor realiza una llamada a un cliente y concierta una cita.
2. Si la cita es en la oficina del consultor, los técnicos corporativos
prepararán una sala de conferencia.
3. Si es en la oficina del cliente, el consultor preparará una
presentación.
4. El consultor y el vendedor se reunirán con el cliente en un sitio a la
hora convenida.
5. El vendedor crea una minuta.
6. Si la reunión ha planteado la solución del problema, el consultor
creará una propuesta y la enviará al cliente.
Ejemplo: Proceso de negociación

22/06/2021
Diagrama de Actividad
con Marcos de
Responsabilidad.

22/06/2021
Resumen: Diagrama de Actividad
• Se construye para modelar el flujo del control (workflow)
• Elementos:
• Permite modelar el flujo del trabajo
– En un sistema
– En una organización
Estado de Actividad (o de Acción)
Estado Inicial
Estado Final
Transiciones
Actividades concurrentes
Bifurcaciones
Condiciones de la bifurcación [ guarda ]
Andariveles

22/06/2021
Lección 4
Procesos de la IDR
Unidad 1
Material docente compilado por el profesor Ph.D. Franklin Parrales

22/06/2021
Contenido
• Elementos de procesos aplicados a la IDR
– Fases y documentos
– Modelo de espiral del proceso de IDR
– Mapeo de procesos AS-IS / TO-BE

22/06/2021
Proceso de ingeniería de requisitos
Estudio de
viabilidad
Obtención y análisis
de requisitos
Especificación de
requisitos
Validación de
requisitos
Informe de
viabilidad
Requisitos
Requisitos
especificados Requisitos validados
Determina si el
sistema es útil
para la empresa Descubrimiento
de los
requerimientos
Transformación de
requerimientos en
estándares.
Verificar que los requerimientos
realmente definen el sistema que
el cliente requiere

22/06/2021
Estudio de
viabilidad
de requisitos
Especificación de
requisitos
Validación de
requisitos
Informe de
viabilidad
Requisitos
Requisitos
Determina si el
sistema es útil
de los
requerimientos
Transformación de
requerimientos en
estándares.
el cliente requiere

22/06/2021
1.- Estudio de factibilidad (viabilidad):
• Entradas:
– Conjunto de requerimientos de negocio preliminares
– Descripción resumida del sistema
– Contribución pretendida del sistema a los procesos
del negocio
• Salida:
– Informe que indique si se debe realizar o no el
sistema.

22/06/2021
• Llevar a cabo un estudio de viabilidad comprende la evaluación y
recopilación de la in formación, y la redacción de informes.
• La fase de evaluación de la información identifica la información
requerida para contestar las tres preguntas anteriores.
• Una vez que dicha información se ha identificado, se debería hablar con
las fuentes de información para descubrir las respuestas a estas
preguntas.
• Algunos ejemplos de preguntas posibles son:
– ¿Cómo se las arreglaría la organización si no se implementara este sistema?
– ¿Cuáles son los problemas con los procesos actuales y cómo ayudaría un sistema
nuevo a aliviarlos?
– ¿Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos
del negocio?
– ¿La información se puede obtener y transferir a otros sistemas de la organización?
– ¿Requiere el sistema tecnología que no se ha utilizado previamente en la organiza-
ción?
– ¿A qué debe ayudar el sistema y a qué no necesita ayudar?

22/06/2021
Fuentes
-Jefes de departamentos donde se utilizara el sistema
-Ingenieros de software que están familiarizados
-Expertos en tecnología
-Expertos en el área
-Usuarios finales
Informe final:
-Recomendación para realizar o no el sistema
-Proponer cambios en el alcance, presupuesto y/o agenda
-Sugerir requerimientos adicionales

22/06/2021
Estudio de
viabilidad
de requisitos
Especificación de
requisitos
Validación de
requisitos
Informe de
viabilidad
Requisitos
Requisitos
Determina si el
sistema es útil
de los
requerimientos
Transformación de
requerimientos en
estándares.
el cliente requiere

22/06/2021
2.- Adquisición y análisis de requerimientos.
Se trabaja con los stakeholders para definir:
-Dominio de aplicación
-Servicios que debe proporcionar el sistema
-Desempeño requerido
-Restricciones, etc.
En su proyecto ¿quienes
son los stakeholders?
¿Cuál es el dominio de
aplicación ?

22/06/2021
2.- Adquisición y análisis de requerimientos
Razones que dificultan el proceso de adquisición de requerimientos

22/06/2021
2.- Adquisición y análisis de requerimientos

22/06/2021
Estudio de
viabilidad
de requisitos
Especificación de
requisitos
Validación de
requisitos
Informe de
viabilidad
Requisitos
Requisitos
Determina si el
sistema es útil
de los
requerimientos
Transformación de
requerimientos en
estándares.
el cliente requiere

22/06/2021
3- Especificación de requerimientos
Requerimientos del usuario → Se expresan en lenguaje natural
Incluyen requerimientos funcionales y no
funcionales

22/06/2021
Requerimientos del sistema → describen el comportamiento del sistema,
pueden requerir diferentes técnicas de representación.

22/06/2021
Documento
requerimientos
de
basado
en el estándar IEEE830

22/06/2021
Usuarios del documento de requerimientos:

22/06/2021
Estudio de
viabilidad
de requisitos
Especificación de
requisitos
Validación de
requisitos
Informe de
viabilidad
Requisitos
Requisitos
Determina si el
sistema es útil
de los
requerimientos
Transformación de
requerimientos en
estándares.
el cliente requiere

22/06/2021
4- Validación de requerimientos
Es el proceso de verificar que los requerimientos definan realmente lo
que el cliente desea
Esta etapa es muy importante, ya que resulta muy costoso corregir
errores en el sistema implementado !
Debe realizarse en cada etapa del proceso para asegurarse que lo que
se esta realizando se esta haciendo bien.
Durante el proceso de validación deben realizarse varias comprobaciones.

22/06/2021

22/06/2021
Estudio de
viabilidad
de requisitos
Especificación de
requisitos
Validación de
requisitos
Informe de
viabilidad
Requisitos
Requisitos
Determina si el
sistema es útil
de los
requerimientos
Transformación de
requerimientos en
estándares.
el cliente requiere
Administración
(gestión)
de
los
requerimientos

22/06/2021
Proceso de los Requerimientos
Obtención Análisis Validación
Administración de los Requisitos
Línea
Base
de
Requerimientos
Línea base actual
Línea base corregida
Planificación
Administración
del Cambio
Cambios en
requerimientos
Cambios
en el proyecto
Planifica-
ción Verificación
Trazabilidad
Especifica-
ción

22/06/2021
Los requerimientos iniciales pueden cambiar, es necesario llevar a cabo la
administración/ actualizacion de requerimientos
La administración de requerimientos tiene dos etapas:
1.- Planeación (planificación) de la administración de requerimientos.
2. Administración del cambio de requerimientos.

22/06/2021
Planeación de la administración de requerimientos
Establece el nivel de detalle que se desea en la administración de requerimientos. En
esta etapa se define lo siguiente:

22/06/2021
Sistemas pequeños pueden no requerir estas herramientas

22/06/2021
Administración del cambio de requerimientos
Debe aplicarse a todos los cambios propuestos después de elaborarse y aprobarse el
documento de requerimientos.
La administración del cambio es esencial ya que debe determinarse si se justifica o
no la realización del cambio
Se tienen tres etapas principales:

22/06/2021
l. Análisis del problema y especificación del cambio El proceso cornienza con la
identificación de un problema en los requerimientos o, en ocasiones, con una pro
puesta de cambio específica. Durante esta etapa , el problema o la propuesta de
cambio se analizan para comprobar que es válida. Este análisis retroalimenta al soli
citante del cambio, quien responderá con una propuesta de cambio de requerimien tos
más específica, o decidirá retirar la petición.
2. Análisis del cambio y estimación del costo El efecto del cambio propuesto se valora usando
información de seguinúento y conocimiento general de los requerimientos del sistema.
El costo por realizar el cambio se estima en términos de modificaciones al documento de
requerimientos y, si es adecuado, al diseño y la implementación del sistema. Una vez
completado este análisis, se toma una decisión acerca de si se procede o no con el
cambio de requerimientos.
3. Impl ementación del cambio Se modifican el documento de requerimientos y, donde sea
necesario, el diseño y la implementación del sistema. Hay que organizar el docu mento de
requerimientos de forma que sea posible realizar cambios sin reescritura o
reorganización extensos. Conforme a los programas , la variabilidad en los docu
mentos se logra al minimizar las referencias externas y al hacer las secciones del
documento tan modulare s como sea posible. De esta manera , secciones individuales
pueden modificarse y sustituirse sin afectar otras partes del documento.

22/06/2021
Proceso de Requisitos
Artefactos
Análisis Especificación Validación
Actividades
Especificación
de Requisitos
Documento
de
Requisitos
Modelo del
Sistema
Planificación Obtención Verificación
Documento
de
Visión

22/06/2021
Documentación de requisitos
• Qué documentar:
– lo que hace el sistema actual
– lo que el cliente pide
– lo que el sistema va a hacer
– criterios de aceptación
– criterios de verificación
• Recomendaciones:
– agrupar por temas
– formular los reqs. como reqs. positivos y no negativos
– expresarlos en voz activa y no pasiva
– indicar si se está documentando solo lo que va en el alcance o
todo lo que se pidió.
– representar reqs. con múltiples vistas (ejemplo de los ciegos y el
elefante).

22/06/2021
Documentos de Requisitos
• Definición de Requisitos: lista completa de lo que el
cliente espera que el sistema haga, escrita de forma
que el cliente la pueda entender
1. Se debe proveer un medio para acceder a archivos externos
creados por otras herramientas
• Especificación de Requisitos (SRS): reformula la
definición en términos técnicos para que los
diseñadores puedan comenzar el diseño
1.1 Se proveerá al usuario los recursos para definir el tipo de
archivo externo
1.2 Cada tipo de archivo tendrá una herramienta asociada y un
ícono que lo identifica
1.3 Cuando el usuario seleccione el ícono que representa un
archivo externo, el efecto es aplicar la herramienta asociada
con ese tipo de archivo al archivo seleccionado

22/06/2021
Documentos de Requisitos (2)
• Usar un mismo documento: Entendimiento común entre
Cliente, usuario, analistas, desarrolladores
• Usar dos documentos: Se debe aplicar Gestión de
Configuración: necesaria para asegurar la
correspondencia entre ambos (si existen por separado)
• Permite seguir la pista y correspondencia entre:
– Definición de Requisitos
– Especificación de Requisitos
– Módulos de Diseño
– Código que implementa los módulos
– Pruebas para verificar la funcionalidad
– Documentos que describen el sistema

22/06/2021
Documento Definición de Requisitos
• Registrar los requisitos en los términos del
cliente
1. Delinear el propósito general del sistema: Incluir
referencias a otros sistemas, glosario y
abreviaciones
2. Describir el contexto y objetivos del desarrollo
del sistema
3. Delinear visión global del sistema: Incluir
restricciones generales
4. Definir en detalle las características del sistema
propuesto, definir la frontera del sistema e
interfaces.
5. Discutir el ambiente en el que el sistema va a
operar (hardware, comunicaciones, personal).

22/06/2021
Contenido

22/06/2021
Proceso espiral de IR
Validación
de requerimientos
Adquisición
de requerimientos
Adquisición
de requerimientos
del usuario
Prototipos
Revisiones
Documento
de requerimientos
del sistema
Inicio
Adquisición de
requerimientos
del sistema
Estudio
de factibilidad
Especificación de
requerimientos
Especificación y modelado
de requerimientos
del sistema
Especificación
de requerimientos del usuario
Especificación de
requerimientos
de la empresa

22/06/2021
Contenido

22/06/2021
As is / To be
• Se intenta responder 3 preguntas básicas:
Temas Preguntas a los usuarios
¿Cuáles son las operaciones y procesos
comerciales?
¿Qué haces?
¿Cómo se deben realizar esas operaciones?
¿Cómo haces aquello?
¿Qué pasos sigues?
¿Qué información se necesita para realizar esas
operaciones?
¿Qué información utilizas?
¿Qué formularios o reportes utilizas?

22/06/2021
As is / To be
1. Procesos actuales
2. Procesos futuros
3. Requerimientos

22/06/2021
• Dibuje diagramas de actividades que describan cómo
se ejecutan los eventos empresariales clave en la
actualidad.
• Asegúrese de resaltar los problemas actuales del
proceso en los diagramas.
• Proporcione una narrativa (párrafo) que vaya con los
diagramas.
• Ejemplo. Si está considerando el registro de
estudiantes, puede desarrollar diagramas para lo
siguiente:
– Determinar cursos / secciones a tomar
– Registrarse para cursos
– Generar horario

22/06/2021
Inscribirse en un curso: situación actual
Estudiante Profesor Registrador
Reg. Form
¿Inscripciones
abiertas?
¿Estudiante necesita
otro curso?
Y
N
Y
¿Puede inscribirse?
N
Y
N
Y
N
¿Formulario
correcto?
Seleccionar cursos
Esperar en la fila,
generalmente bajo
la lluvia
Esperar en la fila para
ser atendido por
el profesor
Solicitud de revisión
Determinar si el
estudiante cumple
los requisitos previos.
Reg. Form
Determinar si hay
espacio disponible en
las secciones bajo
su cargo.
Reg. Form
Inscribir estudiante,
actualizar formulario
Reg. Form
Llevar el formulario
completo
a la mesa del registrador
Reg. Form
Revisar los formularios
para detectar
problemas / errores
Almacenar los datos
de registro en el
ordenador

22/06/2021
As is / To be
2. Procesos futuros
3. Requerimientos

22/06/2021
2. Procesos futuros
• Construya diagramas de actividades que
describan la forma en que las
transacciones deben ejecutarse en el
futuro, con el nuevo sistema de
información.
• Proporcione una narrativa para describir
los pasos del proceso.

22/06/2021
Estudiante Sistema
¿Inscripciones
abiertas?
Y
N
¿Se requiere más
cursos?
Y
N
Inscribirse en un curso: situación propuesta
Seleccionar cursos
Sentarse frente a la
computadora.
Beber café.
Proporcionar nombre
de usuario y contraseña
Autenticar usuario
Comprobar que el estudiante
cumple los prerequisitos
de los cursos
Ingresar los cursos
a inscribirse Consultar disponibilidad
en los paralelos
solicitados
Registrar asignación
del cupo en la
base de datos
Presentar al estudiante
los cursos en los que se
ha podido inscribir.

22/06/2021
As is / To be
2. Procesos futuros
3. Requerimientos

IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos

IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos

Ähnlich wie IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos (20)

Mehr von Franklin Parrales Bravo

Mehr von Franklin Parrales Bravo (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos