All FRPB Idr Capítulo1

Ingeniería de requerimientos Carrera de Software
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

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

para uso de los cursos de Ingeniería de Requerimientos
Unidad 1 01/06/2022 1
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.
Unidad 1 01/06/2022 2

Unidad 1
Lección 1
La Ingeniería de
requerimientos - IDR
Unidad 1 01/06/2022 3
Contenido

• La Ingeniería de requerimientos – IDR
– Definición de la IDR
– Importancia de la IDR
– Actividades de la IDR
Unidad 1 01/06/2022 4
Visión global
Primera fase del ciclo de vida del

n
software en la que se produce una Ingeniería de
Requisitos
especificación a partir de ideas
informales
n Deben obtenerse y documentarse
n Los requisitos de información Resto del
n Los requisitos funcionales ciclo de vida
n Los requisitos no funcionales

n Los criterios para medir el grado de su consecución
n E l 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
Unidad 1 01/06/2022 5
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]
Unidad 1 01/06/2022 6
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 E l 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]
Unidad 1 01/06/2022 7
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]
Unidad 1 01/06/2022 8
Contenido

Unidad 1 01/06/2022 9
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.
Unidad 1 01/06/2022 10
Stakeholders

Los stakeholders son aquellas personas o entidades
que tienen algún impacto o interés en este sistema.
• 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.
Unidad 1 01/06/2022 11
Stakeholders

Unidad 1 01/06/2022 12
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.
Unidad 1 01/06/2022 13
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
Unidad 1 01/06/2022 14
Motivación

Unidad 1 01/06/2022 15
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.
Unidad 1 01/06/2022 16
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)
Unidad 1 01/06/2022 17
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.
Unidad 1 01/06/2022 18
Contenido

Unidad 1 01/06/2022 19
Actividades de la Ing. de
Requerimientos

Unidad 1 01/06/2022 20

Proceso de los Requerimientos Administración de los Requisitos
Requerimientos
Línea Base de
Planifica- Especifica-
Obtención Análisis Verificación Validación
ción ción
Línea base corregida
Trazabilidad Administración
Planificación del Cambio
Línea base actual
Cambios en Cambios
requerimientos en el proyecto
Unidad 1 01/06/2022 21
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
Unidad 1 01/06/2022 22
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
Unidad 1 01/06/2022 23
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)
Unidad 1 01/06/2022 24
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
Unidad 1 01/06/2022 25
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
Unidad 1 01/06/2022 26
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.
Unidad 1 01/06/2022 27
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.
Unidad 1 01/06/2022 28
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
Unidad 1 01/06/2022 29

Unidad 1
Lección 2
Requerimientos

Unidad 1 01/06/2022 30
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
Unidad 1 01/06/2022 31
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.
Unidad 1 01/06/2022 32
¿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.
Unidad 1 01/06/2022 33
Requisitos vs. Diseño

• Requisitos definen el Qué (el problema) del
sistema
• El Diseño define el Cómo (la solución)
Unidad 1 01/06/2022 34
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.
Unidad 1 01/06/2022 35
Contenido

• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos
Unidad 1 01/06/2022 36
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.
Unidad 1 01/06/2022 37
Costos de errores en los requisitos

• Costo de corregir un error en los requisitos
(Boehm-Papaccio,1988)
Unidad 1 01/06/2022 38
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.
Unidad 1 01/06/2022 39
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.
Unidad 1 01/06/2022 40
Contenido

• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos
Unidad 1 01/06/2022 41
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.
Unidad 1 01/06/2022 42
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.
Unidad 1 01/06/2022 43
Tipos de requisitos - Abstracción

• Es necesario escribir los requisitos utilizando
diferentes niveles de abstracción porque
diferentes lectores los usan de diferente
forma.
Gerentes del cliente
Requerimientos Usuarios finales del sistema
del usuario Ingenieros del cliente
Gerentes de los contratistas
Arquitectos del sistema
Requerimientos Usuarios finales del sistema

del sistema Ingenieros del cliente
Arquitectos del sistema
Desarrolladores de software
Unidad 1 01/06/2022 44
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.
Unidad 1 01/06/2022 45
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.
Unidad 1 01/06/2022 46
Contenido

• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos
Unidad 1 01/06/2022 47
División

• Podemos identificar dos divisiones de
requisitos:
- Requisitos de usuario.
- Requisitos de sistema.
Unidad 1 01/06/2022 48
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
Unidad 1 01/06/2022 49
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
Unidad 1 01/06/2022 50
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; ......
Unidad 1 01/06/2022 51
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.
Unidad 1 01/06/2022 52
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.
Unidad 1 01/06/2022 53
Requisitos de sistema

• Hay tres tipos de requisitos de sistema:
– Requisitos funcionales
– Requisitos no funcionales
– Requisitos del dominio.
Unidad 1 01/06/2022 54

Requisitos
funcionales
Unidad 1 01/06/2022 55
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.
Unidad 1 01/06/2022 56
Los requerimiento Funcionales definen:

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.
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.
Unidad 1 01/06/2022 57
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
todas las clínicas a Búsqueda por
la vez nombre y apellido
Búsqueda dentro de
cada clínica por vez Búsqueda por hora
de la cita
Unidad 1 01/06/2022 58

Requisitos
funcionales
Ejemplos
Unidad 1 01/06/2022 59
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.
Unidad 1 01/06/2022 60

• 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.
Unidad 1 01/06/2022 61

• 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.
Unidad 1 01/06/2022 62

• 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.
Unidad 1 01/06/2022 63

Requisitos NO
funcionales
Unidad 1 01/06/2022 64
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.
Unidad 1 01/06/2022 65
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
Unidad 1 01/06/2022 66
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.
Unidad 1 01/06/2022 67
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.
Unidad 1 01/06/2022 68
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.
Unidad 1 01/06/2022 69
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.
Unidad 1 01/06/2022 70
Algunas recomendaciones para determinarlos

Propiedad Medida

Transacciones procesadas por segundo
Rapidez Tiempo de respuesta al usuario y a eventos
Tiempo de actualizacion de la pantalla
K Bytes
Tamaño
Numero de chips de RAM
Tiempo de entrenamiento
Facilidad de Uso
Número de pantallas de ayuda
Número promedio entre fallos
Probabilidad de no disponibilidad
Fiabilidad
Tasa de Ocurrencia de fallos
Disponibilidad
Tiempo de reinicio entre fallos
Porcentaje de eventos que provocan fallos
Robustez
Probabilidad de corrupcion de los datos
despues de fallos
Porcentaje de declaraciones dependientes
Portabilidad de objetivos
Número de sistemas objetivo
Unidad 1 01/06/2022 71
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.
Unidad 1 01/06/2022 72
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
Unidad 1 01/06/2022 73
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)
Unidad 1 01/06/2022 74

Requerimientos
no funcionales
Requerimientos Requerimientos Requerimientos

del producto de la organización externos
Requerimientos Requerimientos Requerimientos Requerimientos Requerimientos

de eficiencia de confiabilidad de seguridad regulatorios éticos

de usabilidad ambientales operacionales de desarrollo legales
Requerimientos Requerimientos Requerimientos Requerimientos

de rendimiento de espacio contables protección/seguridad
Unidad 1 01/06/2022 75
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.
Unidad 1 01/06/2022 76

– 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.
Unidad 1 01/06/2022 77

• 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.
Unidad 1 01/06/2022 78

Requerimientos
no funcionales




Unidad 1 01/06/2022 79
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.
Unidad 1 01/06/2022 80

• 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.
Unidad 1 01/06/2022 81

• 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.
Unidad 1 01/06/2022 82

Requerimientos
no funcionales




Unidad 1 01/06/2022 83
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.
Unidad 1 01/06/2022 84
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.
Unidad 1 01/06/2022 85

Requisitos NO
funcionales
Ejemplos
Unidad 1 01/06/2022 86
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.
Unidad 1 01/06/2022 87

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.
Unidad 1 01/06/2022 88

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.
Unidad 1 01/06/2022 89

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.
Unidad 1 01/06/2022 90

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.
Unidad 1 01/06/2022 91

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.
Unidad 1 01/06/2022 92

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.
Unidad 1 01/06/2022 93

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.
Unidad 1 01/06/2022 94

Requisitos del
dominio
Unidad 1 01/06/2022 95
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
Unidad 1 01/06/2022 96
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.
Unidad 1 01/06/2022 97
¿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.
Unidad 1 01/06/2022 98
Ejemplos de requisitos de dominio

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.
Unidad 1 01/06/2022 99
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.
Unidad 1 01/06/2022 100


Resumen
Unidad 1 01/06/2022 101

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
Unidad 1 01/06/2022 102

Unidad 1
01/06/2022
103
Carrera de Software

Contenido

• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos
Unidad 1 01/06/2022 104

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.
Unidad 1 01/06/2022 105


• 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.
Unidad 1 01/06/2022 106

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.
Unidad 1 01/06/2022 107


• 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.)
Unidad 1 01/06/2022 108


• 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)
Unidad 1 01/06/2022 109

Contenido

• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos
Unidad 1 01/06/2022 110

Motivación

Unidad 1 01/06/2022 111
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.
Unidad 1 01/06/2022 112

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.
Unidad 1 01/06/2022 113

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
Unidad 1 01/06/2022 114

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.
Unidad 1 01/06/2022 115

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 siempre dicen que no
sus necesidades
rehúsan asumir responsabilidades por el siempre están pasados del presupuesto
sistema
incapaces de dar un enunciado utilizable de siempre están atrasados
sus necesidades
no están comprometidos con los proyectos nos exigen tiempo y esfuerzo aún a costa de las
de desarrollo 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
Unidad 1 01/06/2022 116

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
Unidad 1 01/06/2022 117

Contenido

• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos
Unidad 1 01/06/2022 118

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.
Unidad 1 01/06/2022 119

Contenido

• Requerimientos
– Definición
– Tipos
– Importancia
– División
requerimientos
Unidad 1 01/06/2022 120

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
Unidad 1 01/06/2022 121

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
Unidad 1 01/06/2022 122

Formas de representar los requisitos

Unidad 1 01/06/2022 123
Ejemplos

En forma Textual (leng. Natural) Diagrama de árbol
FR 1.0:
FR 1.1:
FR 1.2:
etc.
FR 2.0
etc.
Nota: FR= Requerimiento funcional
Unidad 1 01/06/2022 124

Ejemplos

Requisitos como modelos
Unidad 1 01/06/2022 125


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

Unidad 1 01/06/2022 126

Contenido

• Procesos
– Definición y elementos: entradas, salidas,
recursos y controles
– Diagrama de actividades
Unidad 1 01/06/2022 127

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.
Unidad 1 01/06/2022 128

Descripción y documentación de un
proceso

Controles
Todo aquello que regula el proceso:
Pasos/pautas
Reglas/normas
Entradas Salidas
Materiales, Producto o
equipos, servicio que s
información, Proceso creado por el
personas proceso, que es
Recursos entregado al
económicos, etc 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.
Unidad 1 01/06/2022 129

Contenido

• Procesos
– Definición y elementos: entradas, salidas,
recursos y controles
– Diagrama de actividades
Unidad 1 01/06/2022 130

Diagrama de Actividades

• ¿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.
Unidad 1 01/06/2022 131

Calles
Permiten especificar qué
actividades hace cada actor.
Ejemplo: gestión de pedidos
Gestión de Pedidos

Comienzo de Producción Servicio al Cliente Facturación
paralelismo
Indica que a partir
Actividad
de ahí se realizan Actividad inicial
Representa un paso
varias actividades en Indica el comienzo del
Recibir Pedido en el proceso de
paralelo. proceso de negocio.
negocio.
Satisfacer Enviar
Flujo de objeto Factura
Representa un
Pedido Factura
flujo de
información
(objetos) entre Nodo de objeto
actividades. Representa información
Pedido o documentos (objetos) Recibir
que se generan en una Pago
actividad y se
Actividad compleja consumen en otra. Transición
Son actividades Indica que una
complejas que actividad ha
necesitan un Entregar terminado y se pasa
diagrama de Pedido a la siguiente.
actividades propio
para ser descritas.
Fin de paralelismo
Indica la terminación Cerrar Pedido
de todas las
Actividad final
actividades que se
Indica el final del
realizaban en
proceso de negocio.
paralelo.
Unidad 1 01/06/2022 132

• Actividades Actividad

– 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 Actividad
mostrar su descomposición en actividades más compleja
simples en otro diagrama.
• En cada diagrama de actividades, las actividades
deben tener un nivel de abstracción similar.
• Actividades iniciales y finales
Actividad
– La actividad inicial, que debe ser única, indica dónde inicial
comienza el proceso de negocio.
– Una actividad final, de las que puede haber varias o Actividad
final
ninguna (proceso sin fin), indica dónde puede
terminar el proceso
Unidad 1 01/06/2022 133

• Transiciones Actividad 1 Actividad 2

– 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
Entrega de pedido
[otro caso] [urgente] – El símbolo de
condición se puede
Entrega Entrega usar también para
Ordinaria Urgente
unir varios caminos
condicionales
(opcional).
Unidad 1 01/06/2022 134

Ejemplo: Cajero ATM

Guarda de
decisión
Se abren Flujos
Paralelos
Sincronización
Unidad 1 01/06/2022 135


Ejemplo
Diagrama de Actividad
para calcular el Fibonacci
de un numero.
Unidad 1 01/06/2022 136

Realizar Práctica*

• Paralelismo
– A veces, algunos pasos de un proceso de Seleccionar
negocio se realizan simultáneamente (en Sistema
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
Estudiar Elaborar
y del que salen varias (al menos dos). Negocio Requisitos
– Para indicar que todas las actividades que
se hacían en paralelo han terminado se usa Realizar
un símbolo de fin de paralelismo (join), al Modelos
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 Presentar
Práctica
que se realizaban en paralelo.
*Proceso muy, muy simplificado.
Unidad 1 01/06/2022 137

• 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 fondos bibliotecarios
Director Bibliotecario Usuario
Catalogar
nuevo libro
Registrar
préstamo
Leer libro
Registrar
devolución
[libro OK]
Retirar [libro deteriorado]

libro
Unidad 1 01/06/2022 138

• 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 los requisitos
Requisitos
Análisis
[borrador]
Requisitos
[verificados]
Requisitos Requisitos
Verificación Validación
[analizados] [validados]
transiciones implícitas
(no es necesario dibujarlas)
Unidad 1 01/06/2022 139

Venta por caja

Cliente Cajero Caja Banco

Ejemplo: venta por caja
Comprar y
llenar carrito
Carrito Incluir compras Calcular tasas

del carrito y descuentos
[pago al
contado] [otro caso]
Solicitar
Autorización Autorizar
Pago pago
Recibo Emitir
Recibo
Entregar
compras
Unidad 1 01/06/2022 140

Ejemplo: Proceso de negociación

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.
Unidad 1 01/06/2022 141


Diagrama de Actividad
con Marcos de
Responsabilidad.
Unidad 1 01/06/2022 142

Resumen: Diagrama de Actividad

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


Unidad 1
Lección 4
Procesos de la IDR

Unidad 1 01/06/2022 144

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
Unidad 1 01/06/2022 145

Proceso de ingeniería de requisitos

Estudio de Obtención y análisis
viabilidad de requisitos
Especificación de
Informe de requisitos
viabilidad
Determina si el Requisitos Validación de
sistema es útil
para la empresa Descubrimiento requisitos
de los
requerimientos
Requisitos
especificados Requisitos validados
Transformación de
Verificar que los requerimientos
requerimientos en
realmente definen el sistema que
estándares.
el cliente requiere
Unidad 1 01/06/2022 146


Especificación de
viabilidad
sistema es útil
de los
requerimientos
Requisitos
Transformación de
requerimientos en
estándares.
el cliente requiere
Unidad 1 01/06/2022 147

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.
Unidad 1 01/06/2022 148


• 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?
Unidad 1 01/06/2022 149


-Jefes de departamentos donde se utilizara el sistema
-Ingenieros de software que están familiarizados
Fuentes
-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
Unidad 1 01/06/2022 150


Especificación de
viabilidad
sistema es útil
de los
requerimientos
Requisitos
Transformación de
requerimientos en
estándares.
el cliente requiere
Unidad 1 01/06/2022 151

2.- Adquisición y análisis de requerimientos.

Se trabaja con los stakeholders para definir: En su proyecto ¿quienes
son los stakeholders?
-Dominio de aplicación
¿Cuál es el dominio de
-Servicios que debe proporcionar el sistema
aplicación ?
-Desempeño requerido
-Restricciones, etc.
Unidad 1 01/06/2022 152

2.- Adquisición y análisis de requerimientos

Razones que dificultan el proceso de adquisición de requerimientos
Unidad 1 01/06/2022 153

2.- Adquisición y análisis de requerimientos

Unidad 1 01/06/2022 154

Especificación de
viabilidad
sistema es útil
de los
requerimientos
Requisitos
Transformación de
requerimientos en
estándares.
el cliente requiere
Unidad 1 01/06/2022 155

3- Especificación de requerimientos

Requerimientos del usuario  Se expresan en lenguaje natural
Incluyen requerimientos funcionales y no
funcionales
Unidad 1 01/06/2022 156


Requerimientos del sistema  describen el comportamiento del sistema,
pueden requerir diferentes técnicas de representación.
Unidad 1 01/06/2022 157


Documento de
requerimientos basado
en el estándar IEEE830
Unidad 1 01/06/2022 158


Usuarios del documento de requerimientos:
Unidad 1 01/06/2022 159


Especificación de
viabilidad
sistema es útil
de los
requerimientos
Requisitos
Transformación de
requerimientos en
estándares.
el cliente requiere
Unidad 1 01/06/2022 160

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.
Unidad 1 01/06/2022 161


Unidad 1 01/06/2022 162

Unidad 1 01/06/2022 163

Administración (gestión) de los requerimientos

Especificación de
viabilidad
sistema es útil
de los
requerimientos
Requisitos
Transformación de
requerimientos en
estándares.
el cliente requiere
Unidad 1 01/06/2022 164


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


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.
Unidad 1 01/06/2022 166


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:
Unidad 1 01/06/2022 167


Sistemas pequeños pueden no requerir estas herramientas
Unidad 1 01/06/2022 168


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:
Unidad 1 01/06/2022 169


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 costoEl 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.
Unidad 1 01/06/2022 170

Proceso de Requisitos

Actividades
Planificación Obtención
n Análisis Especificación
n Verificación Validación
n
Artefactos
Documento Documento
Modelo del Especificación
de de de Requisitos
Sistema
Visión Requisitos
Unidad 1 01/06/2022 171

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).
Unidad 1 01/06/2022 172

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
Unidad 1 01/06/2022 173

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
Unidad 1 01/06/2022 174

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).
Unidad 1 01/06/2022 175

Contenido

Unidad 1 01/06/2022 176

Proceso espiral de IR
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
Inicio
Adquisición de Estudio
requerimientos de factibilidad
Validación
del sistema de requerimientos
Adquisición Adquisición
de requerimientos de requerimientos Prototipos
del usuario
Revisiones
Documento
de requerimientos
del sistema
Unidad 1 01/06/2022 177

Contenido

Unidad 1 01/06/2022 178

As is / To be

• Se intenta responder 3 preguntas básicas:
Temas Preguntas a los usuarios

¿Cuáles son las operaciones y procesos
¿Qué haces?
comerciales?
¿Cómo haces aquello?
¿Cómo se deben realizar esas operaciones?
¿Qué pasos sigues?
¿Qué información se necesita para realizar esas ¿Qué información utilizas?
operaciones? ¿Qué formularios o reportes utilizas?
Unidad 1 01/06/2022 179

As is / To be

1. Procesos actuales
2. Procesos futuros
3. Requerimientos
Unidad 1 01/06/2022 180


• 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
Unidad 1 01/06/2022 181

Inscribirse en un curso: situación actual

Estudiante Profesor Registrador

Reg. Form
Seleccionar cursos Reg. Form
Solicitud de revisión
Determinar si el
estudiante cumple
Esperar en la fila, los requisitos previos.
generalmente bajo
la lluvia
¿Inscripciones Determinar si hay

N abiertas? espacio disponible en
las secciones bajo
Y su cargo.
Revisar los formularios
para detectar
Esperar en la fila para N ¿Puede inscribirse? problemas / errores
ser atendido por
el profesor Reg. Form
Y
¿Formulario N
correcto?
Inscribir estudiante,
actualizar formulario
Y
Reg. Form
Y ¿Estudiante necesita Almacenar los datos

otro curso? de registro en el
ordenador
N
Reg. Form
Llevar el formulario
completo
a la mesa del registrador
Unidad 1 01/06/2022 182

As is / To be

2. Procesos futuros
3. Requerimientos
Unidad 1 01/06/2022 183

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.
Unidad 1 01/06/2022 184

Inscribirse en un curso: situación propuesta

Estudiante Sistema

Seleccionar cursos
Sentarse frente a la
computadora. Autenticar usuario
Beber café.
N ¿Inscripciones
abiertas?
Y
Proporcionar nombre
de usuario y contraseña
Comprobar que el estudiante

cumple los prerequisitos
de los cursos
Ingresar los cursos

a inscribirse Consultar disponibilidad
en los paralelos
solicitados
Registrar asignación
¿Se requiere más
Y cursos?
del cupo en la
base de datos
N
Presentar al estudiante
los cursos en los que se
ha podido inscribir.
Unidad 1 01/06/2022 185

As is / To be

2. Procesos futuros
3. Requerimientos
Unidad 1 01/06/2022 186

3. Requerimientos

• Documente los requisitos funcionales y no funcionales
• Ejemplo: Registro de estudiantes (que es parte de un proceso
general: asistir a la universidad): ¿Cuáles son los principales
procesos en el registro de estudiantes?
– Determine los cursos a tomar:
• Basado en programa de estudios, año, requisitos previos, intereses
electivos, etc.
– Inscripción en cursos
– Pago de los cursos
– ¿Otros?
• Se debe determinar: ¿cómo debería funcionar el proceso?
¿Cuáles deberían ser los pasos? ¿Qué información se requiere
para que el proceso funcione de manera eficaz? ¿Qué
información se requiere para respaldar cada paso del proceso?
• Otro ejemplo: inscribirse en un curso
Unidad 1 01/06/2022 187


Unidad 1
Lección 5
Especificación de
requerimientos de
software
Unidad 1 01/06/2022 188

Especificación de requisitos

• Es el proceso de escribir los requisitos de usuario
y del sistema en un documento de requisitos.
• Los requisitos de usuario deben ser entendidos
por los usuarios finales y los clientes que no
tienen formación técnica.
• Los requisitos del sistema son más detallados y
pueden incluir mas información técnica.
• Los requisitos pueden ser parte de un contrato
para el desarrollo del sistema. Por lo tanto, se
debe intentar que sean lo más completos posible.
Unidad 1 01/06/2022 189

Contenido

• Especificación de requerimientos de
software
– Propósito
– Contenido
– Estándares
– Herramientas de soporte
Unidad 1 01/06/2022 190

Propósito

• El objetivo principal de la Especificación
de Requisitos del Sistema (ERS) es
servir como medio de comunicación entre
clientes, usuarios, ingenieros
de requisitos y desarrolladores.
Unidad 1 01/06/2022 191

Contenido

software
– Propósito
– Contenido
– Estándares
Unidad 1 01/06/2022 192

Requerimientos
Definición/Especificación

• Definición de Requerimientos (Primera tarea grupal)
– Una declaración en un Lenguaje Natural incluye los
diagramas de los servicios del sistema y sus límites
operacionales. Escrito para clientes.
• Especificación de Requerimientos (Proyecto parcial)
– Un documento estructurado con descripción o detalle
de los servicios del sistema. Escrito como un
contrato entre el cliente y el contratista.
• Especificación de Software (Proyecto final)
– Descripción detallada de software, la cual, puede
servir como una base para diseño o implementación.
Escrito para desarrolladores.
Unidad 1 01/06/2022 193

Definiciones y Especificaciones

Definición de Requerimientos
1. ElSoftware proporciona significado de representación y acceso a

archivos externos creados por otras herramientas.
Especificación de Requerimientos
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será
aplicada para el archivo.
1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al
usuario.
1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo
externo será definido por el usuario.
1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el
efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo ex-
terno al archivo representado por la selección del icono.
Unidad 1 01/06/2022 194

Definiciones y Especificaciones

Especificación del sistema
1. Definición del problema.
2. Descripción funcional
(lista de requerimientos funcionales)
3. Restricciones
(requerimientos no funcionales)
4. Diagramas de flujo de datos
5. Modelo de datos
(diagrama E/R, CASE*Method o diagrama de clases UML)
6. Diccionario de datos
7. Casos de uso
8. Documentos adicionales
(p.ej. modelos de informes y formularios)
Unidad 1 01/06/2022 195

Lectores de Requerimientos

Gerencia de Cliente
Definición de Usuarios Finales del Sistema
Requerimientos Ingenieros de Clientes
Gerencia de Contratistas
Arquitectos del Sistema
Usuarios Finales del Sistema

Especificación de
Ingenieros de Cliente
Requerimientos
Arquitectos del Sistema
Desarrolladores de Software
Especificación de (Quizá) Ingenieros de Clientes

Software Arquitectos del Sistema
Desarrolladores de Software
Unidad 1 01/06/2022 196

Especificación de requerimientos
en lenguaje natural

• Los requisitos son
escritos en frases en
lenguaje natural.
• Se utiliza para escribir
los requisitos porque es
expresivo, intuitivo y
universal.
• Esto significa que los
requisitos pueden ser
entendidos por los
usuarios y los clientes.
Unidad 1 01/06/2022 197

Especificación en lenguaje natural -

Ejemplo

• 3.2 El sistema debe medir el azúcar en la sangre y
liberar insulina, si es necesario cada 10 minutos. (Los
cambios en el azúcar en la sangre son relativamente
lentos entonces mediciones más frecuentes son
innecesarias; mediciones menos frecuentes podría
llevar a niveles innecesariamente altos de azúcar.)
• 3.6 El sistema debe ejecutar un auto-test de rutina

cada minuto con las condiciones que deben
verificarse y las acciones asociadas definidas en la
Tabla 1. (Una rutina de auto-test puede descubrir
problemas en el hardware y software y alertar al
usuario sobre el hecho de que la operación normal
puede ser imposible.)
Unidad 1 01/06/2022 198

Guía para escribir requisitos

FICHA DE REQUISITO
 Definir plantillas estándares para Proyecto: ___________________________
describir los requisitos. Fecha: __/__/____
Ingeniero de Requisitos: ________________
 Usar un lenguaje simple,
consistente y conciso.
Descripción:__________________________________
 Usar diagramas apropiadamente. ____________________________________________
____________________________________________
 Suplementar el lenguaje natural ____________________________________________
con otras descripciones de
requisitos. Prioridad: Obligatorio Deseado
Tipo: RF RNF: _____________

Sommerville (2002)
Fuente de Información: ________________________
Etapa del Proyecto: ___________________________
Observación: ________________________________________
____________________________________________
Unidad 1 01/06/2022 199


• Crear un formato estándar y usarlo para todos los
requisitos.
• Usar un lenguaje de una manera consistente. El
lenguaje usado para requisitos obligatorios debe ser el
mismo que para requisitos deseables.
• Utilizar texto subrayado para identificar las partes
clave de los requisitos.
• Evitar el uso de jerga informática.
• Incluir una explicación (lógica) de porqué es necesario
un requisito.
Unidad 1 01/06/2022 200


• Al describir requisitos se deben tener en cuenta los siguientes
aspectos:
• Ubicación y Entorno Físicos
– dónde, uno o varios, restricciones ambientales
• Interfaces
– Entrada de 1 o + sistemas, Salida a 1 o + sistemas, restricciones
de formato, soporte
• Usuarios y Factores Humanos
– capacidad de cada tipo de usuario, tipo de entrenamiento,
facilidad de uso, posibilidad de mal uso
• Funcionalidad y Restricciones asociadas
– qué debe hacer, cuándo, modos de operación, cómo y cuándo
se puede modificar el sistema, restricciones de velocidad,
tiempo de respuesta, capacidad de proceso
Unidad 1 01/06/2022 201


• Documentación
– cuánta, formato, para quién
• Datos
– formatos E/S, frecuencia, fuentes, destinos, calidad
requerida, precisión en cálculos, flujo en el sistema
• Recursos
– materiales, personal y otros para construir, usar y
mantener el sistema, habilidades de los desarrolladores,
necesidades de espacio y ambientales, calendario
prescrito, limitaciones en presupuesto
Unidad 1 01/06/2022 202


• Seguridad
– control de acceso a las funciones/datos, aislamiento de los
programas, respaldos-frecuencia, disponibilidad-,
seguridad física
• Aseguramiento de la Calidad
– Confiabilidad – tiempo medio entre fallas, robustez,
tolerancia a fallas
– Disponibilidad - tiempo para estar operativo luego de falla-
mantenimiento estando activo- tiempo máximo de no
disponibilidad
– Mantenibilidad
– Seguridad
– Portabilidad
Unidad 1 01/06/2022 203

• Los requerimientos no funcionales…
– han de especificarse cuantitativamente,
siempre que sea posible (para que se pueda
verificar su cumplimiento).
Unidad 1 01/06/2022 204


• MAL:
– Para facilitar el uso del editor gráfico, se
podrá activar y desactivar una rejilla que
permitirá alinear las figuras del diagrama.
Cuando se ajuste la figura al tamaño de la
pantalla, se reducirá el número de líneas de
la rejilla para que no se dificulte la
visualización del diagrama.
• ¿Por qué?
– Amalgama de varios requisitos.
Unidad 1 01/06/2022 205


• BIEN
– El editor permitirá el uso de una rejilla de
líneas horizontales y verticales que
aparecerán dibujadas tras el diagrama.
Justificación: La rejilla facilita la creación de

diagramas cuidados en los que las figuras se
puedan alinear con facilidad
• ¿Por qué?
– Preciso, conciso y justificado correctamente.
Unidad 1 01/06/2022 206


• MAL
– El sistema será lo más fácil de utilizar posible.
– El sistema proporcionará una respuesta
rápida al usuario.
– El sistema se recuperará automáticamente
tras producirse un fallo.
• ¿Por qué?
– Objetivos generales, vagos y abiertos a
distintas interpretaciones
Unidad 1 01/06/2022 207


• BIEN
– Un usuario experimentado debe ser capaz de utilizar
todas las funciones del sistema tras un entrenamiento
de 2 horas, tras el cual no cometerá más de 3 errores
diarios en media.
– Cuando haya hasta 100 usuarios accediendo
simultáneamente al sistema, su tiempo de respuesta
no será en ningún momento superior a 2 segundos.
– Ante un fallo en el software del sistema, no se tardará
más de 5 minutos en restaurar los datos del sistema
(en un estado válido) y volver a poner en marcha el
sistema.
• ¿Por qué?
– Requisitos verificables.
Unidad 1 01/06/2022 208

Algunas recomendaciones para especificar
requisitos NO funcionales

Propiedad Medida
Transacciones procesadas por segundo
Rapidez Tiempo de respuesta al usuario y a eventos
Tiempo de actualizacion de la pantalla
K Bytes
Tamaño
Numero de chips de RAM
Tiempo de entrenamiento
Facilidad de Uso
Número de pantallas de ayuda
Número promedio entre fallos
Probabilidad de no disponibilidad
Fiabilidad
Tasa de Ocurrencia de fallos
Disponibilidad
Tiempo de reinicio entre fallos
Robustez Porcentaje de eventos que provocan fallos

Probabilidad de corrupcion de los datos
despues de fallos
Porcentaje de declaraciones dependientes de
Portabilidad objetivos
Número de sistemas objetivo
Unidad 1 01/06/2022 209


• Problemas habituales:
– La existencia de un requerimiento ha de estar
debidamente justificada (debemos saber por
qué es un requisito del sistema).
– Un requerimiento es, a veces, difícil de
verificar (especialmente, si es un requisito no
funcional).
– Además, si somos incapaces de especificarlo,
¿cómo sabemos que realmente es un
requisito?
Unidad 1 01/06/2022 210

EJEMPLO: REQUERIMIENTOS FUNCIONALES
Matriculación
• La matrícula será realizada de forma interactiva. Se le preguntará al alumno cuál
es el plan de estudios en que desea matricularse (pueden ser varios).
• Se podrá generar una copia impresa de la matrícula (sin valor oficial) en el
ordenador desde donde se realice el proceso de matriculación.
• Se podrá generar el impreso de pago debidamente cumplimentado.
• Para la matriculación se consultarán los datos del expediente y se realizarán las
validaciones necesarias, descritas a continuación…
• Pago de matrícula:
• La aplicación generará un impreso para que el alumno realice el pago
correspondiente a la matrícula en 1 ó 2 plazos (según las fechas
establecidas).
• Si el alumno tiene matrículas de honor de cursos anteriores o disfruta de
algún tipo de beca, la aplicación deberá calcular automáticamente los
descuentos correspondientes…
Organizados jerárquicamente
20
y desglosados en requisitos individuales
Unidad 1 01/06/2022 211

Interfaces
• Hardware: El sistema se debe implementar sobre la infraestructura existente en
las aulas de prácticas de la E.T.S. Ingeniería Informática.
• Software:
• No existe posibilidad de adquirir licencias de software.
• La aplicación deberá funcionar sobre Oracle.
Unidad 1 01/06/2022 212

Ejemplo: requerimiento funcional
Requerimiento
Número: RF‐1 de usuario

Título: Ingreso de colegiados.
Texto: El sistema debe permitir el ingreso de los datos de los colegiados designados por la Federación
Española de Fútbol.
Tipo: Funcional ‐ Datos
Detalles de El sistema debe permitir el registro de la siguiente información sobre los colegiados:
requisitos y • Nombre. Deberá contener un máximo de 32 caracteres, incluyendo mayúsculas y minúsculas.
restricciones: • Apellido. Deberá contener un máximo de 28 caracteres, incluyendo mayúsculas y minúscula.
• Edad. La edad de los colegiados será únicamente escrita en números.
• Años de Experiencia. Deberá ser escrito solo en números.
• Formación académica. No tendrá un límite de caracteres, contemplará mayúsculas,
minúsculas, números y símbolos.
• Sexo. Indicará si el sexo es femenino o masculino
• Estado de colegiados (habilitado o no habilitado)
• Correo Electrónico. Deberá contener un máximo de 32 caracteres, incluyendo números y
símbolos.
• Usuario. Deberá contener un máximo de 12 caracteres incluyendo minúsculas, mayúsculas,
números y símbolos.
Fecha de revisión 26/12/2020
Especificación del
y versión: Versión1.0
requerimiento (req.
Prioridad: Alta
de sistema)
Unidad 1 01/06/2022 213
Número: RF- 2

Título: Registro de propietarios de vehículos
Texto: El sistema deberá permitir registrar nuevos propietarios de vehículos por parte de la secretaria.
Tipo: Funcional – datos
Detalles de Para registrar nuevos propietarios de vehículos en el sistema se tendrán en cuenta los siguientes parámetros:
requisitos y  Nombre del propietario: Máximo de 20 caracteres alfabéticos. Dato tipo String.
restricciones  Apellido del propietario: Máximo de 20 caracteres alfabéticos. Dato tipo String.
:  Cédula de Identidad del propietario: Máximo de 11 caracteres numéricos. Dato tipo String.
 Número celular del propietario: Máximo de 11 caracteres numéricos. Dato tipo String.
 Número convencional del propietario: Máximo de 8 caracteres numéricos. Dato tipo String.
 Número de placa del coche del propietario. Máximo de 10 caracteres alfanuméricos y especiales. Dato tipo
String.
 Modelo del coche del propietario. Máximo de 30 caracteres alfanuméricos y especiales. Dato tipo String.
 Correo electrónico del propietario. Máximo de 20 caracteres alfanuméricos y especiales. Dato tipo String.
 Tipo de pago. Combo box con 2 opciones.
 Pago domiciliado. Dato tipo String. Máximo 17 caracteres alfabéticos.
 Pago no domiciliado. Dato tipo String. Máximo 20 caracteres alfabéticos
En caso de que el propietario de vehículo tenga domiciliado el pago se agregaran los siguientes datos:
 Nombre de entidad bancaria empleada por el propietario del vehículo. Máximo de 40 caracteres alfabéticos.
Dato tipo String.
 Número de cuenta bancaria. Máximo de 11 caracteres numéricos. Dato tipo String.
Para todos los datos se usará la fuente de texto Arial, tamaño 12.
Fecha de 10/12/2020
revisión y Versión1.0
versión:
Prioridad: Alta
Unidad 1 01/06/2022 214

Ejemplo: requerimiento NO funcional
Requerimiento

de usuario (sin
Número: RNF – 1 jerga técnica)
Título: Tiempo de corrección de fallos inesperados en el sistema.
Texto: Se deben corregir los fallos que surjan en el sistema en un tiempo
máximo de 30 minutos tras el surgimiento del fallo.
Tipo: No funcional – Del producto
Detalles de Ante un fallo en el sistema, no se tardará más de 30 minutos en
requisitos y restablecer el sistema a un estado operacional y volver a poner en
restricciones: marcha el sistema.
Fecha de 9/12/2020 Requerimiento de
revisión y Versión1.0 sistema (con jerga
versión: técnica)
Prioridad: Alta
Unidad 1 01/06/2022 215


Número: RNF – 2
Título: Facilidad de uso del sistema.
Texto: Un usuario del sistema no debe cometer más de tres errores diarios
en media.
Tipo: No funcional – Del producto
Detalles de Un usuario experimentado debe ser capaz de utilizar todas las
requisitos y funciones del sistema tras un entrenamiento de 2 horas, tras el cual
restricciones: no cometerá más de 3 errores diarios en media
Fecha de 9/12/2020
versión:
Prioridad: Alta
Unidad 1 01/06/2022 216

Contenido

software
– Propósito
– Contenido
– Estándares
Unidad 1 01/06/2022 217

Estándares

Unidad 1 01/06/2022 218
Estándar ANSI IEEE 830-1998

• 1. Introducción – Funciones del producto
– Propósito. – Características del usuario
– Alcance – Restricciones
– Definiciones acrónimos y – Suposiciones y
abreviaturas dependencias
– Referencias – Distribución de requisitos
– Panorama • 3. Requisitos específicos
• 2. Descripción general (Se desarrollará mas adelante)
– Perspectiva del • 4. Información de apoyo.
producto:(Interfaces del
sistema, del usuario,
hardware, software, de
comunicación, restricciones
de memoria, operaciones,
requisitos de adaptación)
Unidad 1 01/06/2022 219

Contenido

software
– Propósito
– Contenido
– Estándares
Unidad 1 01/06/2022 220

Definición

• Ingeniería de Software Asistida por Computadora
• Conjunto de herramientas y métodos asociados
que proporcionan asistencia automatizada en el
proceso de desarrollo del software a lo largo de
su ciclo de vida.
– En la gestión del proyecto
(planificación, estimación y control)
– En el desarrollo del software
(análisis, diseño, implementación, validación)
– En el mantenimiento del software.
Unidad 1 01/06/2022 221

Objetivo

• Automatizar las actividades de gestión de
proyectos y mejorar la visión de la ingeniería
• Ayudar en el análisis, diseño y codificación
• Garantizar que la calidad se diseñe antes de
llegar a construir el producto.
• Incrementar la reusabilidad del software.
• Reducir costes de desarrollo y
mantenimiento.
Unidad 1 01/06/2022 222

Características deseables

• Soporte gráfico para varias técnicas (DFD,
DER, modelos OO, etc.)
• Control de errores, unicidad de
identificadores, reglas, metodología, etc.
• Control de documentos y versiones.
• Métricas del software.
• Simulación y prototipado.
• Generación de código.
• Verificación entre diferentes modelos
Unidad 1 01/06/2022 223

Gestión de requisitos software

• Las herramientas CASE facilitan:
– El almacenamiento de requisitos.
– La gestión del cambio.
– La gestión de la traza.
Unidad 1 01/06/2022 224

Herramientas CASE

•Dibujar Diagramas
•Actúan como repositorio
•Ayudan a la navegación
•Soporte Multiusuario
•Genéran código
•Ingeniería Reversa
•Integración con otras
herramientas
Unidad 1 01/06/2022 225

Categorías CASE

PLANIFICACIÓN DIMENSIONAMIENTO
HERRAMIENTAS
DE GESTIÓN SEGUIMIENTO
ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEBA MANTENIMIENTO
HERRAMIENTAS CASE CASE GENERADORES DE HERR. DE HERRAMIENT. DE

TÉCNICAS FRONTAL DORSAL CÓDIGO PRUEBA MANTENIMIENTO
CASE INTEGRADO y LENGUAJES DE 4ª GENERACIÓN
SISTEMA DE REPOSITORIO / DICCIONARIO

HERRAMIENTAS
DE SOPORTE CONTROL DE CONFIGURACIÓN SERVICIOS DE SEGURIDAD
Unidad 1 01/06/2022 226

Componentes de un CASE

INTERFAZ DE USUARIO
Repositorio Metamodelo
HERRAMIENTAS
GENERADOR DE DE CARGA Y
INFORMES DESCARGA DE
DATOS
FACILIDADES DE INTEGRACION
Unidad 1 01/06/2022 227

Unidad 1
01/06/2022
228
Carrera de Software

Unidad 1
01/06/2022
229
Carrera de Software

Unidad 1
01/06/2022
230
Carrera de Software


Unidad 1
Introducción y proceso de
Final de la unidad
Unidad 1 01/06/2022 231
Número: F1
Título: Chequear los requisitos previos del curso

Texto: Describe la lógica que se debe implementar para garantizar que los estudiantes tengan los requisitos previos
adecuados para tomar un curso determinado.
Tipo: Funcional - Procesamiento
Detalles de La Universidad tiene un conjunto de reglas que determinan si un estudiante es elegible para tomar una clase
requisitos y determinada. Una regla es que para tomar una clase, a veces se requiere que los estudiantes tomen otras clases que
restricciones:
les brinden la base necesaria para la clase. Estas reglas deben hacerse cumplir durante el proceso de inscripción del
estudiante. Los prerrequisitos específicos a implementar para cada curso se pueden encontrar en el calendario de la
Universidad.
Durante el proceso de inscripción, el sistema deberá:

•Recuperar el curso al que desea matricularse el alumno
•Recuperar el historial de finalización de cursos de los estudiantes para determinar los cursos tomados y completados
con éxito por el estudiante
•Recuperar los requisitos previos para el curso deseado
•Determinar si el alumno tiene los requisitos previos adecuados para el curso.
•Si el estudiante tiene los requisitos previos requeridos:
• Marcar el curso como correcto, permitirá que el curso avance al siguiente paso del proceso (verificación de la
inscripción)
•Si el estudiante no tiene los cursos previos adecuados:
• Recuperar información de anulación
• Determinar si el instructor ha dado permiso al estudiante (mediante anulación) para inscribirse en el curso.
• Si es así, permitir que el curso se mueva para verificar el paso de inscripción
• Si la respuesta es no, finalizar indicando en un mensaje al estudiante que la inscripción no está permitida.
Fecha de 2/5/2020
revisión y Version1.0
versión:
Prioridad: Alta
Unidad 1 01/06/2022 232

Número: F2
Título: Ingresar cursos
Texto: Describe los datos requeridos del curso a ser ingresados al sistema
Tipo: Funcional - Datos
Detalles de Un curso es una oferta educativa de la Universidad. El sistema debe mantener la siguiente
requisitos y información sobre los cursos:
restricciones:
•Título del curso (Ejemplo: SOF-3-IDR), String, 10 caracteres
•Descripción del curso, String, 25 caracteres
•Programa de estudios. Cada curso está asignado a un programa determinado (por ejemplo, biología,
sistemas de información, administración de empresas)
•Secciones. Una sección se define como una "instancia" de un curso asignado a un instructor, un
intervalo de tiempo (por ejemplo, "J") y un aula y un límite de inscripción (por ejemplo, 50
estudiantes). El sistema debe permitir que se enseñen varias secciones de un curso.
•Prerrequisitos. Un prerrequisito es otro curso que un estudiante debe tomar para ser elegible para un
curso determinado. Cada curso puede tener cero, uno o muchos requisitos previos
•Etc ………….
Fecha de 2/5/2020
versión:
Prioridad: Alta
Unidad 1 01/06/2022 233

Ejemplo: requerimiento técnico

Número: T1
Título: Requisitos del servicio de inscripción
Texto: Describe los requisitos de servicio técnico que se deben colocar en el sistema en términos
de número de usuarios concurrentes y ubicación de usuarios.
Tipo: Técnico
Detalles de •El proceso de inscripción de estudiantes debe permitir que 100 estudiantes se inscriban al
requisitos y mismo tiempo.
restricciones:
•El sistema debe apoyar a los estudiantes que se inscriben localmente (en los laboratorios
de computación de la universidad) así como de forma remota (por ejemplo, desde los
dormitorios en el campus o desde sus hogares).
•El sistema debe admitir "bloquear" el proceso de inscripción en ubicaciones específicas
durante los períodos pico de inscripción. Por ejemplo, el sistema debe permitir el acceso
solo desde computadoras específicas del laboratorio de computación durante el período de
registro de estudiantes de primer año
Fecha de 2/5/2020
revisión y Version1.0
versión:
Prioridad: Alta
Unidad 1 01/06/2022 234


Número: RNF1
Título: Respaldo de la base de datos
Texto: Describe la política de respaldos de la base de datos
Tipo: Funcional - Datos
Detalles de El sistema debe respetar los siguientes aspectos:
requisitos y •El respaldo de la base de datos debe tener lugar a las 01h00 y tendrá una duración máxima de 45
restricciones:
minutos.
•El sistema debe garantizar el acceso a los datos respaldados en unidades externas….
•La base de datos deberá estar mirrorizada con RAID 5
•…
•Etc ………….
Fecha de 2/5/2020
versión:
Prioridad: Alta
Unidad 1 01/06/2022 235

All FRPB Idr Capítulo1

Cargado por

Copyright:

Formatos disponibles

All FRPB Idr Capítulo1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

All FRPB Idr Capítulo1

Cargado por

Copyright:

Formatos disponibles

Ingeniería de requerimientos Carrera de Software

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Objetivo general de la Unidad 1

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

n Los requisitos no funcionales

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

• Es el público de interés para una

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

*Referencia: capítulo 7 libro de texto (Pressman 2005)

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Línea base corregida

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

• En esta parte, los ingenieros de software realizan

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Requisitos vs. Diseño

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

• El Diseño define el Cómo (la solución)

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Costos de errores en los requisitos

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Tipos de requisitos - Abstracción

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Tipos de requisitos - Abstracción

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

Requerimientos Usuarios finales del sistema